リファレンスアーキテクチャ：最大1,000ユーザー
このページでは、1,000ユーザーまでのGitLabリファレンスアーキテクチャについて説明します。リファレンスアーキテクチャの全リストは、利用可能なリファレンスアーキテクチャをご覧ください。
1,000ユーザーまでで、厳しい可用性要件がないのであれば、頻繁にバックアップを取るスタンドアロンのシングルノード・ソリューションが多くの組織に適しています。
- サポートされるユーザー（概算）：1,000
- 高可用性：可用性の高い環境については、修正された3Kリファレンス・アーキテクチャに従うことができます。
- 推定コスト コスト表を参照
- クラウド・ネイティブ・ハイブリッド:いいえ。クラウドネイティブハイブリッド環境では、修正ハイブリッドリファレンスアーキテクチャに従うことができます。
- 検証およびテスト結果：品質エンジニアリングチームは、定期的にスモークテストとパフォーマンステストを実施し、リファレンスアーキテクチャが準拠していることを確認します。
- テストリクエスト/秒(RPS) 率：API: 20 RPS, Web：2 RPS、Git（Pull）：2 RPS、Git (Push)：1 RPS
- 最新の結果
- どのリファレンス・アーキテクチャを使用するか迷っていますか？詳しくはこちらのガイドをご覧ください。
| ユーザー | 設定 | GCP | AWS | Azure |
|---|---|---|---|---|
| 最大500 | 4 vCPU、3.6 GBメモリ | n1-highcpu-4 | c5.xlarge | F4s v2 |
| 最大1,000 | 8 vCPU、7.2 GBメモリ | n1-highcpu-8 | c5.2xlarge | F8s v2 |
上の図は、GitLabが単一のサーバーにインストールできる一方で、内部的には複数のサービスで構成されていることを示しています。GitLabインスタンスがスケーリングされると、これらの各サービスは分割され、要求に応じて独立してスケーリングされます。場合によっては、いくつかのサービスにPaaSを活用することができます（例えば、いくつかのファイルシステムにはクラウドオブジェクトストレージ）。冗長性のために、いくつかのサービスは同じデータを保存するノードのクラスターになります。GitLabの水平設定では、リソースのクラスターやディスカバリーを調整するために必要な様々な補助サービスがあります（例えば、PostgreSQLの接続管理のためのPgBouncer、PrometheusのエンドポイントディスカバリーのためのConsulなど）。
要件
開始する前に、リファレンスアーキテクチャの要件を参照してください。
セットアップ手順
このデフォルトのリファレンスアーキテクチャ用にGitLabをインストールするには、標準のインストール手順を使用してください。
オプションで、外部のPostgreSQLサービスや 外部のオブジェクトストレージサービスを使うようにGitLabを設定することもできます。
高度な検索の設定
Elasticsearchを活用し、高度な検索を有効にすることで、GitLabインスタンス全体でより速く、より高度なコード検索を行うことができます。
Elasticsearch クラスタの設計と要件は、お客様の特定のデータに依存します。インスタンスと一緒にElasticsearchクラスターを設定する方法についての推奨ベストプラクティスについては、最適なクラスター設定の選び方をお読みください。
Helmチャートによるクラウドネイティブハイブリッドのリファレンスアーキテクチャ
クラウドネイティブ・ハイブリッド・リファレンス・アーキテクチャは、選択した_ステートレス・_コンポーネントを公式のHelm Charts経由でKubernetesにデプロイし、_ステートフル・_コンポーネントをLinuxパッケージでコンピュートVMにデプロイする代替アプローチです。
2kのGitLabクラウドネイティブハイブリッド（非HA）と3kのGitLabクラウドネイティブハイブリッド (HA) リファレンスアーキテクチャは、私たちがKubernetesで推奨する最小のものです。ユーザー数が少ない環境では、ノードのスペックを下げることができます。ユーザー数に応じて、すべての推奨ノードスペックを下げることができます。ただし、一般的な要件より低くしないことをお勧めします。