クラウド上でのHigh Availabilityを実現するための4つのステップ。いずれもクラウド運用のベストプラクティスとしては重要な要件だと思います。

クラウド上で可用性の高いアプリケーション環境を構築するのは一見、難しい作業の様に思えますが、重要なポイントは、クラウド上のコンポーネント全てに障害が起きうる、という事を認識しそれに対応した障害対策や自動化の対策を講じる、という意外と地味な作業を行う事です。

6月11～14日に予定している、RightScale User Conferenceにおいては、このHA (High Availability)とDR (Disaster Recovery)が重要なテーマとして様々なセッションが予定されています。多くの企業がこの課題に対して取組んでいる、という実情を反映している事からこのテーマを採用しているわけですが、RightScaleが取組んでいる "HA in the Cloud" に向けた4つのステップについて、下記の通り簡単に説明したいと思います。

1. Build for server failure
サーバの障害は必ず起きるという前提でシステム構築をする
クラウド上のインスタンスは、データセンタにあるサーバと同様のレベルのサポートが必要です。特にサーバの障害に対する対応策の設計は大事です。サーバ障害への対処の第１ステップは任意のサーバ／サービスのリブートに影響を受けない様な環境で動かす事です。下記の点への着目が必要です。
自動スケーリングを設定し、様々なトラフィックの増減のパターンに対して対応出来る様な設計にする。
データベースのミラー、マスター／スレーブ環境等を設定し、データの保全性を確保しダウンタイムを最小限に留める。
ダイナミックDNSや、固定IPを利用し、アプリケーションが利用するインフラのコンポーネントが常に同期している事を保証する。

2. Build for zone failure
クラウドゾーンも必ず障害が起きる、という前提でシステムを構築する
サーバ単位で障害が発生するばかりではない。停電、ネットワーク障害、落雷による電力系統の障害、等さまざまである。こういった複数のサーバ群を対象とした障害に対する対処もアプリケーションとしては必要になってくる。AWSのAvailability Zoneの様に、こういた地域単位の障害に対する保全性、耐久性を確保したサーバ群の単位をゾーン（Zone）と呼び、複数のゾーンにまたがった次の様なアプリケーションの実装が必要になってきます。
少なくとも2つのゾーンに対してアプリケーションが稼働するサーバ群を配置する。
ゾーン間でのデータの同期を行う。通常の範囲でのデータ同期は定額で行う方法がある。

3. Build for cloud failure
クラウド自体もも必ず障害が起きる、という前提でシステムを構築する
稀なケースで、一つの地域（リージョン）に配置される複数のゾーンが同時に障害を起こすケースもあります。2011年、4月に起きた、AWSのサービス障害がその一例です。ここでいう「リージョン」とは、個別のAPIをもつ独立したシステムリソースの事を指し、RightScaleが定義するクラウドの単位でもあります。
可用性（Availability）を限りなく100％に近くする為には、このリージョン（クラウド）単位での障害にも対応出来るためのプロセスを考慮する必要があります。しかし、クラウド間でシステムを構築する際にはいくつかの難しい課題に直面します。API、システム構成等、インタフェースの違い等がまず問題になり、これに対しては、アプリケーションとしては特定のクラウドAPIにとらわれない、汎用的なインターフェースを採用するコンセプトに基づいて構築される必要があります。
RightScaleの提供するクラウド管理システムはこういったクラウド間の違いを吸収し、開発者、システム運用管理者に対して、障害対応力に極めて強い、標準コンポーネントによって構成されるアプリケーション設計戦略を構築するのに大きな効果を発揮します。特定のベンダーが提供する複数のリージョン間にに搭載されるアプリケーションの実装ではなく、ベンダーにも限定されない複数のインフラ提供者にまたがった、次の様なアプリケーションの運用が非常に容易になります。
データのバックアップを複数のリージョンやIaaSプロバイダ間で行う。プロバイダ間のデータの転送はインターネット上で行われるので、特にデータセキュリティの保全が重要になります。
障害時の補完用のインスタンスを別リージョン／クラウドに配置することにより、ゾーンやクラウド上の障害に対するキャパシティ設計を行う。
いっぺんに大規模なクラウド間システムを構築するのでは無く、段階をもってシステムの障害対応戦略を拡張していく（複数ゾーン対応から複数クラウド対応へ）

4. Automate and test everything
全ての管理工数を自動化し、テストを行ってから実装する
システムの構成を順次サーバ障害、ゾーン障害、クラウド障害へ対応出来る様構築していくにつれ、障害に対する対策手順を自動化していく事が次のステップになります。クラウド管理ステムは、上記の様な複数サーバ、ゾーン、クラウドの単位それぞれに対して、障害対策手順を設計し、運用／管理出来る様な機能を提供します。障害時は大抵時間との戦いになるケースが多く、手順を自動化する事は非常に重要、且つ有効なソリューションになる事は自明で、次の様な対策が勧められる。
全てのステージに於けるデータのバックアップを自動化し、障害発生時にはデータの保全性を確保する様に設計します。
常に、システムを監視し、有事の際にアラートが発生する様にシステムをセットアップし、問題が発生した時にどこでどのような問題が起きたのかを迅速に検知出来る様な仕組みを構築する。クラウドプロバイダーからの連絡を待つ方法では、情報伝達が遅い上、精度に欠けるケースが多いのが現状です。（4月のAWS障害時はその問題がよく話題に上がっている）
障害対策プランは、実際にテストをする事によって初めて有効である、と判断出来る。クラウド上でのテストは従来のOn Premise上でのシステムと比較して非常に安くテストを行う事が可能になっている。特に過負荷テスト、障害のシミュレーション等は、RightScaleのコンソールを通して構造的な方法をもって行うことが出来ます。
クラウドのインフラは、DR(Disaster Recovery)やHA(High Availability)のシステム設計を非常に安く、そして確実に導入する事を可能にしている、という点は改めて評価する必要があります。最近、頻繁に発生しているクラウドサービスの障害のニュースが飛び交う中、クラウド上でMission Criticalな業務アプリケーションを何の問題も無く運用を継続し続ける会社も多いのも事実です。こういった会社はあまりニュースに登場していないだけだ、という現状を認識すべきであるが、多くの事が学べると考えます。
RightScaleの提唱するクラウドベストプラクティスと参照アーキテクチャについての上はこのリンクのWhite Paper on HA and DR Scenariosを是非ご参考にして下さい。

Brian Adler @ RightScale, Inc.