全4191文字
PR

マルチリージョン構成を採れば、リージョン障害でもサービスを継続できる。必要な耐障害性のレベルに応じて選択する手法は変わってくる。障害時に本当に機能するのか、日常的なシミュレーションは欠かせない。

 今回は、クラウドサービスの複数のリ-ジョンを併用して耐障害性を高めるマルチリージョン構成について検討します。

 クラウドサービスでは、「リージョン」はある地域を示しており、複数の「アベイラビリティゾーン(AZ)」で構成されています。AZはデータセンターに相当します。

 例えば、AWS(Amazon Web Services)の東京リージョンであれば4つのAZから構成されています。そのため、複数のAZを併用するマルチAZ構成を採っていれば複数のデータセンターにまたがる冗長構成になるため、あるAZで障害が発生しても、別のAZが稼働していれば、システムが致命的な影響を受ける可能性を低くできます。

リージョン障害は起こり得る

 マルチAZにすることで単一のAZ障害に対応できますが、リージョンレベルの障害が発生しないわけではありません。代表的なのは2015年9月に米国東部1リージョンで発生した大規模障害です。AWSのNoSQLサービスDynamoDBに障害が発生したことで、多くのサービスが影響を受けました。いったい何が起きたのか押さえておきましょう。

 DynamoDBはテーブル上のデータを複数のサーバーに分散配置します。これによってデータ量に影響を受けずに高い可用性と一定のレイテンシーを維持することができます。この仕組みを実現するためには、クエリーの要求に対してデータが実際にどこにあるのかを管理する必要があります。これをメンバーシップと呼びます。

 DynamoDBでは基本的にプライマリキーに従った分散配置を行いますが、この当時、DynamoDBにグローバルセカンダリインデックス(GSI)という新たな機能が追加されました。GSIを利用すれば任意のキーによるインデックスが可能になります。この機能が大規模に利用され始めると、当然ながらメンバーシップのデータ容量が増大します。この結果、あるタイミングでデータの分散配置を管理するサービスが適切な時間内に応答できなくなってしまい、最終的にはDynamoDBにおいて半分以上のリクエストが受け付けられない状況になりました。

 DynamoDBはリージョンに対して1つのインスタンスとして提供されているため、すべてのAZが同時に影響を受けます。AWSのサービスの中でも早くから提供されているDynamoDBは、AWSの様々なサービスで内部的に利用されています。このためDynamoDBを利用していたサービスも影響を受けます。具体的にはキューサービス、仮想インスタンスの自動スケーリングサービス、監視ツール、AWS管理コンソールへのログインなどです。最終的にはリージョンレベルで6~8時間にわたって障害が継続したのです。

図 マルチリージョンとマルチAZ
図 マルチリージョンとマルチAZ
AWSの冗長構成
[画像のクリックで拡大表示]