リファレンス・アーキテクチャ:最大3,000ユーザー
このページでは、3,000ユーザーまでのGitLabリファレンスアーキテクチャについて説明します。 リファレンスアーキテクチャの全リストは、利用可能なリファレンスアーキテクチャをご覧ください。
- 対応ユーザー数(概算):3,000人
- 高可用性:真
- テストRPSレート:API:60RPS、Web:6RPS、git:6RPS
サービス | ノード | 構成(8) | 事業継続計画 | エーダブリュエス | Azure |
---|---|---|---|---|---|
GitLab Rails(1) | 3 | 8 vCPU、7.2GBメモリ | n1-highcpu-8
| c5.2xlarge
| F8s v2 |
PostgreSQL | 3 | 2 vCPU、7.5GBメモリ | n1-standard-2
| m5.large
| D2s v3 |
PgBouncer | 3 | 2 vCPU、1.8GBメモリ | n1-highcpu-2
| c5.large
| F2s v2 |
Gitaly(2)(5)(7) | X | 4 vCPU、15GBメモリ | n1-standard-4
| m5.xlarge
| D4s v3 |
Redis(3) | 3 | 2 vCPU、7.5GBメモリ | n1-standard-2
| m5.large
| D2s v3 |
領事+歩哨(3) | 3 | 2 vCPU、1.8GBメモリ | n1-highcpu-2
| c5.large
| F2s v2 |
Sidekiq | 4 | 2 vCPU、7.5GBメモリ | n1-standard-2
| m5.large
| D2s v3 |
オブジェクトストレージ(4) | - | - | - | - | - |
NFSサーバー(5)(7) | 1 | 4 vCPU、3.6GBメモリ | n1-highcpu-4
| c5.xlarge
| F4s v2 |
監視ノード | 1 | 2 vCPU、1.8GBメモリ | n1-highcpu-2
| c5.large
| F2s v2 |
外部負荷分散ノード(6) | 1 | 2 vCPU、1.8GBメモリ | n1-highcpu-2
| c5.large
| F2s v2 |
内部負荷分散ノード(6) | 1 | 2 vCPU、1.8GBメモリ | n1-highcpu-2
| c5.large
| F2s 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ベンチマークをご覧ください。