ChatGPTの大規模障害、原因は新規テレメトリサービスとOpenAIが報告

水曜日の午後、ChatGPTが突然動かなくなって困った人は少なくないはずです。

OpenAIは同社の歴史の中でも最長クラスとなる大規模障害に見舞われました。対話型AIのChatGPTだけでなく、動画生成AIのSora、開発者向けAPIまでもが太平洋時間の午後3時頃から約3時間にわたって完全にストップしました。

サイバー攻撃や新機能リリースによる過負荷が疑われましたが、木曜夜に公開された障害報告書によると、原因は意外にも「社内の監視サービス」でした。

監視ツールが自社サーバーをダウンさせた

OpenAIの説明によると、原因はKubernetesの稼働状況を収集するために水曜日に導入された新しいテレメトリ（遠隔監視）サービスでした。Kubernetesは、同社の膨大なシステムを動かすコンテナ環境を管理するオープンソース基盤です。

監視サービスはシステム全体に広く関与するため、設定の不備によって意図せず大量のリソース消費を伴うKubernetes APIリクエストが発生してしまいました。

その結果、APIサーバーが処理能力を超えてパンクし、大規模クラスターの大部分でコントロールプレーンが停止する事態に陥りました。

さらに悪影響は連鎖しました。各サービスが名前解決に依存しているDNS処理が機能不全に陥ったほか、通常はアクセスを高速化するDNSキャッシュが障害の検知を遅らせる要因となり、問題が把握される前に監視ツールの展開が進んでしまいました。

締め出されたエンジニアたち

ユーザーに影響が出る数分前に異常自体は検知されていたものの、復旧には長い時間がかかりました。

Kubernetesサーバーが完全に過負荷に陥っていたため、エンジニアが管理画面にアクセスできなくなる「締め出し」状態が発生したためです。

OpenAIは複数のシステムとプロセスが同時に予期せぬ形で連鎖障害を起こしたと説明し、事前のテストでこの影響を検知できなかったことを認めました。今後は段階的な導入プロセスの見直しや、どのような状況でもKubernetesサーバーへアクセスできる復旧経路を確保するとしています。

なぜ重要か

今回の3時間にわたる全面停止は、OpenAIのAPIに基幹業務を依存している企業や開発者にとって重い教訓となります。

開発者視点で見れば、単一のAIプロバイダーだけに依存するリスクが浮き彫りになりました。サービスが止まれば自社の顧客体験が直接損なわれます。現時点でOpenAIの障害時に自動で代替モデルへ切り替えるフォールバック体制を組んでおく価値は非常に高いと言えます。

業界全体にとっても、最先端AIの急拡大に対してインフラ運用が追いついていない現実を示しています。サイバー攻撃ではなく自社の監視ツールの設定ミスで基幹システム全体が巻き込まれる脆弱さは、どれほど巨大なAI企業であっても例外ではありません。

事後レポートで詳細を包み隠さず公表した姿勢は評価できますが、Soraなど負荷の高いサービスが今後本格化する中で、足元のインフラの堅牢性をどこまで高められるかがOpenAIの信頼を大きく左右することになりそうです。