Cells

このページには今後予定されている製品・機能・機能性に関する情報が含まれています。ここに示す情報は参考目的のみです。購入・計画の決定にこの情報を使用しないでください。製品・機能・機能性の開発、リリース、タイミングは変更または延期される可能性があり、GitLab Inc. の独自の判断に委ねられています。
StatusAuthorsCoachDRIsOwning StageCreated
ongoing@ayufan, @fzimmer, @DylanGriffith, @lohrc, @tkuah@ayufan, @sxuereb@daveyleach~devops::tenant scale2022-09-07

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

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

ゴール

Goals, Glossary and Requirements を参照してください。

Cells のイテレーション

  • （保留中）Cells 1.0 のターゲットは、SaaS GitLab.com オファリングを利用する社内のお客様向けのソリューションを提供し、Cells の基礎的な作業を行うことです。
  • （保留中）Cells 1.5 のターゲットは、Cells 1.0 アーキテクチャの上に構築された、SaaS GitLab.com オファリングを利用する既存および新規のエンタープライズ顧客向けのマイグレーションソリューションを提供することです。
  • （保留中）Cells 2.0 のターゲットは、cellular アーキテクチャにおけるパブリックおよびオープンソースのコントリビューションモデルをサポートすることです。
  • 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 は、お客様ごとに専用のサーバーリソースで provision されるという理由から、依然として高いコストで提供されています。一方、Cells は共有リソースを使用します。 このため、GitLab Dedicated は大規模顧客により適しており、GitLab Cells は GitLab.com で利用を始める中小規模の企業により適しています。

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

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

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

Cells はどのように provision されますか？

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

cells-deployment

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

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

デプロイメントプロセス

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

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

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

[!note] これは高レベルの概要です。より詳細については、Dedicated Architecture Documentation を参照してください。

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

design discussion も参照してください。

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

design discussion を参照してください。

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

TBD

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

design discussion を参照してください。

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

TBD

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

TBD

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

draft checklist を参照してください。

より包括的なガイドは、この merge request でも公開されています。

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

機能を cell-local にすべきか、cluster-wide にすべきかをどう判断しますか？

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

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

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

Cluster-wide な機能は強く推奨されません。理由は次のとおりです:

  • 大量のデータを cluster-wide に保存する必要が出てくる可能性があり、scalability headroom を減らしてしまいます。
  • 自明でない data aggregation の実装が必要になる可能性があり、single node failure に対するレジリエンスが低下します。
  • mixed deployments で動作させる必要があるため、構築がより難しくなります。Cluster-wide な機能はこのことを考慮する必要があります。
  • GitLab.com 上での on-premise ライクな体験 を提供する能力に影響する可能性があります。
  • cluster-wide だと考えられている機能の一部は、信頼された intra-cluster 通信を同じユーザー ID で使った aggregation 技術によって、より良く実装できる可能性があります。 たとえば、ユーザーの Profile はクラスタ全体で共有されています。
  • Cells アーキテクチャは、何が cluster-wide なサービスとみなせるかを制限しています。 最初は cluster-wide であるサービスでも、完全なサービス分離を達成するため、将来的には分割されることが想定されています。 どの機能も、そのようなサービス（例: Elasticsearch）に依存して構築されるべきではありません。

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

reference architecture for up to 1000 RPS or 50,000 users を参照してください。

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

意思決定ログ

リンク

最終更新 May 6, 2026: Merge pull request #100 from kyama0/fix/upload-images-tolerate-upstream-missing (70970e1a)
ページのソースコードを見る - ページの編集 - please contribute. Creative Commons License