数千人規模の開発を支えるGitLab環境の設計方法

エンタープライズ規模では、小さなアーキテクチャ上の選択でも想定以上の影響を及ぼすことがあります。少数のチームでは問題なく機能していたデプロイも、数千人のデベロッパー、リポジトリ、パイプラインが依存するようになると、制約へと変わりかねません。

だからこそ、ロールアウト前の判断の一つひとつが大きな意味を持ちます。たとえば、次のような要素が挙げられます。

• チームが運用すべき範囲を定めるデプロイモデル
• CI/CDワークロードの実行方法や分離のあり方、さらにプラットフォームチームが担う運用負荷を左右するRunner戦略
• 冗長性と復旧のあり方を左右する可用性目標
• プラットフォームに必要なキャパシティを決めるワークロード

これらの要素が組み合わさることで、新たな運用上の制約を生まずに、プラットフォームがどれだけ成長を吸収できるかが決まります。

本ガイドの内容

• スケール前に決めておくべきアーキテクチャ上の判断
• Runner戦略の立て方
• 高可用性とディザスタリカバリの計画
• 大規模環境でパイプラインのパフォーマンスが低下するポイント
• Kubernetesとクラウドネイティブなデプロイの検討事項
• プラットフォームチーム向けアーキテクチャ検証チェックリスト

スケール前に決めておくべきアーキテクチャ上の判断

GitLabのデプロイモデルによって、プラットフォームのどの部分をチームがサイジング、保護、監視、アップグレード、復旧しなければならないかが決まります。エンタープライズ向けのデプロイでは、主に次の3つの選択肢があります。

GitLab.com： GitLabが提供するマルチテナント型のSaaS（Software as a Service）です。アプリケーションと基盤インフラはGitLabが運用し、組織側はGitLabの設定やインテグレーション、自社で管理するRunnerを担当します。

GitLab Dedicated： Amazon Web Services（AWS）上でホストされる、フルマネージドの単一テナント型SaaSです。アップデート、高可用性、ディザスタリカバリを含む基盤インフラはGitLabが運用し、組織側はアプリケーションレベルの制御を通じてユーザーとデータへのアクセスを管理します。

GitLab Self-Managed： 組織が自らGitLabインスタンスをインストール、管理、保守します。インフラを自社で管理し、環境の運用、スケーリング、セキュリティ確保、復旧までを担います。

組織に求められる制御のレベルと、無理なく担えるインフラ運用の責任範囲を踏まえてモデルを選びましょう。たとえば、次のような選び方が考えられます。

• マルチテナント型SaaSで要件を満たせ、インフラ運用の最小化を最優先する場合はGitLab.com
• 単一テナントによる分離や、ネットワーク、データレジデンシーといった領域の制御が必要で、なおかつGitLabのインフラを自社で運用したくない場合はGitLab Dedicated
• 基盤インフラを直接制御する必要があり、プラットフォームを運用できる体制がチームに整っている場合はGitLab Self-Managed

判断を下す前に、選択肢を絞り込む決め手となりうる要件を文書化しておきましょう。特に注意すべきなのは、データレジデンシー、ネットワーク分離、復旧目標、インフラの制御範囲です。そのうえで、アップグレード、監視、キャパシティの計画、バックアップ、インシデント対応など、各モデルでチーム側に残る運用業務を整理します。

この作業を通じて、組織にどこまでのインフラ責任が必要で、現実的にどこまで担えるのかという、核心となるトレードオフが明確になるはずです。

運用の境界線が定まったら、次はCI/CDワークロードを実行するコンピュートレイヤーの計画に進みます。

Runner戦略の立て方

GitLab RunnerはCI/CDジョブを実行し、その背後にあるパイプラインはGitLabアプリケーションが調整します。なぜこの役割分担がエンタープライズ規模で重要なのでしょうか。アプリケーションとRunnerとでは、キャパシティが反応する需要の種類が異なるからです。アプリケーションはGit、Web、API、自動化のトラフィックを処理し、RunnerフリートはCI/CD処理の量と同時実行数を吸収します。

そのため、Runnerフリートはデベロッパーの人数ではなく、ワークロードそのものに基づいてサイジングすべきです。まずは次の項目を文書化しましょう。

• ジョブの量と所要時間
• ピーク時の同時実行数
• オペレーティングシステムとコンピュートの要件
• ネットワーク経路と特殊なハードウェア
• 特権が必要なワークロードや機密性の高いワークロード
• リリース期間や定期スキャンなどのピーク期間

これらの情報をもとに、キュー待ち時間（queued duration）の目標を達成するために同時に実行しなければならないジョブ数を見積もります。チームの規模よりもワークロードのデータが重要なのは、デベロッパー数が同じ組織でも、パイプラインの実行頻度、自動化の度合い、ジョブの要件によってCI/CDの需要が大きく異なることがあるためです。

適切なRunnerスコープを選ぶ

Runnerスコープは、各プールをチームがどの範囲で利用できるかを決めるもので、インスタンスRunnerはGitLabインスタンス全体のプロジェクトで、グループRunnerは特定グループ内のプロジェクトとサブグループに限定して利用できます。最も範囲が狭いプロジェクトRunnerは、専用の認証情報や特殊なインフラ、より強固な分離を必要とするワークロードに適しています。ただし、キャパシティを少数のワークロードで専有するため、ジョブの発生が断続的な場合はアイドル状態になることもあり、利用率も判断材料に加えましょう。

ワークロードの信頼境界とコンピュート要件を満たす範囲で、できるだけ広いスコープを選ぶのが基本です。一般にプールが広いほど利用率は高まる一方、機密性の高いデプロイジョブや特殊なワークロードでは、専用インフラを用意する合理性が生まれる場合もあります。

オートスケールを計画する

オートスケールを使えば、需要に応じてRunnerのキャパシティを拡張・縮小できますが、そのインフラの運用にもプラットフォームエンジニアリングの工数がかかります。Runnerフリートを自社で管理する場合は、新しいリソースが使えるようになるまでの時間を考慮してください。インスタンスのプロビジョニング、クラウドのクォータ、イメージのダウンロード、キャッシュの可用性はいずれも、需要が急増した際のキュー待ち時間に影響を与える可能性があります。追加のコンピュートが立ち上がるまでの短期的な需要を吸収できるよう、すぐに使えるキャパシティを十分に確保しておきましょう。

この運用業務をGitLabに任せることもできます。GitLabホストRunnerはGitLab.comとGitLab Dedicatedで利用でき、基盤となるRunnerインフラとオートスケールはGitLabが管理します。Runnerマシンのプロビジョニング、パッチ適用、スケーリングにかける時間を減らしたいチームにとって、Runner戦略はインフラ管理の判断から、キャパシティとワークロード配置の判断へと性質を変えることになるでしょう。

ワークロードに合ったexecutorを選ぶ

executorの選択によって、CI/CDジョブがどこで実行され、チームがどのインフラを運用しなければならないかが決まります。クラウドネイティブ環境であればKubernetes executorが既存のKubernetesクラスターを利用し、パブリッククラウドの仮想マシン上でオートスケールするワークロードであれば、GitLabが提供するDocker Autoscaler executorやInstance executorを使えます。

最適な選択は、ジョブが必要とする環境と、チームが管理できるインフラによって決まります。Kubernetes executorでは各CI/CDジョブが個別のPodで実行されるため、クラスターの挙動もRunnerのパフォーマンスの一部になります。スケジューリングの遅延、リソースのリクエストとリミット、ノードのキャパシティ、オートスケールといった要素はすべて、ジョブの開始や完了の速さに影響する点に注意してください。

CI/CDの需要が増えてもexecutorがボトルネックにならないよう、こうした制約をキャパシティの計画に織り込んでおきましょう。

高可用性とディザスタリカバリの計画

可用性の計画は、ダウンタイムとデータ損失がビジネスに与える影響を把握するところから始めるべきです。次の目標を定義しましょう。

• サービスレベル目標（SLO）：通常運用時にプラットフォームが維持すべきサービスレベル
• 目標復旧時間（RTO）：障害発生後、どれだけ早くサービスを復旧させる必要があるか
• 目標復旧時点（RPO）：組織が許容できるデータ損失の範囲

これらの目標を組み合わせることで、アーキテクチャに必要な冗長性と復旧能力が明確になります。

そのうちどこまでをプラットフォームチームが担うかは、デプロイモデルによって異なります。GitLab Self-Managedを利用している場合、こうしたアーキテクチャ上の判断はすべてチームの責任です。GitLabリファレンスアーキテクチャを本番環境に対応した出発点として活用し、可用性と復旧の要件に合わせてトポロジーを調整してください。

GitLab Dedicatedでは、ディザスタリカバリの基盤インフラとフェイルオーバーのプロセスをGitLabが管理します。お客様はGeoベースのディザスタリカバリ用にセカンダリAWSリージョンを選択でき、プライマリリージョンとセカンダリリージョン間のレプリケーションの維持と、必要時のフェイルオーバーはGitLabが担います。

Self-Managedの場合、高可用性、ディザスタリカバリ、バックアップは、それぞれ別個でありながら互いに補完し合うレイヤーとして復旧設計に組み込む必要があります。

• 高可用性は、プライマリ環境内のコンポーネント障害による影響を抑えます。
• ディザスタリカバリは、サイトやリージョンが失われた後にサービスを復旧させます。
• バックアップは、データの破損や削除のほか、レプリケーションによってセカンダリサイトにまで伝播しうる障害からデータを守ります。

さらにSelf-Managedでは、復旧目標をアーキテクチャ要件に落とし込みましょう。どこに冗長性が必要か、データをどのようにレプリケートするか、重要なデータをバックアップでどう保護するかを決めます。IDサービスやネットワークサービスといった依存関係も、復旧計画に含めてください。

GitLab Geoは、プライマリサイトから同期するセカンダリサイトを備えたアクティブ/パッシブ型のディザスタリカバリアーキテクチャを提供します。Self-Managedではフェイルオーバーにお客様自身による運用手順が必要となるため、現実に即した条件でプロセスをリハーサルし、その結果をRTOとRPOに照らして評価してください。

復旧を遅らせる可能性のある依存関係の障害や手動の手順を記録し、その結果をもとに設計を強化していきましょう。

大規模環境でパイプラインのパフォーマンスが低下するポイント

GitLabの導入が進むにつれて、パフォーマンス計画の重点は、想定される需要に合わせたサイジングから、実際の負荷がかかった状態でのプラットフォームの挙動の検証へと移ります。最初のステップは、どこで時間が失われているのかを特定することです。

GitLabではキュー待ち時間と実行時間が区別されており、これが診断の有効な出発点になります。ジョブのキュー待ち時間は開始までにどれだけ待機したかを示し、ジョブの実行時間は実際の処理にかかった時間を表します。パイプラインの実行時間はパイプラインの実行に費やされた時間を計測するもので、保留中のキュー待ち時間は含まれない点も押さえておきましょう。

これらの指標は、それぞれ異なる制約を示しています。キュー待ち時間が長ければRunnerのキャパシティ不足が考えられ、実行時間が長ければパイプライン設計、テストスイート、依存関係のダウンロード、リポジトリの転送などが原因となっている可能性があります。

パフォーマンスのベースラインを確立する

代表的なプロジェクトを通常時とピーク時の両方の需要下でテストし、どこからパフォーマンスが低下し始めるかを確認します。リリース期間、定期的なセキュリティスキャン、コミットが集中する時期といった条件も含め、ボトルネックを浮き彫りにする次のシグナルを追跡しましょう。

• キュー待ち時間
• ジョブとパイプラインの実行時間
• Runnerの利用率
• リトライと失敗
• キャッシュのパフォーマンス
• アーティファクトの転送時間
• インフラの飽和度

結果はRunnerプールやワークロードの種類ごとに分けて分析し、組織全体の平均値によって特定のチームやワークロードに影響するボトルネックが見えなくならないようにします。そこから得た知見をもとに、Runnerのキャパシティ拡張、パイプラインの最適化、GitLabアプリケーションのスケーリングを行うしきい値を設定しましょう。

大規模リポジトリとモノレポは個別にテストする

大規模リポジトリとモノレポは、GitLabとRunnerのインフラに特有の負荷をかけます。頻繁なクローンやフェッチはCPU、メモリ、ディスク、ネットワークの使用量を増加させる可能性があり、多くのパイプラインが同じリポジトリに同時にアクセスする場合は特に顕著です。

その影響を見積もる際は、リポジトリのサイズだけに目を向けないようにしましょう。クローンの頻度、CI/CDの同時実行状況、ブランチの運用パターン、各ジョブが転送するデータ量は、いずれもプラットフォームの負荷を左右します。

キャパシティを拡張する前にワークロードを最適化する

パイプラインの設計次第で、プラットフォームそのものへの負荷を減らせます。独立したジョブは並列実行し、不要なパイプラインは避け、頻繁にダウンロードされる依存関係はキャッシュし、アーティファクトの保持期間は制限しましょう。モノレポでは、関連するパスが変更されたときだけジョブをトリガーし、各ジョブが転送するリポジトリデータの量を減らします。

ロールアウト後も、利用状況の変化に合わせて計測を続けてください。Self-Managed環境では、実際のリソース使用率とワークロードのパターンが、アーキテクチャをスケールすべきタイミングを最も明確に示すシグナルとなります。

Kubernetesとクラウドネイティブなデプロイの検討事項

GitLabのアーキテクチャにおいて、Kubernetesは2つの異なる役割を担えます。Kubernetes executorは既存のクラスター内でCI/CDジョブをPodとして実行でき、GitLab Self-ManagedはKubernetes上のクラウドネイティブアーキテクチャで稼働できます。

これらの選択はプラットフォームの異なる部分に影響するため、個別に評価する必要があります。RunnerにKubernetesを使えばCI/CDのコンピュートのプロビジョニングとスケーリングの方法が変わり、GitLab自体をKubernetes上で動かせばアプリケーションとそれを支えるインフラの運用方法が変わります。

Kubernetes Runnerはクラスターの一部として計画する

Kubernetes executorでは、RunnerマネージャーがKubernetes APIを呼び出し、CI/CDジョブごとにPodを作成します。つまり、クラスターそのものがRunnerアーキテクチャの一部になるということです。

こうしたジョブが依存するKubernetesのリソースと制御を計画しましょう。具体的には、ネームスペース、サービスアカウント、リソースのリクエストとリミット、ワークロードの分離などです。機密性の高いデプロイジョブは、信頼性の低いビルドワークロードとより強固に分離する必要がある場合もあります。

設定と同じくらい重要なのがキャパシティです。クラスターのオートスケールが、キュー待ち時間の目標を満たせるスピードでノードを追加できるかをテストしてください。最終的には十分なコンピュートが確保されるとしても、ノードのプロビジョニングが遅ければ、需要の急増時にジョブが待たされることになります。

GitLabをKubernetes上で動かすためのアーキテクチャを選ぶ

GitLab自体をKubernetes上で動かす場合は、より広範なアーキテクチャ上の判断が求められます。GitLabが新規のSelf-Managedデプロイ向けに推奨しているCloud Nativeリファレンスアーキテクチャでは、GitLabのコンポーネントをKubernetes上で稼働させ、PostgreSQL、Redis、オブジェクトストレージは外部に配置します。

特定のコンポーネントをKubernetesの外に置く必要がある場合は、Cloud Native Hybridも引き続き選択肢となります。標準のCloud NativeアーキテクチャではGitalyが非クラスター構成で稼働するため、たとえばリポジトリレベルの高可用性のためにGitaly Clusterが必要なチームは、ハイブリッド型またはVMベースのリファレンスアーキテクチャを検討すべきです。

どのモデルを選ぶにしても、GitLabプラットフォーム全体の運用計画にKubernetesを組み込んでください。クラスターと外部サービスをまたいだ可観測性に加え、GitLabとそのインフラ依存関係を考慮したアップグレードプロセスが必要になります。キャパシティと復旧のテストでも、クラスターを本番環境の一部として対象に含めましょう。

このデプロイモデルの詳細については、「クラウドネイティブとは？」をご覧ください。Kubernetesは、その運用モデルがインフラ要件に合致し、かつ確実に運用できるスキルがチームに備わっている場合に選択しましょう。

プラットフォームチーム向けアーキテクチャ検証チェックリスト

ロールアウト前にこのチェックリストを活用し、デプロイ、サイジング、Runner、復旧、パフォーマンスにわたる主要なアーキテクチャ上の判断を検証してください。各項目について、判断の裏付けとなるエビデンスを文書化するか、ギャップを解消する担当者を割り当てます。

エンタープライズ規模では、初期のアーキテクチャ上の判断すべてに負荷がかかります。強固なGitLab環境ほど、組織が実際にどう運用されているかを反映し、需要の変化に備えた余裕を残しています。

こうした条件は、導入の拡大とともに変わっていきます。計測を続け、需要の変化に応じてアーキテクチャを見直し、次の判断はエビデンスに基づいて下しましょう。そうした規律を持つことで、GitLabは単により多くのユーザーを支えるプラットフォームから、組織の成長に歩調を合わせて進化し続けるプラットフォームへと変わります。

💡 GitLab Dedicatedがエンタープライズ規模の運用をどのように支えるのか、詳しくはこちら。