Content last updated 2026-10-12

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.
StatusAuthorsCoachDRIsOwning StageCreated
ongoingayufan fzimmer DylanGriffith lohrc tkuah sxuerebayufan tkuahdaveyleachdevops tenant scale2022-09-07

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

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

ゴール

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

Protocells

Protocells は Cells アーキテクチャの現在のイテレーションです。以前の Cells 1.0、 Cells 1.5、Cells 2.0 のイテレーションに代わり、レガシー Cell のデータベースの負荷を恒久的に軽減することに 新たな重点を置いています。

概要

Protocells は、水平スケーラビリティを提供することでレガシー Cellのデータベースの負荷を軽減します。

Organizations は論理的な境界として、Cells は物理的な境界として機能します。

この設計は、Organizations、Organization の移行、Cells インフラストラクチャという 3 つの主要コンポーネントを統合します。

進捗は作業用エピックで追跡します。

提案

flowchart TD
    subgraph P1["1 · Organizations"]
        A["Top-level group\n+ child resources"] -->|"transferred to"| B["Organization"]
        B --> C["Missing references\nrender gracefully\non source & target cell"]
    end

    subgraph P2["2 · Organization Migration"]
        D["Organization"] -->|"all data, no loss"| E["New Cell"]
        E -->|"canonical cell updated"| F["Topology Service"]
    end

    subgraph P3["3 · Cells Infrastructure"]
        G["Incoming Request"] -->|"routed by org"| H["Routing Logic"]
        H -->|"lookup"| F
        F -->|"cell location"| H
        H -->|"proxy"| E
    end

    B -.->|"migrate"| D
    A ~~~ G

Protocells は 3 本の柱で構成されています:

柱目的結果
1. OrganizationsOrganization の分離により、Organizations を論理的な境界として導入します。トップレベルグループと、その子リソース（グループ、プロジェクト、ユーザーなど）を、専用の Organization に移管します。
2. Organization の移行Organization のデータ移行の設計ドキュメントに基づいて、Cells 間で Organizations を移動できるようにします。Organization のすべてのデータを、損失なく別の Cell に移動します。Topology Service でその Organization の正規の Cell を更新して切り替えます。
3. Cells インフラストラクチャCells インフラストラクチャの設計ドキュメントに基づいて、自己完結した複数の GitLab インスタンスを GitLab.com 上に Cells としてデプロイします。ルーティングロジックが Organization に基づいて適切な Cell にリクエストを振り分けます。

各柱の詳細:

柱詳細
1. Organizationsすべてのリクエストに対して Organization コンテキストの解決を確立し、データや操作が Organization の境界を越えることを防ぎます。Self-Managed と Dedicated では、Organization の ADRに基づいて、インスタンスと Organization の 1 対 1 の対応を確立します。Organization を別の Cell に移動した際、参照先が欠けていても移動元と移動先の両方の Cell でページが引き続き表示されます。たとえば、作成者（ユーザー）が Organization と一緒に移動されなかった Issue や、移動したユーザーが別の Organization の Issue に残したコメントが該当します。
2. Organization の移行このツールは、レガシー Cell から新しい Cells への Organizations の移行をサポートします。水平スケーラビリティと、インフラストラクチャ全体での負荷分散を可能にします。
3. Cells インフラストラクチャ各 Cell は複数の Organizations をホストできます。Cells は、独自のデータベースとインフラストラクチャを持つ独立した GitLab インスタンスとして動作します。

この取り組みは、データ保持など、レガシー Cell のデータベースを支える他の補完的な取り組みを妨げるものではありません。

設計と実装の詳細

論理的な境界と物理的な境界

このアーキテクチャでは、2 種類の境界を区別します:

論理的な境界（Organization）: データのシャーディング境界（例: PostgreSQL、Gitaly）とアクセス制御を定義します。

Organizations は、GitLab のすべての機能とデータを分離する単位です。

物理的な境界（Cell）: インフラストラクチャの分散を定義します。

Cells は、複数の Organizations をホストできる自己完結した GitLab インスタンスです。

この分離により、次のことが可能になります:

  • 論理構造を変更せずに Organizations を Cells 間で移動します。
  • 複数の Organizations が単一の Cell 上のインフラストラクチャを共有します。
  • Organizations をまたぐ操作で公開 API を使用します。

Organization にスコープを限定した操作

ほとんどの操作は、スコープを 1 つの Organization に限定すべきです。

これにより、機能が論理的な境界の内側で動作し、分離を維持します。

Organizations をまたぐ操作

複数の Organizations をまたぐすべての操作は、公開 API を使用しなければなりません。

これにより、次のことを確保します:

  • 適切な認証と認可の境界。
  • デプロイモデル間で一貫した動作。
  • Organizations 間での明確な関心の分離。

Organizations をまたぐ操作の例:

  • ユーザー認証とセッション管理。
  • 共有リソースへの公開 API アクセス。
  • GitLab.com の管理操作。

デプロイモデル

GitLab.com
  • 複数の Cells があり、それぞれが複数の Organizations をホストします。
  • Organizations が分離の単位になります。
  • Cells が物理的な分散の単位になります。
  • デフォルトの Organization が既存ユーザー向けの後方互換性を提供します。
Self-Managed と Dedicated
  • Organization ごとに単一のインスタンスを使用します（1 対 1 の対応）。
  • Organizations が論理的な境界を提供します。
  • インスタンスが物理的な境界を提供します。
  • GitLab.com と比べて運用モデルが簡素になります。

機能の同等性

お客様が既存の機能を引き続き利用できるようにするため、機能の同等性が必要です。 これらの取り組みでは、次の点に重点を置きます:

アーキテクチャ概要

これは Cells アーキテクチャの概念図です。インフラストラクチャの詳細図（GCP プロジェクト、VPC、Cell ごとのリソース）については、Cells: インフラストラクチャのアーキテクチャを参照してください。

@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
        }

        Cell_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 --> TS
Cell_Puma --> TS
Cell_Sidekiq --> TS

@enduml

将来のスコープ

Cells 2.0 の目標は、Cell ベースのアーキテクチャで パブリックおよびオープンソースのコントリビューションモデルをサポートすることでした。 Protocells では、当面の焦点をレガシー Cell のデータベースの負荷軽減に絞ったため、 元のスコープに含まれていた次の側面は未解決のままです。 現在の Protocells のロールアウトの一部ではなく、将来のスコープとして追跡します:

  1. Organizations 間の相互運用（「Org Connect」）: Organization の境界を越えて公開プロジェクトに貢献するには、 まだ存在しない相互運用機能が必要です。 Organizations ADR 015では、この概念を 「Org Connect」と名付け、実現までにはまだ「長い道のりがある」としています。
  2. ユーザーの Organizations が複数の Cells にまたがること: ユーザーはすでに多数の Organizations に所属できますが、異なる Cells 上にある Organizations をシームレスに利用するには、 まだデプロイされていない New Auth Stack（GATE）が必要です。 これは未解決の設計上の疑問ではなく、実施順序に関する依存関係です。
  3. 公開 Organizations の Cells 間での移行: Organization を Cells 間で移行することは Protocells のスコープに含まれます（Cells: データ移行を参照）が、 現時点で現実的な候補となるのは非公開の Organizations だけです。 公開 Organizations は、内部 API を介して「行き来」し、 同一クラスタ内で到達可能であると想定する機能に依存しています。たとえば、Gitaly の リポジトリ間操作によるフォークなどです。 公開 Organization を別の Cell に移行すると、その前提が崩れるため、公開 Organization を 移行できるようにするには、この部分を別途作り直す必要があります。

技術的な提案

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 に対して検証されます。

デプロイメントプロセス

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

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

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

ここで説明しているのは、新しい Cell のプロビジョニングです。その後、既存の Cells にコード変更をロールアウトする方法については、Cell ベースのアーキテクチャでのアプリケーションのデプロイメントを参照してください。

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

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

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

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

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

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

未定

mycorp.gitlab.com のようなサブドメインを使用しないのはなぜですか？

すべての Cells は単一の GitLab.com ドメイン下にありますを参照してください。 その目標に加えて、サブドメインには具体的な問題がいくつかあります:

  • サブドメイン間で Cookie が漏れることによるセキュリティ上の問題を防ぐため、注意が必要です。
  • Organization によって URL とホストが変わるため、インテグレーションと API のやり取りが複雑になります。
  • ユーザーを有効な Organization/URL にリダイレクトする共通のログインサービスを構築する必要があります。
  • 名前の衝突が発生するリスクが高まり、その影響も大きくなります。たとえば、大企業内の異なる部門や 組織、似た名前の企業などが該当します。

ユーザーは 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 が以下のタスクを実行します。

  1. 追加の Cell 上に Organization を作成します。
  2. Organization に Owner ロールを持つ新しいユーザーを作成します。
  3. Organization から Admin を削除します。機能セットによっては省略可能です。
  4. 新しい 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 を使用する機会を見出しています。

意思決定ログ

最終更新 October 28, 2026: Merge pull request #591 from kyama0/translation/batch-2026-10-28-1 (5d840611)
ページのソースコードを見る - ページの編集 - please contribute. Creative Commons License