こんにちは、Enterprise Cloud部 ソリューションアーキテクト1課 宮形 です。
4月からガバメントクラウドのBLOG記事を書き始めましたが、応援いただいた有志の方にアイキャッチ画像を作っていただきました。とてもうれしく、今回からこちら画像を利用させていただきます。ドキュメンタリー番組のタイトルっぽくてイイ感じです
本BLOGでは、過去にあったAWSの大規模障害とその影響、対策についてご紹介させていただく内容となります。
弊社お客様よりよくお尋ねされるのが「クラウドって障害がよくあるイメージありますが、AWSだと過去どんな障害ありました？」というものがあります。 ガバメントクラウドへの移行に向けて、地方自治体のご担当様も同じ不安をもたれたり、人から説明を求められることも多いのではないでしょうか。 もし過去にあった障害がガバメントクラウドAWS上で再度起こった場合、地方自治体様のシステムにどのような影響があるか。これらも交えてご紹介したいと思います。
本BLOGの内容は、社内・社外の有識者、先輩方々がこれまでに取り上げた内容の焼き増しも多くなっております。敬意と感謝の気持ちをこの場をもってお伝えします。ありがとうございます。
東京リージョン Direct Connect 全体の障害
ガバメントクラウドAWSで多く利用されるであろう東京リージョン(ap-northeast-1)において、直近で最もインパクトが大きかった事象としては、日本時間 2021年9月2日 午前 7 時 30 分に発生した、AWS Direct Connect というオンプレミスとAWS間の専用ネットワーク接続を提供するサービスの障害かと思います。
Summary of AWS Direct Connect Event in the Tokyo (AP-NORTHEAST-1) Region
- 仮にガバメントクラウドAWSにおいて地方自治体様の標準準拠システムを東京リージョンのみで稼働していた場合の障害影響
- 業務影響：標準準拠システムが利用できなくなります
- 復旧方法：AWS側の復旧をお待ちいただきます
この障害については、当時弊社より有効な予防策を早い段階で情報公開しております。
AWS Direct Connect はオンプレミスとの物理的な接続箇所を2つ以上で冗長化されることが推奨されており、このように構成することでAWS側の一時的な設備障害ではネットワーク全断が起こらないないようになっています。残念ながらこの障害当時は、AWS側の設備に不備があり影響が広範囲になってしまいましたが、その原因は既に除去されたとあります。
この障害の対策としては AWS大阪リージョン (ap-northeast-3)の活用となります。大阪リージョンは 2021年9月2日 障害当時存在し AWS Direct Connect のサービスも利用可能でしたが、機能が限定されていたり利用可能なネットワークキャリア様が少なかったため、十分活用できているとは言えない状況でした。その後アップデートがされ、今現在では東京リージョン、大阪リージョンどちらも AWS Direct Connect は殆ど機能差異なく利用可能となっています。ガバメントクラウドAWSにおいてミッションクリティカルなシステムを稼働させる場合、AWS Direct Connect は東京リージョン、大阪リージョン間で東西冗長化する構成をお勧めします。
下記は仮に AWS Direct Connect を東西冗長化していた構成で、東京リージョン Direct Connect 全体の障害が発生した場合の通信経路となります。地方自治体様の端末より大阪リージョンを経由し、Direct Connect Gateway を通り東京リージョン上の標準準拠システムを実行するEC2やRDSへ通信が行える状態となり、システムの利用停止を回避することができます。
参考までに、目安となる AWS Direct Connect のサービスレベルアグリーメント(SLA)では「マルチサイト冗長 SLA」で 99.99%未満からサービスクレジットが設定されております。
AWS Direct Connect Service Level Agreement
アベイラビリティゾーンの障害
こちらも同じく東京リージョン(ap-northeast-1)で過去にあった障害になります。リージョン全体ではありませんが、アベイラビリティゾーン という物理的な単一または複数のデータセンターの単位での障害となります。最近ではこのような障害がありました。
- 日本時間 2021年2月20日 午後 11 時 50 分頃発生した アベイラビリティーゾーン apne1-az1 における冷却ユニットの電源障害
- 日本時間 2019年8月23日 午前 12 時 50分頃発生した アベイラビリティーゾーン apne1-az4 におけるEC2サーバーのオーバーヒート
当時のサーバーワークスからのお知らせ：2019年8月23日に発生したAWS東京リージョンの障害に関してのご報告 - 株式会社サーバーワークス
これらの影響で、該当のアベイラビリティゾーンにあるEC2インスタンスへの接続障害やEBSというストレージのパフォーマンス劣化が発生しました。
AWSではアベイラビリティゾーン(以下AZと記)という括りでデータセンターを自然災害対策・電力供給・ネットワーク等で地理的に分離しています。東京リージョンでは本BLOG執筆の2024年5月時点では3つのAZが選択できるようになっています。AWSにおいては 仮想サーバーに該当する Amazon EC2、データベースのマネージドサービス Amazon RDS、仮想ディスクにあたる Amazon EBS 等でインスタンス起動やデータ保存する配備先の AZ を指定する必要があります。
- 仮にガバメントクラウドAWSにおいて地方自治体様の標準準拠システムを単一のAZのみでAWSリソースを稼働していた場合の障害影響
- 業務影響：標準準拠システムが利用できなくなくなる、またはパフォーマンス劣化が発生します
- 復旧方法：AWS側の復旧をお待ちいただきます
この通り単一のAZ（シングルAZ）でシステムを構成すると、AZ障害によりシステム全停止となる恐れがあります。 AZ障害の対策としては、複数AZにAWSリソースやEC2・RDSインスタンスを配置する「マルチAZ構成」が基本となります。
下記は仮に標準準拠システムを実行するEC2・RDSをマルチAZ構成とした際の、アベイラビリティゾーンに障害があった場合の通信経路となります。生存したAZでEC2・RDSが継続して利用できますので、標準準拠システムの利用停止を回避することができます。ただし、EC2はマルチAZ構成においては複数台サーバー構成となります。Elastic Load Balancing を用いた通信の分散や、EC2同士の設定およびデータの同期を考慮する必要があります。
参考までに、目安となる EC2 のサービスレベルアグリーメント(SLA)においては、マルチAZ構成で同時に配備されるインスタンスにおいて 99.99%、シングルAZで単一に配備されるインスタンスにおいては 99.5% の稼働率で利用可能にするための商業上合理的な努力を払うものとあります。
他、海外リージョンの障害
ここまでは東京リージョンにおける障害について記載しましたが、他 海外リージョンの障害についてみていきたいと思います。
本BLOG執筆の2024年5月時点では、AWSにおいては 世界 33のリージョンと 105 のアベイラビリティゾーンが選択可能となっております。*1 このうち地方自治体様がガバメントクラウドにおいて利用するのは、日本国内の東京リージョン(ap-northeast-1)と大阪リージョン(ap-northeast-3)になるかと思います。これは総務省のガイドラインにおいて「日本の法令の範囲内で運用できるデータセンターを選択」する必要があるためです。*2
海外リージョンについても一定頻度で大規模障害は発生しておりまして、最近では下記が記憶に新しいです。
- 日本時間 2021年6月14日 午前 4 時 18 分頃発生した バージニア北部リージョン(us-east-1)の複数のサービスにおいてエラーレートの上昇および遅延
ガバメントクラウドの利用においては海外リージョンの障害は無関係に思えますが、一部AWSリソースやサービスにおいては海外リージョンがコントロールプレーンになっている場合があります。例えば下記のようなサービスが該当します。
- AWS IAM ： AWS リソースへのアクセス権限を管理するためのサービス
- AWS Organizations ：複数のAWSアカウントを一元管理できるサービス
- Amazon Route 53 ： AWSが提供するDNSサービス
- Amazon CloudFront ： AWSが提供するCDN（コンテンツデリバリーネットワーク）
詳細は下記サイトに記載されています。
Global services - AWS Fault Isolation Boundaries
例えばバージニア北部リージョンが障害になったとして、AWSが提供するDNSサービスにあたり Amazon Route 53 の名前解決が全世界で出来なくなるということはありません。サービスの実態は世界中リージョンに配置されたデータプレーンにて提供されているため殆どの場合は影響はありません。ただし、コントロールプレーンはサービスやリソースの作成、設定閲覧、変更、削除などを担っていますので、障害中は構築や設定変更作業が出来なくなる可能性があります。
地方自治体様の標準準拠システムにおいては、海外リージョンの障害でサービスや機能の提供に即座に影響があるとは考えにくいですが、全くの無関係では無いという点は理解しておく必要があります。
どの障害にも共通する備え
どの障害にも共通する備えとしては、AWSクラウドに今 障害が起こっているか切り分けする手法を確立しておくことかと思います。
AWS Health Dashboard を開くと、どなたでもすぐにAWSサービス毎の障害状況を、今時点と過去12 か月間の履歴を確認することができます。
AWS Health Dashboard は誰でもアクセスすることで閲覧できますし、AWSマネジメントコンソールへサインインすることでご利用のAWSアカウント固有の未解決な問題や、スケジュールされたAWSのメンテナンスを確認することも出来ます。Amazon EventBridge というイベントトリガーを組み合わせて、組織で利用するメールやSlack等へ障害状況を通知することもできます。
まとめ
いかがでしたでしょうか。AWS過去の障害を知ることで、ガバメントクラウドへの移行に向けて、どこまで適切な備えをしてくべきか検討いただくヒントになれば幸いです。
障害は無いにこしたことはなく予防も大事ですが、起こることを前提とした備えも重要かと思います。
AWS の各サービスにはSLA(サービスレベルアグリーメント)が設定されており、AWSはその達成のために目標稼働率(99.xxxパーセント等で表現)を商業上合理的な努力として設定しています。
AWSのサービスを選択しベストプラクティスに基づき利用することで安心してご利用いただけることは間違いありませんが、障害ゼロを約束するサービスというものは存在しません。是非皆様には過剰にはなりすぎない適切な備えを検討いだければと思います。
本BLOGの内容が、少しでも皆様の参考になれば幸いです。
*1:AWS グローバルインフラストラクチャ ：https://aws.amazon.com/jp/about-aws/global-infrastructure/
*2:地方公共団体における情報セキュリティポリシーに関するガイドライン(令和 4 年 3 月版) ：https://www.soumu.go.jp/main_content/000805453.pdf
