COLUMN

AWSへ移行して良かった7つのこと

NTT東日本でクラウドサービスを担当しております。パブリッククラウドおよびクラウドゲートウェイの技術検証、営業支援、提案書の作成をメインで担当しております。
昨今、「クラウドがすごく便利」、「これからはクラウドコンピューティングの時代」など、クラウド推しの文言を至るところで見かけますが、私自身が実際にオンプレミスのシステムをクラウドに移行した際に感じた数々のメリットを書いてみます。

1.ハードウェアの購入が不要

よくあるプロジェクトの遅延理由として、いつまでたってもハードウェアが納品されず、開発や構築フェーズに移れないということがあります。ハードウェアの選定、社内予算の制約や検収方法の確認など理由はたくさんあるのですが、完了日が決まっているプロジェクトで機材がいつまでも届かないという事態で実質的な開発期間が短くなり開発者が悲鳴を上げるなんてことが少なくありません。

AWSを利用するとハードウェアの購入の工程の大部分を省けるため、アカウント発行し、すぐに構築や開発フェーズに入ることができました。

ただし、稀に社内で実運用に利用するためのAWSのアカウントの発行手続きが遅れることはあります。その場合でも、先に自社の開発用アカウントでVPCを作成して構築・開発作業を進めておき、後に正式なアカウントが発行された際に先に開発用アカウントで行っていた手順をトレースすることで簡単に同じ環境を再現したり、構築したサーバのAMIを新規アカウントに引き渡したりできましたので、大きな問題にはなりませんでした。

2.キッティング作業をやらなくて良い

オンプレミスの場合には、サーバが納品されてもすぐに使えるわけではありません。届いたサーバを開発室に運んで付属品などの検品や型番のチェックなど注文とおりのものが届いているか、仮組みして通電させてサーバハードウェアに問題がないことを確認する必要があります。

タイミングはプロジェクトによりますが、仮組みしたサーバに問題がなければ、データセンターやサーバ室のラックに取り付け、LANケーブルの引き込みや指定ポートへの差込みを行います。その際、ラックとマウントキットの形状が合わなかったり、ケーブル同士が干渉してうまく設置できなかったりすることもあります。機器の取り付けとケーブリング作業の後は、冗長電源の入力系統の確認とテスト、ネットワーク系の疎通確認などの作業を行います。機器の設置と前後して、ネットワークチームの担当者がスイッチの空きポート確認やVLANの変更など、ネットワーク機器の設計や設定変更も並行して行われています。

データセンターやサーバ室の建物が開発室から離れている場合には台車とタクシーを使ったり、専門の業者に運搬をお願いしたりする場合もありますので、運搬の見積もりや支払いも必要です。業務用の機器は非常に高価ですので運搬中の事故に備え保険もかける場合があります。また、敷地・ビル・データセンターへの入場・入館申請なども必要となります。データセンターやサーバ室でのキッティング作業が終わった後も、ダンボールや梱包資材などの廃棄、付属品の整理などに追われます。また、サーバの利用が終了した際には、取り外しや廃棄の手続きが必要となります。

一方クラウドの場合では、ウェブブラウザを起動して管理コンソールからマウスでいくつかクリックするだけで、これらの作業が終わってしまいます。すぐにサーバを使用することができますので、「クラウドを利用すればビジネスの速度が加速する」を実体験として強く感じました。また、購入設置を伴わないため、廃棄の作業も必要がありません。

3.お客様の間違いにもすぐに対応できた

アクシデント発生時に、意図せずクラウドの強みを実体験できたことがあります。

あるパッケージ製品を動作させる基盤としてRHEL6系が必須でRHEL7系は未対応であることが、仕様書・設計書がFixし構築作業がすでに進んでいる段階で判明しました。

オンプレミスでこのような基盤の選定ミスが発生した場合には、OSの調達からやり直したり、再度データセンターに出向き、OSの再インストールやライセンス認証などを行ったりする必要があります。最近は問題となることが少なくなりましたが、ドライバが未対応でデバイスが正常動作しないなどの問題が発生する場合もあります。また、OSインストール後に、再度ネットワークの疎通確認なども行うのですが、これらの作業を丁寧に行うと、どうしても工程の遅延が発生してしまいます。併せて、入館の再申請手続きや、データセンターが遠方の場合には新幹線・タクシーチケット・ホテルの手配など、付随する事務処理も膨らむ場合があります。

今回はAWSで構築を進めていましたので、管理コンソールからRHEL7で構築したインスタンスについて、AMIと呼ばれるバックアップデータを作成した後にインスタンスを削除し、同じサブネットに同じIPアドレスでRHEL6のインスタンスをデプロイするという作業のみで対応が完了しました。パラメータなどの間違いがないようゆっくり行いましたが、作業に要した時間は15分くらいだったと記憶しています。

OSの変更の必要性が判明してからRHEL6のインスタンスを利用できるようになるまでわずかな時間でしたので、その後、RHEL7向けに作られた作業手順書をRHEL6系のコマンド、設定ファイルなどに書き換え、インスタンスの再構築を行う作業も行いましたが、当日中には作業が完了し、後続のタスクへ進むことができました。

4.簡単に海外サイトを構築できた

昨今、地震などの災害や停電などに備え、遠隔地にバックアップサイトを用意し、災害による顧客影響や機会損失、業務の中断などを最小限に抑えるような仕組みを用意する仕組みとして事業継続計画(*1)や災害復旧(*2)の重要性が広く知られるようになりました。

先述の通り、インフラ基盤の設計や構築には大変な手間がかかりますが、これを国内の遠隔地や国外で行う場合には、現地データセンターとの契約の他、出張作業、現地スタッフや通訳の手配、法律関係の調査などなどさらに膨大な追加の時間と費用と工数が発生します。

AWSやAzureなどのクラウドでは、これらの面倒なIT基盤構築の土台となるインフラ(土地・建物・電力・回線・人材・運用体制など)をすでに世界中に整備してあり簡単に利用できるように提供されていますので、簡単に海外サイトを構築・開始することが可能です。

AWSの場合では、ウェブブラウザを立ち上げて管理コンソールからリージョンと呼ばれる国・地域を選択、そこに日本国内(東京リージョン)で構築した手順と同じようにネットワークやインスタンスを設置していくことで、海外サイトも素早く立ち上げることができました。

日本国内のバックアップサイトとして利用するもよし、海外向けのサービスや現地向け物販をやるもよし、今までは大変な手間と時間と費用がかかったITサービスやIT基盤の海外展開が敏速に行えます。

5.データのバックアップも楽にできた

構築したサーバは日々データが更新されていきますので、バックアップを取る運用が必要になります。

これまではバックアップと言えばテープ媒体やNASなどに蓄積していましたが、テープは媒体の交換なども必要ですし、書き込み回数に制限があるため、媒体自体の寿命管理などの運用オペレーションや実務を行うオペレータ人員が必要でした。また、プロジェクトごとにバックアップ機能を提供するソフトウェアが異なり、バックアップソフトの使い方を調べたり、ソフト別の作業手順書を作成したり、テスト仕様書を作り直したりといった手間もありました。

AWSの場合には、管理コンソールから簡単なマウス操作でバックアップイメージ(AMI)を作成することでバックアップとして蓄積することができました。

また、AWS-cli(コマンドラインインターフェース)やSDK(開発キット)が公開されていますので、これらを利用すればジョブを作成し、定時実行や定期削除などバックアップデータ管理の無人化・自動化も可能となります。

なお、バックアップイメージはS3と呼ばれるオブジェクトストレージに保管されますが、東京リージョンの場合、都内三箇所のデータセンターに冗長に保管されます。ユーザー側では媒体の管理や交換、故障したストレージの修理・交換など面倒な作業は必要がありませんし、メンテナンス作業はすべてAWS側で行ってくれますのでとても楽になります。

さらにすごいのは、クラウドのデータセンター同士は高品質な専用線で結ばれていますので、簡単なコマンドの投入により、日本国内で取得したバックアップデータを海外のデータセンターに複製することも可能です。

6.パッチ適用や修正を安全に行うことができるようになった

クラウドサービスでサーバは仮想マシンとして提供されていますので、Hyper-Vやvmwareなどの仮想化基盤で培った運用テクニックはそのままAWSなどクラウド上でも活用することができます。

例えば、修正パッチ適用前にサーバのバックアップイメージを取得、このイメージからテスト用インスタンスをデプロイし、パッチを適用。テスト用インスタンスでテストを実施し、問題がないことを確認してから本番環境へ適用するといった手順ですが、クラウドでもこれら仮想化基盤で培ったノウハウをそのまま持ち込むことが可能です。

7.故障修理対応や法定停電から開放された

自前でサーバを保有し運用する場合、故障時の修理対応などで、エンジニアの入館申請と修理立会いなどが必要でした。故障するのは、IT機器に限らず、エアコン、サーキュレーター、入退室管理システムなど周辺システムの故障や保守も必要となります。故障時以外にも、法定点検による停電などIT機器やサービスとしての対応も必要で、泊り込みによる対応などがエンジニアの負担にもなっていました。

クラウドに移行してからは、これらの作業から開放されずいぶんと楽になったなと感じます。時間的な余裕ができたおかげでドキュメントの更新など後回しになっていた作業にも着手できるようになったのはクラウド移行の大きなメリットでした。