先週（12月11日）、OpenAIのChatGPTやSoraなどのサービスが4時間10分にわたって停止し、多くのユーザーに影響が出ました。現在、OpenAIはChatGPTの停止に関する詳細な報告書を正式に発表しています。
簡単に言うと、今回の障害の根本原因は小さな変更でしたが、深刻な結果を引き起こしました。エンジニアは重要な局面で制御面からロックアウトされ、問題に迅速に対処することができませんでした。この障害に対し、OpenAIのエンジニアは問題を発見後、迅速に複数の修復作業を開始しました。これには、クラスタ規模の縮小、Kubernetes管理APIへのネットワークアクセスの阻止、Kubernetes APIサーバーのリソース増加などが含まれます。数回の試行錯誤を経て、エンジニアはようやく一部のKubernetes制御面へのアクセスを回復し、トラフィックを正常なクラスタに転送する措置を講じ、最終的にシステムの完全復旧を実現しました。
事故は太平洋標準時午後3時12分に発生しました。エンジニアはKubernetes（K8S）制御面の指標を収集するために、新しいテレメトリサービスを展開しました。しかし、このサービスの設定が意図せず広範囲に及んだため、各クラスタの各ノードで同時にリソースを大量に消費するK8S API操作が行われました。この状況はAPIサーバーのクラッシュを迅速に引き起こし、ほとんどのクラスタのK8Sデータ面がサービス能力を失いました。
注目すべきは、K8Sデータ面は理論的には制御面から独立して動作できますが、DNSの機能は制御面に依存しているため、サービス間で相互に接続できなくなります。API操作の過負荷により、サービス検出メカニズムが損なわれ、サービス全体が停止しました。問題は3分以内に特定されましたが、エンジニアが制御面にアクセスしてサービスをロールバックできないため、「デッドロック」状態に陥りました。制御面のクラッシュにより、問題のあるサービスを削除できず、復旧できませんでした。
OpenAIのエンジニアはすぐに、クラスタを復旧するためのさまざまな方法を探求し始めました。彼らは、K8SのAPI負荷を軽減するためにクラスタ規模を縮小し、管理K8S APIへのアクセスを阻止してサーバーが正常に動作できるようにすることを試みました。さらに、K8S APIサーバーのリソース構成を拡大して、リクエストをより適切に処理できるようにしました。一連の努力を経て、エンジニアはようやくK8S制御面のコントロールを取り戻し、障害のあるサービスを削除してクラスタを段階的に復旧することができました。
その間、エンジニアはトラフィックを復旧済みのクラスタまたは新しく追加された正常なクラスタに転送して、他のクラスタの負荷を軽減しました。しかし、多くのサービスが同時に復旧しようとしたため、リソース制限が飽和し、復旧プロセスに追加の手動介入が必要となり、一部のクラスタの復旧に時間がかかりました。今回の事故を通して、OpenAIは経験をまとめ、将来同様の状況に遭遇した際に再び「ロックアウト」されるのを防ぐことが期待されます。
報告書の詳細:https://status.openai.com/incidents/ctrsv3lwd797
要点：
🔧 障害原因：小さなテレメトリサービスの変更がK8S API操作の過負荷を引き起こし、サービス停止につながりました。
🚪 エンジニアの困難：制御面のクラッシュによりエンジニアがアクセスできず、問題に対処できませんでした。
⏳ 復旧プロセス：クラスタ規模の縮小やリソース増加などの手段により、最終的にサービスを復旧しました。
