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

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

  • 対応ユーザー数（概算）：1,000人
  • 高可用性:False
ユーザー 構成(8) 事業継続計画 エーダブリュエス Azure
500 4 vCPU、3.6GBメモリ n1-highcpu-4 c5.xlarge F4s v2
1000 8 vCPU、7.2GBメモリ n1-highcpu-8 c5.2xlarge F8s v2

上記に加えて、現在利用可能なRAMが十分である場合でも、サーバー上に少なくとも2GBのスワップを持つことをお勧めします。 スワップを持つことで、利用可能なメモリが変更された場合にエラーが発生する可能性を減らすことができます。 また、カーネルのスワッピネス設定を10 のような低い値に設定することで、RAMを最大限に活用しつつ、必要なときにスワップを利用できるようにすることをお勧めします。

1,000人までのユーザーにサービスを提供する必要がある状況では、頻繁にバックアップを取るシングルノード・ソリューションが多くの組織にとって適切です。 GitLabリポジトリ、設定、データベースの自動バックアップにより、厳しい可用性要件がなければ、これは理想的なソリューションです。

セットアップ方法

  • このデフォルトのリファレンス・アーキテクチャでは、標準のインストール手順を使用してGitLabをインストールしてください。
注：オプションで、GitLabが外部のPostgreSQLサービスや外部のオブジェクトストレージサービスを使用するように設定することもできます。

脚注

  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ベンチマークをご覧ください。