AWS障害でPayPayやニコニコなど停止…なぜ大規模な障害となったのか？企業の対応策は(2/2)

クラウド固有機能は便利なほど移れなくなる

　AWSの代わりにAzureやGoogle Cloudも契約すれば、障害問題は解決するのか。答えは、それほど単純ではない。3社はいずれも複数のゾーンやリージョンを使う機能を提供しているが、どの機能を選び、どのように組み合わせるかは利用企業に委ねられている。

　マイクロソフトも、Azureが可用性ゾーンや複数リージョンなどの機能を提供する一方、要件に合う機能を評価して構成するのは利用者の責任だと説明している。

　Google Cloudも、自然災害やケーブル切断など予測できない障害によって、サービスが停止する可能性があると明記する。その上で、RTO（目標復旧時間）とRPO（目標復旧時点）を定め、障害を前提にアプリケーションを設計するよう求めている。

　むしろ難題は、各クラウドの固有機能が便利であるほど、別のクラウドへ移りにくくなる点だ。データベース、認証、メッセージ配信、監視、生成AIなどをマネージドサービスへ深く組み込めば、開発速度や運用効率は上がる。その一方、別サービスとの仕様差が広がり、プログラムや運用手順の作り直しが必要になる。

　マルチクラウドは、AWSとAzureの契約書を2枚持つことではない。データを同期し、代替環境を起動し、利用者の通信を切り替え、担当者が復旧作業を実行できて初めて意味を持つ。技術だけでなく、運用担当者の習熟も必要になる。

　すべてを異なるクラウドへ移植可能にすれば、今度は開発速度とコストを犠牲にする。重要なのは、移しやすさと固有機能の利便性を一律に判断せず、止まった際の事業影響に応じて使い分けることだ。

止まらない企業が使い分ける3つの待機方式