世界中にチームと CI ファームがある場合、GitHub Enterprise Server のプライマリ インスタンスのパフォーマンスが低下する可能性があります。 アクティブ geo レプリカを使うと読み取り要求のパフォーマンスが向上しますが、書き込みスループットが制限されます。 プライマリ インスタンスの負荷を軽減し、書き込みスループットのパフォーマンスを向上させるには、これらの地理的に分散したクライアントの近くに配置されたリポジトリの非同期読み取り専用ミラーであるリポジトリ キャッシュを構成できます。
リポジトリ キャッシュを使うと、CI ファームや分散チームの近くにリポジトリ データが提供されるため、GitHub Enterprise Server は、複数のクライアントにサービスを提供するために、同じ Git データを長距離ネットワーク リンク経由で何回も送信する必要がなくなります。 たとえば、プライマリ インスタンスが北米にあり、アジアの多くの場所でもそれを利用している場合は、アジアの CI ランナーが使用するためのリポジトリ キャッシュをアジアに設けるとメリットがあります。
リポジトリ キャッシュは、プライマリ インスタンス (単一インスタンスでも、geo レプリケートされたインスタンスのセットでも) で、Git データの変更をリッスンします。 CI ファームや他の読み取り負荷の高いコンシューマーは、プライマリ インスタンスの代わりにリポジトリ キャッシュからクローンしてフェッチします。 変更は、クライアントごとに 1 回ではなく、キャッシュ インスタンスごとに 1 回ずつ、定期的にネットワーク全体に反映されます。 通常、Git データは、データがプライマリ インスタンスにプッシュされてから数分以内に、リポジトリ キャッシュで使用できるようになります。 CI システムは、cache_sync Webhook を使うことで、キャッシュで使用可能になったデータに対応できます。
GitHub Enterprise Server は、Git と Git Large File Storage (Git LFS) データの両方をキャッシュします。
リポジトリ キャッシュと同期できるようにするリポジトリを、きめ細かく制御できます。 Git データは、ユーザーが指定した場所にのみレプリケートされます。
リポジトリ キャッシュと呼ばれる特殊な種類のレプリカを作成することで、リポジトリ キャッシュを構成できます。 詳しくは、「リポジトリ キャッシュの構成」をご覧ください。