• 目標
  • スケーラビリティ
  • 可用性の向上
  • 一貫したエクスペリエンス
  • 地域
  • マーケットセグメント
  • セルフマネジメント
• 要件
  • クラスター全体のデータ集約
  • 全てのセルはGitLab.comの単一ドメイン下にあります。
  • ユーザーは多くのセルと対話可能
  • 貢献者のワークフローへの最小限の影響
  • オンプレミスのような体験
  • 変更の最小化
  • リージョンサポート
  • セルフマネージドカスタマー（Omnibus/CNG）への影響を制限します。
  • 10倍のヘッドルーム
  • 100倍のヘッドルーム
  • サービス可用性の向上
  • ユーザーあたりのコストはGitLab.comと同等かそれ以下
  • 統一されたデプロイ方法
  • 混在デプロイで稼働するセル
  • 単一セルの障害に対する高い耐障害性
  • スモールセル
  • ロバストなロールバック・シナリオとディザスタリカバリ・シナリオ
  • 既存のGitLab.comデータベースのスケール
  • 細胞のリバランス
  • 顧客はGitLab.comからDedicatedにマイグレーションすることができます。
  • 開発環境での使いやすさ
• 非ゴール
  • 異なるGitLabインスタンス間のフェデレーション
  • クラウドマネージドサービスの利用
  • セルはカナリア・デプロイを置き換えるべき
• 用語解説
  • セル
  • クラスター
  • 組織
  • トップレベルグループ
  • ユーザー

細胞目標

目標

スケーラビリティ

この新しい共有インフラアーキテクチャの主な目的は、私たちのSaaSプラットフォームにさらなるスケーラビリティを提供することです。GitLab.comは大部分がモノリシックであり、現在のアーキテクチャにはスケーラビリティの限界があると（内部で）見積もっています。特にPostgreSQLデータベースと Redisは、データベースのパーティショニングと分解を考慮したとしても、水平方向にスケーラブルでないリソースです。

セルは需要に応じて追加セルを作成できるため、水平方向にスケーラブルなソリューションを提供します。最適なスケーラビリティを実現するために、必要に応じてセルをプロビジョニングし、調整することができます。

可用性の向上

共有インフラストラクチャ・アーキテクチャの大きな課題は、トップレベル・グループ間の分離の欠如です。これはノイジー・ネイバー効果につながります。トップレベル・グループ内の組織の行動が他のすべての組織に影響を与える可能性があります。これは非常に望ましくないことです。セルはセル・レベルでの分離を提供します。組織のグループは、別のセルにある他の組織から完全に隔離されます。これにより、共有インフラストラクチャのコスト効率の恩恵を受けながら、ノイジーネイバー効果を最小限に抑えることができます。

さらに、セルはディザスタリカバリ機能を実装する方法を提供します。自動フェイルオーバー機能により、セル全体を読み取り専用のスタンバイにレプリケートできます。

一貫したエクスペリエンス

GitLabのSaaSプラットフォームでも、セルフマネジメントのGitLabインスタンスと同じユーザーエクスペリエンスが得られるはずです。

地域

GitLab.comはアメリカ合衆国内でのみホスティングされています。他の地域にある組織からは、ローカルなSaaSを提供したいという声が上がっています。Cellは異なる地域にデプロイすることができるため、CellはGitLabリージョンへの道を提供します。組織のどのデータがCellの外側にあるかによって、これはデータレジデンシーとコンプライアンスの問題を解決するかもしれません。

マーケットセグメント

現時点では、GitLab.comには「ソーシャルネットワーク」的な機能があり、孤立した組織モデルにはうまく適合しないかもしれません。しかし、そのような機能を取り除くには、いくつかの課題があります：

1. 既存のgitlab-org 貢献者はどのように名前空間に貢献するのでしょうか？
2. 既存のトップレベルグループをどのように新しいモデルに移行させるか（事実上、そのソーシャル機能を壊す）？

中小企業や中堅市場層がこれらの機能に興味があるのか、あるいはほとんどの場合、これらの機能を持たないことが許容されるのかを評価する必要があります。

セルフマネジメント

一貫性を保つため、セルフマネージド・インスタンスもセル・アーキテクチャを採用することが予想されます。拡張するために、セルフマネージド・インスタンスはセルを追加するオプションをサポートしながら、単一のセルだけで継続することができます。セルフマネージド・インスタンスでは、組織、そして可能であればユーザーの分解も採用されるでしょう。

要件

クラスター全体のデータ集約

アーキテクチャは、クラスターのセルを単一のビューで表示する方法を提供する必要があります。これは

• 異なる組織からのユーザーToDoの集約
• 公開プロジェクトや公開ソースコードをクラスター全体で検索

全てのセルはGitLab.comの単一ドメイン下にあります。

一般ユーザーはCellsの存在に気づかないはずです。Cellはインスタンス管理者だけが見ることができます。別のCellでOrganizationsを使用しているユーザーや、Cell間でOrganizationsをマイグレーションしているユーザーは、ユーザーの介入を必要としないか、ユーザーには見えないような運用上の詳細であるべきです。

ユーザーは多くのセルと対話可能

異なるセルに存在する可能性のある異なる組織と対話するために多くのアカウントを使用することは強く推奨されません。多くのアカウントを使用する必要性は採用を減らし、オープンソースプロジェクトに貢献したいユーザーの障壁となります。

将来的には、特定の顧客の期待に応じて、ユーザーは組織固有の設定を持つことができます。インスタンスンスでは、ユーザーは異なる組織で異なる表示名で表示されるかもしれません。

ユーザーが多くのSSHキーを管理するのは複雑なので、異なる組織にアクセスするために異なるSSHキーを使用する必要はありません。

貢献者のワークフローへの最小限の影響

GitLab.comには、多くのオープンソースやオープンコアのプロジェクトがあります（gitlab-org/gitlabを含む）。Cellsによって公開プロジェクトに貢献することが難しくなるようなことがあってはなりません。貢献するための新しい方法を学ぶことは、Cells の採用を妨げる可能性があります。導入されるアーキテクチャは、最小限の方法で既存のワークフローを変更することに焦点を当てるべきです。

オンプレミスのような体験

現在、オンプレミスにはSaaSと比較して多くの利点があります。オンプレミスでは、ユーザー管理、アクセスコントロール、インスタンス全体の設定など、GitLabインストールのあらゆる側面をコントロールすることができます。

SaaSとオンプレミスの違いは、ユーザーエクスペリエンスの違いにつながるため、お客様にとっても私たちにとっても問題です。

変更の最小化

Cellsの導入は、サポートされているGitLab.comのワークフローに変化をもたらします。Cellは、説得力のあるユーザー体験ストーリーを提供する限り、GitLabの使い方に影響を与えるかもしれません。導入される各変更がオペレーション上の価値かユーザー価値のどちらか、理想的には両方を提供することが望まれます。

どのようなCellsアーキテクチャも、壊れるような変更を導入しないこと、導入する場合はその変更をサポートするための長いウィンドウを提供することに重点を置くべきです。破壊的な変更の導入は、Cellsの採用率と有効性を低下させ、アーキテクチャのロールアウトをよりリスキーなものにします。

ブレークチェンジの重大性を区別することは重要です：

• 必須：設計上、新しいアーキテクチャへのマイグレーションは破壊的な変更をもたらします。このような場合、顧客は新しいワークフロー、新しいAPI、または新しいエンドポイントをすぐに使用する必要があり、すべての変更に一度に適応する必要があります。顧客にはロールバックする選択肢が限られています。

• オプション：新しいアーキテクチャへのマイグレーションは、破壊的な変更を導入することを強制しません。このような場合、新しいワークフロー、新しいAPI、新しいエンドポイントなど、導入された変更にゆっくりと適応することができますが、システムの主要な部分は以前と同じように動作します。顧客には、以前の既知の動作状態にロールバックする方法があります。

リージョンサポート

リージョンのサポートによって、異なるアベイラビリティゾーンや完全に異なるデータセンターで GitLab を実行できるようになります。

これには、ユーザーがヨーロッパ、アメリカ西部、アメリカ東部にOrganizationを作成することや、GitLab Inc.が異なるクラウドインフラストラクチャプロバイダー（Google Cloud、AWS）を使用して顧客にサービスを提供することが含まれますが、これらに限定されません。

セルは、GitLab.com上で、GitLabがサポートする異なるデプロイ地域/データセンター間で、Organizationを運営する既存の顧客がOrganizationを移動できるようにします。

セルフマネージドカスタマー（Omnibus/CNG）への影響を制限します。

Cellの導入は、小規模なインストールに影響を与えないようにすべきです。Cellを導入することで、リソース要件が増加するCellに関心がない限り、自主管理顧客が追加コンポーネントを実行する必要はありません。

10倍のヘッドルーム

Cellsアーキテクチャは、少なくとも10倍のヘッドルームを提供しなければなりません。そのため、アーキテクチャは10個のCellsを実行するのに適していなければなりません。10個以上のCellを動作させる際に発生する複雑な問題を最初に解決する必要はありません。

100倍のヘッドルーム

Cellsアーキテクチャは、10以上のCellsを実行できる必要があります。

サービス可用性の向上

Cellsアーキテクチャでは、クラスターの特定のCellsに顧客を配置することで、一部の顧客に対してより良いSLAを提供できるはずです：

• Cellは、急増するワークロードによる正当な利用など、ノイズの多い隣接セルの影響を軽減する必要があります。
• セルは、例えばCIが暗号通貨のマイニングに使用されるなど、不正使用による影響を軽減する必要があります。

ユーザーあたりのコストはGitLab.comと同等かそれ以下

現在のGitLab.comのアーキテクチャは、費用対効果に優れています。Cellsを導入すると、データのディストリビューションによりインフラストラクチャのコンポーネントが増えることになります：

• 提案されているCellsアーキテクチャは、インフラコンポーネントの分離を達成することに関して、追加のCellsを実行するコストを評価する必要があります。場合によっては、インフラコンポーネントを再利用することでCellsのランニングコストを削減できるかもしれません。
• 提案される Cells アーキテクチャは、Cell の高度なマルチテナンシーを保証する必要があります。
• 提案されるCellsアーキテクチャは、Cellsの負荷を長期的にバランスさせる方法を可能にするかもしれません。

統一されたデプロイ方法

提案されているCellsアーキテクチャでは、100以上のCellsをクラスターで運用する必要があると想定しています。これはオペレーション・オーバーヘッドとなります。Cellsアーキテクチャでは、デプロイ、モニタリング、ロギング、ディザスタリカバリ、カスタマーサポートなど、既存のインフラストラクチャツールを可能な限り再利用することが強く望まれています。

混在デプロイで稼働するセル

Cellsアーキテクチャでは、クラスター全体で異なるバージョンのアプリケーションを実行することが強く求められています。その目的は、クラスターの一部で変更をテストしたり、クラスターの一部をそれほど頻繁に更新したりできるように、ステージングされたデプロイを提供することです。

これはまた、Cellsが基盤となるインフラストラクチャコンポーネントの異なるバージョンで動作できる必要があることを示しています：PostgreSQLバージョン、Redisバージョン、Gitalyバージョン、Elasticsearchバージョン。

Cell内で異なるバージョンを使用しても、他のCellに影響を与えない必要があります。

単一セルの障害に対する高い耐障害性

単一セルが使用不能になっても、他のセルが正常に機能しないようなことがあってはなりません：

• セル間のクラスター内通信は、単一セルの障害に強いこと。
• クラスター内通信は、他のセルに保存されたデータへの依存を制限する必要があります。
• クラスター共有データは、単一のセルがクラスター全体の機能停止を引き起こすことを防ぐアンチコラプションレイヤーを提供する必要があります。
• セルは監視されるべきであり、その可用性ステータスは他のすべてのセルからアクセス可能であるべきです。
• クラスター全体のデータ集計は、各セルの可用性ステータスを考慮する必要があります。
• セルローカルのデータ（グループやプロジェクト）の損失は、そのセルにあるデータへのアクセス能力にのみ影響します。

スモールセル

Cellsアーキテクチャは、スモールセルを実行するためのコスト効率の良い方法を提供する必要があります。スモールセルを実行することで、データセットが大幅に小さくなり、シングルノードの垂直スケーリングが可能になるため、レイテンシやパフォーマンスの面で優れた品質を達成することができます。

スモールセルを実行する能力は、個々のセルデプロイの複雑さを軽減します：

• 容量を増やす最初の手法として、シングルノードの垂直スケーリングを推奨（CPU数、使用可能メモリを増やす）。
• 停電時の復旧時間を短縮するため、Cell内に保存するデータ量を削減。
• データ量を減らすことで、データベースのマイグレーションが高速化され、レイテンシが改善され、ユーザー向けのパフォーマンスが向上します。

ロバストなロールバック・シナリオとディザスタリカバリ・シナリオ

Cellsアーキテクチャのロールアウトは、GitLab.comのオペレーション方法を根本的に変えるものです。これには多くの新しいコンポーネントを導入し、異なるCellsにデータを水平にディストリビューションすることが含まれます。

私たちは、ある時点で何かがうまくいかなくなることを想定しています。Cellsアーキテクチャの各デプロイフェーズでは、以前の動作状態にロールバックする方法を提供する必要があります。これにはユーザー向けの変更だけでなく、インフラストラクチャにデプロイされたコンポーネントも含まれます。

既存のGitLab.comデータベースのスケール

Cellsをデプロイしている間、既存のGitLab.comデータベースは成長し続けるでしょう。Cellsアーキテクチャは、Cell 1（既存のGitLab.com）の容量をできるだけ早く増やす方法を提供するはずです。

細胞のリバランス

セル上のディストリビューションは、ある時点で不均一になることが予想されます。

セルの再バランスの問題はかなり複雑ですが、ある程度の規模になれば、不均衡なセルのランニングコストに比べてプラスのROIが得られるかもしれません。

そのためには、セル間の顧客データを既存のセルに選択的にマイグレーションする方法を理解する必要があるかもしれません。

顧客はGitLab.comからDedicatedにマイグレーションすることができます。

Cellsはより分離されたアーキテクチャを強制します。しかし、SaaSのGitLab.comからGitLab Dedicatedに移行したいお客様もいらっしゃると思われます。

これは、GitLab.comクラスターからDedicatedへ選択的にデータをマイグレーションできることを意味します。これを実現するには

• GitLab.comクラスターのDedicatedセルに顧客をマイグレーション。
• GitLab.comクラスターからCellを切り離して、独立したDedicated Cellにすること。

開発環境での使いやすさ

Cellsアーキテクチャは、開発者が必要に応じてローカルで実行しやすいものでなければなりません：

• クラスター全体の機能の実装。
• モデルセルが使用できません。

非ゴール

以下の目標はこの文書の一部ではありません。ある時点では検討されましたが、上記の目標や要件から逸脱するものとして却下されました。

異なるGitLabインスタンス間のフェデレーション

Cellsアーキテクチャは、共有されるデータのセットを使って信頼できるクラスター内通信を提供することを意図しています。フェデレーションは、完全に異なる2つの外部インスタンス間のデータフローの問題を解決するためのものです。

クラウドマネージドサービスの利用

セルは、クラウドでより多くのマネージドサービスを利用しようとする他の取り組みを妨げるべきではありません。

セルはカナリア・デプロイを置き換えるべき

Cellsを導入すれば、一度に1つのCellsに変更をロールアウトできるため、カナリア・デプロイを実行する必要がなくなります。現在のカナリア・デプロイの主な利点は、コードの変更をまず内部ユーザーにロールアウトできることです。Cellsを使えば、特定のCellsに内部ユーザーを配置し、最初にデプロイすることができます。

さらにCellは、例えばSidekiqコードを一部のユーザー向けにアップグレードする方法がないなど、現在のカナリアでのいくつかの問題を解決するかもしれません。

用語解説

セル

PodはCellに改名されました。https://gitlab.com/gitlab-com/www-gitlab-com/-/merge_requests/121163

セルは、異なる組織に属する複数のトップレベルグループを含むインフラコンポーネントのセットです。コンポーネントには、データストア（PostgreSQL、Redisなど）とステートレスサービス（Webなど）の両方が含まれます。セル内で提供されるインフラストラクチャ・コンポーネントは、組織とそのトップレベル・グループ間で共有されますが、他のセルと共有されることはありません。このようにインフラストラクチャ・コンポーネントが分離されているため、セルは互いに独立しています。

• 各セルは他のセルから独立しています
• インフラコンポーネントは、セル内の組織とその最上位グループによって共有されます。
• 水平方向のスケーラビリティを提供するため、より多くのセルをプロビジョニング可能
• セルに障害が発生しても、他のセルの障害につながることはありません。
• ノイジー・ネイバー効果はセル内に限定
• CellはOrganizationsからは見えません。
• セルは地理的に異なる地域にある可能性あり（例：EU、米国、日本、英国）
• GitLab Dedicatedインスタンスがクラスターに参加し、セルになることができます。

却下された類義語GitLabインスタンス, クラスター, シャード, ポッド

クラスター

クラスターはCellの集まりです。

• クラスターはクラスター全体のメタデータを保持します：ユーザー、ルート、設定。

推奨されない同義語Whale、GitLab専用インスタンス、インスタンス

組織

組織は、1 つまたは複数のトップレベルグループの傘です。組織はデフォルトで互いに分離されています。つまり、ネームスペースの横断機能は、単一の組織に存在するネームスペースに対してのみ機能します。

組織のブループリントを参照してください。

組織は既知の概念で、例えばAWSや GCPに存在します。

組織は次のような前提の下で機能します：

1. ユーザーは、組織内で何が起きているかに関心があります。
2. 機能は組織内で機能する必要があります。
3. 組織間で連携する必要がある機能はごくわずかです。
4. ユーザーは、閲覧するページの大部分が一度に単一の組織にのみスコープされることを理解しています。
5. 組織は1つのセルにあります。

プロパティ：

• トップレベルグループは組織に属します。
• 組織は、デフォルトで互いに分離されています。つまり、グループ間の機能は、単一の組織内に存在するグループに対してのみ機能します。
• 個人のネームスペースは、組織に所属してはなりません。

推奨されない同義語： 請求可能なエンティティ、顧客

トップレベルグループ

使用例：

https://gitlab.com/gitlab-org/gitlab/:

• gitlab-org は、top-level group; 組織のすべてのグループとプロジェクトのルートです。
• gitlab はproject;組織のプロジェクトです。

トップレベルのグループは、事実上の組織のエンティティとして機能してきました。Organizationsの創設により、トップレベルのグループはOrganizationsの下にネストされることになります。

時間の経過とともに、トップレベルグループとグループの区別はなくなります。トップレベルグループがグループと異なるすべての機能は、組織に移動します。

• 同じ組織に属するトップレベルグループは同じセルに配置されます。
• トップレベルグループは、同じ組織に属する他のトップレベルグループと相互作用することができます。

推奨されない同義語ルートレベル名前空間

ユーザー

ユーザーは、単一のセルに限定されることなく、グローバルに利用できます。ユーザーは1つの組織に所属しますが、様々な権限を持つグループやプロジェクトメンバーシップを通じて、多くの組織に参加することができます。組織内では、ユーザーは複数のトップレベルグループを作成できます。ユーザーのアクティビティは 1 つの組織に限定されませんが、貢献者（ToDo など）は組織内でのみ集約されます。これにより、セル間で集計する必要がなくなります。

• ユーザーはすべてのセルでグローバルに共有されます。
• ユーザーは複数のトップレベルグループを作成できます。
• ユーザーは複数のトップレベルグループのメンバーになることができます。
• ユーザーは1つの組織に所属します。395736を参照してください。
• ユーザーは、異なる組織のグループやプロジェクトのメンバーになることができます。
• ユーザーは組織を管理できます。
• ユーザーのアクティビティは組織に集約されます。
• すべてのユーザーは1つの個人ネームスペースを持ちます。