OpenAI、18年物のバグをコアダンプの大量分析で発見

OpenAIは、傘下のリアルタイムデータ基盤「Rockset」で数か月にわたり原因不明のクラッシュが発生していた問題について、コアダンプ（クラッシュ時のメモリ情報）を大量に集めて分析する「疫学的」手法で原因を突き止めたと、同社エンジニアリングブログで報告した。従来は個別のクラッシュを一件ずつ調査していたが埒が明かず、過去1年分のコアダンプを自動収集・分類するパイプラインを構築したところ、実は性質の異なる2つの不具合が重なっていたことが判明したという。1つはオープンソースライブラリ「GNU libunwind」に18年間潜んでいたレース条件（競合状態）のバグ、もう1つはAzure上の特定サーバー1台で起きていたハードウェアの静かな破損だった。同社はlibunwindの修正を本家プロジェクトに還元しており、同様の構成で稼働する他社サービスにも影響がある可能性があるとしている。

背景と詳細

Rocksetは2024年にOpenAIが買収したリアルタイムデータシステムで、報道によれば同社内のデータ基盤の一部を担っている。このRocksetで、C++プログラムが実行時に破損したアドレスやNULLアドレスへ処理を戻してしまうという、極めて再現性の低いクラッシュが継続的に発生していた。OpenAIのエンジニアはコントロールされたテスト環境ではこの不具合を再現できず、当初は単一の原因を想定して個別のクラッシュログを人手で調べていたが、数か月間手がかりをつかめずにいたと報じられている。

転機となったのは、個々のクラッシュを追うのではなく、疫学調査のように「クラッシュ全体の母集団」を対象にデータを集める発想への転換だったという。OpenAIのチームはChatGPTを使って、各コアダンプファイルの先頭部分をダウンロードしてレジスタ情報を抽出し、既知の誤検知を除外するスクリプトを作成し、過去1年間に発生した全クラッシュのコアダンプを自動的に分析するパイプラインを構築した。

この大規模分析によって、これまで1つの現象として扱われていたクラッシュ群が、実際には性質の異なる2つのクラスタに分かれることが分かった。1つは、GNU libunwindというオープンソースライブラリに18年間存在し続けていたレース条件で、スタックポインタを更新するアセンブリ命令の実行から、復帰先の命令ポインタが読み込まれるまでのごく短い時間帯（報道によれば約100ピコ秒の間）にシグナルが到着すると、カーネルが処理中のコンテキストを上書きし、復元される命令ポインタが破損するというものだった。もう1つは、Azure上の特定のホスト1台で起きていた、検知されにくい静かなハードウェア破損だったという。

OpenAIはこれを受けて、Rocksetのスタック巻き戻し処理をGNU libunwindからlibgcc由来のアンワインダーに切り替えて回避するとともに、libunwind自体の修正をエンジニアのNathan Bronson氏が本家プロジェクトへアップストリームで提供したと報じられている。libunwindはさまざまなソフトウェアで広く使われているライブラリであるため、例外処理やシグナル処理を大量に行うC++サービスを運用する他の組織にも同様の潜在バグが存在し得るとしている。

なぜ重要か

今回の事例は、AIサービスの裏側を支える地味なインフラ層にも、長年気づかれなかった不具合が潜み得ることを改めて示している。日本国内でもAIチャットボットやデータ基盤の運用が急速に広がっており、原因不明の障害調査を「個別調査」から「大規模データを俯瞰する」アプローチへ転換する発想は、システム運用に携わるエンジニアにとって参考になりそうだ。またlibunwindは業界で広く使われるオープンソースライブラリであるため、同様の構成でサービスを運用している国内企業も無縁ではない可能性がある。生成AIを実務に使ってバグ調査用のスクリプトを書かせたという点も、AIにツールを使わせる仕組みの一事例として注目される。OpenAIは他にも自社設計の推論特化型AIチップ「Jalapeño」を発表するなど、AIサービスを支えるインフラへの投資を続けている。

今後の見通し

OpenAIはすでにlibunwindプロジェクトへ修正を提供したとしており、今後この修正が同ライブラリの正式リリースに取り込まれれば、同様の構成を持つ他のサービスの潜在的なクラッシュリスクも軽減される可能性がある。ただし、修正の反映状況や適用範囲について続報があるかは現時点では分かっておらず、今後の動向を注視する必要がありそうだ。