CDP:Multi-Datacenterパターン

提供:AWS-CloudDesignPattern
移動: 案内, 検索
寄贈したアーキテクト

データセンターレベルの冗長化

目次

解決したい課題

 サーバー障害を想定したときの可用性向上にはMulti-Serverパターンが適しているが、データセンターレベル(例えば停電や地震、ネットワーク障害)の障害を想定したとき、Multi-Serverパターンでは対処できない。

 データセンターレベルの障害を想定すれば、複数のデータセンターを利用する必要がある。しかし、距離が十分に離れたデータセンターを複数確保し、さらにシステムを冗長化するために物理ハードウエアを購入するのは非常にコストがかかる。そのうえ、調達やセッティングにも時間がかかるので、費用対効果を考えると実現は困難な場合が多い。

 また、可用性を向上させるには単に複数のデータセンターを用意するだけでなく、データの同期やデータセンター間の通信を考慮して高速な専用線で結ぶ必要があり、これもまた実現を妨げる要因である。

クラウドでの解決/パターンの説明

 クラウドサービスを提供するデータセンターは複数あり、各データセンター間は専用線で結ばれていることが多い。利用者ごとに利用するデータセンターを指定できるので、その負荷に応じたシステムを各データセンターに(仮想サーバーを用いて)構築しておく。複数のデータセンターに分散配置したシステムを、これまでと比べて簡単に安価に実現できる。データセンターレベルの障害や災害が発生しても耐えられるようになる。

実装

 AWSは、東京やシンガポールなどのリージョン(地域)の中に、アベイラビリティゾーン(AZ)と呼ばれるデータセンターが複数存在する。利用するAZは選択でき、EC2インスタンスをどのAZに配置するかは利用者側で自由に決められる。AZ間は高速な専用線で結ばれており、AZをまたいだシステムを構築できる。

 実装はMulti-Serverパターンとほぼ同一である。異なるのはEC2インスタンスの配置で、インスタンス起動時に別のAZを選択する。ELBは自動的に複数AZにまたがって構成されるので、利用者が設定を意識する必要はない。また、Webレイヤだけでなく、DBレイヤも存在するときなど、すべてのレイヤにおいて、異なるAZにまたがって構成すること。

構造

6wNg0ISJczU5Pz1m-221B9.png

利点

  • データセンターレベルの大きな障害が発生しても、サービス継続可能なシステムを構築できる。
  • 東日本大震災以降注目されているディザスターリカバリー(DR)構成を安価に迅速に構築できる。
  • AWSはAZごとに初期費用や月額利用料がかかるわけではないので、単一のAZを使用しても複数のAZを使用しても費用は変わらない。

注意点

  • マスタースレーブ構成でDBを使用する場合は、どちらかのAZにマスターを置くことになる。AZ間は高速な専用線で結ばれているとはいえ、AZ内の通信よりは速度が劣る。AZ間の通信速度がボトルネックにならないように注意する。
  • AZ間の通信速度が気になる場合は、アプリケーションやHAProxyなどのミドルウェアで基本的には同一AZのEC2と通信するようにし、そのEC2が障害時に別AZのEC2と通信するように制御することも可能である。[関連ブログ 1]
  • 高いレベルでの耐障害性を達成するには、必要な台数のサーバーを各AZに冗長的に配置しなければいけないことに注意する。例えば、3台のサーバーが必要な場合は、各AZに3台ずつのサーバーを配置しておかないと、片側のAZに障害が起こった際にその負荷をさばくことができなくなる。
  • (2015年4月時点の)ELBは、複数AZをまたがった冗長構成はサポートしているが、リージョンをまたがった冗長構成をサポートしていない。

その他

  • 複数AZを利用するとAZ間の通信費用はかかるが、安価(2015年4月時点では1Gバイト当たり0.01米ドル)なので複数サーバーで冗長構成を取る場合、基本的にMulti-Datacenterパターンを推奨する。

関連ブログ

  1. suz-lab - blog の「HAProxyの"backup"オプションで障害時のみ別AZを利用」( http://blog.suz-lab.com/2012/05/cdp-multi-datacenter-azhaproxy-azec2.html )
個人用ツール
名前空間
変種
操作
CDPメニュー
ツールボックス