リファレンスアーキテクチャ: 最大20 RPSまたは1,000ユーザー

このリファレンスアーキテクチャは、1秒あたり20リクエスト（RPS）のピーク負荷をターゲットにしています。実際のデータに基づくと、この負荷は通常、手動と自動両方のインタラクションを含む最大1,000ユーザーに対応します。

リファレンスアーキテクチャの完全なリストについては、利用可能なリファレンスアーキテクチャを参照してください。

• Target Load（目標負荷）: API: 20 RPS、Web: 2 RPS、Git（プル）: 2 RPS、Git（プッシュ）: 1 RPS
• High Availability（高可用性）: いいえ。高可用性環境については、変更された3Kリファレンスアーキテクチャに従ってください。
• Cloud Native Hybrid（クラウドネイティブハイブリッド）: いいえ。クラウドネイティブハイブリッド環境の場合は、変更されたハイブリッドリファレンスアーキテクチャに従うことができます。
• Unsure which Reference Architecture to use（どのリファレンスアーキテクチャを使用すればよいかわからない場合）は、アーキテクチャの選択を参照してください。詳細については、どのアーキテクチャで始めるかを決定するを参照してください。

Footnotes（脚注）:

1. マシンタイプの例は、説明目的で提供されています。これらのタイプは、検証とテストで使用されていますが、推奨されるデフォルトとして意図されたものではありません。リストされている要件を満たす他のマシンタイプへの切り替え（利用可能な場合はARMバリアントを含む）がサポートされています。詳細については、サポートされているマシンタイプを参照してください。
2. GCPの場合、8 vCPUおよび16 GBのRAMの推奨要件に一致する、もっとも近い同等の標準マシンタイプが選択されています。必要に応じて、カスタムマシンタイプも使用できます。

次の図では、GitLabを1台のサーバーにインストールしているものの、内部では複数のサービスで構成されていることを示しています。インスタンスがスケールすると、これらのサービスは分離され、特定の要求に応じて個別にスケールされます。

場合によっては、一部のサービスにPaaSを利用できます。たとえば、一部のファイルシステムにCloudオブジェクトストレージを使用できます。冗長性を確保するため、一部のサービスはノードのクラスターとして構成され、同じデータを保存します。

水平にスケールされたGitLab設定では、クラスターの調整やリソースの検出のために、さまざまな補助サービスが必要です。たとえば、PostgreSQL接続管理用のPgBouncerや、Prometheusエンドポイント検出用のConsulなどです。

@startuml 1k
card "**Prometheus**" as monitor #7FFFD4
package "GitLab Single Server" as gitlab-single-server {
together {
  card "**GitLab Rails**" as gitlab #32CD32
  card "**Gitaly**" as gitaly #FF8C00
  card "**PostgreSQL**" as postgres #4EA7FF
  card "**Redis**" as redis #FF6347
  card "**Sidekiq**" as sidekiq #ff8dd1
}
card "Local Storage" as local_storage #white
}

gitlab -[#32CD32]--> gitaly
gitlab -[#32CD32]--> postgres
gitlab -[#32CD32]--> redis
gitlab -[#32CD32]--> sidekiq
gitaly -[#32CD32]--> local_storage
postgres -[#32CD32]--> local_storage
sidekiq -[#32CD32]--> local_storage
gitlab -[#32CD32]--> local_storage

monitor .[#7FFFD4]u-> gitlab
monitor .[#7FFFD4]u-> sidekiq
monitor .[#7FFFD4]-> postgres
monitor .[#7FFFD4]-> gitaly
monitor .[#7FFFD4,norank]--> redis

@enduml

要件

続行する前に、リファレンスアーキテクチャの要件を確認してください。

テスト手法

20 RPS/1,000ユーザーのリファレンスアーキテクチャは、もっとも一般的なワークフローに対応するように設計されています。GitLabは、次のエンドポイントスループットの目標に対して、定期的にスモークテストとパフォーマンステストを実施しています:

これらの目標は、CIパイプラインやその他のワークロードを含む、指定されたユーザー数に対する環境負荷の合計を反映した、実際の顧客データに基づいています。

テスト手法の詳細については、検証とテストの結果セクションを参照してください。

パフォーマンスに関する考慮事項

環境に次の要素がある場合、追加の調整が必要になるかもしれません:

• リスト上の目標よりも一貫して高いスループット
• 大規模なモノレポ
• 大幅な追加のワークロード

これらの場合は、詳細について環境をスケーリングするを参照してください。これらの考慮事項がお客様にあてはまると思われる場合は、必要に応じて追加のガイダンスについてお問い合わせください。

セットアップ手順

このデフォルトのリファレンスアーキテクチャにGitLabをインストールするには、標準のインストール手順を使用してください。

オプションで、外部PostgreSQLサービスまたは外部オブジェクトストレージサービスを使用するようにGitLabを設定することもできます。パフォーマンスと信頼性が向上しますが、複雑さが増します。

高度な検索を設定する

Elasticsearchを活用し、高度な検索を有効にすることで、GitLabインスタンス全体でより高速で高度なコード検索を実現できます。

Elasticsearchクラスターの設計と要件は、データによって異なります。Elasticsearchクラスターをインスタンスとともにセットアップする方法に関するベストプラクティスについては、最適なクラスター設定を選択するを参照してください。

Helm Chartを使用したクラウドネイティブハイブリッドリファレンスアーキテクチャ

クラウドネイティブハイブリッドリファレンスアーキテクチャのセットアップでは、選択したステートレスコンポーネントは、公式のHelm Chartを使用してKubernetesにデプロイされます。ステートフルコンポーネントは、Linuxパッケージを使用してコンピューティング仮想マシンにデプロイされます。

Kubernetesで使用できる最小のリファレンスアーキテクチャは、2,000または40 RPS GitLabクラウドネイティブハイブリッド （非HA）と3,000または60 RPS GitLabクラウドネイティブハイブリッド（HA）です。

ユーザー数またはRPSが少ない環境の場合は、ノードの仕様を下げることができます。ユーザー数に応じて、提案されたすべてのノード仕様を必要に応じて下げることができます。ただし、一般要件を下回ることは避けてください。

次のステップ

これで、コア機能が設定された新しいGitLab環境ができました。要件に応じて、オプションのGitLab機能をさらに設定することもできます。詳細については、GitLabのインストール後の手順を参照してください。