複数のデバイスで開発する開発者に専用のビルドキャッシュが役立つのはなぜですか？

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

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

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

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

実践的なBazelのリモートキャッシュ導入ガイドでは、複数のマシンが同じ入力を個別に再ビルドせず、成果物を再利用する方法を説明しています。

同じ作業を繰り返すことが多く、成果物が決定論的で、転送時間が再計算より短い場合は、専用キャッシュを導入する価値があります。プロジェクトが小さい場合や、デバイス間で入力を共有する機会が少ない場合は、効果がほとんどありません。

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

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

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

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

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

家庭で使う場合は、各デバイスに小さなローカルキャッシュを、サーバーに大きな共有キャッシュを用意しましょう。リモートで作業する開発者は、ネットワーク経由での利用が再ビルドより速い場合に限り、共有キャッシュを使えます。

キャッシュを保護対象の家族共有領域やバックアップ先に置かないでください。頻繁な更新と自動削除は、専用のクォータを設定した専用データセットで行いましょう。

Featured

ZimaBoard 2 - 大きなアイデアを実現するミニホームサーバー

Single board computer zimaboard2

$339.00 - $529.00

Buy Now

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

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

リモートビルド基盤の運用に関する実務レポートによると、キャッシュディスクはガベージコレクションより速くいっぱいになることがあり、ネットワークのテールレイテンシーによって平均的な速度向上が帳消しになる場合もあります。

キャッシュが利用できない場合は、キャッシュなしで続行します。ビルドは停止せず、再計算するようにしてください。復元対象のキャッシュに代替不可能な来歴データが含まれていない限り、設定からサービスを復元し、エントリーを再生成させます。

キャッシュを使うか、諦めるかの境界を決める

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

プロジェクトごとに信頼レベル、保持期間、I/Oパターンが異なる場合は、キャッシュサービスを分割しましょう。ホットな成果物が削除されるならSSD容量を増やし、測定の結果、ボトルネックが検索やコンパイルではなく転送だと分かった場合に限り、ネットワーク容量を増やしてください。小さなファイルのSMBテスト手順は、メタデータが多い転送の限界を特定するのに役立ちます。

ヒット率が低いままか、無効化の問題によるコストがビルド時間の短縮効果を上回る場合は、キャッシュの拡張をやめましょう。正しい成果物を作り直すほうが、間違った成果物を速く得るより安上がりです。

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

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