OpenAIがChatGPTのデータ基盤で発生した不可解なクラッシュを解析し、18年間見過ごされてきたオープンソースライブラリ「libunwind」の競合バグと、特定サーバーのハードウェア不良という2つの原因を同時に特定した。個別の障害調査を超え、全クラッシュを母集団として捉える「コアダンプ疫学」とも呼ぶべき手法が、複雑なインフラ障害の原因究明を変えつつある。

スタックを壊す「ありえない」現象の同時多発

OpenAIの検索基盤「Rockset」で、関数の戻り先アドレスがNULLになる、スタックポインタが8バイトずれるといった不可解なクラッシュが散発していた。通常のメモリ破壊では確率的に起こりにくく、該当コードには問題が見当たらない。調査チームがChatGPTと共に仮説を立てても、すべてを否定する証拠ばかりが積み上がった。この一見不可能に思える現象が、実際には異なる2つの根本原因から同時期に引き起こされていたことが、後の大規模解析で判明する。

個別コアダンプ精査の限界と「疫学」的転換

初期の調査では、少数のコアダンプを詳細に調べる従来型のデバッグ手法が採られたが、異常なクラッシュの原因特定には至らなかった。ここでチームは発想を転換し、全サーバーから収集した大量のコアダンプを一つの母集団として統計的に分析する手法に切り替えた。地域、ハードウェア、ソフトウェアバージョン、エラー種別といった属性で分類し、発生パターンの偏りを見つける「疫学」的アプローチが突破口となった。

ハードウェアの「サイレント」な計算誤りを特定

集団解析の結果、特定のAzureホスト上でのみ、CPUが加算や乗算を稀に誤る「サイレントデータ破壊」が発生している証拠が浮上した。アプリケーションやOSのログには正常と記録される一方で、実際の計算結果が数ビット反転するこの種の障害は検出が極めて難しい。OpenAIは正常なサーバーと異常なサーバーの命令実行結果を比較する大規模な健全性チェックを実装し、問題のあるハードウェアの隔離に成功した。この取り組みは、クラウドの物理層まで視野に入れた信頼性対策の重要性を浮き彫りにしている。

18年潜んだlibunwindの競合が可視化された瞬間

ハードウェア不良を除外した後も残存したクラッシュ群から、スタックトレース取得に使われる「libunwind」の内部で競合状態が発生しているパターンが浮かび上がった。非同期シグナル安全性を欠いたコードが約18年前から存在し、スレッド間のタイミング次第でメモリ破壊を起こしていた。Rocksetの負荷特性がこの競合の発生確率を高めたと考えられる。修正パッチは既にアップストリームに提案され、広範なC++サービスが潜在的に抱えていたリスクの解消につながっている。