2026年8月27日未明、Protonで広範囲にわたる障害が発生し、一部のユーザーのサービスに影響が生じました。根本的な原因は、フランクフルトのデータセンターにおける冷却システムの完全な停止でした。Protonのすべてのシステムは冗長化されており、データセンター全体の障害にも耐えうる十分なキャパシティを備えていますが、フェイルオーバーに通常より時間を要し、ユーザーに影響を与える中断につながる少数のシナリオが存在します。

ここでは、何が起きたのかのタイムライン、インシデント発生時の判断とその理由、そしてどのように解決されたかについて説明します。

タイムライン

8月26日（水）午後11時（中央ヨーロッパ時間）過ぎ、フランクフルトデータセンターのメインルームで冷却システムの障害が発生しました。午後11時15分頃には、30分足らずで温度が約21.8℃（通常温度）から51.9℃まで上昇し始め、室内の測定プローブの中には気温60℃を報告するものもありました。温度の上昇に伴い、施設内のサーバーおよびネットワーク機器が次々と停止し始めました。

ユーザーへの影響を伴うインシデントは、障害が拡大して重要な冗長性が失われた8月27日深夜0時頃に始まりました。これは、重要なラック上のプライマリーおよびバックアップのネットワークスイッチの両方が故障したことで発生し、不運にもこのラックには複数のプライマリーデータベースのコピーが含まれていました。Protonのほぼすべてのシステムは冗長化されており、自動的かつ即座にフェイルオーバーしますが、プライマリーデータベースのフェイルオーバーは人による監視なしに自動では行われません。

この制御を手動で行っているのは、いわゆる「スプリットブレイン」状態を回避するためです。スプリットブレインとは、プライマリーデータベースが一時的に利用不能になることでレプリカが一部の更新を見逃し、後から整合性を取ることが困難な形で同期ずれを起こす現象を指します。さらに、プライマリーデータベースのフェイルオーバーが発生した場合、レイテンシとパフォーマンスの理由から同じデータセンター内のレプリカにフェイルオーバーするのが標準的な運用手順です。しかし今回の問題の性質上、同様にダウンする可能性のある対象へとフェイルオーバーしてしまう恐れがあったため、この手順は賢明ではない可能性がありました。

下された決断

この時点で、Protonのオンコールエンジニアは極限のプレッシャーの中で、いくつかの重大な判断を下す必要がありました。

  • サービスのオンライン復旧を優先するか、それとも冷却問題への対処とデータセンター内のハードウェアの保護を優先するか？
  • フランクフルトの同じ建物内のレプリカにフェイルオーバーすべきか（より迅速で影響も少ないが、熱を制御できなければ一時しのぎにすぎない可能性がある）、それともチューリッヒにフェイルオーバーすべきか？
  • すべてをフェイルオーバーするのか、それとも現時点でダウンしているものだけにするのか？ 完全なデータセンター障害に対しては、すべてが迅速かつほぼ自動的にフェイルオーバーする緊急時対応策が用意されていますが、個々のサーバーが無作為に次々と停止していくような状況は、フェイルオーバーロジックではうまく対処できません。

最終的に、温度上昇のペースが速かったことから、サービスのオンライン復旧よりもハードウェアの保護を優先せざるを得ませんでした。冷却システムは通常冗長化されており、冷却機能が完全に失われることは極めて稀で、温度が危険水域に達するまでには十分な時間があるため、通常はこのような選択を迫られることはありません。近年のAI向け高出力CPUやGPUによるサーバーの電力密度の急激な増加が、この問題をさらに悪化させました。その結果、以前なら危険水準に達するまで3〜4時間かかっていたものが、わずか20分で危険水準に達してしまいました。

そのため、オンコールチームはハードウェアを保護するために可能な限り多くのサーバーの電源を落としつつ、冷却機能を復旧させるために現地のデータセンター運用チームとの連絡に集中しました。昨今のAIブームに伴うサーバー機器の不足により、これらの機器の多くは一度失われると短期間での交換が不可能です。ダウンタイムが長期化するリスクを冒してでも、機器の保護を最優先にする必要がありました。

00:45 CESTまでに冷却機能を復旧させ、施設内の温度が下がり始めたため、オンコールチームはサービスの回復へと焦点を移しました。この時点で、トラフィックの流れを大きく変えて新たな不安定要因を生み出すのを避けるため、レプリカがまだ稼働している場合はプライマリーデータベースをフランクフルトへフェイルオーバーし、フランクフルトに稼働中のレプリカがない場合はチューリッヒへフェイルオーバーする判断を下しました。冷却が制御下に入った今、フランクフルトをオンラインに復帰させるのは比較的容易であり、チューリッヒに切り替えるよりも早いと判断したため、この選択肢が選ばれました。

しかし、残念ながら事態はそのようには進みませんでした。障害発生中、フランクフルトのインフラにある多くのネットワークカードが105℃（通常の動作温度は45℃）に達し、これによって特殊な温度保護モードがトリガーされ、コールドシステムリセットが行われるまでネットワークカードが無効化されてしまいました。当社のセキュリティ態勢によりシステムのアウトオブバンドコントローラーへのアクセスが制限されていたため、回復作業を支援するために追加のスタッフを起こす必要がありました。

01:30 CESTまでに、大半のユーザーに対して大半のサービスをオンラインに復帰させることができました。ただし、プッシュ通知や決済処理など、一部の重要度の低いシステムは02:00 CEST頃まで回復しませんでした。

初期のインシデントレポートで報告したとおり、メールの消失はありませんでしたが、インシデント発生中は送受信両方のメール配信に遅延が生じました。

ユーザー向けサービスは完全に復元されたものの、エンジニア、特にデータベースチームにとって夜はまだ終わりませんでした。一部のプライマリーデータベースがチューリッヒにあり、他はフランクフルトにあるという極めて異常な状態にインフラが置かれ、そのいくつかは冗長性やパフォーマンスが低下した状態で稼働していました。チームはこれらの問題の中で最も差し迫ったものを解決するために徹夜で作業し、完全な冗長性を復元するための作業は8月27日の日中も続けられました。

インフラのほぼすべてを保護することができましたが、残念ながら一部のサーバーは熱により故障（ヒートデス）し、生き残った機器の寿命にこの過熱障害が影響を与えるかどうかはまだ分かっていません。

根本原因と今後のステップ

8月27日のその後の調査により、冷却障害の根本原因は、冷却システムに電力を供給する冗長化された両方のエアコンプレッサーのエアフィルター交換にあったことが判明しました。残念ながら、データセンター事業者はこの作業を事前の通知なしに深夜に行い、冷却障害が発生した際にもその連絡を怠ったため、当社の対応時間が大幅に削られることになりました。当社は、このようなインシデントの再発を防ぐため、事業者と緊密に連携しています。

しかし、この種の障害によって通常よりも復旧プロセスが長引く可能性があることは、現在のデータベースインフラの既知の制限事項でもあります。今回のインシデントにつながった一連の出来事は極めて起こり得ないものでしたが、現実に発生してしまいました。

この障害モードに対処するために必要なデータベースの回復力強化の取り組みはすでに進行中であり、年内に完了する予定です。新しいデータセンターのスペースを含む追加のインフラキャパシティも現在立ち上げ中であり、数週間以内に利用可能になる見込みで、これにより単一サイトへの依存度がさらに低減されます。

不運にも、これらの改善が完全に整う前に今回のインシデントが発生してしまいました。現在、重要なデータベースインフラの変更に必要な慎重さを維持しつつ、残りの作業をどこで安全に加速できるかを検討しています。

ユーザーの皆様がProtonに極めて高い信頼性を期待されていることを当社は認識しており、今回のインシデントは、この作業を完了させてレジリエンス基準を向上させ続ける重要性を再認識させるものとなりました。影響を受けられたすべてのユーザーの皆様に、心より深くお詫び申し上げます。