この最適化に関する詳細な分析プロセスは、クラウド技術の推進団体であるCloud Native Computing Foundation（CNCF）が主催する技術カンファレンス「KubeCon + CloudNativeCon NA 2025」の基調講演にて、OpenAIの技術スタッフであるファビアン・ポンス氏によって明かされた。

　課題解決に当たり、OpenAIの担当者はOSの性能を細かく分析できるツール「perf」を用いてFluent Bitの動作を調査した。事前の仮説では、メタデータの付与や不要なログのフィルタリングなど、複雑な文字列処理でCPUの処理能力を大量に消費していると推測していた。しかし、分析レポートは全く異なる結果を示した。特定のスレッドにおいて、CPU処理時間の約35％を占めていたのは、ファイルの状態やサイズを取得する「fstat64」というシステムコール（OSの機能を呼び出す仕組み）だったのだ。

　真の原因は、Fluent Bitがデフォルトで利用している、ファイル変更をリアルタイムで検出する「Linux」の標準機能「inotify」の仕様にあった。inotifyはイベントを検出する機能を持つが、どれだけのデータ量が書き込まれたかまでは通知しない。そのためFluent Bitは、イベントを受け取るたびにfstat64を実行し、ファイルサイズを確認して読み取りの再開位置を記録する。

　OpenAIのシステム構成では、個々のプログラム実行環境（Pod）が常時ログを書き込んでいる。そのため、inotifyのイベント通知とそれに伴うfstat64の実行が無限ループのように繰り返され、スレッドがプロセッサの最高速度で回転し続ける「システムコールの嵐」を引き起こしていたのだ。

1行の設定変更が生んだ劇的な効果

　解決手段は極めて簡潔であり、Fluent Bitの設定ファイルに「inotify: false」という1行を追加し、inotifyを完全に無効化することだった。これによって、従来はファイル変更のたびに実行されていたfstat64の処理を、指定した間隔での定期的な確認に切り替えた。最もログ出力が激しいPodに対しても1秒に1回という高頻度で確認する設定に変更したが、それでもinotifyを使用していたときと比較して、実行回数は桁違いに減少した。

　この設定をテスト用のシステムに適用した直後からFluent BitのCPU使用率は半減し、全サーバへの適用後は約3万CPUコアを確保できるようになった。Kubernetesにおいて全サーバに特定のプログラムを常駐させる仕組み「DaemonSet」は、全てのノード（サーバ）に配置される性質上、少しの処理増大がインフラ全体における巨大なコンピューティングリソースの消費に直結する。今回の最適化によって解放された3万コアは、ChatGPTの推論リクエスト処理や新たなAIモデルの実験へと振り向けられ、結果的に同居する他のワークロードのパフォーマンス向上をもたらした。

最適化の知見をエコシステム全体へ

　OpenAIが構築した社内のログシステム「OLogs」は、1日9PBものデータを処理している。このインフラは、全体を管理するKubernetesを中心に、ログ集約のFluent Bit、通信の交通整理を担うプロキシソフトウェア「Envoy」、システムの稼働データを統一形式で収集・分析可能にする「OpenTelemetry」といったオープンソースソフトウェア群で構成されている。同社はこれらの技術を活用して監視機能を内製化し、運用費用の削減を進めている。

　OpenAIは自社システム最適化にとどまらず、得られた知見をオープンソースコミュニティーに還元する方針を固めている。inotifyの即応性を維持しつつ、イベント検出から一定時間経過後に1度だけstatを実行する機能を、Fluent Bitの開発チームに提案している。

　クラウド時代において分散システムによる自由度の高い拡張が一般的になる中でも、根幹となるハードウェアの最適化が果たす役割は依然として大きい。極端な負荷条件下で顕在化した事象の解消は、結果としてコミュニティーが提供するツールの品質を高め、あらゆる利用者の恩恵につながる。

本稿は、CNCFが2025年11月13日に公開した動画「Keynote: How One Line of Code Freed 30,000 CPU Cores: Deep-Diving Fluent Bit at Petabyte... F. Ponce」を基に作成しました。