AWS障害（2026年5月）：データベース災害復旧のための教訓

2026年5月7日～8日に何が起こったのか

この熱異常は、5月7日木曜日午後5時25分頃（太平洋夏時間）に発生しました。データセンターの1つのホールで冷却能力が低下し、停電が発生しました。これにより、影響を受けたラック上のEC2インスタンスとEBSボリュームが物理的に損傷しました。AWSは影響を受けたゾーンからトラフィックを分散させましたが、復旧には損傷したハードウェアを安全にサービスに戻す前に、冷却能力を物理的に回復させる必要がありました。冷却は、インシデント発生から20時間以上経過した5月8日金曜日午後1時50分（太平洋標準時）に、異常発生前のレベルまで安定しました。この時点で、影響を受けたインスタンスとボリュームのほとんどが復旧しました。

根本原因が重要です。これはソフトウェアのバグや設定ミスではなく、建物が過熱したことが原因でした。ソフトウェアによるオーケストレーションでは、物理的なハードウェアの損傷を自動的に回避することはできません。そのため、この記事の残りの部分は、高可用性ではなく、リージョンをまたいだ災害復旧について解説します。

誰が影響を受けたのか

Coinbaseは7時間ほどオフライン状態となりました。取引、取引所へのアクセス、残高更新、プライム、国際取引所、デリバティブ取引所など、すべてのサービスが停止しました。この障害は、同社にとって既に困難な週の終わりに発生しました。月曜日には、Coinbaseは従業員約700人の14%削減を発表していました。障害発生の数時間前の木曜日の午後には、同社は第1四半期の純損失が3億9400万ドル、売上高が前年同期比31%減少したと報告していました。

CEOのブライアン・アームストロング氏は、何が問題だったのかについて異例なほど率直に語りました。Xに掲載された公式声明の中で、同氏は今回の障害は「決して許容できるものではない」と述べ、Coinbaseのほとんどのシステムは単一のAWSアベイラビリティゾーンの障害に耐えられるように設計されているものの、中央集権型の取引所はそうではなかったことを認めました。Coinbaseのプラットフォーム責任者であるロブ・ウィトフ氏は後に、主要な取引所システムはレイテンシを最小限に抑えるために単一のゾーンで稼働しており、バックアップシステムは「今回の障害発生時に想定通りに機能せず、障害が長引き、エンジニアが手動で災害復旧手順を実行せざるを得なかった」と確認しました。

FanDuelは東部時間午後9時頃、レイカーズ対サンダーの準決勝第2戦が始まった直後にオフラインになりました。これは、米国のスポーツブックがサービスを停止する最悪のタイミングと言えるでしょう。ライブベットは換金できず、ユーザーは返金とボーナスを要求するスクリーンショットを投稿し、中には法的措置をちらつかせる者もいました。FanDuelは「技術的な問題によりユーザーがプラットフォームにアクセスできない」ことを認め、約2時間後にAWSとの連携を確認しました。

CMEグループは、機関投資家向け取引プラットフォームであるCME Directで、ログインと遅延に関する問題が発生したと報告しました。規制対象のデリバティブ取引所にとって、たとえ短時間の障害であっても、技術的な問題にとどまらず、規制および運用上のリスク管理上の問題を引き起こします。

これらは、障害がニュースになった3社です。実際の影響範囲ははるかに広範でした。US-EAST-1で本番ワークロードを実行し、アベイラビリティゾーンuse1-az4のEC2インスタンスまたはEBSボリュームに依存している企業は、障害を経験した可能性があります。これには、AWS上で稼働しているSingleStore Heliosのお客様も含まれます（Heliosは、当社のフルマネージドクラウドデータベースサービスです）。多くの企業は、障害をうまく吸収できるアーキテクチャを採用していました。一方、直接影響を受けた企業もありました。報道された企業は、株式市場の規制により声明の提出が義務付けられているため、注目を集めています。静かにリモート会議で夜を明かしたチームは、見出しには登場しませんが、彼らのビジネスへの影響は決して軽視できません。

隠れたコスト：SLAクレジットと現実

AWS は、標準の EC2 サービスレベル契約に基づき、影響を受けた顧客に補償を行います。補償額は通常、影響を受けたインスタンスの月間コンピューティング費用の 10% です。収益の損失、顧客の信頼の喪失、規制上のリスクに対する補償はありません。独立した調査では、実際のコストははるかに高いことが一貫して示されています。2024年の ITIC ダウンタイム時間コスト調査では、中規模および大規模企業の 90% が障害発生時に 1 時間あたり 30 万ドル以上の損失を被り、41% が 1 時間あたり 100 万ドルから 500 万ドルの損失を被っていることがわかりました。金融およびトレーディングでは、損失はさらに大きくなります。

クラウドSLAは、事業継続計画ではありません。それは、少額の返金にすぎません。

高可用性と災害復旧は、それぞれ異なる問題を解決する

このような事態の後には、マルチAZが解決策だと結論づけたくなる誘惑に駆られます。しかし、その結論を複雑にする要因が2つあります。

まず、Coinbaseは既にほとんどのワークロードでマルチAZ構成を採用していました。同社の声明では、この点が明確に示されています。「Coinbaseシステムは、単一ゾーンの障害に対して耐性を持つように設計されています。今回のケースでは、複数のAWSゾーンに影響を与える障害が発生しました。」取引所自体は、レイテンシと顧客のコロケーションを最適化するために、設計上単一ゾーンで稼働していました。レイテンシに非常に敏感なリアルタイムの運用ワークロードを実行している場合、おそらく同様のトレードオフを行っているでしょう。

第二に、マルチAZ構成であっても、リージョンレベルの障害に対しては何の効果もありません。AWSでは、可用性ゾーンを高可用性の障害ドメインとして扱います。災害復旧はリージョン単位で行われ、リージョンは意図的に独立しています。US-EAST-1で熱障害が発生しても、明示的に設定していない限り、データはUS-WEST-2に移動されません。

この違いは重要です。高可用性は、1つのラックまたは1つのゾーンで発生した障害からシステムを保護します。災害復旧は、1つのリージョンで発生した障害からシステムを保護します。ほとんどの運用ワークロードでは、両方が必要です。

お客様へのお知らせ

この記事を読んでいるHeliosのお客様には、率直にお伝えしたいと思います。お客様の中には、AWS US-EAST-1リージョンのHelios上で、ミッションクリティカルなリアルタイムワークロードを実行している方もいらっしゃるでしょう。しかし、すべてのお客様がSmart DRを有効にしているわけではありません。木曜日の夜、リモート会議に参加したり、ダッシュボードを不安な気持ちで見守ったりしていた方もいらっしゃるでしょう。運用責任者は、建屋が深刻なダメージを受けるまで、回復力への投資が評価されることはほとんどありません。そして、その段階になると、もはや予算の話ではなく、どれだけ早く復旧できるかが重要になってきます。

正直なところ、このような事態は再び発生するでしょう。US-EAST-1サーバーは過去数年間、度重なる深刻な障害の原因となっており、今回の根本原因は、いかなるソフトウェア設計をもってしても解消できない物理的な問題でした。次の地域的な障害は「発生するかどうか」ではなく、「いつ発生するか」、そして「発生時にどのワークロードが影響を受けるハードウェア上で稼働しているか」が問題となります。次の障害発生時ではなく、ダッシュボードが正常な今のうちに、皆様とご相談させていただきたいと考えています。

SingleStoreをご利用のお客様で、現在リージョンをまたいだ災害復旧体制を構築されていない場合は、アカウントチームまたはカスタマーサクセス担当者までご連絡ください。お客様の現在のアーキテクチャ、アプリケーションレベルのフェイルオーバー要件、セカンダリリージョンで実際に必要な機能、そしてSmart DRがお客様にとって最適なソリューションであるかどうかについて、一緒に検討させていただきます。場合によっては最適ではないこともありますので、その旨をお伝えいたします。重要なのは、次の障害発生時に改めて検討せざるを得なくなる前に、お客様が信頼できる計画を策定していただくことです。

SingleStore Smart DRの機能

SingleStore Helios Smart DRは、Helios向けのリージョン間災害復旧サービスです。AWS、GCP、Azureでサポートされています。簡単に言うと、地理的に離れたリージョンにデータベースの非同期レプリカを継続的に維持し、ポータルまたはAPIからフェイルオーバーとフェイルバックを実行します。概要は以下のとおりです。

• RPO（目標復旧時点）は最大10分。非同期データベースレプリケーションは、プライマリリージョンとセカンダリリージョン間で継続的に実行されます。リージョン障害が発生した場合でも、失われるデータは、まだレプリケーションが完了していないデータのみです。
• デフォルトでは、アイドル状態のコンピューティングリソースは発生しません。フェイルオーバーが発生するまでは、ストレージとデータ転送に対してのみ料金が発生します。従来のアクティブ/パッシブ型の災害復旧では、インフラストラクチャのコストが2倍になりますが、Smart DRでは、ホットスタンバイを明示的に有効にしない限り、コストは増加しません。
• トポロジー全体を完全に複製します。データだけでなく、ワークスペース構成、ユーザー、ロールと権限、ファイアウォールポリシー、インジェストパイプライン、メタデータも複製します。フェイルオーバー後、セカンダリリージョンはプライマリリージョンと同じ状態になり、接続文字列も新しくなります。
• フェイルオーバーとフェイルバックは、数回のクリックで完了します。ポータルのSmart DR構成ページから「フェイルオーバー」をクリックし、確認すると、システムがワークスペースをプロビジョニングし、データベースを接続して接続文字列を出力します。フェイルバックも同様の手順で行われますが、完全な再読み込みではなく、増分同期が実行されます。
• RTOを短縮するためのホットスタンバイ。ホットスタンバイを有効にすると、セカンダリリージョンでコンピューティングリソースを常に稼働状態に保ち、プライベートエンドポイントを事前に構成し、本番環境を中断することなくDR動作をテストできます。ホットスタンバイを使用した場合、目標RTOは約20分です。一度も実行されたことのないDRプランは仮説にすぎません。
• ポイントインタイムリカバリと連携して動作します。PITRは独立して動作します。この組み合わせにより、地域的な障害だけでなく、不適切なデプロイメントや破壊的なクエリなどの論理エラーからも保護されます。

Smart DRが終了し、お客様のDRプランが始まる場所

制約事項については正直にお伝えします。Smart DRはデータベースの復旧パスを保護しますが、エンドツーエンドのアプリケーション災害復旧計画の必要性をなくすものではありません。

フェイルオーバー時のアプリケーションの動作、ネットワーク、プライベートエンドポイント、DNSまたは接続管理、運用上のオーナーシップ、ランブックなどについては、引き続き検討が必要です。誰がフェイルオーバーの決定を下すのか。アプリケーションはどのように再接続するのか。ターゲットリージョンでの正当性をどのように検証するのか。プロセスを定期的にテストするにはどうすればよいのか。これらの疑問は、Smart DRでは解決できません。私たちは、そうでないふりをするよりも、そうはっきり申し上げたいと思います。

レプリケーションは非同期で行われます。これは運用データベースにとって適切なトレードオフですが、同期型のマルチリージョン・アクティブ/アクティブ構成ではありません。10分というRPOは上限値であり、保証ではありません。実際のRPOは、ワークロードの特性と障害発生時のレプリケーション遅延によって異なります。

今週やるべき3つのこと

SingleStoreの顧客であるかどうかに関わらず、今後7日間でやっておくべきことが3つあります。

1. リージョンの関連性をマッピングしましょう
2. 想定されるRTOをストレステストしましょう
3. 何を購入するのかを明確にしましょう

Smart DRの有効化をご希望のSingleStoreのお客様向けに、ドキュメントではセットアップ手順を詳しく解説しています。また、Smart DRの製品ブログでは、設計思想についてより深く掘り下げています。担当営業チームが、お客様の現在のワークロードに合わせてパイロットテストと準備状況テストを実施いたします。

結論

インターネットは依然として建物内で稼働しており、建物は過熱する可能性があります。これは、アーキテクチャ図では明らかにされない部分です。Coinbase、FanDuel、CME、その他の影響を受けたプラットフォームのチームは、困難な状況に適切に対応しました。木曜の夜から金曜の朝にかけて復旧作業に当たったエンジニアの方々には、心から同情いたします。

2026年5月の出来事から得られる教訓は、AWSが信頼できないということではありません。AWSは全体として非常に信頼性が高く、今回の事態におけるエンジニアリング対応もプロフェッショナルでした。教訓は、信頼できるプロバイダーを利用していることと、回復力があることは同じではないということです。回復力は、自社で構築するものです。データの保存場所、データの複製頻度、そしてアプリケーションを別のリージョンで迅速に実行できるかどうかといった、自社の選択によって決まります。Smart DRはそのための選択肢の一つです。他にも選択肢はあります。唯一選択肢がないのは、何も選択しないことです。