by Brian Adler @ RightScale
2012の終わりを迎えるにあたり、今一度クラウドコンピューティングを運用する上で重要な要件を整理していきたい。
次の９つのポイントは、来年2013年に向けてクラウドの運用をより効率よく行うためのアドバイスです。
１）インスタンスサイズと数についてはよくテストを行ってから決める事
- どのクラウドもCPU、メモリ、ディスクがそれぞれ異なる複数のサーバサイズを提供する。まず、各社どのようなレンジのサーバ規模を持っているのかをしっかり調べましょう。
- 各サイズに対して、負荷テストを行い、自分のアプリケーションにとって最も的確なサイズのものを選ぶようにしましょう。アプリがCPUを多く必要とするがメモリはあまり使わない、という事であればマルチコアCPUのサーバインスタンスを選ぶようにしましょう。
- データベースに関しては、一般的にデータベース全体がメモリ上に乗るようにする事が勧められます。データベースサーバに関してはいろいろとハイメモリ型のサーバの種類があるはずです。
- RightScaleは、PlanForCloudと呼ばれるツールを提供しており、アプリケーションのクラウド上での運用に関してコストを最適化するためのサービスを提供しています。例えば、On-Demand型か、Reserved Instance型等の価格体系の比較もしてくれます。
２）サーバ障害は起こるもの、と想定してシステム設計する
- 自動スケーリング機能を設定して、トラフィックの急増等のシステム負荷やシステム障害に対して動的に対応出来るようにしましょう。例えば、まずは再手減のサーバアレイの規模（台数）を設定し、どんな状態でも必ず必要最低限の数のサーバが稼働している様、保証しましょう。RightScaleの機能を利用して、サーバアレイの自動的なプロビジョニング／デプロビジョニングをかなり詳細までカスタマイズする事が出来ます。カスタマイズはスクリプトを通してプログラミングする事が出来、サーバの動的な操作に加えて、サーバの動的な監視、アラートの発信、バッチ処理のキュー管理、等の機能がサポートされています。機能の詳細は、RightScaleのクラウド管理自動化機能を参照ください。
- データベースは、複数のゾーン(AZ)やクラウド事業者間で複製を作り、単一のゾーンやクラウドでの障害の影響を受けないように設計します。システム性能への影響も懸念として出てきますが、クラウド上での運用は、ユーザが冗長性設計をする事が必須事項となってきてます。
- データベース等、IPが時と共に変更を要する内部コンポーネントについては、動的なDNSを採用しましょう。逆にユーザが直接アクセスするアプリケーションの入り口部分については固定IPを設定しましょう。
３）ゾーン障害に備える
- アプリケーションの各Tier毎に、２つ以上のゾーンにサーバを分散させましょう。クラウド障害時の被害を最小限に抑えるための配慮です。
- すべてのデータ（データベースに加え、共有ファイルシステムも含めて）を複数ゾーン間で多重化しましょう。
４）クラウド障害に備える
- 同じクラウド事業者の異なるソーンのみならず、異なるリージョン間でもデータのバックアップや同期を取りましょう。リージョン全体が障害を起こすケースも起きており、そういう事態に対して、別のリージョンで待機させているデータをデータ回復に活用する事が出来ます。
５）とにかく自動化
- データベース／データストアの別リージョン／クラウドへの定期的なバックアップを自動化しましょう。特定のリージョンで障害が起きた時でも、アプリケーション回復が非常に楽になります。
- 常にシステムの状態を監視し、自動的にアラートを発信、問題が小さい内に対策が打てるようにしましょう。RightScaleはこの監視を自動化するためのツールを多く備えています。
６）とにかくキャッシュする事
- まず殆どのアプリケーションは、キャッシングを活用する事で性能を向上させる事が出来ます。また、Webフロントアプリの部分にしろ、バックエンドのデータベースシステムにしろ、同様です。
- アプリケーションサーバに内蔵されているキャッシュは使わない事。内蔵型のキャッシュは、データベースの一部をアプリケーション上で管理する形で行われますが、アプリケーションサーバを複数使用する際、またアプリケーションサーバを動的に増減させる場合も、結果的にデータベースサーバに対するこのアプリケーションサーバからのキャッシュ関連のアクセスが急増し、システム性能の大幅な低下に直結します。
- 独立したマルチノード型のキャッシュシステムを採用しましょう。大量メモリのサーバを一台を用意し、キャッシュ専用マシンに設定する事も可能ですが、このマシンが障害に会った時、すべてのキャッシュが落ちない様にするための配慮が必要ですので、そのための多重化対応です。
- もう一つ、アプリケーションサーバに内蔵されたキャッシュのソリューションの問題は、アプリケーションサーバにオートスケーリングが適用出来なくなるからです。新規のアプリサーバを立ち上げる度に、キャッシュ全体の設定が変わり、キャッシュ間で大量のデータが移動する結果になります。これはシステム性能を大幅に下げる要因になり、勧められません。独立したキャッシングシステムを容易に構築する技術を持っているベンダーが数社存在します。特にキャッシュの動的なオートスケーリングは、CouchBase等のベンダーがソリューションを提供してます。
７）同期を取る事
- データは、他のゾーンに同期を確保しておきましょう。特定のゾーンでの障害時、そこにマスター、スレーブのいずれかがあったとしてもシステムのダウンタイムは最小限に抑える事が出来ます。
- 合わせて、他のクラウド／リージョンにもデータの同期を取っておきましょう。大規模な障害が起きた際に、影響を受ける心配の無い場所にデータのバックアップを確保する安心感は大です。
- 可能であれば、さらにスレーブとして、Ephermalディスク（EC2等でついてくるメモリ）上に一つ設定する事を勧めます。AWSの障害の内、EBSが原因によるものも多く、EBSへの依存度を少しでも下げるためにもこの対策は必要である、と言えます。
８）意外なところで起きる障害要因を早期発見する
- もしアプリケーションコードがGitやSVNレポジトリで管理されている場合、このレポジトリの稼働状態がアプリケーション全体の稼働状態に影響を及ぼします。RightScaleを通して自動化やインフラストレクチャのデザインはしっかり設計し、障害への対応もしっかりしていても、アプリケーションサーバが動的にコードを入手する事が出来なければ、そこが重要な障害要因になります。
９）クラウドロックインに注意
- ベンダー特定の運用ツールやアプライアンスは、一時的にアプリケーションの運用効率を向上する事が可能になりますが、同じベンダーの提供する他のツールとの連携も強いケースが多いために、障害発生時にも想定以上の問題が発生する可能性が高くなります。クラウドベンダーに依存しないツールを利用する事により、特定のクラウドプラットホームに縛られない、クラウド依存度の無いアプリケーション運用が可能になり、結果的に障害対応に強いシステム運用が可能になるはずです。マルチクラウドもメリットは特定のクラウドの障害に対応するソリューションになるだけではなく、コストの最適化にも寄与します（より安いクラウドへの移行が可能になります）。
上記のソリューションをより詳しく記載したWhite Paperは次のリンクからダウンロード出来ます。
