はじめに
「クラウド」というキーワードが浸透し始めて数年、システムインフラのクラウド化の流れは暫く止む気配がありません。弊社でも特に東日本大震災を契機にWeb、メール、ファイルサーバ類をほぼ移設しました。24時間冷房を効かせたオフィス内のサーバルームの管理は遠い昔のことのようです。
もちろん弊社のクライアントにおいてもこの流れは変わりません。そこで、比較的大規模なシステムにてオンプレミスからクラウドへ移設した事例をひとつご紹介します。
AWS化のきっかけ
かつてiDCに設置した設備は4ラックにぎっしり詰まったラックサーバやブレードサーバ、ネットワーク機器など幅3m×高さ2m×奥行き1mの壮観な機械の壁のようでした。故障と交換を繰り返しつつも24h体制の監視と保守で運用してきましたが、ハードウェアの保守期限や部品の供給期限が迫る中、これを契機に運用の諸問題の解決を図るべく、新たなインフラとしてAWS (Amazon Web Services) への移設を決断しました。
対象システム
24h365dで稼働するインターネット上のコンテンツ配信サービス、1000万以上のユーザを数え、複雑な決済コントロールを持つ難解なシステムです。インターネットのサービサーらしく、コンテンツの2次利用や他サービスとの相乗効果を狙った多数の亜流システムを抱えています。
移設方針
できればこの4ラック全てを綺麗さっぱりクラウドへ移設したかったのですが、システムの性質上どうしても1ラック十数台のサーバ＋ネットワーク機器は地上に残し、残る三十数台のサーバを含むシステムを雲上へ上げることにしました。当面はオンプレとクラウドのハイブリッドシステムを目指します。
完全移設は次のフェーズにて実現する予定です。
移設においてもっとも悩ましいのはシステムの心臓部であるデータベース。この難しい移植手術を成功させるため、以下の方針にて作業を進めました。
1) 各種AWSインスタンス、ネットワークの構築
2) データベースを利用しない独立したアプリケーションの移設
3) 地上に残るシステムと雲上のデータベース間のアクセスのAPI化
4) システムのクラウドへの移設
5) データベースの移設
6) システムの切り替え
7) DNSの移設
1)AWSで利用したコンポーネントはVPC、EC2、EBS、S3、RDS、Route53、CloudFront、CloudWatch、ELB。
もっと最適な構成にするため他のコンポーネントも駆使したかったのですが、今回は時間とコストの兼ね合いであまり構成を変えずに移設しました。
3)はこれも諸事情によりAWSとオンプレ間にVPNが引けなかったため苦渋のアプリ改造です。状況が許すならばAmazon VPNを使って地上との架け橋を立てるのが得策でしょう。
5)は既存のクラスタ構成のOracleからRDSへとデータ移行を行いました。
7)はBINDからR53への切り替えです。最初に行っても良かったのですが、全体のAWSの動作を確認してから移設へ踏み切りました。
移設作業
上記作業を構築とテストを行いつつ要した期間は3ヶ月。細々とした問題にはぶつかりましたが、ほぼ予定通りの工程で作業が進みました。
1)のインフラ構築がWebブラウザからAWSコンソールを使って瞬時に作れてしまうのが工期短縮の大きな要因です。クラウド時代においてはインフラ構築もソフトウェアエンジニアのタスクとなります。
クラウド化のメリット
クラウドへの移行を完遂し、予期してはいたものの実感した効果を記しておきます。
- ハードウェアの資産管理、保守期限、部品の供給期限の管理からの解放
- ハードウェア障害に関わる交換作業からの解放
- オンプレで最も頻度の高いストレージ障害への考慮からの解放
- セキュリティホールが後を絶たないミドルウェアの自動アップデート
- 複雑な設計が必要なクラスタ構成のシンプル化
- 新規サービス企画時のインフラ余力の調査の不要
- インフラの気軽な追加、スケールアウト、廃棄
- AWSコンソールによる簡単、スピーディーなインフラ再編
日々システム運用に関わるエンジニア視点では、ディスク障害が発生しない（していても隠蔽されてシステムに影響がない）ことは大きな恩恵です。ハードウェア障害の大半はディスク障害に起因し、特にデータベースに絡む障害時の対応は緻密を極めます。
また、DNS（BIND）のセキュリティーホールのような甚大な影響を及ぼしかねないミドルウェアをAWSコンポーネント化することによる保守の移譲は保守コスト低減に大いに役立ちます。
障害対応やシステムアップデートに割く時間を前向きな活動に利用することができるでしょう。
AWSの注意点
メリットばかりのAWSですが、根本はインテリジェンスな機器の集合体に変わりはありません。頻度は非常に少ないですが、AWSインスタンスがハングアップし、コンソールからのForce Rebootができなくなることも起こり得ます。こんな時はAWSのサポートに連絡し即復旧してもらいましょう。
このようなAWS内部での障害の可能性もありますので、CloudWatchを使った監視や、AWSインスタンス外部からの監視も導入することをお勧めします。ご紹介したシステムでも外部の監視サービスを利用し、障害発生時には即携帯にメールが届くよう配慮しています。
最後に
以上述べたように、シンプルなクラウド化でも大きなメリットを享受できます。
クラウド化は目的ではなく、クラウド化した後のシステムの拡張性を獲得し、新たなビジネス、サービスを展開するための基盤整理と捉えるのが妥当でしょう。
クラウド化を検討しつつもまだその一歩を踏み出せていない方へ、少しでも勇気と行動のきっかけを提供できれば幸いです。