5ノードRaftのうち3ノードが同時に死んだ理由 — Coinbaseの2026年5月7日障害を読む

はじめに — 他人のポストモーテムが教科書より正確なとき
何が起きたか
クォーラムの算術に隠れた前提 — 障害の独立性
それでもCoinbaseはその選択を撤回しない
災害時にしか走らないコードは、テストされたことのないコードだ
マネージドサービスはリスクを消さず、移すだけだ
最も正直な箇所 — 3-AZであっても防げなかった
タイムラインを読み直すと、単一原因の物語は崩れる
AZは障害の最小単位ではない
では実務で何を変えるべきか
おわりに — そしてこの記事が知らないこと
参考資料

はじめに — 他人のポストモーテムが教科書より正確なとき

分散システムの文章の8割は同じ一文から始まります。「Raftは2f+1ノードでf個の障害に耐える」。正しい話ですし、試験にも出ますし、実務でこれを知らないせいで死ぬ人はいません。人が死ぬのは、その一文に書かれていない前提のせいです。

2026年6月1日、Coinbaseが5月7日の障害についてのポストモーテムを公開しました。この記事が読む価値を持つのは、「私たちは愚かなミスをしました」という類の話ではないからです。むしろ逆です — 意図的で、文書化されており、そのドメインでは弁護可能なアーキテクチャ選択が、まさにその選択が無いものとして扱っていた障害モードと正面から衝突した話です。そしてCoinbaseは今もその選択を撤回していません。

本稿はそのポストモーテムを根拠として読み進めます。すべての時刻と数値はCoinbase自身が明らかにしたものであり、出典が異なる場合はそう明記します。

何が起きたか

始まったのはソフトウェアではなく物理現象でした。Coinbaseの説明によれば、米東部時間5月7日午後7時20分、AWS us-east-1リージョンの可用性ゾーンuse1-az4内にある一つのデータホールで複数のチラーが同時に故障しました。冷却が絶たれると該当ラックは熱保護シャットダウンに入り、その建物のEC2インスタンスとEBSボリュームがオフラインになりました。

AWS側の説明も同じ絵を描いています。The RegisterとNetwork Worldが引用したAWSステータスダッシュボードの文言によれば、AWSは太平洋時間午後5時25分の更新で、影響を受けたハードウェア上のEC2インスタンスとEBSボリュームが「熱イベント中の電源喪失」の影響を受けたと記し、翌朝の更新では、温度が運用しきい値を超えたためハードウェアを保護するべくサーバーが自動的にシャットダウンしたと説明しました。ソフトウェアで迂回できる種類の障害ではなかったということです — 冷却を復旧させない限り、ハードウェアに再び電気を通すことはできないからです。

Coinbaseが公開したタイムラインです。すべて米東部時間です。

5月7日
  7:20 PM  use1-az4 内の一つのデータホールで複数のチラーが同時故障
           冷却喪失 -> 該当ラックの熱保護シャットダウン -> EC2 / EBS オフライン
  7:48 PM  Coinbaseの取引の大半が停止
  9:29 PM  AWSがプレイスメントグループ内のEC2インスタンスを終了
           マッチングエンジン5ノード中3ノードがダウン -> クォーラム喪失

5月8日
 12:06 AM  クォーラム復旧
  2:25 AM  マッチングエンジンをキャンセル専用(cancel-only)モードでオープン
  3:00 AM  損傷したブローカーからトピックを退避させるための手動パーティション再割り当て
  3:49 AM  全銘柄の取引が正常に再開
  5:30 AM  coinbase.com / モバイルアプリの取引が縮退状態で復旧
  9:30 AM  P0 / P1 トピックが完全復旧
  9:53 AM  coinbase.com / モバイルアプリが完全復旧
  2:00 PM  残っていたイベントストリーミングトピックのバックログを解消

Coinbase自身のまとめはこうです — 取引、入金、出金をはじめ顧客が依存する大半のサービスが「およそ8時間」にわたって利用不能または縮退し、全システムの完全復旧には「さらに12時間」を要しました。参考までに、午後7時48分(取引停止)から午前3時49分(全銘柄再開)までは正確に8時間1分であり、この「およそ8時間」はタイムラインと矛盾しません。

クォーラムの算術に隠れた前提 — 障害の独立性

Coinbase Exchangeのマッチングエンジンは、Raftベースのレプリケートクラスターであり、AWSクラスタープレイスメントグループ(Cluster Placement Group)の中で動いています。ノードは5個で、Raftの算術どおりなら2個までの障害に耐えます。3個生きていれば過半数なので、動作を続けられます。

3個が死にました。しかも一度に。

ここで重要なのは「3個死んだから5ノードでは足りなかった」ではありません。ノードを7個に増やしても同じことが起きたはずです。本当の問題はその算術の前提です。「5ノードは2個の障害に耐える」という文の正確な形は5ノードは2個の独立した障害に耐えるです。そしてクラスタープレイスメントグループは、その独立性を意図的に消し去るものです。

AWS自身のプレイスメントグループのドキュメントが、このトレードオフをそのまま記しています。ドキュメントは配置戦略をこう分類します。

Cluster — 単一の可用性ゾーン内でインスタンスを「近くに密集させる」(packs instances close together)。目的は、HPCのようにノード間通信が密結合したワークロードに必要な低レイテンシのネットワーク性能を得ることです。
Partition — インスタンスを論理パーティションに分割し、異なるパーティションのインスタンスグループが同じハードウェアを共有しないようにします。ドキュメントが例に挙げるのはHadoop、Cassandra、そしてKafkaです。
Spread — 少数のインスタンスを互いに区別されるハードウェアへ厳密に配置して「相関障害を減らす」(reduce correlated failures)。

そしてドキュメントにはこうも書かれています — プレイスメントグループをまったく使わない場合、EC2はデフォルトでインスタンスをハードウェア全体に分散させ「相関障害を最小化する」(minimize correlated failures)よう試みる、と。

つまりAWSのドキュメントで「correlated failure」という語が出てくるのはSpreadとデフォルト動作を説明する箇所であり、Clusterを説明する箇所には出てきません。Clusterはその正反対側に立つ戦略です。レイテンシを買い、独立性を売る取引であり、その取引はドキュメントの最初のページに明記されています。

したがって、この事件を一行でまとめるとこうなります。クォーラムはノードを数えるが、障害はノードを数えない。 障害が数えるのは失敗ドメインです。プレイスメントグループ内の5ノードは、Raftにとっては5に見え、チラーにとっては1に見えます。

それでもCoinbaseはその選択を撤回しない

ここがこのポストモーテムで最も興味深い箇所です。こうした文章はふつう「私たちは単一障害点を作ってしまい、反省しています」という流れになります。Coinbaseはそう書きませんでした。

ポストモーテムはコロケーションを意図的な選択だったと明記し、その理由をこう記しています — 真剣な市場が求めるレイテンシとスループットを満たすマッチングエンジンは、投票に参加するクラスターメンバー間で可用性ゾーンをまたぐネットワークホップを許容できない、と。そして分散合意の物理学と、公正で流動性のある板を運用する経済学が、同じ答え、すなわちコロケーションを指し示していると記しています。

この主張は真剣に受け止める必要があります。Raftではコミットのレイテンシは、リーダーがフォロワー過半数からの応答を受け取るまでの時間、すなわち投票メンバー間の往復レイテンシに縛られます。AZをまたぐとその往復は伸び、そのコストはコミット一つひとつに乗ります。低レイテンシ取引システムでカーネルチューニングによってマイクロ秒を削り出す人々にとって、これは交渉の余地のない制約です。(Coinbaseは具体的なレイテンシ数値を公開しておらず、私もここで数字を作り出すことはしません。)

したがってCoinbase自身の診断は、コロケーションそのものではなく、その隣に位置します。ポストモーテムの言葉では、アーキテクチャ上の問題は別の可用性ゾーンへ自動フェイルオーバーする能力がなかったことでした。プレイスメントグループを使ったことが問題ではなく、そこから抜け出す自動経路が無かったことが問題だった、というわけです。

これは言葉遊びではなく、実務上まったく異なる処方箋につながります。「プレイスメントグループを使うな」はこのチームには役に立たない助言です — そうすればマッチングエンジンが要求性能を出せなくなるからです。一方、「失敗ドメインを意図的に結合したのなら、そこから出る扉を作り、定期的に開けておけ」は実行可能な助言です。実際、Coinbaseの改善項目の一行目がそれです — マッチングエンジンのウォーム・クロスゾーン・スタンバイ設計を改善し、定期的な周期で本番フェイルオーバー訓練を行う、最大の取引所はメンテナンス時間帯に参加させ、残りはサンドボックスの周期で回す、というものです。

災害時にしか走らないコードは、テストされたことのないコードだ

ポストモーテムの中で私が最も長く見つめた一文は、実はこれです。クォーラムを復旧させるため、Coinbaseは障害対応の最中に緊急コード変更をデプロイせねばならず、その内容は5ノード全部がresolve可能でなければならないという起動時の前提を取り除くことでした。

この一文をゆっくり読んでみてください。クラスターを蘇らせようとしているのに、クラスターが立ち上がりません。なぜなら起動コードが、自分が生まれたトポロジーを事実として扱っていたからです。5ノード全部が名前解決できて初めて立ち上がる — 平常時は真、デプロイ時も真、ステージングでも真です。3ノードが灰になった夜だけ偽になります。つまりこの前提は、他のあらゆる日には正しく、必要とされるその一日だけ誤っている種類のコードです。

これがなぜ起きるかは自明です。正常系は毎秒何千回も実行され、復旧系は数年に一度しか実行されません。そして実行されないコードはテストされていないコードです。「私たちには復旧手順があります」と言うとき、実際に意味しているのはたいてい「復旧手順を記した文書があります」です。文書はコンパイルされません。

その夜Coinbaseが実際に行ったことの一覧が、この点をそのまま示しています — 緊急コード変更をデプロイし、損傷したプレイスメントグループの外に新しいノードグループを作り、3-of-5クォーラムを復旧させるための慎重な手順を踏みました。この3つのうちどれもボタン一つではありませんでした。3つとも、その夜が初めての実行に近いものでした。

だからこそ改善項目に「定期的な本番フェイルオーバー訓練」が入ったのです。訓練の目的は、人が手順に慣れることよりもむしろ、復旧経路を実際に動くコードにしておくことです。一度も動かしたことのないフェイルオーバーは、フェイルオーバーではなく仮説です。

マネージドサービスはリスクを消さず、移すだけだ

2つ目の障害モードは、まったく別の層からやって来ました。Coinbaseのイベントストリーミングの大部分は、AWSのマネージドKafkaであるMSKの上で動いています。

マネージドKafkaの約束は明快です。ポストモーテムが整理した表現では、個々のブローカーが死ねばサービスが自動でパーティションリーダーを再選出し、残ったブローカーでトラフィックを処理し続ける、可用性ゾーン全体が飛べば結果は可用性の喪失ではなく容量の低下であるべき、というものです。

そうはなりませんでした。Coinbaseの説明によれば、AWS MSKのコントロールプレーンの不具合が自動パーティションリーダー再選出を妨げ、MSKクラスター2つが「healing」状態に陥ってプロデューサーが書き込めなくなりました。

ここで指摘したい点が2つあります。

第一に、これはクラッシュではなくグレー障害です。 「healing」は死ではありません。死であればむしろ楽です — ヘルスチェックが赤くなり、アラートが鳴り、フェイルオーバーが働きます。「healing」はシステムが自分自身に「私は今回復中だ」と語っている状態であり、その言葉は真かもしれませんし、永遠に真にならないかもしれません。その間、プロデューサーは書き込めません。ダッシュボードは緑でも赤でもなく黄色であり、黄色には自動化が結びついていません。

第二に、自分で直せないことこそが本当のコストです。 自前運用のKafkaであれば、リーダー再選出を手動で強制したり、コントローラーを再起動したりする選択肢があったはずです。MSKではそのレバーは自分の手の中にありません。Coinbaseが最終的に行ったのは、午前3時にAWSのエンジニアリングチームとリアルタイムで手動パーティション再割り当てを行い、トピックを損傷したブローカーから移すことでした。そして改善項目の一つは、「MSKを通じては提供されないKafkaの制御手段」のためのツールとランブックを作ることです。この一文は、マネージドサービスの本当の請求書を驚くほど正確に要約しています — 運用負担をベンダーに渡せば、ベンダーが直せないときは自分も直せません。そのときの復旧時間は、自分のエンジニアリング能力ではなく、ベンダーの対応速度によって決まります。

そしてこの2つ目の障害モードが実際にどれほど高くついたかは、タイムラインが物語っています。クォーラムは午前12時06分に復旧しましたが、市場が開いたのは午前3時49分でした。 3時間43分の隔たりです。Coinbaseは、その遅延が主にMSKの問題によるものだったと直接述べています。合意クラスターを蘇らせることと、サービスを蘇らせることは、同じ出来事ではありませんでした。

最も正直な箇所 — 3-AZであっても防げなかった

ポストモーテムには、大半の二次報道が静かに落としてしまった一文があります。Coinbaseは、Kafkaクラスターの一つが2-AZ構成だったために影響範囲(blast radius)と復旧時間が広がったと認めたうえで、すぐにこう付け加えます — ただし、MSKコントロールプレーンの不具合は2-AZクラスターと3-AZクラスターに同程度に影響した、と。

これは自己弁護ではなく、正確さです。そしてこの一文を削れば、この事件から学べることは半分に減ります。

ここから得られる教訓はこうです。データプレーンの冗長性は、コントロールプレーンの障害を修復しません。 3つ目のAZを追加するというのは、「ブローカーがもう一つ多くある場所がもう一つ増える」ということです。しかし問題がブローカーの不足ではなく、リーダーを選ぶはずの主体がリーダーを選べないことであるなら、AZをもう一つ足しても、リーダーの選べないブローカーの山がもう一つ増えるだけです。冗長性はコントローラーが生きているときにしか価値を持ちません。

注目すべきは、Coinbaseがそれでも2-AZクラスターを3-AZへ移すと書いている点です。これは正しい判断です — 3-AZは今も2-AZより優れており、「今回は役に立たなかった」ことは「次回も役に立たない」ことを意味しないからです。ただし、それを「今回の障害の解決策」として包装してはいません。改善項目が根本原因を解決したふりをしないポストモーテムは、思っているより珍しいものです。

タイムラインを読み直すと、単一原因の物語は崩れる

この事件は、現在おおむねこう語られています。「Raftクラスターがクォーラムを失ったので、Coinbaseは止まった」。すっきりしていて、覚えやすく、タイムラインと合いません。

取引が止まったのは午後7時48分です。マッチングエンジンがクォーラムを失ったのは午後9時29分です。取引はクォーラムが崩れる1時間41分前に、すでに止まっていました。

では午後7時48分に何が取引を止めたのか。ポストモーテムはこれを明示していません。ただしMSKの問題を説明する中で、その波及が手数料サービスを止め、手数料サービスが止まると気配値の算出が止まり、そのため大半の顧客はこの事件をKafka障害としてではなく壊れたマッチングと壊れた気配値として経験した、と記しています。台帳パイプラインの一部や決済、複数のデータパイプラインも同様の形で影響を受けたとのことです。

状況証拠はそちらを指していますが、ポストモーテムが午後7時48分の因果を明示していない以上、私もそれを断定しません。ここで自信を持って言えることは、より慎重であると同時に、より有用です — タイムラインだけでも単一原因の物語が誤りであることは証明されます。 そしてCoinbase自身のフレーミングもまさにそれです。局所的なクラウド事業者の事件を数時間規模のプラットフォーム障害に押し上げたのは2つの障害モードであり、それぞれは独立して復旧可能だったが、重なったことで増幅された、というのです。

これが大規模障害が実際に起きる仕組みです。一つの根本原因ではなく、普段は互いを知らない2つの欠陥が同じ夜に出会う。そして事後に私たちはそのうち一番絵になるもの(「合意クラスターがクォーラムを失った」)を選び、事件全体の名前として使います。その瞬間、残り半分の教訓は消えます。ちなみに、こうした事後の再構成に警戒しようというのが、まさにブレームレスポストモーテム文化が実際に守ろうとしているものでもあります。

AZは障害の最小単位ではない

最後に、この事件が揺さぶったメンタルモデルがもう一つあります。

Coinbaseは、自分たち(そしてほとんどのAWS顧客)が設計基準とする原則をポストモーテムに明記しています — 可用性ゾーン一つは丸ごと死にうるし、正しく設計されたシステムは残ったゾーンでサービスを続けるべきだ、と。そしてこの種の障害は、ハイパースケール事業者が可用性ゾーンの境界で吸収するよう設計されているものだ、と。

しかし実際に死んだのは可用性ゾーンではありませんでした。一つのデータホールでした。AZより小さいのです。

ここに皮肉があります。障害はAZより小さかったのに、5ノードクラスターの3ノードを奪いました。なぜならプレイスメントグループの影響範囲もAZより小さかったからです。2つの小さな円が重なったのです。「AZ単位で考える」という習慣は、AZより大きな障害(リージョン全体のコントロールプレーン問題)だけでなく、AZより小さな障害に対しても目を曇らせます。問われるべき問いは、自分のレプリカがいくつのAZに散っているかではなく、自分のレプリカがいくつの実際の失敗ドメインに散っているかです。そしてクラスタープレイスメントグループを使った瞬間、その答えはAZの数よりはるかに小さくなります。

CAP定理のような抽象概念が実務でしばしば無力になるのは、まさにこのためです。理論上P(分断)は一つの確率変数ですが、現実にはチラーの配管構造です。

では実務で何を変えるべきか

この事件から正直に持ち帰れることを挙げます。

レプリカではなく、失敗ドメインを数えてください。 「うちのetcdは5ノードです」は答えになりません。問うべきは「その5ノードが同時に死ぬ単一の事象が存在するか」です。同じラック、同じスイッチ、同じ電源、同じデータホール、同じプレイスメントグループ、同じKubernetesノードグループ、同じAMI、同じデプロイパイプライン。このリストのどこかで重なれば、クォーラムの算術はその分だけ嘘になります。

意図的に結合したのなら、出る扉を作って開けてみてください。 コロケーション自体は罪ではありません。Coinbase自身の診断がそれです。問題は結合したまま脱出経路を自動化しなかったことでした。レイテンシのために独立性を売ったのなら、その代金で買ったのは「いつか手でほどかねばならない夜」です。その夜をあらかじめ予約し、リハーサルしてください。

起動コードからトポロジーの前提を見つけ出し、消してください。 「全N個のノードがresolveできて初めて立ち上がる」という条件は、平時にはヘルスチェックに見え、災害時には錠前になります。縮退したクラスターで起動できるかどうかを知る唯一の方法は、実際に縮退したクラスターで起動してみることです。

マネージドサービスにはこの問いを投げかけてください — 壊れたのがコントロールプレーンなら、自分に何ができるのか。 答えが「サポートチケットを開く」であれば、それがあなたのRTOです。そのRTOを受け入れられるかどうかが、マネージドか自前運用かを分ける本当の基準であり、「運用負担」という言葉でひとまとめにされるより、はるかに具体的な問いです。

データプレーンの冗長性とコントロールプレーンの冗長性を区別してください。 AZを増やすのは前者です。コントローラーが動けなくなる障害には効きません。

そして、この事件から学びすぎないでください。 これが一番重要かもしれません。Coinbaseは投票メンバー間のAZホップを許容できないマッチングエンジンを運用する取引所です。あなたのサービスがそのような制約を持たないなら — 大半はそうです — そもそもクラスタープレイスメントグループを使う理由はなく、AWSのデフォルト動作(ハードウェア全体に分散させて相関障害を最小化する)がすでに正しい選択です。このポストモーテムから「低レイテンシのためにノードを密集させるべきだ」を学び取るなら、それはまさに間違った学び方です。学ぶべきはその逆です — 密集させる本物の理由を持つ者ですら、その代償をこれだけ払った、ということです。

おわりに — そしてこの記事が知らないこと

Coinbaseのポストモーテムの最後の段落には、こういう趣旨の一文があります。私たちの基準はAWSに障害があったかどうかには依存せず、それに耐えられるほど頑丈なシステムを自分たちが構築したかどうかにすべてかかっている、と。この一文が本稿全体の要約です。クラウド事業者の障害はあなたの障害の言い訳にはなりません — それはあなたが設計文書に書き込んだ前提に対する採点にすぎません。

ここからは本稿の限界を記します。

私たちは片方の話しか持っていません。 AWSのpost-event summary一覧を確認すると、この2026年5月の熱事件についての公式サマリーも、MSKコントロールプレーンの不具合についての公式サマリーも掲載されていません(直近の項目は2025年10月のDynamoDB事件です)。したがって、MSKの不具合に関して本稿に書かれた内容 — リーダー再選出が妨げられた、クラスターが「healing」に陥った、2-AZと3-AZが同程度に影響を受けた — はすべてCoinbase側の説明です。AWSが検証または確認した事実ではありません。Coinbase自身も6月1日時点で、この不具合についてAWSと共にまだ根本原因分析を続けていると記しています。したがってこの部分は暫定的なものとして読むのが妥当です。

そして私たちは午後7時48分の真相を知りません。 前述のとおり、ポストモーテムは最初の取引停止の因果を明示していません。状況証拠はありますが、確認はありません。

こうした空白が残るのが、このジャンルの現実です。ポストモーテムは真実の写しではなく、それを書いた組織がその時点で知っていて、語ることができたことの写しです。それでもCoinbaseの記事は読む価値があります — 自分たちの選択を弁護しながら、同時にその選択の代償を書き、自分たちの改善項目が根本原因を解決していないことまで記しているからです。この2つを同時に行う記事は珍しいものです。