JetBrainsはTeamCity向けにWarm Agentsプラグインをリリースした。これは、継続的インテグレーションおよび継続的デリバリー環境で特に頻繁に発生する遅延の一つ、つまりテストやビルドの開始前にクラウドビルドエージェントが起動するのを待つ問題に対処するものだ。このプラグインでは、各クラウドイメージについて、アイドル状態で起動済みのエージェントを目標数維持できるため、指定した水準を下回るとTeamCityが直ちに新しいエージェントの提供を開始する。
このプラグインはTeamCityがサポートするあらゆるクラウドプロバイダーで動作するため、ビルド基盤全体を常時稼働させるのではなく、一時的なエージェントを利用するチームに適している。特に、環境の準備時間が実行時間を上回る可能性のある短時間のタスクを対象としている。起動の遅いクラウドWindowsエージェントによって、1分で完了するテストがさらに数分間キューで待機する場合もある。
実際に何が変わるのか？
タスクの到着時にのみエージェントを作成するのではなく、TeamCityは各クラウドイメージのアイドル状態のエージェント数を監視し、その数が目標を下回ると新しいインスタンスを起動する。数はREST API、またはProject Settings | Integrations | Warm Agentsのパスにあるプロジェクト設定から調整できる。特定のイメージについて準備済みエージェントの維持を停止するには、目標を0に設定する。
このプラグインにはTeamCity 2024.12.3以降、プロジェクト内で設定済みのクラウドプロファイルとクラウドイメージ、さらにManage project’s agent cloud profiles権限が必要となる。JetBrains Marketplaceからインストールして有効化した後は、REST APIまたはteamcity-cliツールで管理できる。
速度の代償とスケーリングの制限
Warm Agentsは無料で高速化を提供するものではない。稼働中の準備済みエージェントはすべてビルドエージェントライセンスを消費し、アイドル状態のクラウドインスタンスもクラウドプロバイダーにコストを発生させ続ける。そのため、このプラグインは待機時間と運用支出の間に明確なトレードオフをもたらす。実際の需要が低い場合、目標値を増やしても必ずしも実用上の改善にはつながらない。
クラウドイメージに設定された稼働インスタンスの上限は、エージェント目標数がそれを上回る値に設定されていても、TeamCityによって尊重される。また、インスタンスは短い間隔を空けてバッチ単位で起動されるため、高い目標に到達するまでには時間がかかる場合がある。目標を引き下げた場合も、TeamCityは稼働中のエージェントを強制的に停止しない。クラウドイメージに定義されたアイドルタイムアウトは引き続き有効であり、目標数を維持するため、停止したインスタンスの一部が再起動される可能性がある。
スケジューリングと計測
JetBrainsは、需要パターンに応じて目標値を変更するため、スケジュールされたタスクを利用することを提案している。たとえば、朝に引き上げ、夜には0に下げるといった設定だ。これはKotlin DSLとREST API呼び出しによって実行でき、OAuthトークンはビルドログに表示されないよう、パスワード型のパラメーターとして保存する。
また、このプラグインは各クラウドイメージについて、使用率や飽和度の指標を含むPrometheus形式のメトリクスを提供する。これによりチームは、需要のピーク時間帯や、準備済みエージェント数がキューに並ぶタスク数に追随しているかどうかを把握できる。複数ノードの環境では、専用のCookieプロファイルを通じてメトリクスのリクエストをメインノードに送る必要がある。
なぜこのニュースが重要なのか？
このプラグインは、エージェントの準備にかかる時間を、予測不能な遅延から調整・監視可能なリソースへと直接変換する仕組みを提供する。その実用的な価値は、短時間のタスクを反復的に実行するチームや、予測可能な需要ピークがあるチームでより大きくなる。一方、断続的にしか稼働しないプロジェクトでは、ウォームエージェントを維持するコストを正当化できない可能性がある。そのため、導入にあたってはアイドル状態のコストと実際の待機時間を比較し、固定された高い数値を選ぶのではなく、メトリクスを利用して目標値を調整する必要がある。