AIエージェントがKubernetesの隠れた障害を発見 — 1時間毎クラッシュの真犯人はWireGuard

5月1日、Lovableのインフラエンジニアが「A Bug Hunt in Our Kubernetes Cluster」と題した記事を公開した。この記事では、AIエージェントを活用したログ解析により発見されたKubernetesクラスターの複雑なネットワーク障害について詳しく紹介されている。

AIエージェント時代の新しいデバッグ手法

クラウドネイティブアプリケーションの普及に伴い、Kubernetesクラスターでの障害分析はますます複雑化している。従来の手動ログ解析では限界があり、特に大規模環境では膨大なログデータから問題を特定するのは困難だ。この課題に対し、AIエージェントを活用した自動化されたデバッグが新たなソリューションとして注目されている。

Lovableは開発者向けのフルスタックWebアプリケーション構築プラットフォームで、ピーク時に毎秒50個以上のサンドボックスを動的に生成している。先週、ユーザーがプロジェクトオープンの失敗やGitHubクローンのタイムアウトなど、断続的な障害に遭遇し始めた。

従来の手動ログ解析では限界があるため、エンジニアのSaschaはAIエージェントを使った新しいデバッグアプローチを試行した。ClickHouseログにアクセスできるAIエージェントに質問を投げかけたところ、驚くべき事実が判明した。

1時間毎のクラッシュパターンをAIが発見

Google Kubernetes Engine（GKE）クラスター内のanetdポッドが6日間で120回、つまりほぼ1時間に1回クラッシュしていたのである。anetdはGoogleによるCiliumベースのネットワーキング実装で、Kubernetesクラスター内のネットワーク層を担当している。

このコンポーネントがクラッシュすると、新しいポッドがネットワークインターフェースを取得できなくなり、継続的なサンドボックス生成に依存するサービスで直接的な障害が発生する。従来であれば、このような規則的なクラッシュパターンを発見するには膨大な時間を要していたが、AIエージェントは瞬時に異常を特定した。

WireGuardモジュール内の並行性バグ

詳細なクラッシュダンプ分析により、concurrent map-access panicが特定された。これは複数のgoroutineが適切なロックなしで同じデータ構造にアクセスしようとした際に発生するGoの典型的なバグパターンである。

重要な発見は、パニックの発生場所だった。問題はanetdのWireGuardモジュール内部、具体的にはWireGuard接続を追跡するマップデータ構造への並行アクセス管理部分で発生していた。

WireGuardは高性能な暗号化VPNプロトコルで、近年多くのクラウドプロバイダーがノード間通信の暗号化に採用している。Googleでは透明なノード間暗号化として提供されているが、このケースではGoogleのanetd統合コードに並行性制御の不備があったことが判明した。

Googleサポートとの緊急対応

日曜日にもかかわらず、Googleのアカウントチームとの緊急通話が実施された。彼らの推奨は明確だった：透明なノード間暗号化を無効にしてWireGuardモジュールを回避する。

セキュリティの観点では理想的ではないが、クラスターはすでにGoogleのプライベートネットワーク上で動作しており、安定性を優先する判断が下された。変更をロールアウトし、全anetdポッドを再起動すると、クラッシュは停止した。

しかし、約4時間後、再び問題が発生した。

第二の障害：MTU不一致による分散システムの複雑性

今度はValkey（Redisフォーク）への接続がランダムに失敗し始めた。最初はValkey自体を疑いノード数を倍増したが、エラーは継続した。

エンジニアのErikがネットワークレベルの調査を開始し、tcpdumpでパケットキャプチャを実施した。Wiresharkでの分析により、決定的な証拠が発見された：

"Destination unreachable (Fragmentation needed)."

MTU不一致の根本原因

問題の核心はMTU（最大転送単位）の不一致だった。WireGuard有効時、クラスターは暗号化オーバーヘッドを考慮してMTU 1420バイトを使用していた。WireGuardを無効化した際、設定は1500バイトに変更されるはずだったが、一部ノードが再起動されておらず、古い1420バイト設定を維持していた。

この不一致は特にValkey接続に影響した。APIポッドがどのノードで実行されるかによって、接続が成功するか神秘的に失敗するかが決まった。解決策は全ノードの再ロールによる一貫したMTU設定の確立だった。

分散システム障害の教訓とAIの可能性

3時間以上に及んだGoogleチームとの技術セッションを通じて、重要な洞察が得られた。分散システムでは単一層での障害は稀で、多くの場合複数の問題が連鎖している。WireGuardクラッシュが第一層、MTU不一致が隠れた第二層で、最初の修正後にのみ顕在化した。

Lovableのような大量のポッド作成・削除を行う顧客は少なく、彼らが未発見のバグを表面化させていた。Googleは後日WireGuardの並行性バグにパッチを適用し、多くの顧客の利益となった。

今回の事例で特筆すべきは、AIエージェントによる初期発見の重要性である。従来であれば発見に数日を要したであろう規則的なクラッシュパターンを、AIが瞬時に特定したことで、迅速な問題解決への道筋が開かれた。これは、現代の複雑なクラウドインフラにおける障害対応の新たな標準となる可能性を示している。

詳細はA Bug Hunt in Our Kubernetes Clusterを参照していただきたい。