Content last updated 2026-09-07

Cells

This page contains information related to upcoming products, features, and functionality. It is important to note that the information presented is for informational purposes only. Please do not rely on this information for purchasing or planning purposes. The development, release, and timing of any products, features, or functionality may be subject to change or delay and remain at the sole discretion of GitLab Inc.

Status	Authors	Coach	DRIs	Owning Stage	Created
ongoing	`ayufan` `fzimmer` `DylanGriffith` `lohrc` `tkuah`	`ayufan` `sxuereb`	`daveyleach`	devops tenant scale	2022-09-07

このドキュメントは作業中であり、Cells の設計のごく初期の状態を表しています。重要な部分の多くがまだ文書化されていませんが、今後追記していく予定です。

Cells は、私たちの SaaS プラットフォームのための新しいアーキテクチャです。このアーキテクチャは水平方向にスケール可能で、レジリエントであり、より一貫したユーザー体験を提供します。将来的には、データレジデンシー制御（リージョン）やフェデレーション機能などの追加機能も提供する可能性があります。

ゴール

目標、用語集、要件を参照してください。

Cells のイテレーション

（保留中）Cells 1.0のターゲットは、SaaS GitLab.com オファリングを利用する社内のお客様向けのソリューションを提供し、Cells の基礎的な作業を行うことです。
（保留中）Cells 1.5のターゲットは、Cells 1.0 アーキテクチャの上に構築された、SaaS GitLab.com オファリングを利用する既存および新規のエンタープライズ顧客向けのマイグレーションソリューションを提供することです。
（保留中）Cells 2.0のターゲットは、Cell ベースのアーキテクチャにおけるパブリックおよびオープンソースのコントリビューションモデルをサポートすることです。
Protocells は Cells 1.0、Cells 1.5、Cells 2.0 を置き換え、データベースの負荷を恒久的に削減することに新たな焦点を置いたものです。

アーキテクチャ概要

@startuml

cloud "Cloudflare" as CF {
  [Routing Service Worker] as CF_RSW
}

node "GitLab Inc. Infrastructure" {
  node "Cell Services" as Cell_Services {
    [Topology Service] as TS
    [Cloud Spanner] as TS_CS

    TS --> TS_CS
  }

  node "A Cell" as Cell {
    frame "GitLab Rails" as Cell_Rails {
      [Puma + Workhorse + LB] as Cell_Puma
      [Sidekiq] as Cell_Sidekiq
    }

    [Container Registry] as Cell_Registry

    database DB as Cell_DB {
      frame "PostgreSQL Cluster" as Cell_PSQL {
        package "ci" as Cell_PSQL_ci {
          [gitlab_ci] as Cell_PSQL_gitlab_ci
        }

        package "main" as Cell_PSQL_main {
          [gitlab_main_cell_local] as Cell_PSQL_gitlab_main_cell_local
          [gitlab_main_org] as Cell_PSQL_gitlab_main_org
        }

        PC_PSQL_main -[hidden]-> Cell_PSQL_ci
      }

      frame "Redis Cluster" as Cell_Redis {
        [Redis (many)] as Cell_Redis_many
      }

      frame "Gitaly Cluster" as Cell_Gitaly {
        [Gitaly Nodes (many)] as Cell_Gitaly_many
      }
    }

    Cell_Rails -[hidden]-> Cell_DB
  }

}

CF_RSW --> Cell_Puma
CF_RSW --> Cell_Registry
CF_RSW --> Cell_Puma
CF_RSW --> Cell_Registry
CF_RSW --> TS
Cell_Puma --> TS
Cell_Sidekiq --> TS

@enduml

技術的な提案

Cells アーキテクチャは、データ処理、ロケーション、スケーラビリティ、そして GitLab アーキテクチャ全体に長期的な影響を与えます。このセクションでは、評価対象となっているさまざまな技術提案へのリンクをまとめます。

影響を受ける機能

Cells アーキテクチャは多くの機能に影響を与え、その中には書き直しや大幅な変更を必要とするものもあります。影響を受ける既知の機能と、暫定的な解決案のリストを以下に示します。

影響を受ける機能: プレースホルダー

以下の影響を受ける機能のリストは、Cells の影響を見積もり、ソリューション提案を作成するための作業がまだ必要なプレースホルダーにすぎません。

よくある質問

Cells アーキテクチャと GitLab Dedicated の違いは何ですか？

Cells と Dedicated の個別の考えと違いについては、こちらにまとめています。

新しい Cells アーキテクチャは、GitLab.com をスケールするためのものです。そのために、Organization を Cells に移すという方法を取りますが、異なる Organization は引き続きサーバーリソースを共有することができます（アプリケーション側で他の Organization からの分離を提供する形です）。それでも、すべては既存の GitLab SaaS ドメイン名 gitlab.com の下で動作します。また、Cells は引き続き、users などの一部の共通データや、Group・Project のルーティング情報を共有します。たとえば、別々の Organization に属していて、それらが別の Cell に存在していたとしても、2 人のユーザーが同じユーザー名を持つことはできません。

上記の違いがあるため、GitLab Dedicatedは、お客様ごとに専用のサーバーリソースでプロビジョニングされるという理由から、依然として高いコストで提供されています。一方、Cells は共有リソースを使用します。このため、GitLab Dedicated は大規模顧客により適しており、GitLab Cells は GitLab.com で利用を始める中小規模の企業により適しています。

一方、GitLab Dedicated は、任意の Organization に対して完全に分離された GitLab インスタンスを提供することを目的としています。このインスタンスは独自のカスタムドメイン名で動作しており、GitLab SaaS を含む他のすべての GitLab インスタンスから完全に分離されています。たとえば、GitLab Dedicated 上のユーザーは、GitLab.com で既に取られているユーザー名と異なるユニークなユーザー名を持つ必要はありません。

異なる Cells は互いに通信できますか？

直接はできません。私たちのゴールは、Cells を分離した状態に保ち、グローバルサービスを通じてのみ通信することです。

Cells はどのようにプロビジョニングされますか？

Cells の GitLab.com クラスタは、GitLab Instances のプロビジョニングに GitLab Dedicatedのツーリングを使用しています。そのため、いくつかのプロジェクトでは Cells は Tenant と呼ばれることがあります。 Cell インスタンスがプロビジョニングされると、GitLab.com クラスタに参加して Cell となります。 1 つの要件として、そのインスタンスに事前のデータが含まれていないことが挙げられます。これは、Cells が Topology Serviceから取得するカスタムのプライマリキー範囲でデータを保存するためです。

Cells のデプロイメント

Cells は the tissue プロジェクトで管理されており、dev および prod の両環境のすべての Cells を rings ディレクトリで管理しています。

各 Cells の構成は、GitLab Dedicated のテナントでも既に使用されている tenant-model-schema に対して検証されます。

デプロイメントプロセス

デプロイメントワークフローは以下の手順に従います:

Instrumentorが Cell の構成（Dedicated Tooling では TENANT_MODEL として知られています）を取得します。
Instrumentor が TENANT_MODEL をパースし、必要な構成を GET (GitLab Environment Toolkit)に渡します。
GET がインフラをデプロイし、プロビジョニングされた Kubernetes Cluster に GitLab をインストールするために Helm Installationを使用します。

このアプローチは、ステージングおよび本番環境において Kubernetes ワークロードを経由して既存のレガシー Cell インフラに GitLab をデプロイする方法と整合しています。

[!note] これは高レベルの概要です。より詳細については、Dedicated アーキテクチャドキュメントを参照してください。

共有リソースに到達するため、Cells は Private Service Connectを使用します。

設計に関するディスカッションも参照してください。

Cells のトポロジーとは何ですか？

設計に関するディスカッションを参照してください。

Organization のユーザーは、どのように正しい Cell にルーティングされるのですか？

未定

ユーザーは Cells と Organization に対してどのように認証しますか？

設計に関するディスカッションを参照してください。

ユーザーはどのようにログインしますか？

現在の承認済みの設計については、Organization ログイン設計ドキュメントを参照してください。

UI: Organization へのログインは、その Organization にスコープを限定します: https://<GITLAB_DOMAIN>/users/sign_in?organization=gitlab-inc。
SAML: https://<GITLAB_DOMAIN>/users/auth/saml/callback が ?organization=gitlab-inc を受け取り、正しい Cell にルーティングされます。
これには、高可用性のソリューションで利用可能にした Organization のリストを使う動的ルーティング方式が必要です。

Cells はどのようにリバランスされますか？

未定

追加の Cell 上の Organization にユーザーをどのようにオンボーディングしますか？

[!note] この回答は以前の Cells 1.0 のイテレーションから引き継いだもので、現在の Protocells の設計に照らした検証は行われていません。確定的な回答として扱うには、Product からの意見が必要です。

Admin が以下のタスクを実行します。

追加の Cell 上に Organization を作成します。
Organization に Owner ロールを持つ新しいユーザーを作成します。
Organization から Admin を削除します。機能セットによっては省略可能です。
新しい Owner がこのグループのデータをインポートします。これにより、ユーザーが作成され、グループ/プロジェクトと Organization に追加されます。

Cells はディザスタリカバリー機能をどのように実装できますか？

未定

機能を Cells と互換性のあるものにするにはどう適応すればよいですか？

チェックリストの草案を参照してください。

より包括的なガイドは、このマージリクエストでも公開されています。

ご質問は #f_protocells か、Protocells Office Hours セッションにご連絡ください。

機能を Cell 内に限定すべきか、クラスタ全体にすべきかをどう判断しますか？

デフォルトでは、機能は Organization レベルにスコープされる必要があります。このルールから逸脱する場合は、Tenant Scale による検証と承認が必要です。

Cells アーキテクチャの設計目標では、すべての Cells は単一のドメイン下にあるため、Cells はユーザーから不可視である必要があります:

Cell 内に限定した機能は、Cell の管理に関係するものに限定されるべきであり、Cell のセマンティクスを顧客に公開するような機能であってはなりません。
Cells アーキテクチャは、データのマイグレーション時にユーザーに影響を与えずに、Cell 間で Organization と顧客データの分散を自由に制御したいと考えています。

クラスタ全体の機能は強く推奨されません。理由は次のとおりです:

大量のデータをクラスタ全体に保存する必要が出てくる可能性があり、スケーラビリティの余力を減らしてしまいます。
自明でないデータ集約の実装が必要になる可能性があり、単一ノードの障害に対するレジリエンスが低下します。
混在デプロイメントで動作させる必要があるため、構築がより難しくなります。クラスタ全体の機能はこのことを考慮する必要があります。
GitLab.com 上でのオンプレミスのような体験を提供する能力に影響する可能性があります。
クラスタ全体で提供すべきだと考えられている機能の一部は、信頼されたクラスタ内通信を同じユーザー ID で使った集約技術によって、より良く実装できる可能性があります。たとえば、ユーザーのプロフィールはクラスタ全体で共有されています。
Cells アーキテクチャは、何がクラスタ全体のサービスとみなせるかを制限しています。最初はクラスタ全体で提供するサービスでも、完全なサービス分離を達成するため、将来的には分割されることが想定されています。どの機能も、そのようなサービス（例: Elasticsearch）に依存して構築されるべきではありません。

Cells は最大 1000 RPS または 50,000 ユーザー向けのリファレンスアーキテクチャを使用しますか？

最大 1000 RPS または 50,000 ユーザー向けのリファレンスアーキテクチャを参照してください。

インフラチームは、負荷に応じて Cells を適切にサイジングします。 Tenant Scale チームは、Cells のデプロイメントの基盤として GitLab Dedicated を使用する機会を見出しています。

意思決定ログ

リンク

最終更新 September 12, 2026: Merge pull request #526 from kyama0/translation/batch-2026-09-12-1 (a1f3c26a)

ページのソースコードを見る - ページの編集 - please contribute.