大規模な災害が発生した際でもシステムの運用を継続可能にするには、クラウドコンピューティングを支える一つのデータセンターが使えなくなった場合に備える必要があります。もし、被災地のデータセンターにアクセスできなかったとしても、遠隔地のデータセンターに設けたディザスタリカバリーサイト（待機系システム）で処理を引き継げるようにするのです。
最終回となる第5回では、Windows Azure Platformでディザスタリカバリーサイトを設ける設計を取り上げます。前回、ベータプログラムに参加することによって利用可能になるCTP（Community Technology Preview）として、Windows Azure Traffic Managerが用意されていることを紹介しました。Traffic Managerを活用することで、いざというときにはディザスタリカバリーサイトに処理を移す、災害に強いシステムを作ることができます。
本番系と待機系で構成が違っても構わない
Windows Azureの管理ポータルにあるTraffic Managerのポリシー作成画面で、ルーティング設定のロードバランシング方法として「Failover」を選択すると、ロードバランス先となるサーバーのうち、最上位（リストの一番上）のサーバーに全てのリクエストが割り振られるようになります。そして、大規模災害などでそのサーバーへのアクセスが不能になった場合は、2番目に登録されたサーバーに全てのリクエストが届くよう、Traffic Managerが割り振りを変更します。
ディザスタリカバリーを実現するには、まず、クライアントに最も近い場所のデータセンターで本番系サーバーを稼働させます。そして、そのサーバーをTraffic Managerのロードバランス先リストの最上位に登録します。さらに、本番系とは地理的に離れた場所にあるデータセンターで待機系サーバーを稼働させ、そのサーバーをリストの2番目に設定するのです。必要に応じて、待機系の予備サーバー群をリストの3番目や4番目などとして設定します
Traffic Managerに登録するロードバランス先のサーバーは、構成や提供するサービスなどが異なっていても構いません。例えば、本番系サーバーではラージインスタンスなどを用いた大き目の構成でフルサービスを提供し、待機系サーバーではスモールインスタンスで一部サービスに限定して運用を継続することもできます（図1）。また、本番系サーバーが停止した際に、エクストラスモールインスタンスのSorryサーバー（代替コンテンツを配信するサーバー）からレスポンスを返す設計も可能です。
Webロールではセッション維持に注意
Webアプリケーションを運用するなど、システムにWebロールを使用している場合は、待機系サーバーを設ける際に、セッション維持への配慮が必要になることがあります。Webアプリケーションによっては、セッションが維持されないと想定外の挙動を示すからです。
この問題を避けるには、第3回で取り上げたセッション状態プロバイダーを使って、ストレージサービスやSQL Azureなどにセッションデータを保存する必要があります。セッション状態プロバイダーを使ってシステムを構築する際には、稼働前テストにおいて、本番系や待機系のWebロールが同じセッションデータを参照していることや、どのサーバーでリクエストが処理された場合でもセッションが維持されていることを綿密に確認することが重要です。
富士通システムソリューションズ
