Skip to content
Latchkey

Remote Cacheとは?

remote cacheはcacheをローカルディスクから共有ストレージへ移動させ、あるマシンの結果を他のすべてのマシンと実行が再利用できるようにします。

cachingはcacheが生き残る場合にのみ役立ちます。エフェメラルなCI runnerでは、ローカルディスクは各jobの後に消去されるため、ローカルのみのcacheは毎回空です。remote cacheは、任意のrunnerが取得できる中央にartifactを保存することでこれを解決します。

なぜローカルcacheはCIで失敗するのか

ホスト型およびマネージド型のrunnerは通常、新しいVMです。最初のjobはローカルcacheを埋めますが、2番目のjobはそれを決して見ない別のVMで実行されます。CIにおけるローカルcacheのヒット率は事実上ゼロです。

remote cacheの仕組み

  • ステップは入力からkeyを計算し、そのkeyをcacheサービスに問い合わせます。
  • ヒットした場合、保存されたartifactをダウンロードし、作業をスキップします。
  • ミスした場合、作業を実行し、次回のためにそのkeyの下に結果をアップロードします。

小さな例

Bazelの--remote_cache=grpc://cache.internalは、すべてのbuildを共有cacheに向けます。モジュールをコンパイルするCI実行は結果をアップロードし、別のrunner上の次の実行は、ローカル状態が生き残らなかったにもかかわらず、再コンパイルする代わりにそれをダウンロードします。

リードスルーと書き込みパス

信頼できるブランチは通常cacheに書き込みます。pull requestはしばしば読み取りのみで、信頼できない変更が共有結果を汚染できないようにします。バッキングストレージは通常、S3のようなオブジェクトストアです。

Latchkeyについてのメモ

Latchkeyはcacheバックエンドをマネージドrunnerと同じリージョンで実行するため、remote cacheの読み書きは低レイテンシのパスを使用し、パブリックインターネットのegressコストを回避します。

重要なポイント

  • remote cacheは共有ストレージに存在するため、任意のrunnerが結果を再利用できます。
  • エフェメラルなrunnerでは不可欠であり、そこではローカルcacheは決してヒットしません。
  • 汚染を避けるため、cacheへの書き込みは信頼できるブランチに制限しましょう。

関連ガイド