リファレンス・アーキテクチャ：最大50,000ユーザー

このページでは、50,000ユーザーまでのGitLabリファレンスアーキテクチャについて説明します。 リファレンスアーキテクチャの全リストについては、利用可能なリファレンスアーキテクチャをご覧ください。

  • 対応ユーザー数（概算）：50,000人
  • 高可用性：真
  • テストRPSレート：API：1000RPS、Web：100RPS、git：100RPS
サービス ノード 構成(8) 事業継続計画 エーダブリュエス Azure
GitLab Rails(1) 12 32vCPU、28.8GBメモリ n1-highcpu-32 c5.9xlarge F32s v2
PostgreSQL 3 16 vCPU、60GBメモリ n1-standard-16 m5.4xlarge D16s v3
PgBouncer 3 2 vCPU、1.8GBメモリ n1-highcpu-2 c5.large F2s v2
Gitaly(2)(5)(7) X 64vCPU、240GBメモリ n1-standard-64 m5.16xlarge D64s v3
Redis(3) - キャッシュ 3 4 vCPU、15GBメモリ n1-standard-4 m5.xlarge D4s v3
Redis(3) - キュー / 共有ステート 3 4 vCPU、15GBメモリ n1-standard-4 m5.xlarge D4s v3
Redis Sentinel(3) - キャッシュ 3 1 vCPU、1.7GBメモリ g1-small t2.small ビーワンエムエス
Redis Sentinel(3) - キュー/共有ステート 3 1 vCPU、1.7GBメモリ g1-small t2.small ビーワンエムエス
Consul 3 2 vCPU、1.8GBメモリ n1-highcpu-2 c5.large F2s v2
Sidekiq 4 4 vCPU、15GBメモリ n1-standard-4 m5.xlarge D4s v3
NFSサーバー(5)(7) 1 4 vCPU、3.6GBメモリ n1-highcpu-4 c5.xlarge F4s v2
オブジェクトストレージ(4) - - - - -
監視ノード 1 4 vCPU、3.6GBメモリ n1-highcpu-4 c5.xlarge F4s v2
外部負荷分散ノード(6) 1 8 vCPU、7.2GBメモリ n1-highcpu-8 c5.2xlarge F8s v2
内部負荷分散ノード(6) 1 8 vCPU、7.2GBメモリ n1-highcpu-8 c5.2xlarge F8s v2

脚注

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

  2. Gitalyノードの要件は、お客様のデータ、特にプロジェクトの数とそのサイズに依存します。 HA環境では最低2ノード、50,000人以上のユーザーをサポートする場合は最低4ノードを使用することを推奨します。 また、各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はリポジトリデータ（Gitalyを置き換える）とオブジェクトストレージの両方の代替手段として使うことができますが、パフォーマンス上の理由から通常は推奨されません。 しかし、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ベンチマークをご覧ください。