mirrordを使ってステージングクラスタでAI-SREの修正を検証する
本稿では、mirrordをAI-SREツールHolmesGPTと統合し、実際のKubernetesクラスタで自動的に修正をテストする方法を紹介します。2つのシナリオ(エラー率アラートは合格、レイテンシアラートは不合格)を通じて、検証フローを示します。mirrordはビルドやデプロイなしで高速かつ並列にパッチを検証できます。
本稿は2部構成の第2部であり、mirrordをAI-SRE(AIサイトリライアビリティエンジニア)に統合し、実際のクラスタで修正を自律的にテストする方法を紹介します。検証には、セルフホスト可能な唯一のオープンソースAI-SREであるHolmesGPTを使用し、2つのバグを仕込んで合格(PASS)と不合格(REJECT)の両方の結果を実演しました。
フローは次のとおりです。HolmesGPTがアラートを調査してMarkdownレポートを出力し、小さなClaudeラッパーがそのレポートをコードパッチに変換します。検証器はmirrord execを使用して、パッチを適用したコードを実際のクラスタで実行し、未適用のベースラインと比較して、アラートの実際のSLO(サービスレベル目標)に基づいた判定を返します。
デモクラスタには、Python製のチェックアウトサービス、価格設定サービス、および負荷生成Podが含まれています。Prometheusがメトリクスを収集し、AlertmanagerがSLO違反時にアラートを発行します。HolmesGPTはクラスタ内のPodとして実行され、Alertmanagerにサブスクライブしています。アラートが発火すると、HolmesGPTが調査し、レポートを検証器Podに渡します。検証器はブリッジ(Claude呼び出し)を実行してパッチを生成し、mirrord execを使用してパッチ適用後のコードをターゲットPodのネットワークID、環境、マウントで実行します。
シナリオ1:エラー率アラート(合格)。ある変更により、約10%のリクエストが500エラーを返すようになり、CheckoutErrorRateHighアラートが発火しました。HolmesGPTはログからValueErrorを迅速に特定し、ブリッジがitem-3ケースを処理するパッチを生成しました。検証器はベースライン(エラー率10%)とパッチ適用後(0%)で各100リクエストを実行し、SLO条件が満たされず、回帰もなかったため、合格と判定しました。
シナリオ2:レイテンシアラート(不合格)。価格設定サービスにクライアント側のタイムアウトがなく、10回に1回の呼び出しが約1.5秒かかるため、p99レイテンシが300ミリ秒のSLOを超えていました。HolmesGPTはキャッシュの実装を提案し、ブリッジがインメモリTTLキャッシュのパッチを生成しました。検証結果:ベースラインのp99は2162ミリ秒、パッチ適用後も2010ミリ秒で、依然としてSLOを違反していました。p50は99.8%改善しましたが、キャッシュミス時のテールレイテンシが解消されていません。判定は不合格でした。正しい修正はクライアントサイドタイムアウトの追加であり、その場合p99は約330ミリ秒に改善され、合格となりました。
これら2つのシナリオは、検証ループが一見正しそうな修正でも実際には効果がないものを阻止できることを示しています。mirrordの利点は、ビルドやデプロイを必要とせず、実際のクラスタで高速かつ並列に複数のパッチを検証できる点です。関連コードはGitHubで公開されており、ぜひお試しください。