本番アーキテクチャ

Tags:

Visibility: Audit

GitLab.com のコアインフラは主に Google Cloud Platform（GCP）の us-east1 リージョンにホストされています（リージョンとゾーンを参照）。

このドキュメントは GitLab.com の公開向け運用に不可欠でないサーバーはカバーしていません。

目的

このページは GitLab.com の本番アーキテクチャの概要を記録した文書です。

スコープ

GitLab.com を実行するコンピュートとネットワークのレイアウト

役割と責任

役割責任
インフラチーム設定と管理の責任者
インフラ管理（コードオーナー）重大な変更とこの手順の例外の承認責任者

手順

関連ページ

現在のアーキテクチャ

GitLab.com 本番アーキテクチャ

GitLab.com 本番アーキテクチャ図

ソース、GitLab 社内使用のみ。

GitLab.com の大部分は GitLab クラウドネイティブ Helm チャートを使用して Kubernetes 上にデプロイされています。PostgresSQL、Gitaly、Redis、Elasticsearch などのデータストアサービスにはいくつかの例外があります。

クラスター設定

GitLab.com は本番用に 4 つの Kubernetes クラスターを使用しており、ステージング用にも同様の設定のクラスターがあります。 1 つは us-east1 リージョンのリージョナルクラスターで、残りの 3 つは GCP のアベイラビリティゾーン us-east1-b、us-east1-c、us-east1-d に対応するゾーンクラスターです。 複数のクラスターを持つ理由は以下の通りです。

  • 高帯域幅サービスがゾーンをまたいでネットワークトラフィックを送信しないようにするため
  • ワークロードの分離
  • クラスターのメンテナンス変更とアップグレードの分離

複数のゾーンクラスターにトラフィックを分割することを選択した理由の詳細については、単一のリージョナルクラスターに対する代替案を検討したこのIssueを参照してください。 単一のリージョナルクラスターは Sidekiq や Kas のような高帯域幅要件のないサービスやリージョナルデプロイがより適したサービスにも使用されています。

GitLab の透明性の価値に従い、GitLab.com のすべての Kubernetes クラスター設定はインフラと設定を含めて公開されています。

インストールの管理には以下のプロジェクトが使用されています。

  • k8s-workloads/gitlab-com: GitLab Helm チャートの GitLab.com 設定を含みます。
  • k8s-workloads/gitlab-helmfiles: クラスターのロギング、モニタリング、インテグレーションの設定を含みます。
  • argocd/apps: ArgoCD のすべてのサービスのアプリケーションを含みます。
  • argocd/config: ArgoCD のトップレベルアプリケーション、AppProjects、リポジトリ、クラスターインベントリ、RBAC 設定を含みます。
  • config-mgmt: クラスターの Terraform 設定で、クラスター、ノードプール、サービスアカウント、IP アドレス予約など、クラスターを実行するために必要なすべてのリソースが設定されています。
  • charts: インフラ部門が、コミュニティチャートのないサービスをデプロイするために作成したチャートです。

すべてのインバウンドの Web リクエスト、git http リクエスト、git ssh リクエストは Cloudflare で受信され、HAProxy をオリジンとしています。Sidekiq では、Sidekiq キューを異なるリソースグループに分割するために複数の Sidekiq クラスター用ポッドが設定されています。詳細は Sidekiq のチャートドキュメントを参照してください。

モニタリングとロギング

GitLab.com のモニタリングはアプリケーションと同じクラスターで実行されます。メトリクスは ops クラスターで Mimir を使用して集約され、複数のコンポーネントを持つ Grafana でインターフェースを提供しています。

Prometheus は monitoring ネームスペースの kube-prometheus-stack Helm チャートを使用して設定されており、すべてのクラスターが独自の Prometheus を持つことでメトリクスのシャーディングを実現しています。

ソース、GitLab 社内使用のみ

クラスターのアラートは、プラットフォームの全体的な SLA に集約される生成済みのルールを使用します。

ロギングはfluentd-elasticsearchを使用して設定されており、すべてのポッドのログが一意の Elasticsearch インデックスに転送されます。fluentd-elasticsearch は logging ネームスペースにデプロイされています。

クラスター設定の更新

GitLab アプリケーションのみに使用される単一のネームスペース gitlab があります。 チャート設定の更新は gitlab-com k8s-workloads プロジェクトで設定され、環境ごとのオーバーライドがある GitLab.com 環境のデフォルト設定として YAML 設定ファイルが使用されています。 これらの設定の変更は、MR レビューワークフローを使用してレビューした後、SRE と Delivery チームによって適用されます。 GitLab.com で変更が承認されると、設定の更新が本番環境の可用性に依存しないよう、変更を適用するパイプラインは別の運用環境で実行されます。

ロギング、モニタリングなどの他のサービスのクラスター内ネームスペースについては、gitlab-helmfilesを使用して同様の GitOps ワークフローが踏まれます。

GitLab.com は Kubernetes クラスターで使用されるイメージのプルに自分自身に依存しません。 代わりに、CNG イメージには dev.gitlab.org コンテナレジストリを使用します。 これはインシデント発生時でもイメージのプルとアプリケーションの実行を必要に応じて維持できるようにするためです。 自分たちでビルドしないイメージについては、Docker Hub からプルする場合があります。 便利なことに、これらのイメージは Google の Container Registry 製品にミラーリングされています。 GKE ノードはこのミラーを最初から設定しており、Docker Hub が利用できない場合のさらなる冗長性を提供しています。

データベースアーキテクチャ

ソース、GitLab 社内使用のみ

Redis アーキテクチャ

ソース、GitLab 社内使用のみ

ソース、GitLab 社内使用のみ

GitLab.com はキャッシュ、レート制限、Sidekiq キューイングなど、さまざまなユースケース向けに複数の Redis シャードを使用しています。各 Redis シャードの設定と使用法についての詳細は、chef-repo および GitLab を参照してください。Redis インスタンスと GitLab デプロイメントの関係はこの Grafana リンクで確認できます。

必要に応じて、アプリケーションの変更によって CPU 飽和に対処することもあります。これに関するいくつかのテクニックについてはこのビデオで説明されています。

ネットワークアーキテクチャ

ソース、GitLab 社内使用のみ

ネットワークインフラは現在のアーキテクチャ図で定義された各クラスのサーバー向けのネットワークで構成されています。各ネットワークには上記で定義された同様のルールセットが含まれています。

現在、ops ネットワークとピアリングしています。このネットワーク内には、メトリクスシステムを充実させるために InfluxDB と Prometheus データの流入を許可するモニタリングインフラの大部分があります。

アラート管理のために、環境の潜在的な障害に関わらずアラートを送信できるよう、すべてのネットワークをピアリングしてアラートマネージャーのクラスターを構成しています。

これらのネットワークピア間でアプリケーションデータや顧客データは流れません。

DNS と WAF

GitLab は Cloudflare の Web アプリケーションファイアウォール（WAF）を活用しています。DNS（gitlab.com、gitlab.net）は Cloudflare でホストし、Amazon Route 53（gitlab.io など）も使用しています。 CloudFlare についての詳細はランブックとアーキテクチャ概要を参照してください。

TLD ゾーン

DNS 名については、GitLab をサービスとして提供するすべてのサービスは gitlab.com ドメイン、GitLab をサポートする補助サービス（Chef、ChatOps、VPN、ロギング、モニタリングなど）は gitlab.net ドメインに配置します。

リモートアクセス

本番環境へのアクセスはバスチョンホストを通じて、アクセスが必要な者のみに付与されます。 バスチョンを通じたアクセスの設定手順はバスチョンランブックを参照してください。

シークレット管理

GitLab は 2 つの異なるシークレット管理アプローチを使用しています。Google Cloud Platform（GCP）サービスには GKMS、その他のすべてのホストシークレットには Chef Encrypted Data Bags を使用しています。

GKMS シークレット

シークレット管理の詳細については、GKMS を使用した Chef シークレットおよび Kubernetes でのシークレット管理方法のランブックを参照してください。

モニタリング

状態を確認するには、詳細についてモニタリングハンドブックを参照してください。

例外

このアーキテクチャポリシーと設計への例外はコンプライアンス Issue トラッカーで追跡されます。

参考資料

CI サービスアーキテクチャ
このドキュメントは、GitLab.com ユーザー向けに提供され、インフラチームが管理している共有ランナーおよび GitLab 共有ランナーのみを対象としています。 全体アーキテクチャ 私たちの CI …
サポートアーキテクチャ
このドキュメントは GitLab.com の機能をサポートするアーキテクチャを対象としていますが、ユーザー向けではなく、インフラチームが管理しています。 dev.gitlab.org …
ディザスタリカバリアーキテクチャ
このページは内部ハンドブックの単一ページに移動しました。
最終更新 May 6, 2026: Merge pull request #100 from kyama0/fix/upload-images-tolerate-upstream-missing (70970e1a)
ページのソースコードを見る - ページの編集 - please contribute. Creative Commons License