複数デバイスで開発する人に専用ビルドキャッシュが役立つ理由

専用のビルドキャッシュは、同じリポジトリをノートパソコン、デスクトップ、CIランナー、または異なるCPUプラットフォーム間でビルドし、キャッシュの転送とメンテナンスにかかるコストよりも同じ作業の繰り返しにかかるコストの方が大きい場合に役立ちます。

キャッシュは最適化手段にとどめ、信頼できる唯一の情報源にはしないでください。キャッシュミスが発生してもビルドは成功する必要があります。また、キャッシュキー、信頼境界、クォータ、ガベージコレクションによって、1台のデバイスが共有サービスを汚染したり容量を使い果たしたりするのを防ぎます。

デバイス間で繰り返される作業を測定する

各デバイスで、依存関係のダウンロード、コンテナレイヤー、コンパイル済みオブジェクト、生成アセット、ビルド全体の所要時間を記録します。マシンを切り替えた後や一時的なCIジョブを開始した後に、同じ入力が再ビルドされる頻度を数えます。

実用的なリモートBazelキャッシュの解説では、複数のマシンが同一の入力を個別に再ビルドする代わりに、アーティファクトを再利用する方法を説明しています。

繰り返しの作業が多く、アーティファクトが決定論的で、転送時間が再計算より短い場合は、専用キャッシュを導入する価値があります。プロジェクトが小さい場合や、デバイス間で入力を共有することがほとんどない場合、メリットはほとんどありません。

キャッシュキーと信頼境界を定義する

キーには、ソース入力、依存関係のロックファイル、コンパイラーまたはランタイムのバージョン、対象アーキテクチャ、重要な環境フラグ、ビルドステップを含めます。広すぎるキーは誤ったヒットを生み、狭すぎるキーは再利用を生みません。

信頼できるCIジョブには書き込みアクセスを付与し、開発者のマシンや信頼できないブランチには読み取り専用アクセスを検討します。キャッシュエントリーには実行可能な出力が含まれる可能性があるため、任意のコードからの書き込みを受け入れることは、サプライチェーンに関する判断になります。

アーキテクチャとツールチェーンの世代を分離します。Apple Siliconのノートパソコンとx86 Linuxランナーは、ダウンロードしたソースパッケージを共有できても、コンパイル済みアーティファクトには異なるものが必要になる場合があります。

キャッシュをコストの高い処理の近くに配置する

自宅でのワークフローでは、各デバイスに小規模なローカルキャッシュを保持し、サーバーにはより大規模な共有キャッシュを保持します。リモートの開発者は、ネットワーク経路が再ビルドより十分に高速な場合に限り、共有レイヤーを使用できます。

キャッシュは、保護された家族共有やバックアップ先から分離します。頻繁な変更と自動削除は、独自のクォータを持つ専用データセットで行います。

-15% OFF

ZimaBoard 2 - あなたの大きなアイデアのためのミニホームサーバー

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

クォータ、ガベージコレクション、キャッシュミスを運用する

最大サイズ、高水位と低水位、最大保持期間、大容量エントリーのポリシーを設定します。ヒット率、転送バイト数、短縮できたビルド時間、退避率、キャッシュ検索にかかった時間を追跡します。

リモートビルドインフラの運用に関する実務的な説明では、キャッシュディスクがガベージコレクションより速く満杯になる可能性や、ネットワークのテールレイテンシによって平均的なメリットが失われる可能性が指摘されています。

キャッシュが利用できない場合は、オープンに失敗するようにします。つまり、ビルドを停止せずに再計算するべきです。特定のキャッシュに代替不可能な来歴データがある場合を除き、設定からサービスを復元し、エントリーは再び蓄積させます。

キャッシュするか停止するかの境界を設ける

少なくとも2台のデバイスが同じ高コストの入力を再ビルドし、ヒット率を測定でき、信頼できる書き込み元を1つに制限するポリシーを適用できる場合は、専用キャッシュを導入します。すべてのパッケージマネージャーを一度にキャッシュするのではなく、まずは1つのツールチェーンから始めます。

プロジェクトごとに信頼性、保持期間、I/Oパターンが異なる場合は、キャッシュサービスを分割します。退避によって頻繁に使うアーティファクトが削除される場合はSSD容量を追加します。転送がボトルネックとして測定された場合にのみネットワーク容量を追加し、検索やコンパイルがボトルネックの場合は追加しません。小さなファイルのSMBテストワークフローは、メタデータ負荷の高い転送制限の特定に役立ちます。

ヒット率が低いまま、または無効化のインシデントによるコストが短縮できたビルド時間を上回る場合は、キャッシュの拡張を停止します。クリーンなキャッシュミスの方が、高速でも誤ったアーティファクトより安価です。

最終的なセットアップのルール

すべてのサービスに明確な役割、保護された状態、制御されたアクセス経路、テスト済みの復元手順、トポロジーを分割または拡張するための測定可能な条件があれば、セットアップは合格です。