リポジトリのキャッシュについて

世界中にチームと CI ファームがある場合は、プライマリ GitHub Enterprise Server インスタンスのパフォーマンスが低下する可能性があります。 アクティブ geo レプリカを使うと読み取り要求のパフォーマンスが向上しますが、書き込みスループットが制限されます。 プライマリ インスタンスの負荷を軽減し、書き込みスループットのパフォーマンスを向上させるには、これらの地理的に分散したクライアントの近くに配置されたリポジトリの非同期読み取り専用ミラーであるリポジトリ キャッシュを構成できます。

リポジトリ キャッシュを使用すると、CI ファームと分散チームに近いリポジトリ データを提供することで、 GitHub Enterprise Server が同じ Git データを長距離ネットワーク リンク経由で複数回送信して複数のクライアントにサービスを提供する必要がなくなります。 たとえば、プライマリ インスタンスが北米にあり、アジアの多くの場所でもそれを利用している場合は、アジアの CI ランナーが使用するためのリポジトリ キャッシュをアジアに設けるとメリットがあります。

リポジトリキャッシュは、Gitデータの変更を検出するために、プライマリインスタンス(単一のインスタンスまたは地理的にレプリケートされたインスタンスのセット)を監視します。 CI ファームや他の読み取り負荷の高いコンシューマーは、プライマリ インスタンスの代わりにリポジトリ キャッシュからクローンしてフェッチします。 変更は、クライアントごとに 1 回ではなく、キャッシュ インスタンスごとに 1 回ずつ、定期的にネットワーク全体に反映されます。 通常、Git データは、データがプライマリ インスタンスにプッシュされてから数分以内に、リポジトリ キャッシュで使用できるようになります。 CI システムで cache_sync Webhook を使うことで、キャッシュで使用できるようになったデータに対応できます。

GitHub Enterprise Server では、Git と Git 大容量ファイルストレージ (Git LFS) の両方のデータがキャッシュされます。

リポジトリ キャッシュと同期できるようにするリポジトリを、きめ細かく制御できます。 Git データは、ユーザーが指定した場所にのみレプリケートされます。

リポジトリ キャッシュと呼ばれる特殊な種類のレプリカを作成することで、リポジトリ キャッシュを構成できます。 詳細については、 AUTOTITLE を参照してください。