リファレンスアーキテクチャ: Cloud Native First（ベータ版）

クラウドネイティブファーストリファレンスアーキテクチャは、ワークロードの特性に基づいた4つの標準サイズ（S/M/L/XL）を備えた、最新のクラウドネイティブなデプロイパターン向けに設計されています。これらのアーキテクチャは、すべてのGitLabコンポーネントをKubernetesにデプロイし、PostgreSQL、Redis、およびオブジェクトストレージには、マネージドサービスやオンプレミスオプションを含む外部のサードパーティソリューションを使用します。

アーキテクチャの概要

クラウドネイティブファーストアーキテクチャは、Kubernetesと外部サービスにまたがってGitLabコンポーネントをデプロイします:

@startuml kubernetes
skinparam linetype ortho

card "Kubernetes via Helm Charts" as kubernetes {
  collections "**Webservice Pods**\n//Auto-scaling//" as web #32CD32

  collections "**Sidekiq Pods**\n//Auto-scaling//" as sidekiq #ff8dd1

  collections "**Gitaly Pods**\n//StatefulSets//" as gitaly #FF8C00

  collections "**Supporting Pods**\n//NGINX, Toolbox//" as support #e76a9b
}

card "External Services" as external {
  collections "**PostgreSQL**" as database #4EA7FF

  collections "**Redis Cache**" as redis_cache #FF6347

  collections "**Redis Persistent**" as redis_persistent #FF6347

  cloud "**Object Storage**" as object_storage #white
}

kubernetes -[hidden]---> external

web -[#32CD32,norank]--> object_storage
web -[#32CD32,norank]--> redis_cache
web -[#32CD32,norank]--> redis_persistent
web -[#32CD32,norank]--> database

sidekiq -[#ff8dd1,norank]--> object_storage
sidekiq -[#ff8dd1,norank]--> redis_cache
sidekiq -[#ff8dd1,norank]--> redis_persistent
sidekiq -[#ff8dd1,norank]--> database

@enduml

Kubernetesコンポーネント:

• Webservice - Webリクエストを処理します
• Sidekiq - バックグラウンドジョブを処理します
• Gitaly - 永続ボリュームを備えたStatefulSetsを使用してGitリポジトリを管理します
• サポートサービス - NGINX Ingress、Toolbox、モニタリングコンポーネント

外部サービス:

• PostgreSQL - 高可用性のためのオプションのスタンバイレプリカと、安定性およびパフォーマンス向上のための読み取りレプリカとともにデプロイされるマネージドデータベースサービス
• Redis - キャッシュ用インスタンスと永続化用のインスタンスを分離し、それぞれ高可用性のためのスタンバイレプリカをオプションでデプロイできます
• オブジェクトストレージ - アーティファクトおよびパッケージ向けのS3、Google Cloud Storage、Azure Blob Storageなどのオブジェクトストレージサービス

おすすめのマネージドサービスプロバイダー（GCP Cloud SQL、AWS RDS、Azure Databaseなど）については、推奨されるクラウドプロバイダーとサービスを参照してください。

利用可能なアーキテクチャ

これらのアーキテクチャは、典型的な本番環境のワークロードパターンを表すRPS目標の範囲に基づいて設計されています。RPS目標は出発点であり、実際に必要なキャパシティはワークロードの構成や使用パターンによって異なります。RPSの内訳と、調整が必要となる場合のガイダンスについては、RPSの内訳を理解するを参照してください。

想定される負荷の特定方法や適切なサイズの選択に関する詳細なガイダンスについては、リファレンスアーキテクチャのサイジングガイドを参照してください。

主なメリット

クラウドネイティブファーストアーキテクチャには次のメリットがあります:

• 自己修復型インフラストラクチャ - Kubernetesが失敗したポッドを自動的に再起動し、正常なノード間でワークロードを再スケジュールする
• 動的リソーススケーリング - Horizontal Pod AutoscalerとCluster Autoscalerが実際の需要に基づいてキャパシティを調整する
• デプロイの簡素化 - GitLabコンポーネントに対する従来のVM管理が不要で、すべてKubernetesを通じてオーケストレーションされる
• 運用負荷の軽減 - PostgreSQL、Redis、オブジェクトストレージにマネージドサービスを使用することで、データベースとキャッシュのメンテナンスが不要になる
• 組み込みの高可用性 - すべてのコンポーネントに対して自動フェイルオーバーを備えたマルチゾーンデプロイを実現する
• コスト効率の向上 - ピーク時のキャパシティを維持しつつ、需要の低い期間はリソースをスケールダウンする

要件

Cloud Native Firstアーキテクチャをデプロイする前に、以下があることを確認してください:

• サポートされているKubernetesクラスターがあり、その他のチャートの前提条件を満たしていること
• データベース、ユーザー、拡張機能が設定された外部PostgreSQLインスタンス
• 外部Redisインスタンス
• オブジェクトストレージサービス（S3、Google Cloud Storage、Azure Blob Storageなど）

ネットワーキング、マシンタイプ、クラウドプロバイダーサービスを含む完全な要件については、リファレンスアーキテクチャの要件を参照してください。

Kubernetes上のGitaly固有の要件と制限については、Kubernetes上のGitalyの要件を参照してください。

Small（S）

目標負荷: 100 RPS以下 | 全体的に軽度の負荷

ワークロードの特性:

• 総RPS範囲: 1秒あたりのリクエスト数が100以下
• Git操作: Gitのプッシュとプルのアクティビティが少ない
• リポジトリサイズ: アクティブに使用されるモノレポには不向き
• CI/CDの使用: 同時実行パイプラインが少ない
• APIトラフィック: 自動化されたワークロードに対する処理能力が低い
• ユーザーパターン: 使用の急増に対してある程度の耐性がある

Kubernetesコンポーネント

ポッドのスケーリング構成

Gitalyに関する注意: Git cgroups: 27 GB、バッファ: 3 GB。リポジトリcgroupsは1に設定されています。チューニングのガイダンスについては、Gitaly cgroupsの設定を参照してください。

外部サービス

Medium（M）

目標負荷: 200 RPS以下 | 全体的に中程度の負荷

ワークロードの特性:

• 総RPS範囲: 1秒あたりのリクエスト数が200以下
• Git操作: Gitのプッシュとプルのアクティビティが中程度
• リポジトリサイズ: 低頻度で使用されるモノレポをサポート。さらに大規模または高頻度で使用されるモノレポでは、パフォーマンス調整が必要になる場合があります
• CI/CDの使用: 中程度のパイプライン並行処理
• APIトラフィック: 標準的な自動化ワークロードをサポート
• ユーザーパターン: 使用状況の変動に対して十分な耐性がある

Kubernetesコンポーネント

ポッドのスケーリング構成

Gitalyに関する注意: Git cgroups: 56 GB、バッファ: 6 GB。リポジトリcgroupsは1に設定されています。チューニングのガイダンスについては、Gitaly cgroupsの設定を参照してください。

外部サービス

Large（L）

目標負荷: 500 RPS以下 | 全体的に高い負荷

ワークロードの特性:

• 総RPS範囲: 1秒あたりのリクエスト数が500以下
• Git操作: Gitのプッシュとプルのアクティビティが多い
• リポジトリサイズ: 適度に使用されるモノレポをサポート。さらに大規模または高頻度で使用されるモノレポでは、パフォーマンス調整が必要になる場合があります
• CI/CDの使用: 適切なSidekiqのスケーリングを伴う、高頻度のパイプライン使用
• APIトラフィック: 大規模な自動化ワークロードをサポート
• ユーザーパターン: 使用状況の変動に対して非常に高い耐性がある

Kubernetesコンポーネント

ポッドのスケーリング構成

Gitalyに関する注意: Git cgroups: 120 GB、バッファ: 6 GB。リポジトリcgroupsは1に設定されています。チューニングのガイダンスについては、Gitaly cgroupsの設定を参照してください。

外部サービス

Extra Large（XL）

目標負荷: 1000 RPS以下 | 全体的に集中的な負荷

ワークロードの特性:

• 総RPS範囲: 1秒あたりのリクエスト数が1000以下
• Git操作: Gitのプッシュとプルのアクティビティが非常に多い
• リポジトリサイズ: 頻繁に使用されるモノレポをサポート。さらに大規模または集中的に使用されるモノレポでは、パフォーマンス調整が必要になる場合があります
• CI/CDの使用: 集中的なCI/CDワークロード
• APIトラフィック: 大規模な自動化およびインテグレーションのトラフィック
• ユーザーパターン: 多様なアクセスパターンに対応する設計

Kubernetesコンポーネント

ポッドのスケーリング構成

Gitalyに関する注意: Git cgroups: 248 GB、バッファ: 6 GB。リポジトリcgroupsは1に設定されています。チューニングのガイダンスについては、Gitaly cgroupsの設定を参照してください。

外部サービス

追加情報

このセクションでは、クラウドネイティブファーストアーキテクチャのデプロイと運用に関する補足的なガイダンスを提供します。これには、マシンタイプの選択、コンポーネント固有の考慮事項、スケーリング戦略が含まれます。

マシンタイプのガイダンス

ここに記載されているマシンタイプは、検証およびテストで使用された例です。使用できるモデルは次のとおりです:

• より新しい世代のマシンタイプ
• ARMベースのインスタンス（AWS Graviton）
• 仕様を満たす、または上回る別のマシンファミリー
• 特定のニーズに合わせてサイズ調整されたカスタムマシンタイプ

パフォーマンスが不安定になるため、バースト可能なインスタンスタイプは使用しないでください。

詳細については、サポートされているマシンタイプを参照してください。

Gitalyに関する考慮事項

クラウドネイティブファーストアーキテクチャにおけるKubernetes上のGitalyは、次の仕様でStatefulSetsを使用します:

• 専用ノード配置 - Gitalyポッドは、ノイジーネイバー問題を回避するため専用ノードにデプロイされます。
• リソース割り当て - ポッドのリクエストと制限は、ノードキャパシティからオーバーヘッド（Kubernetesシステムプロセスのために予約されたメモリ2 GB、1 vCPU）を差し引いた値に設定されます。
• Git cgroupsメモリ - デフォルトでは10%のバッファを含めて割り当てられますが、大規模なポッドでは最大6 GBに制限されます。たとえば、Smallでは27 GBをGit cgroupsに割り当て、3 GBをバッファとしますが、Medium以上のサイズでは6 GBの制限が適用されます（Mediumでは56 GBのcgroupsに対して6 GBのバッファ）。

Gitalyデプロイモード:

設計上、Kubernetes上のGitaly（非Cluster）は、各ポッドに保存されているリポジトリにとって単一障害点となるサービスです。データは、ポッドごとに1つのインスタンスから取得され、提供されます。各Gitalyポッドはそれぞれ独自のリポジトリ群を管理し、リポジトリを分散させることでGitストレージの水平スケーリングを実現します。

Gitaly Cluster (Praefect)は、クラウドネイティブファーストアーキテクチャではサポートされていません。KubernetesにおけるGitalyデプロイの制限については、Kubernetes上のGitalyを参照してください。

リポジトリの分散:

複数のGitalyストレージを設定した場合（例: default、storage1、storage2）、GitLabはデフォルトですべての新しいリポジトリをdefaultストレージに作成します。すべてのGitalyポッドにリポジトリを分散させるには、ストレージのウェイトを設定して負荷を分散させます。

リポジトリストレージのウェイトを設定する方法については、新しいリポジトリの保存先を設定するを参照してください。

Gitaly cgroupsの設定

Gitalyは、個々のGit操作によるリソース枯渇を防ぐためにcgroupsを使用します。デフォルトの設定では、リポジトリのcgroup数が1に設定されています。これは、オーバーサブスクリプションを通じて、単一のリポジトリがポッドのリソース全体を最大限に利用できるようにする出発点となります。

ただし、この設定がすべてのワークロードに最適とは限りません。アクティブなリポジトリが多い環境や、特定のリソース分離要件がある環境では、観測された使用パターンに基づいてcgroups設定を調整する必要があります。これには、リポジトリのcgroups数とメモリー割り当ての調整が含まれます。

Gitaly cgroupsの測定、チューニング、設定に関する詳細なガイダンスについては、Gitaly cgroupsを参照してください。

大規模なモノレポ（2 GB超）や負荷の高いGitワークロードの場合は、さらにGitalyの調整が必要になる場合があります。詳細なガイダンスについては、リファレンスアーキテクチャのサイジングガイドを参照してください。

外部サービスに関する注記

• PostgreSQLは、高可用性を実現するためにスタンバイレプリカを含めてデプロイすることができます。安定性とパフォーマンスを向上させるために、読み取りレプリカを追加することも可能です。より大規模な環境（L、XL）では、データベースの負荷を分散させるために読み取りレプリカを使用するメリットがより大きくなります。
• Redisインスタンスは、高可用性のためにスタンバイレプリカを含めてデプロイすることができます。GCPでは、Memorystoreインスタンスはメモリのみで構成されます。掲載されているマシン仕様は参考値です。
• インスタンスの設定を伴うすべてのクラウドプロバイダーサービスについて、回復力のあるクラウドアーキテクチャのプラクティスに合わせて、3つの異なるアベイラビリティーゾーンに最低3つのノードを実装することをおすすめします。

オートスケールと最小ポッド数

すべてのアーキテクチャは、Kubernetes Horizontal Pod Autoscaler（HPA）とCluster Autoscalerを使用してキャパシティを管理します:

• Webservice - CPU使用率に基づいてスケールし、最小ポッド数は控えめに設定します
• Sidekiq - CPU使用率に基づいてスケールします
• Cluster Autoscaler - ポッドリソースリクエストに基づいてノードを自動的にプロビジョニングおよび削除します

最小ポッド数は、内部テストに基づいて、コスト効率とパフォーマンスの信頼性のバランスを取るため、最大値の約2/3に設定されています。これは、次の目標を達成することを目的としています:

• 需要増加時に迅速にスケーリングする
• ノード障害またはアップグレード時に十分なキャパシティを確保する
• 需要の少ない期間のコストを最適化する

十分に把握できている負荷パターンがある場合は、必要に応じて最小値を調整できます:

• 急激なトラフィックスパイクがある環境や、厳格なパフォーマンスSLAがある環境では、最小値を増やす。
• モニタリングにより、継続的な負荷が一貫してデフォルト値を下回っていることが判明した場合は、最小値を減らす。

高度なスケーリング

クラウドネイティブファーストアーキテクチャは、基本仕様を超えてスケールするように設計されています。環境に次の要素がある場合、キャパシティの調整が必要になることがあります:

• 記載されているRPS目標よりも一貫して高いスループット
• 非定型的なワークロード構成（RPSの内訳を理解するを参照）
• 大規模なモノレポ（2 GB超）
• 大幅な追加ワークロード
• GitLab Duo Agent Platformの広範な使用

スケーリング戦略は、コンポーネントの種類によって異なります。

水平スケーリング（WebserviceとSidekiq）

キャパシティを増やすには、最大レプリカ数とノードプールのキャパシティを調整して、水平にスケールします:

• Webservice - Helmの値でmaxReplicasを増やし、それに対応するノードをWebserviceノードプールに追加する
• Sidekiq - より高いジョブスループットに対応できるようmaxReplicasを増やし、ノードをSidekiqノードプールに追加する

これらのステートレスコンポーネントでは、水平スケーリングが推奨されるアプローチです。

垂直スケーリング（PostgreSQL、Redis、Gitaly）

ステートフルコンポーネントでは、インスタンスまたはポッドの仕様を引き上げます:

• PostgreSQLとRedis - マネージドサービスプロバイダーを通じて、より大きなインスタンスタイプにアップグレードする。
• Gitaly - ポッドあたりのCPUとメモリの仕様を増やす。これには、Gitalyノードプールでより大きなノードタイプが必要になり、あわせてGit cgroupsのメモリ割り当ての調整も必要です。

Sidekiqキューの最適化

デフォルトでは、Sidekiqはすべてのジョブタイプを単一のキューで処理します。ワークロードパターンが多様な環境では、ジョブ特性に基づいて個別のキューを設定できます:

• 高優先度キュー - CIパイプライン処理やWebhook配信など、時間的制約のあるジョブに使用する
• CPUバウンドキュー - 並行処理設定を調整した、計算負荷の高いジョブに使用する
• デフォルトキュー - 標準的なバックグラウンド処理に使用する

キューを分離することで、ジョブ処理の信頼性が向上し、優先度の低いジョブが時間的制約のある操作をブロックするのを防ぐことができます。これは特に、自動化ワークロードの多い大規模な環境（L、XL）で効果的です。

Sidekiqキューの構成の詳細については、特定のジョブクラスの処理を参照してください。

GitLab Duo Agent Platformのスケーリング

GitLab Duo Agent Platformでは、標準的なGitLabワークロードに加えて、追加のインフラストラクチャ要件が発生します。Agent Platform導入時のモニタリングとスケーリングに関する詳細なガイダンスについては、GitLab Duo Agent Platformのスケーリングを参照してください。

スケーリングに関する考慮事項

いずれかのコンポーネントを大幅にスケールする場合は、次を実行してください:

• 依存コンポーネントのリソース飽和状態をモニタリングする。WebserviceまたはSidekiqへの負荷が増加すると、PostgreSQLとGitalyに影響を与える可能性があります。
• スケーリングに関する変更は、先に本番環境以外でテストする。
• サービス間でボトルネックが移動しないよう、相互に依存するコンポーネントをまとめてスケールする。

包括的なスケーリングのガイダンスについては、環境をスケーリングするを参照してください。

デプロイ

クラウドネイティブファーストアーキテクチャは、Helmチャートと外部サービスプロバイダーを直接使用するか、GitLab Environment Toolkitを通じてデプロイできます。

GitLab Environment Toolkit

GitLab Environment Toolkitは、以下により自動デプロイを提供します:

• クラウドリソースのInfrastructure as Code（Terraform）
• Helmチャート設定の自動化
• 各アーキテクチャサイズ向けの事前検証済みの設定
• アップグレードとメンテナンスの簡素化

デプロイの手順については、GitLab Environment Toolkitのドキュメントを参照してください。

手動デプロイ

手動デプロイの前提条件:

• 必要なデータベース、ユーザー、権限を設定済みの外部PostgreSQL
• 設定済みでアクセス可能な外部Redisインスタンス
• 作成済みのオブジェクトストレージバケット
• 必要に応じて認証用に作成したKubernetes Secrets（PostgreSQLパスワード、Redisパスワード、オブジェクトストレージ認証情報、GitLabシークレット）

前提条件とシークレット設定の詳細については、GitLabチャートの前提条件とシークレットを設定するを参照してください。

Helmチャートを使用した手動デプロイの場は、次の手順に従います:

1. 前提条件の説明に従って、必要な外部サービスとシークレットを設定します
2. 適切なノードプールとオートスケーラーを備えたKubernetesクラスターを設定します
3. Helm Chart設定セクションに示されているHelm値を適用します
4. helm installを使用してGitLabをデプロイします

詳細な手動デプロイ手順については、KubernetesへのGitLabのインストールを参照してください。

Helm Chart設定

Helm Chartの設定例と詳細なデプロイのガイダンスについては、GitLabチャートリポジトリを参照してください。

クラウドネイティブファーストアーキテクチャにおける主要な設定領域は次のとおりです:

• リソース仕様 - ポッドのCPUとメモリの制限は、上記の各アーキテクチャサイズに示されている仕様と一致させる
• オートスケール - HPA構成により、最小ポッド数を最大数の2/3に設定し、CPUベースのスケーリング目標を指定する
• ノード配置 - ノードセレクターにより、ワークロードが適切なノードプール（例: webservice、sidekiq、gitaly、support）にデプロイされるようにする
• 外部サービス - PostgreSQL、Redis、オブジェクトストレージの接続の詳細
• Gitaly - cgroups、永続性、ストレージ分散を備えたStatefulSet設定

アーキテクチャ固有のレプリカ数とリソース値については、上記の各サイズセクションの仕様を参照してください。

次の手順

デプロイ後、通常、実際のワークロードパターンに合わせて環境のモニタリングとチューニングが必要になります。

モニタリングと検証

1. リソース使用状況のモニタリング - Prometheusを使用して、すべてのコンポーネントのCPU、メモリ、キュー深度を追跡する
2. RPS前提条件の検証 - 実際のRPSの内訳を、想定している80/10/10の構成と比較する
3. 調整が必要な箇所の特定 - 使用率が一貫して70％を超えているコンポーネントがないか確認する
4. Gitaly cgroupsの確認 - リポジトリアクセスパターンに基づいて、リポジトリのcgroups数のチューニングを検討する

必要に応じて調整する

リファレンスアーキテクチャは出発点です。多くの環境では、次の要因に基づく調整が有効です:

• 実際のワークロード構成 - API/Web/Gitの比率が一般的なパターンと大きく異なる場合は、RPSの構成を理解するを参照してください
• リポジトリの特性 - モノレポのサイズ、クローン作成の頻度、アクセスパターンにより、コンポーネント固有の調整が必要になる場合があります
• 成長パターン - ユーザー数の増加、CI/CDの拡張、または自動化のスケーリング

コンポーネント別の調整のガイダンスについては、高度なスケーリングを参照してください。

オプション機能を設定する

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