CDP:Multi-Datacenterパターン
データセンターレベルの冗長化
目次 |
解決したい課題
サーバー障害を想定したときの可用性向上にはMulti-Serverパターンが適しているが、データセンターレベル（例えば停電や地震、ネットワーク障害）の障害を想定したとき、Multi-Serverパターンでは対処できない。
データセンターレベルの障害を想定すれば、複数のデータセンターを利用する必要がある。しかし、距離が十分に離れたデータセンターを複数確保し、さらにシステムを冗長化するために物理ハードウエアを購入するのは非常にコストがかかる。そのうえ、調達やセッティングにも時間がかかるので、費用対効果を考えると実現は困難な場合が多い。
また、可用性を向上させるには単に複数のデータセンターを用意するだけでなく、データの同期やデータセンター間の通信を考慮して高速な専用線で結ぶ必要があり、これもまた実現を妨げる要因である。
クラウドでの解決/パターンの説明
クラウドサービスを提供するデータセンターは複数あり、各データセンター間は専用線で結ばれていることが多い。利用者ごとに利用するデータセンターを指定できるので、その負荷に応じたシステムを各データセンターに（仮想サーバーを用いて）構築しておく。複数のデータセンターに分散配置したシステムを、これまでと比べて簡単に安価に実現できる。データセンターレベルの障害や災害が発生しても耐えられるようになる。
実装
AWSは、東京やシンガポールなどのリージョン（地域）の中に、アベイラビリティゾーン（AZ）と呼ばれるデータセンターが複数存在する。利用するAZは選択でき、EC2インスタンスをどのAZに配置するかは利用者側で自由に決められる。AZ間は高速な専用線で結ばれており、AZをまたいだシステムを構築できる。
実装はMulti-Serverパターンとほぼ同一である。異なるのはEC2インスタンスの配置で、インスタンス起動時に別のAZを選択する。ELBは自動的に複数AZにまたがって構成されるので、利用者が設定を意識する必要はない。また、Webレイヤだけでなく、DBレイヤも存在するときなど、すべてのレイヤにおいて、異なるAZにまたがって構成すること。
構造
利点
- データセンターレベルの大きな障害が発生しても、サービス継続可能なシステムを構築できる。
- 東日本大震災以降注目されているディザスターリカバリー（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パターンを推奨する。
