リファレンス・アーキテクチャ:最大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 |
脚注
-
私たちのアーキテクチャでは、各 GitLab Rails ノードを Puma ウェブサーバを使って実行し、ワーカー数を利用可能な CPU の 90% に設定し、4 つのスレッドを使用しています。 他のコンポーネントと一緒に GitLab Rails を実行しているノードでは、ワーカー数をそれに応じて減らす必要があります。
-
Gitalyノードの要件は、お客様のデータ、特にプロジェクトの数とそのサイズに依存します。 HA環境では最低2ノード、50,000人以上のユーザーをサポートする場合は最低4ノードを使用することを推奨します。 また、各Gitalyノードは5TB以下のデータを保存し、
gitaly-ruby
ワーカーの数、利用可能なCPUの20%に設定することを推奨します。ノードの追加は、上記の推奨事項に基づき、予想されるデータサイズと拡散のレビュアーと合わせて検討する必要があります。 -
推奨されるRedisのセットアップは、アーキテクチャのサイズによって異なります。 小規模なアーキテクチャ(3,000ユーザー未満)の場合は、1つのインスタンスで十分です。 中規模のインストール(3,000~5,000ユーザー)の場合は、すべてのクラスに対して1つのRedisクラスターを実行し、Redis SentinelをConsulと一緒にホストすることをお勧めします。 より大規模なアーキテクチャ(10,000ユーザー以上)の場合は、Cacheクラスに対して別のRedisクラスターを実行し、QueuesクラスとShared Stateクラスに対してそれぞれ別のRedisクラスターを実行することをお勧めします。 また、Redis SentinelクラスターはRedisクラスターごとに別々に実行することをお勧めします。
-
LFS、アップロード、アーティファクトなどのデータオブジェクトについては、パフォーマンスと可用性が向上するため、可能な限りNFSよりもObject Storageサービスを推奨します。
-
NFSはリポジトリデータ(Gitalyを置き換える)とオブジェクトストレージの両方の代替手段として使うことができますが、パフォーマンス上の理由から通常は推奨されません。 しかし、GitLabPagesには必要であることに注意してください。
-
私たちのアーキテクチャはHAProxyをロードバランサーとしてテストされ、検証されています。 同様の機能を持つ他のロードバランサーも使用できますが、それらのロードバランサーは検証されていません。
-
GitalyまたはNFSノードは、これらのコンポーネントのI/Oが重いため、読み取りオペレーションで少なくとも8,000 IOPS、書き込みで2,000 IOPSのスループットを持つHDDよりもSSDディスクでセットアップされることを強くお勧めします。 これらのIOPS値は、時間の経過とともに、環境のワークロードの規模に応じて高くまたは低く調整される可能性があるため、スターターとしてのみ推奨されます。 クラウドプロバイダー上で環境を実行している場合は、IOPSを正しく設定する方法について、プロバイダーのドキュメントを参照する必要があるかもしれません。
-
アーキテクチャは、GCP上のIntel Xeon E5 v3 (Haswell)CPUプラットフォームで構築され、テストされました。 異なるハードウェアでは、CPUまたはノード数の調整が必要な場合があります。 詳しくは、CPUのSysbenchベンチマークをご覧ください。