クラウド障害の過去事例
クラウドサービスはリージョン、AZごとに独立してサービス提供されています。ただし、1つのクラウドでシステムを運用している場合、過去事例から見ても、大規模な障害により、一時的に特定のクラウド上で運用するサービスが提供できなくなったことがあります。
AZ単位の障害
2019年8月に発生したAWSの障害は、AWSの東京リージョン内の1つのデータセンター（AZ）で、AZ内の制御システムに問題が発生し、複数の要因により冗長化された冷却システムに障害が発生しました。それによってAZ内の一部のサーバー区画の温度が上昇した結果、サーバーの電源が停止するなど、同一AZ内のRDS、ほかのサービスのパフォーマンス劣化なども発生しました。1つのAZの障害ではありましたが、そのAZを利用しているシステムにおいては、完全な復旧までに少なくとも6時間程度の時間を要しました。
リージョン単位の障害
2021年9月に発生したAWSの障害は、東京リージョンのすべてのAZへ影響するものでした。AWSの管理するネットワークデバイスの潜在的なバグにより、東京リージョンに至るDirect Connect（閉域ネットワーク接続サービス）が約5時間にわたって不通となり、東京リージョンをマルチAZで利用していた場合でも、東京リージョンを利用するさまざまな企業や組織のITシステムに障害が発生した、というものです。障害発生当時、AWSからはDirect Connectではなく、VPN接続に切り替えることで障害を迂回できると発表されましたが、Direct Connectと比較すると帯域や品質、安定性が劣るVPNを構築している、またはしなければならない、手動で切り替えなければならないことから、多くの利用者は対応できませんでした。
ただし、この障害は大阪リージョンには影響がありませんでした。東京リージョンに加えて、大阪リージョンを利用するマルチリージョン構成であれば、大阪リージョンに切り替えることでサービス提供は継続できたでしょう。
なお、後日Transit Gatewayと呼ばれるサービスをマルチリージョン構成とし、同様の事象発生時に閉域ネットワークを利用する構成で迂回させることで、東京リージョンを利用したサービス継続も可能となる、と発表されました。この迂回構成の詳細についてはコラムで紹介します。
マルチリージョンでの迂回
2021年9月に発生したAWSの障害は、東京リージョンのすべてのAZへ影響するものでした。ただし、障害箇所は東京リージョン全域のDirect Connectであったものの、ほかの東京リージョン内のサービス（EC2やRDSなど）は正常に稼働しており利用が可能でした。また、Direct Connectを利用していないシステムには影響がないものでした。
本障害への対策として、Transit Gatewayと呼ばれるサービスをマルチリージョン構成とし、同様の事象発生時に閉域ネットワークを利用する構成で迂回（東京リージョンのDirect Connectを経由させないように）させることで、東京リージョンを利用したサービス継続も可能となります。
概要構成を紹介します。Transit Gateway（TGW）はマルチリージョン構成となり、専用線接続サービスであるDirect Connectは、リージョンに紐づかないグローバルサービスとなるDirect Connect Gateway（DXGW）を利用します。
Transit Gatewayはリージョン間を接続するInter-Region Peeringを使って、東京リージョン-大阪リージョン間の迂回経路を構成しています。Inter-Region Peeringについては、通常時は東京リージョンと大阪リージョンを接続するリージョン間通信経路としても利用可能です。
本障害は、東京リージョンに至るDirect Connect全域が障害箇所でした。そのため、Direct Connect Gatewayから大阪リージョンTransit Gatewayを迂回して東京リージョンへ到達させることで、東京リージョンのDirect Connectを経由することなく、専用線、東京リージョンを利用したままサービス提供を継続できます。
なお、大阪リージョンを経由させることになりますので、レイテンシーが発生します（筆者が構築した環境では、通常時は4-5msであったレイテンシーが、迂回後は20ms程度に上昇しました）。また、Transit Gatewayの障害を考慮する必要もあると考えられます。
クラウドベンダー単位の障害
2023年1月に発生したMicrosoftのネットワーク障害は、影響範囲が全世界に波及しうるものでした。原因はWAN（ネットワーク）の保守作業を行った際に、設定変更を予定していた機器のみではなく、WAN内のすべての機器に対してコマンドが送信されたことで、WAN内のすべての機器でルーティングに必要な情報の再計算が引き起こされたことによるものと発表されています。結果、Azureの一部サービスへのアクセスや、Microsoft 365、Microsoft Teamsなどが約5時間以上利用できなくなりました。
この障害は、マルチリージョン構成であっても回避できないAzure全体に影響するものでした。
その他にも、世界全体でみると、各クラウドベンダーで大なり小なりの障害は発生しています。2023年4月には、Google Cloudのパリリージョンにおいて、冷却システムのポンプが故障した結果、バッテリールームが浸水し、火災にまで至った障害が発生しており、本障害の完全な復旧には数週間を要する大規模な障害となりました。障害が発生していないクラウドベンダーはありません。落雷などの災害によるもの、電源障害などの設備故障によるもの、ヒューマンエラー（設計の不具合や運用、手順誤り）によるシステム障害など、原因は多岐にわたり障害をゼロにすることはできないということを裏付けています。また、マルチAZやマルチリージョン構成に分散していても、集中し共通する箇所は存在しており、あるクラウドの全リージョンが影響範囲となる障害が存在することが明らかになりました。
クラウドベンダー単位による障害は、企業や組織のITシステムが1つのクラウドサービスに依存することに対して、どのようなリスクマネジメントに取り組むのかを問いかけています。このリスクを低減する対応策の1つが、「マルチクラウド」であると考えられます。
マルチクラウドでの機能分散
なお、複数のクラウドの機能を利用したい、またはデファクトスタンダードが存在しない機能であるため、複数のクラウドを比較評価しながら選定したいという要望もあります。執筆時点で、最も活況であるのは生成AIのサービスでしょう。実際に、AWS、Azure、Google Cloudの3つのサービスから成るマルチクラウド環境を利用している企業もあります。
また、サービスを提供するプラットフォームはAWSやAzureを利用しつつ、データ分析プラットフォームはGoogle Cloudを利用している企業もあります。サービス提供で利用する業務データベースとは別のクラウドのデータベースを活用して分析用の環境を利用する構成となります。各クラウドの提供するサービスのメリットを見極め、良い部分を組み合わせてマルチクラウドでの運用を選択したケースと言えるでしょう。
まとめ
マルチクラウドについては、気づいたら企業内で複数のクラウドを利用していたというケースもあります。このようなケースについては、ガバナンスが効いておらず、いわゆるカオスな状態であったり、シャドーIT（企業・組織側が把握せずに利用されているクラウドサービスなど）となっていたりすることも多いでしょう。
シングルクラウドのベンダーロックイン回避、コストや技術的な課題に対する対策、機能ごとの使い分け、ワークロードの分散などの要件に合わせて、計画的、発展的、戦略的にマルチクラウドを推進していくことが望まれるでしょう。
マルチクラウドデータベースの教科書 クラウドロックインを乗り越えるデータベース構築ノウハウ
朝日英彦、小林隆浩、矢野純平 著
出版社：翔泳社
発売日：2024年8月6日
価格：3,740円（税込）
本書について
マルチクラウドにおける、現代的なデータベース構築・設計を解説する書籍です。4大クラウド（AWS, Microsoft Azure, Google Cloud, Olacle Cloud Infrastructure）のDBaaSの解説はもちろん、データベースの観点からマルチクラウドの優位性や課題を紹介します。
本書の特徴
- マルチクラウドジャーニーを徹底解説：データベースという視点から一段登って、システム全体を俯瞰してマルチクラウドを推進する際に必要な点を整理しています
- DBaaSを網羅的に紹介：発行時点でのDBaaSの特徴を保存したスナップショットとして、クラウド選定時やDBaaS選定時に活用いただけます
- マルチクラウドで利用可能なDBaaS、その構成パターンを紹介：現時点で採用可能な構成パターンを本書にまとめました。マルチクラウドデータベースのもたらす価値も丁寧にまとめています
