リファレンス・アーキテクチャ

このページでは、GitLabの品質チームとサポートチームによって構築され、検証された推奨リファレンスアーキテクチャについて詳しく説明します。

以下は、各アーキテクチャ層と処理可能なユーザー数を表したチャートです。 時間の経過とともにユーザー数が増加するため、それに応じて GitLab を拡張することをお勧めします。

Reference Architectures

これらのリファレンス・アーキテクチャのテストは、GitLabのパフォーマンス・ツールを使って特定のコード化されたワークロードで実行され、テストに使用されたスループットはサンプル顧客データに基づいて計算されました。 規模に合ったリファレンス・アーキテクチャを選択した後、関係するコンポーネントとその設定方法を確認するために、Configure GitLab to Scaleを参照してください。

各エンドポイントタイプは、1,000ユーザーあたり(RPS) 、1秒あたり以下のリクエスト数でテストされています：

  • API: 20 RPS
  • ウェブ：2RPS
  • git: 2 RPS

2,000ユーザー未満のGitLabインスタンスでは、メンテナンスとリソースのコストを最小限に抑えるために、GitLabを1台のマシンにインストールしてデフォルトのセットアップを使用することをお勧めします。

2,000人以上のユーザがいる組織では、GitLabのコンポーネントを複数のマシンノードにスケールすることをお勧めします。 マシンノードはコンポーネントごとにグループ化されています。 これらのノードを追加することで、GitLabインスタンスのパフォーマンスとスケーラビリティが向上します。

GitLabをスケーリングする際には、考慮すべきいくつかの要素があります：

  • フロントエンドのトラフィックを処理する複数のアプリケーションノード。
  • アプリケーションノード間でトラフィックを分散するために、ロードバランサーが前面に追加されます。
  • アプリケーションノードは共有ファイルサーバーとバックエンドのPostgreSQLとRedisサービスに接続します。
注:ワークフローによっては、以下の推奨リファレンス・アーキテクチャを適宜変更する必要があります。 ワークロードは、ユーザーのアクティブ度、自動化の使用量、ミラーリング、リポジトリ/変更サイズなどの要因に影響されます。 さらに、表示されるメモリ値は、GCPマシン・タイプによって提供されます。 異なるクラウド・ベンダーの場合は、提供されるアーキテクチャに最も一致するオプションを選択するようにしてください。

利用可能なリファレンス・アーキテクチャ

以下のリファレンス・アーキテクチャが利用可能です：

可用性コンポーネント

GitLabには以下のコンポーネントが付属しています：

  1. 自動バックアップ
  2. トラフィック負荷分散装置
  3. ダウンタイムなしのアップデート
  4. データベースの自動フェイルオーバー
  5. GitLab Geoによるインスタンスレベルのレプリケーション

これらのコンポーネントを実装する際には、まず1台のサーバーから始め、バックアップを行います。 最初のサーバーが完了してから、次のサーバーに進んでください。

また、GitLabのために追加のサーバーを導入しないからといって、必ずしもダウンタイムが長くなるとは限りません。 ニーズや経験レベルによっては、サーバーを一台にしたほうがユーザーにとって実際に認識できるアップタイムが長くなることもあります。

自動バックアップ

このソリューションは、GitLabがデフォルトでインストールされている多くのチームに適しています。 GitLabリポジトリ、設定、データベースの自動バックアップにより、厳しい要件がなければ最適なソリューションになります。自動バックアップは、セットアップが最も複雑ではありません。 これは、あらかじめ決められたスケジュールのポイントインタイムリカバリを提供します。

トラフィック負荷分散装置

  • 複雑さのレベル：中
  • 必要なドメイン知識：HAProxy、共有ストレージ、ディストリビューションシステム
  • GitLab Starter、Premium、Ultimateに対応しています。

そのためには、GitLabを複数のアプリケーションノードに分離し、ロードバランサーを追加する必要があります。 ロードバランサーは、GitLabアプリケーションノード間でトラフィックを分散します。 一方、各アプリケーションノードは、バックエンドで共有ファイルサーバーとデータベースシステムに接続します。 この方法では、アプリケーションサーバーの1つに障害が発生しても、ワークフローが中断されることはありません。 ロードバランサーとしては、HAProxyを推奨します。

この追加コンポーネントを使用すると、デフォルトのインストールに比べて多くの利点があります：

  • ユーザー数を増やしてください。
  • ゼロダウンタイムのアップグレードを可能にします。
  • 可用性の向上。

ダウンタイムなしのアップデート

  • 複雑さのレベル：中
  • 必要な領域知識：PostgreSQL、HAProxy、共有ストレージ、ディストリビューションシステム
  • GitLab Starter、Premium、Ultimateに対応しています。

GitLabはゼロダウンタイムアップデートをサポートしています。 ゼロダウンタイムアップデートは単一のGitLabノードで実行できますが、GitLabを複数のアプリケーションノードに分けることをお勧めします。 各コンポーネントの少なくとも1つがオンラインであり、インスタンスの使用負荷を処理できる限り、アップデート中にチームの生産性が中断されることはありません。

データベースの自動フェイルオーバー

データベースシステムに自動フェイルオーバーを追加することで、データベースノードを追加してより高いアップタイムを実現できます。 これは、クラスター管理とフェイルオーバーポリシーでデフォルトのデータベースを拡張します。RepmgrまたはPatroniと組み合わせたPgBouncerを推奨します。

GitLab Geoによるインスタンスレベルのレプリケーション

GitLab Geoでは、GitLabインスタンスを他の地理的な場所に複製し、読み取り専用の完全稼働インスタンスとして、災害時に昇格させることもできます。

GitLab のスケール設定

注意:GitLab 13.0以降、GitリポジトリにNFSを使用することは非推奨です。 GitLab 14.0では、GitリポジトリへのNFSのサポートは削除される予定です。 できるだけ早くGitalyクラスタにアップグレードしてください。

以下のコンポーネントは、GitLabをスケールするために設定する必要があるものです。 これらのコンポーネントは、選択したリファレンスアーキテクチャで必要な場合、通常設定する順番でリストされています。

それらのほとんどはGitLabのdeb/rpmパッケージ（Omnibus GitLabと呼ばれます）にバンドルされていますが、システムアーキテクチャによっては、それに含まれていないコンポーネントが必要になる場合があります。 必要な場合は、GitLabが提供するコンポーネントを設定する前に、それらを設定する必要があります。 あなたの組織に適したソリューションを選択する方法についてのアドバイスは、設定方法の欄に記載されています。

コンポーネント 説明 設定方法 Omnibus GitLabとバンドルされています。
ロードバランサー(6) 複数の GitLab アプリケーションサービスノードがある場合に、ロードバランシングを行います。 ロードバランサーの設定(6) いいえ
オブジェクト・ストレージ・サービス(4) 共有データオブジェクトの推奨ストア オブジェクトストレージの構成 いいえ
NFS(5)(7) 共有ディスクストレージサービス。 代替オブジェクトストレージとして使用可能。 GitLab Pagesに必要。 NFSの設定 いいえ
領事(3) サービス発見とヘルスチェック/フェイルオーバー コンシュル構成 はい
PostgreSQL データベース PostgreSQLの設定 はい
PgBouncer データベース接続プーラ PgBouncerの設定 はい
代表 PostgreSQL クラスタ管理とフェイルオーバー PostgreSQLとRepmgrの設定 はい
パトロニ PostgreSQLクラスタ管理とフェイルオーバーの代替手段 PostgreSQL と Patroni の設定 はい
Redis(3) 高速なデータ検索とキャッシュのためのキー/バリューストア Redisの設定 はい
Redisセンチネル Redis Redisセンチネルの設定 はい
Gitaly(2)(7) Gitリポジトリへのアクセスを提供します。 Gitalyの構成 はい
Sidekiq 非同期/バックグラウンドジョブ Sidekiqコンフィギュレーション はい
GitLabアプリケーションサービス(1) Puma/Unicorn, Workhorse, GitLab Shell - フロントエンドのリクエストに対応 (UI, API, Git over HTTP/SSH) GitLabアプリのスケーリング設定 はい
Prometheusと Grafana GitLab環境モニタリング スケーリング用監視ノード はい

Cloud Native Helmによるコンポーネントの選択設定

また、GitLabのクラウドネイティブインストール方法として、Harmチャートも提供しています。 リファレンスアーキテクチャでは、必要に応じて、一部のコンポーネントをこの方法でセットアップすることができます。

このようなセットアップでは、データベースやGitalyのようなステートフルなバックエンドコンポーネントを、Omnibusや評判の良いサードパーティのサービスを介して外部で実行する、高度な構成でのチャートの使用をサポートします。 現在、_大規模なスケールで_Helmを介してステートフルなコンポーネントを実行することはサポートしていません。

これらの環境を設計する際には、上記の各リファレンスアーキテクチャを参照してサイジングの指針を得る必要があります。 Helmを介して実行されるコンポーネントは、Kubernetesリソースに変換されるだけで、Omnibus仕様と同様にスケーリングされます。

たとえば、RailsノードがHelmで実行される50kのインストールをセットアップする場合、Omnibusと同じ量のリソースがKubernetesクラスタに与えられ、Railsノードがそのクラスタ全体でいくつかの小さなポッドに分割されるはずです。

脚注

  1. 私たちのアーキテクチャでは、各 GitLab Rails ノードを Puma ウェブサーバを使って実行し、ワーカー数を利用可能な CPU の 90% に設定し、4 つのスレッドを使用しています。 他のコンポーネントと一緒に GitLab Rails を実行しているノードでは、ワーカー数をそれに応じて減らす必要があります。

  2. Gitalyノードの要件は、お客様のデータ、特にプロジェクトの数とそのサイズに依存します。各Gitalyノードは、5TB以下のデータを保存し、gitaly-ruby ワーカーの数、利用可能なCPUの20％に設定することをお勧めします。ノードの追加は、上記の推奨事項に基づき、予想されるデータサイズと拡散のレビュアーと合わせて検討する必要があります。

  3. 推奨されるRedisのセットアップは、アーキテクチャのサイズによって異なります。 小規模なアーキテクチャ（3,000ユーザー未満）の場合は、1つのインスタンスで十分です。 中規模のインストール（3,000～5,000ユーザー）の場合は、すべてのクラスに対して1つのRedisクラスターを実行し、Redis SentinelをConsulと一緒にホストすることをお勧めします。 より大規模なアーキテクチャ（10,000ユーザー以上）の場合は、Cacheクラスに対して別のRedisクラスターを実行し、QueuesクラスとShared Stateクラスに対してそれぞれ別のRedisクラスターを実行することをお勧めします。 また、Redis SentinelクラスターはRedisクラスターごとに別々に実行することをお勧めします。

  4. LFS、アップロード、アーティファクトなどのデータオブジェクトについては、パフォーマンスが向上するため、可能な限りNFSよりもObject Storageサービスを推奨します。

  5. NFSはオブジェクトストレージの代替としても使えますが、パフォーマンス上の理由から通常は推奨されません。 ただし、GitLabPagesでは必須であることに注意してください。

  6. 私たちのアーキテクチャはHAProxyをロードバランサーとしてテストされ、検証されています。 同様の機能を持つ他のロードバランサーも使用できますが、それらのロードバランサーは検証されていません。

  7. GitalyまたはNFSノードは、これらのコンポーネントのI/Oが重いため、読み取りオペレーションで少なくとも8,000 IOPS、書き込みで2,000 IOPSのスループットを持つHDDよりもSSDディスクでセットアップされることを強くお勧めします。 これらのIOPS値は、時間の経過とともに、環境のワークロードの規模に応じて高くまたは低く調整される可能性があるため、スターターとしてのみ推奨されます。 クラウドプロバイダー上で環境を実行している場合は、IOPSを正しく設定する方法について、プロバイダーのドキュメントを参照する必要があるかもしれません。

  8. アーキテクチャは、GCP上のIntel Xeon E5 v3 (Haswell)CPUプラットフォームで構築され、テストされました。 異なるハードウェアでは、CPUまたはノード数の調整が必要な場合があります。 詳しくは、CPUのSysbenchベンチマークをご覧ください。