リファレンス・アーキテクチャ：最大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ベンチマークをご覧ください。
