TeamCity クラウドコストの最適化

TeamCity クラウドは、ビルド数の増減に応じて動的にスケーリングできるフルマネージド CI ソリューションをすばやく開始する方法を提供します。ただし、このようにスケールアップの柔軟性が高まると、ビルドクレジットの消費量が増えるため、追加コストが発生するリスクが生じます。

TeamCity クラウドには、ビルドの実行時間を最適化するのに役立つ多くの組み込みメカニズムが用意されていますが、TeamCity クラウドのユーザーとして、必要以上のリソースとクレジットを消費しないようにするためにできることはたくさんあります。

この記事では、ビルドクレジットの消費を最適化し、使用コストを削減するのに役立つヒントと提案を確認します。

要約

提案の概要は次のとおりです。

各ユーザーが VCS のユーザー名の完全なリストを提供していることを確認してください。
パフォーマンスモニターを使用して統計情報を表示し、ボトルネックを特定します。
ビルドエージェントのサイズの適合性を確認してください。
マトリックスビューを使用して、最も集中的なプロジェクトとビルド構成に関するインサイトを取得します。
VCS トリガーの休止期間を定義します。
VCS チェックアウトルールを使用します。
ビルドが長時間実行されたりハングしたりしないように、時間制限を設定します。
一部のビルドには自己ホスト型ビルドエージェントを使用してください。
ビルドチェーンを設定することで、ビルド結果と増分ビルドの再利用を有効にします。
ライブラリまたはパッケージをアーティファクトとして後続のビルド構成に渡します。
広く使用されているビルドエージェントの前払い。
毎月自動的に更新されるリソースを確認します。
サブスクリプションに適したサイズを選択してください。

この記事では、それぞれについてさらに詳しく説明します。

各ユーザーが VCS ユーザー名の完全なリストを入力していることを確認する

TeamCity Cloud サブスクリプションは、アクティブなコミッターの数に基づいています。アクティブなコミッターとは、基本的に、30 日間の期間内に 10 件以上の VCS コミットを行い、最終的に TeamCity によってビルドされる開発者のことです (自動または手動でトリガーされたビルド経由)。ユーザーがアクティブなコミッターとして分類されると、サブスクリプション内のコミッタースロットの 1 つが使用されます。

アクティブなコミッターは VCS ユーザー名によって区別されるため、個々のユーザーが複数のバージョン管理システムに対して異なるユーザー名を持っている場合、TeamCity がそれらのユーザー名を認識していることが重要です。これにより、すべてのユーザーの VCS コミットを 1 人の TeamCity ユーザーに正しく関連付けることができます。これが行われない場合、個々のユーザーは、ユーザー名ごとに 1 つのコミッタースロットを消費します。

ユーザーのプロファイルページにある追加の VCS ユーザー名にデータを入力することにより、TeamCity に追加の VCS ユーザー名を認識させることができます。TeamCity クラウドでは、TeamCity ユーザーごとに最大 3 つの異なる VCS ユーザー名を定義できます。

この方法により、コミッタースロットの最小数を使用できるだけでなく、ユーザーは変更タブで変更を正しく追跡し、プロジェクトページですべての個人ビルドを確認できます。

パフォーマンスモニターを使用して統計を表示し、ボトルネックを特定する

パフォーマンスモニタータブがビルド結果を分析することで潜在的なボトルネックを検出できるかどうかを確認してください。以下にその例を示します。ビルドエージェントの CPU 使用率がビルドの途中で 95% に達しています。これは、より大規模なビルドエージェントが必要になる可能性を提案しています。

より強力な仕様のビルドエージェントを使用するには、ビルド構成にエージェント要件を定義できます。例: 最小メモリ量（RAM）を定義するには、teamcity.agent.hardware.memorySizeMb パラメーターを設定します。このビルド構成でのビルドは、30GB 以上の RAM を搭載したビルドエージェントでのみ実行されます。

ビルドエージェントのサイズの適合性を確認する

すべてのビルドを、パフォーマンスの高いクラウドビルドエージェント（Linux Large など）で実行するように割り当てたくなるかもしれません。実際には、一部のビルドでは、割り当てられたクラウドビルドエージェントの全機能を活用できない場合があります。この良い例は、大規模なインスタンスのすべての CPU コアを利用しないプロセスを実行することです。そのビルドを切り替えて、CPU コアの数が少ない小さなインスタンスで実行すると、ビルドクレジットの消費量を減らすことができます。

ビルド構成内のビルドステップの CPU とメモリの要件が最小限である場合は、プロジェクトのそれらの部分を実行し、より小さなビルドエージェントでチェーンをビルドし、よりリソースを消費するビルド構成用により大きなビルドエージェントを予約するのが合理的です。ビルドチェーンを使用する場合は、各ビルド構成でエージェント要件を定義することにより ( 上記のように)、チェーンの各部分を異なるサイズのビルドエージェントで実行するように割り当てることができます。

パフォーマンスモニタービルド機能は、ビルド全体でのシステムリソースの使用状況に関するインサイトを提供します。これは、使用するクラウドビルドエージェントの適切なサイズを選択できます。

マトリックスビューを使用して、最も集中的なプロジェクトを特定し、構成を構築する

マトリックスは、エージェント画面から使用できるタブです。すべてのプロジェクトとビルド構成の概要を示し、特定の時間枠内のすべてのビルドエージェントにわたる全体的なビルド時間の合計を示します。

多くのプロジェクトまたはビルド構成がある場合、マトリックスビューは、最もビルド集約型のプロジェクトを見つける簡単な方法を提供します。これは、ビルドを実行するのに最適なビルドエージェントのタイプを決定できます。

VCS トリガーの休止期間を定義する

リポジトリに対して短期間に複数のコミットが行われると、個別のビルドが実行される可能性があります（コミットごとに 1 つのビルド）。時間の経過とともに、これらのコミットの多くを 1 つのビルドで組み合わせることができる場合、これはビルドクレジットの過剰な消費につながる可能性があります。

TeamCity は、VCS トリガーでクワイエット期間を指定することにより、これを簡単に実行できます。クワイエット期間は、最後の VCS 変更が検出されてからビルドがキューに追加されるまでの間に TeamCity が維持する時間枠です。定義された期間内にビルド構成で新しい VCS の変更が検出された場合、サイレント期間は新しい変更の検出時間から最初からやり直します。クワイエット期間内に新しい VCS の変更が検出されなかった場合にのみ、ビルドがキューに追加されます。

この例では、VCS トリガーに対して 300 秒（5 分）のクワイエット期間が定義されています。

休止期間の使用に関する重要な注意事項: チェックインごとにビルドをトリガーするオプションを選択した場合、休止期間の設定は無視されます。

複数のコミットが 1 つのビルドに結合されている場合でも、コミットが複数の開発者によって行われた場合でも、変更タブに移動すると、ビルドの変更の完全なリストを確認できます。さらに、ビルドが失敗した場合は、エラーまたは失敗を変更のリストと相互参照して、失敗の原因となった可能性のあるユーザーを確認できます。

VCS チェックアウトルールを使用する

リポジトリ内のファイルまたはディレクトリのサブセットが変更された場合にのみビルドが必要な場合は、VCS チェックアウトルールを指定して不要なビルドを制限することをお勧めします。コミットが VCS ルートのチェックアウトルールパターンのいずれにも一致しない場合、TeamCity はそれを無視します。

長時間実行またはハングしたビルドを防ぐために時間制限を設定する

ビルドが何らかの理由でハングした場合（たとえば、未処理の例外やクラウドビルドエージェントでのプロセスの失敗など）、デフォルトの TeamCity クラウドサーバーのタイムアウトである 120 分に達するまで実行されたままになり、ビルドを消費する可能性があります 120 分間のクレジット。

ビルドの実行に通常 3 分かかることがわかっている場合は、5 分より長く実行された場合にビルドが自動的に失敗するように TeamCity を構成することをお勧めします。これは、ビルドの失敗条件を構成することで簡単に実行できます。デフォルトでは、これは 0 分に設定されています。これは、120 分のグローバルサーバータイムアウトが適用されることを意味します。

ビルドを実行できる分数を制限することで、ハングしたビルドがビルドクレジットを過度に消費するのを防ぐことができます。

一部のビルドには、セルフホストのビルドエージェントを使用する

JetBrains が提供するクラウドビルドエージェントに加えて、自己ホスト型ビルドエージェントを TeamCity クラウドサーバーに接続するオプションがあります。これらの自己ホスト型エージェントは、社内ネットワークまたはプライベートクラウド環境で実行されているマシンである可能性があります。また、AWS スポットインスタンスなどを使用するように TeamCity を構成して、オンデマンド料金よりも安い料金で予備の EC2 容量を利用することもできます。

セルフホストエージェントがインターネットにアクセスして TeamCity クラウドドメインを解決できる限り、インバウンドポートを開く必要はありません。TeamCity ビルドエージェントは、ポーリングプロトコルを介して単方向のエージェント間接続を使用します。この場合、ビルドエージェントは TeamCity クラウドサーバーへの HTTPS 接続を確立し、サーバーコマンドについてサーバーを定期的にポーリングします。

無制限の数のセルフホストビルドエージェントを TeamCity クラウドに接続し、毎月それらのセルフホストエージェントで実行する同時ビルドの数に応じてビルドクレジットを引き換えることができます。これは、何百ものセルフホストビルドエージェントを接続できることを意味します。たとえば、1 か月に 5 つのセルフホストビルドエージェントスロットに対して 100,000 ビルドクレジットを引き換えた場合、これらのセルフホストビルドエージェントのいずれか 5 つでビルドを実行できるようになります。エージェントを同時に構築します。

セルフホストビルドには 1 分あたりの料金はかかりません。非常に長時間実行されるビルドや、クラウドビルドエージェントで利用できないカスタムツールを必要とするビルドがある場合は、それらのより複雑なビルド用にセルフホストビルドエージェントを予約し、より短いまたはそれほど複雑でないビルドにはクラウドビルドエージェントを使用できます。

ビルドチェーンを構成することにより、ビルド結果とインクリメンタルビルドの再利用を可能にする

多数のビルド手順を含む単一の大きなビルド構成を持つ代わりに、ビルド構成を個別の（より小さな）ビルド構成に分割し、ビルドチェーン（ビルドパイプラインとも呼ばれます）でリンクすることができます。例: 単一のビルド構成に、ステージング環境へのソリューションのビルド、テスト、デプロイの手順が含まれている場合、ビルド、テスト、ステージングにデプロイの 3 つのビルド構成を作成し、各ビルド手順をそれぞれのビルド構成に移動することができます。

各ビルド構成でスナップショットの依存関係を定義すると、これらのビルド構成がリンクされ、ビルドチェーンがセットアップされます。

TeamCity のビルドチェーンにより、増分ビルドとビルド結果の再利用が可能になります。例: ビルドおよびテストビルド構成は正常に完了する可能性がありますが、外部ステージング環境との一時的な接続の問題により、ステージングにデプロイは失敗する可能性があります。ビルドチェーン全体を最初から再実行する (そしてビルドクレジットをさらに消費する) のではなく、TeamCity はビルドおよびテストの結果を再利用し (新しい VCS 変更がないと仮定)、ステージングにデプロイからビルドチェーンを開始します。これにより、ビルドクレジットの消費が削減されると同時に、プロジェクトのデプロイにかかる全体的な時間も短縮されます。

アーティファクトを後続のビルド構成に渡す

同じライブラリまたはパッケージを使用するチェーンに複数のビルド構成がある場合は、アーティファクトとしてチェーン全体に渡すことができます。例: ビルド構成ごとに各ビルドエージェントで npm install を実行するのではなく、多くの npm パッケージを使用する場合は、npm パッケージディレクトリを最初のビルド構成にアーカイブし、アーティファクトとして TeamCity に保存して、後続のビルド構成。

アーティファクトの依存関係をそれ自体（特に最後に完了したビルド）に持つようにビルド構成を構成することもできるため、ビルドの最後に依存関係をアーカイブし、アーカイブをビルドアーティファクトとしてアップロードし、にアーティファクトの依存関係を作成できます。同じビルド構成での以前のビルド。これにより、同じビルド構成の将来のビルドで、以前にダウンロードした依存関係を使用できるようになります。

これは、アーティファクトの依存関係を通じて実現できます。パッケージの数（およびサイズ）によっては、これにより、ビルドチェーンでの後続のビルドの時間を短縮し、将来のビルドですべてのパッケージを最初からダウンロードするのを防ぐことができます。

この例では、新しいアーティファクトの依存関係がビルド構成に追加されており、アーカイブされた npm パッケージがビルドチェーンの以前のビルドから現在のビルドエージェントに自動的に転送されます。

広く使用されているビルドエージェントの前払い

特に長時間実行されるビルドがある場合、または単一のタイプのクラウドビルドエージェントを月に 125 時間以上使用していることに気付いた場合は、そのタイプのクラウドビルドエージェントの 1 つ以上のインスタンスに対して前払いし、他の 1 分あたりを回避できます。料金。これは、毎月クレジットのバッチを引き換えることによって達成されます。

このアプローチはビルドクレジットの消費を大幅に節約しますが、これは同時実行性の低下とのトレードオフにつながることに注意することが重要です。例: 特定のタイプのビルドエージェントを 5 つ前払いした場合、前払いレートと同時に実行できるのは、これらのタイプのエージェントのうち最大 5 つだけです。同じタイプのエージェントでさらに並行してビルドすると、分単位の料金に戻ります。

自動的に更新されたリソースを確認する

TeamCity Cloud サブスクリプション \& リソースページでは、追加のリソース（追加のコミッタースロット、プリペイドエージェント、データストレージ、セルフホストエージェントでの同時ビルド）にクレジットを引き換えることができます。これらのリソースのいずれかを増やすと、特定の数のクレジットが当月の利用可能な残高からすぐに差し引かれます。

例: 自己ホスト型エージェントで追加の同時ビルドを 1 つ行うと、月額 20,000 クレジットがかかります。月の初日にこの追加リソースのクレジットを引き換えると、合計 20,000 クレジットが差し引かれます。または、月の半ばに追加リソースのクレジットを引き換えた場合、その月の残りの控除額は最大 10,000 クレジットで日割り計算されます。

メモ : 月末までにこれらの追加リソースを減らさない場合、同じリソースが翌月に適用され、1 か月間のリソースに対して該当するクレジットが差し引かれます。一時的にのみ追加リソースが必要で (たとえば、忙しい時期)、翌月に使用しない可能性のあるリソースに対してクレジットを利用したくない場合は、当月末までに追加リソースを減らすことをお勧めします。

追加のリソースを増やした直後に減らすこともでき（後で忘れた場合に備えて）、これらのリソースは今月の残りの期間のみアクティブのままになります。

サブスクリプションに適したサイズを選択する

新しい TeamCity Cloud サブスクリプションを取得するとき、または更新するときは、サブスクリプション内のコミッターの数に基づいて、TeamCity Cloud インスタンスに割り当てられているリソース（ビルドクレジット）の数を注意深く確認することをお勧めします。これは、リソースが過剰にあるかどうかを確認できます。

サブスクリプションに十分な数のリソースがない場合は、アカウントを補充するために追加のビルドクレジットを購入する必要がある場合があります。これは、サブスクリプションにコミッターを追加するときにコミッタースロット、データストレージ、データ転送の料金を支払うため、追加のビルドクレジットを取得するためだけに、サブスクリプションのコミッターを人為的に増やすよりも費用対効果が高くなります。毎月の終わりにリセットされるサブスクリプションに含まれるビルドクレジットとは異なり、追加で購入したビルドクレジットは、完全に使用されていない場合、月ごとにロールオーバーします。