サーバーが00:32に電源喪失、08:18に判明した経緯

解決済み。このインシデントは2026年8月17日00:32 UTCから08:47 UTCまで発生し、現在はクローズしています。顧客データは一切失われず、破損も漏洩もしていません。この期間中にデプロイメントが失敗した場合、自動的に再試行されることはありませんでした。再度トリガーすれば実行されます。以下は、発生した事象と変更点の全容です。 2026年8月17日日曜日、午前00:32 UTCに当社のストレージサーバーの1台が電源を失いました。再起動もせず、クラッシュもせず、ただ停止し、エンジニアが午前08:22 UTCに手動で電源ボタンを押すまでそのままの状態でした。8時間15分にわたり、S3互換オブジェクトストレージ、コンテナレジストリ、サーバーレスデプロイメント、静的サイトデプロイメントが利用不能になりました。稼働中のアプリケーションはサービスを提供し続けました。データは失われていません。 当社のステータスページは障害を検知し、インシデントを00:35 UTCに開始しました。障害発生からわずか3分後でした。ステータスページは正確で、公開されており、障害発生中ずっと稼働していました。しかし、誰もそれに気づきませんでした。担当エンジニアが別の理由でステータスページを開いた午前08:18 UTCに、多くのサービスが赤くなっている理由を尋ねるまで、私たちは事態を把握していませんでした。システムが障害を認識してから人がそれを認識するまでのこのギャップこそが、真のインシデントです。それ以外はすべて詳細に過ぎません。 顧客が見たもの 障害の原因は1つでしたが、症状は4つあり、それがステータスページが単一のサーバー障害よりも悪く見えた理由です。オブジェクトストレージは応答遅延ではなく、接続拒否を返しました。S3は劣化ではなく、完全に利用不能になりました。コンテナレジストリは、レジストリのブロブがオブジェクトストレージに保存されているため、それに伴ってダウンしました。サーバーレスおよび静的サイトのデプロイメントは、レジストリ経由でイメージをプッシュ・プルするため、失敗しました。失敗したデプロイメントはそのまま失敗し続けました。これらは自動的に再試行されないため、事後に手動での再トリガーが必要でした。既存のワークロードは影響を受けませんでした。アプリケーションは、障害発生中も現在のバージョンを提供し続けました。 1つの詳細が多くの顧客を困惑させました。それは、サーバーレスコンテナの環境変数を変更するだけでもレジストリにアクセスするという点です。Knativeは新しいリビジョンごとにイメージタグをダイジェストに解決するため、既にプッシュしたイメージを再利用するデプロイメントであっても、レジストリがダウンしていると失敗します。障害中に環境変数のみの変更は安全だと想定していた場合、その想定は合理的でしたが、誤りでした。 なぜ1台のマシンがサービス全体をダウンさせたのか これが重要な部分であり、私たちが書くことを予想していなかった部分です。顧客のオブジェクトデータは、イレージャーコーディング（誤り訂訂正符号化）で保存されています。各オブジェクトは4つのデータチャンクと2つのパリティチャンク、合計6つのピースに分割され、そのうち任意の4つでオブジェクトを再構築できます。理論上、これは2つのピースの損失に耐えられます。問題は、その6つのピースがどこに配置されることを許容していたかです。当社のストレージクラスターは、異なるマシンに配置することを要求せずに、個々のディスク間でチャンクを分散させています。各ストレージサーバーは多数のディスクを保持しています。そのため、1台のサーバーが停止すると、各オブジェクトの6つのチャンクのうち平均1.5個が失われました。そして、多数のオブジェクトでは2つまたは3つが失われました。6つ中1つを失う：オブジェクトは引き続き提供されます。2つを失う：安全に提供するために必要な最小値を下回り、読み取りが停止します。3つを失う：再構築に必要な4つを下回り、ディスクが戻るまで読み取れません。これが、障害が部分的ではなく全体的であった理由であり、マシンがオフの間は自己修復できなかった理由です。データは決して失われていませんでした。ハードウェアが戻ってくるまで、単に到達不能だっただけです。 明白な修正策は、6つのチャンクを6台の異なるマシンに配置することです。当日、私たちはそれを実行できませんでした。なぜなら、4+2スキームは6つの障害ドメインを必要とし、当時は4台のストレージマシンで運用していたからです。これは設定フラグ1つで修正できる問題ではありませんでした。それは、デフォルトの後ろに静かに延期されていた容量決定でした。追加のストレージ容量は既に計画されており、オブジェクトストレージのホストレベル冗長性が、このインシデントから最優先で変更される事項です。ここに日付は設定しません。約束して修正するよりも、導入後に発表する方が良いと考えています。 2つ目の小さな問題が事態を悪化させました。バルクデータと並行して、オブジェクトストレージは少量の内部ブックキーピングレコードを保持しており、これはイレージャーコーディングではなく2つのコピーとして保存されています。これらのコピーも同じマシンを共有することが許容されていました。そして、少数のレコード、特にストレージゲートウェイが起動時に読み取るレコードについては、両方のコピーが障害サーバー上にありました。その単一の小さなレコードが、読み取り劣化と接続拒否の違いを生みました。数百テラバイトの顧客データは、それを記述する数キロバイトの設定よりも良好に振る舞いました。この半分には新しいハードウェアは必要ありません。これらのブックキーピングレコードを、既に実行しているサーバー上で3台の別々のマシンに3つのコピーとして移動することは可能です。そして、これは完全な障害を遅い障害に変換する変更です。これはキューの先頭にあります。 ニアミス 発生しなかったもう1つのことがあります。それを伝えないよりも伝える方が良いでしょう。ストレージマシンが消失すると、クラスターは残りのマシン上で失われたコピーの再構築を開始します。これは通常、正しい動作です。この場合、約115 TiBを、間に140 TiBの空き容量を持つ3台のサーバーに再構築することを意味しました。この軌道は97%フルに達し、クラスターが書き込みを完全に停止する閾値を超え、さらなるハードウェア障害なしに、当社の自動化によって読み取り障害を全体障害に変えてしまうことになります。観測された再構築レートでは、それは約5日後でしたので、時間ではなく日がありました。しかし、進むべき方向は間違っており、再構築を抑制していませんでした。構造的な教訓は不快で単純です。利用率71%では、4ノードクラスターはノードの永続的な損失を吸収できません。それを生き残るには、実質的に多くの空き容量またはより多くのマシンが必要です。 電源喪失の原因 私たちは知りませんし、そうでないと偽るつもりもありません。ソフトウェアで確認できる原因はすべて除外されています。カーネルパニック、クラッシュログ、メモリエラー、熱イベントはありませんでした。すべてのドライブは、エラーゼロでヘルスチェックに合格しました。マシンは、停止する前に103日間、カーネル警告なしで連続稼働していました。再起動でもありませんでした。システムログは途中で終了しており、8時間後に手動で電源投入されるまで起動エントリは一切含まれていませんでした。ストレージレイヤーは、シャットダウンではなく突然の電源遮断を独立して確認しました。当社のハードウェアプロバイダーは、その時間帯にデータセンターで電源イベントが発生したことを報告しておらず、マシン自体の監視データもありません。完全なハードウェア検査は利用可能ですが、ストレージノードで約6時間のダウンタイムが必要であり、マシンが正常に稼働している間は、そのコストが回答の価値を上回ります。イベントはサーバーの記録に残っています。もしこれが2回目に発生した場合、すぐに検査を手配します。今回の発生からの証拠があれば、診断は大幅に速くなるでしょう。 同日に変更したこと 回復後数時間以内に2つの変更が実施されました。 1. オンコール担当者への電話通知 このインシデント以前は、プラットフォームインシデントは1人にメールで通知されていました。日曜日の午前00:35に届くメールはアラームではありません。インシデントが当社の公開ステータスページに表示されると、オンコール担当者に電話がかかり、SMSも同時に送信されます。信頼性を高めるために、3つの設計上の選択肢を挙げる価値があります。 - これは意図的に通常の通知システムの外にあります。そのシステムは、プリファレンス、ダイジェスト、レート制限、サイレント期間を適用します。これらは顧客通知にはすべて正しいですが、ページャーにはすべて間違っています。ページは抑制されてはなりません。 - 音声メッセージは、当社のインフラストラクチャ上のページから取得するのではなく、通話リクエスト内に含まれます。報告されている障害は、そのページを提供していた可能性のあるものかもしれません。履歴によってトリガーされることはありません。この非常に詳細な投稿の背後にあるバックフィルされたエントリを含む、事後に書かれたインシデントは無視されます。ポス​​トモーテムが午前3時に電話を鳴らすべきではありません。 2. スイッチ可能なウォッチドッグ