Gitaly

プラン: Free、Premium、Ultimate
提供形態: GitLab Self-Managed

Gitalyは、Gitリポジトリへの高レベルRPC（リモートプロシージャコール）アクセスを提供します。GitLabは、Gitデータの読み書きにGitalyを使用します。

GitalyはすべてのGitLabインストールに存在し、Gitリポジトリのストレージと取得を調整します。Gitalyは次のように動作します:

単一インスタンスのLinuxパッケージインストール（1台のマシン上でGitLab全体を実行する）でバックグラウンドサービスとして動作する。
スケーリングや可用性の要件に応じて、独自のインスタンスに分離され、完全なクラスター設定で設定される。

Gitalyは、GitLabのGitリポジトリへのアクセスのみを管理しています。それ以外の種類のGitLabデータへのアクセスには、Gitalyを使用しません。

GitLabは、設定されたリポジトリストレージを通じてリポジトリにアクセスします。新しいリポジトリはそれぞれ設定されたウェイトに基づいて、いずれかのリポジトリストレージに保存されます。各リポジトリストレージは次のいずれかです:

ストレージパスを使用してリポジトリに直接アクセスするGitalyストレージ。各リポジトリは単一のGitalyノードに保存され、すべてのリクエストはこのノードにルーティングされます。
Gitaly Cluster (Praefect)によって提供される仮想ストレージで、各リポジトリは、フォールトトレランスのために複数のGitalyノードに保存されることがあります。Gitaly Cluster (Praefect)の場合:
- 読み取りリクエストは複数のGitalyノードに分散され、パフォーマンスが向上します。
- 書き込みリクエストはリポジトリのレプリカにブロードキャストされます。

以下は、Gitalyへの直接アクセスを使用するよう設定されたGitLabを示しています:

この例では、次のように動作します:

各リポジトリは、3つのGitalyストレージ（storage-1、storage-2、storage-3）のいずれかに保存されます。
各ストレージは、Gitalyノードによって処理されます。
3つのGitalyノードは、それぞれのファイルシステムにデータを保存します。

ディスク要件

GitalyとGitalyクラスター (Praefect) は、I/O負荷の高いプロセスであるため、効果的に動作させるには高速ローカルストレージが必要です。そのため、すべてのGitalyノードでソリッドステートドライブ（SSD）を使用することを強くおすすめします。これらのSSDは、Gitalyが多くの小さなファイルを並行処理でオペレートするため、高い読み取りおよび書き込みスループットが必要です。

参考として、次のチャートは、GitLab.com上のGitalyの本番環境フリート全体のP99ディスクIOPSを1分単位で示しています。データは、月曜日の朝に始まり、月曜日の朝に終わる7日間の代表的な期間からクエリされました。稼働週におけるトラフィック増加に伴い、IOPSが定期的にスパイクしていることがわかります。Rawデータではさらに大きなスパイクが確認でき、書き込みは最大で8000 IOPSに達しました。ディスクのスループットは、こうしたスパイクを処理できる必要があり、Gitalyリクエストの途切れを防ぐ上で不可欠です。

P99ディスクIOPS（読み取り）:
P99ディスクIOPS（書き込み）:

通常、次のようになります:

1秒あたり500〜1000読み取り、ピーク時は1秒あたり3500読み取り。
1秒あたり約500回の書き込み、ピーク時は1秒あたり3000回以上の書き込み。

執筆時点でのGitalyフリートの大部分は、t2d-standard-32インスタンスとpd-ssdディスクです。Advertised（アドバタイズ）されている最大書き込みおよび読み取りIOPSは60,000です。

GitLab.comでは、GitLab Self-Managedインスタンスではデフォルトで有効になっていない、コストの大きいGit操作に対して、より厳格な並行処理制限を設けています。反対に、並行処理制限が緩い場合や、特に大規模モノレポに対する操作、あるいはpack-objectsキャッシュの利用などによっても、ディスクアクティビティーは大幅に増加する可能性があります。

実際には、独自の環境では、Gitalyインスタンスで観察されるディスクアクティビティーは、公開されているこれらの結果とは大きく異なる場合があります。クラウドプロバイダー環境で実行している場合、より大きなインスタンスを選択すると、通常、利用可能なディスクIOPSが増加します。スループットが保証されたプロビジョニングされたIOPSディスクタイプを選択することもできます。IOPSを正しく構成する方法については、クラウドプロバイダーのドキュメントを参照してください。

リポジトリデータについては、パフォーマンスと一貫性の理由から、GitalyとGitaly Cluster (Praefect)ではローカルストレージのみがサポートされています。NFSやクラウドベースのファイルシステムなどの代替手段はサポートされていません。

Gitalyアーキテクチャ

Gitalyはクライアント/サーバーアーキテクチャを実装しています:

Gitalyサーバーとは、Gitaly自体を実行しているノードのことです。
Gitalyクライアントとは、Gitalyサーバーにリクエストを送信するプロセスを実行するノードのことです。Gitalyクライアントは、Gitalyコンシューマーとも呼ばれ、次が含まれます:

以下は、Gitalyのクライアント/サーバーアーキテクチャを示しています:

%%{init: { "fontFamily": "GitLab Sans" }}%%
flowchart LR
    accTitle: Gitaly client-server architecture
    accDescr: GitLab clients connect to Gitaly server through gRPC to access local filesystem and object storage.

  subgraph Gitaly clients
    Rails[GitLab Rails]
    Workhorse[GitLab Workhorse]
    Shell[GitLab Shell]
    Zoekt[Zoekt Indexer]
    Elasticsearch[Elasticsearch Indexer]
    KAS["GitLab Agent for Kubernetes (KAS)"]
  end

  subgraph Gitaly
    GitalyServer[Gitaly server]
  end

  FS[Local filesystem]
  ObjectStorage[Object storage]

  Rails -- gRPC --> Gitaly
  Workhorse -- gRPC --> Gitaly
  Shell -- gRPC --> Gitaly
  Zoekt -- gRPC --> Gitaly
  Elasticsearch -- gRPC --> Gitaly
  KAS -- gRPC --> Gitaly

  GitalyServer --> FS
  GitalyServer -- TCP --> Workhorse
  GitalyServer -- TCP --> ObjectStorage

Gitalyの設定

Gitalyは、Linuxパッケージインストールにあらかじめ設定された状態で提供されており、この設定は最大20 RPS/1,000ユーザーに適しています。想定する規模に応じて以下を参照してください:

最大40 RPS/2,000ユーザーまでのLinuxパッケージインストールについては、個別のGitaly設定手順を参照してください。
自己コンパイルインストールまたはカスタムGitalyインストールについては、Gitalyを設定するを参照してください。

毎日Git書き込みオペレーションを行うアクティブユーザーが2,000人を超えるGitLabインストールでは、Gitaly Cluster (Praefect)の使用が最適な場合があります。

Gitalyコマンドラインインターフェース（CLI）

gitalyコマンドは、Gitaly管理者に追加のサブコマンドを提供するコマンドラインインターフェースです。たとえば、Gitaly CLIは次の用途に使用されます:

リポジトリに対してカスタムGitフックを設定する。
Gitalyの設定ファイルを検証する。
内部Gitaly APIにアクセスできることを確認する。
ディスク上のリポジトリに対してGitコマンドを実行する。

その他のサブコマンドの詳細については、sudo -u git -- /opt/gitlab/embedded/bin/gitaly --helpコマンドを実行してください。

リポジトリをバックアップする

GitLab以外のツールを使用してリポジトリをバックアップまたは同期する場合は、リポジトリデータのコピー中に書き込みを防止する必要があります。

バンドルURI

Gitalyでは、GitのバンドルURIを使用できます。詳細については、バンドルURIに関するドキュメントを参照してください。

リポジトリへの直接アクセス

Gitクライアントやその他のツールを使用して、ディスクに保存されているGitalyリポジトリに直接アクセスすることはおすすめしません。これは、Gitalyが継続的に改善および変更されているためです。これらの改善により、前提としていたことが無効になり、パフォーマンスの低下、不安定化、さらにはデータ損失が発生する可能性があります。次に例を示します:

Gitalyには、info/refsアドバタイズメントキャッシュのような最適化機能があり、公式のgRPCインターフェースを利用してリポジトリへのアクセスを制御およびモニタリングすることで成り立っています。
Gitaly Cluster (Praefect)には、フォールトトレランスや分散読み取りといった最適化機能があり、gRPCインターフェースとデータベースを用いてリポジトリの状態を判断することで実現されています。

Gitリポジトリへの直接アクセスは、ご自身の責任で行ってください。サポートは提供されていません。