OpenAIのポストモーテムを拝見する

はじめに

2024 年 12 月 11 日、OpenAI で大規模な障害が発生し、ChatGPT、API、Sora など全サービスが約 4 時間にわたってダウンしました。今回はそのポストモーテムを読んで、いくつかの興味深いポイントをピックアップしてみます。

背景

OpenAI のバックエンドは、マルチリージョンで稼働されている Kubernetes クラスタで構成されています。

Kubernetes クラスタは大きく分けて 2 つの部分から構成されています:

1. コントロールプレーン

   • クラスタの管理
   • API サーバー、DNS などの重要なコンポーネントの管理
   • クラスタ全体の状態管理

2. データプレーン

   • 実際のワークロード(モデル推論など)を実行
   • 数千台のノードで構成
   • 通常はコントロールプレーンに依存せず動作可能

今回の障害は、クラスタの監視強化のために導入された新しいテレメトリーサービスが、このコントロールプレーンに予期せぬ負荷をかけたことが発端となっています。

障害の概要

• 発生期間: 2024/12/11 15:16 PST ~ 19:38 PST (約 4 時間)
• 影響: すべての OpenAI サービスが利用不可または著しい機能低下
• 原因: 新しい監視用テレメトリーサービスのデプロイメントによる Kubernetes コントロールプレーンの過負荷

興味深いポイント

1. 小さな変更が大規模障害を引き起こす

新しい監視ツールの導入という、一見すると単純な変更が全サービスのダウンを引き起こしました。これは以下の要因が重なったためです:

• クラスタサイズに応じてスケールする予期せぬ API 負荷
• DNS キャッシュによる問題の遅延的な顕在化
• テスト環境では発見できなかった大規模クラスタ特有の問題

2. 復旧を困難にした"ロックアウト効果"

障害発生から原因判明まで 3 分しかかからなかったのになぜ復旧に 4 時間もかかったのか？

問題を修正するために必要な Kubernetes API サーバーに、その問題自体によってアクセスできなくなるという"ロックアウト効果"です。これにより復旧作業が著しく困難になりました。

3. マルチレイヤーでの対策

OpenAI は再発防止のため、以下のような複数レイヤーでの対策を計画しています:

1. より堅牢な段階的ロールアウト
2. 障害テスト
3. 緊急時のコントロールプレーンアクセス確保
4. データプレーンとコントロールプレーンの分離
5. より高速な復旧メカニズム

教訓

このインシデントから得られる主な教訓は:

1. 変更の影響は非線形的にスケールする可能性がある
2. テスト環境と本番環境の差異を常に意識する必要性
3. 復旧手段自体が障害の影響を受けないようにする重要性
4. システムの依存関係を最小限に抑える設計の重要性

まとめ

今回 OpenAI のポストモーテムを読んで、SRE としての視点でいくつかのポイントをピックアップしてみました。
OpenAI のような大規模なシステムを経験する機会はあまりないと思いますが、
障害原因特定の早さ、アーキテクチャの設計、復旧手段の冗長性確保など、まだまだ学ぶことは多いです。

今の時代でいろんなサービスがネットワーク経由で提供しており、裏側に安定したインフラの維持が不可欠です。
ちょっとした変更でも、予期せぬ影響を与える可能性があること、企業に対して大きな損失を与える可能性があることを常に意識しておくことが大切です。

[参考文献]

• OpenAI Status - Incident Report