OpenAI、クラッシュ分析で18年前のオープンソースバグとハードウェア障害を特定

本番環境のC++サービスが不可解なクラッシュを起こし、スタックトレースが壊れているとき、通常のデバッグは手詰まりになりがちです。OpenAIが最近直面したのも、まさにそうした奇妙な現象でした。原因を突き止める舞台となったのは、2024年に買収され、ChatGPTの検索やプラグイン、会話履歴検索を支える基盤データエンジン「Rockset」です。

発生していた症状は極めて不可解でした。通常のC++関数が正常に終了した直後、存在しない不正なアドレスへジャンプしてセグメンテーション違反を起こしていました。スタック内の戻り先アドレスが突然NULLになっていたり、スタックポインタが不可解に8バイトずれていたりと、通常のコンパイラ出力では到底考えられない挙動を示していました。

ChatGPTで1年分のコアダンプを疫学調査

エンジニアたちは、1件ずつ原因を突き止める医師のような個別診断を諦め、全体を俯瞰する疫学的なアプローチへと舵を切りました。

そこでChatGPTを活用し、Azureに保存されていた過去1年分の本番環境コアダンプを並列解析する自動化スクリプトを作成しました。各ダンプからレジスタ情報を取り出し、ログと突き合わせて分類したところ、単一の謎のエラーと思われていたものが、実は全く別の2つのバグによる集団であると判明しました。

壊れたCPUと18年前のオープンソースのバグ

データが整理されると、正体はあっけなく割れました。第1の群は、特定のAzure物理ホスト1台だけで発生していました。CPU自体が静かに計算を誤るという、稀に見るハードウェア障害が起きていたのです。

そして第2の群から見つかったのは、広く使われているオープンソースライブラリ「GNU libunwind」に18年間も潜んでいたレースコンディションでした。Rocksetは負荷計測のために高頻度でシグナルを発生させる設計だったため、この古いバグを日常的に踏み抜いていました。この不具合にはすでに修正パッチが適用されています。

なぜ重要か

ユーザー視点では、ChatGPTの検索機能や連携ツールの裏側にあるデータ基盤が安定し、謎のタイムアウトやエラーが減るという実利があります。

今回の事例で特に巧妙だと感じるのは、LLMを使って低レイヤーのバイナリ解析パイプラインを即座に組み上げ、統計的なクラスタリング問題へと落とし込んだ点です。個々の難解なクラッシュログとにらめっこするのではなく、大量のコアダンプを母集団として捉えた判断が勝因と言えます。

同時に、巨大なAIインフラの足元がいかに繊細なバランスの上に成り立っているかを痛感させられます。最先端のAIサービスであっても、実行速度を稼ぐためにC++に頼る以上、四半世紀近く前のOSSのバグやクラウド事業者のハードウェアの気まぐれに足をすくわれます。AIのリアルタイム検索が高度化するにつれ、こうした極限状態でのソフトウェア品質管理が競争力を左右することになりそうです。