Cells: ゴール

ゴール

スケーラビリティ

この新しい共有インフラストラクチャアーキテクチャの主な目標は、SaaS プラットフォームに追加のスケーラビリティを提供することです。 GitLab.com は大部分がモノリシックであり、（社内での）推定によると、現在のアーキテクチャには PostgreSQL データベース や Redis のような水平スケールが難しいリソースに対して、 データベースのパーティショニングや分解を考慮しても、スケーラビリティの限界があると見込まれています。

Cells は需要に応じて追加の Cell を作成できるため、水平スケーラブルなソリューションを提供します。Cells は最適なスケーラビリティのために必要に応じてプロビジョニングおよびチューニングできます。

可用性の向上

共有インフラストラクチャアーキテクチャにとっての主要な課題は、トップレベルグループ間の分離の欠如です。 これはノイジーネイバー効果を引き起こす可能性があります。 あるトップレベルグループ内の組織の動作が他のすべての組織に影響を与える可能性があります。 これは非常に好ましくありません。 Cells は Cell レベルでの分離を提供します。 特定のグループの Organizations は、異なる Cell に存在する他の Organizations から完全に分離されます。 これにより、共有インフラストラクチャのコスト効率の恩恵を受けながら、ノイジーネイバー効果が最小化されます。

さらに、Cells はディザスターリカバリー機能を実装するための手段を提供します。 Cell 全体を読み取り専用のスタンバイにレプリケーションし、自動フェイルオーバー機能を備えることができます。

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

Organizations は、セルフマネージド GitLab インスタンスと同じユーザーエクスペリエンスを SaaS プラットフォームで体験できるべきです。

リージョン

GitLab.com はアメリカ合衆国内でのみホストされています。 他のリージョンに所在する Organizations は、ローカルの SaaS オファリングの需要を表明しています。 Cells は GitLab Regions への道を提供します。なぜなら Cells は異なる地域にデプロイできるためです。 組織のどのデータが Cell の外部に存在するかによっては、データ居住と コンプライアンスの問題が解決されるかもしれません。

マーケットセグメント

現時点では、GitLab.com は、より孤立した Organization モデルにうまく合わない「ソーシャルネットワーク」のような機能を持っています。 ただし、これらの機能を削除すると、いくつかの課題が生じます:

1. 既存の gitlab-org の貢献者はどのように名前空間に貢献しますか?
2. 既存のトップレベルグループを新しいモデルに移行する方法は（事実上ソーシャル機能を削除することになりますが）?

中小企業および中堅市場セグメントがこれらの機能に関心があるかどうか、またはほとんどのケースでそれらがなくても問題ないかどうかを評価する必要があります。

セルフマネージド

一貫性の観点から、セルフマネージドインスタンスも シングル Cell アーキテクチャを採用することが期待されています。セルフマネージドインスタンスは ルーティングやトポロジーのような追加の Cell サービスを必要とせず、シングル Cell を維持し続けることができます。Organizations と、場合によってはユーザーの分解もセルフマネージドインスタンスに採用されます。

要件

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

アーキテクチャは Cell のクラスターを単一ビューで表示する方法を提供する必要があります。 これは以下を意味する場合があります:

• 異なる Organizations からのユーザーの To-Do を集計する
• 公開プロジェクトや公開ソースコードのクラスター全体の検索を実行する

すべての Cells が単一の GitLab.com ドメイン配下にある

一般ユーザーは Cells の存在を認識すべきではありません。 Cells はインスタンス管理者にのみ見えるべきです。 ユーザーが他の Cell 上の Organizations を使用したり、私たちが Organizations を Cell 間で移行したりすることは、 ユーザーの介入を必要としない、あるいはユーザーに見えない運用上の詳細であるべきです。

サブドメイン（例: mycorp.gitlab.com や mygitlab.mycorp.com）はルーティングに使用されません。 なぜなら、ユーザーが何個の Organizations と対話するかに関わらず、GitLab.com は単一のアプリケーションのように感じられるべきだからです。 Organization または Cell ごとのサブドメインは、インスタンス間の強い分離の印象を与え、 Organizations 間でユーザーとデータを共有するという長期的な目標と相反します。 サブドメインの使用は顧客に対して破壊的変更（リンク、レジストリなど）をもたらします。

ユーザーが多数の Cells と対話できる

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

将来的には、ユーザーは特定の顧客の期待に応じて、Organization 固有の設定を持てるようになる可能性があります。 例えば、ユーザーは異なる Organizations で異なる表示名で表示されるかもしれません。

ユーザーは多数の SSH キーを管理する複雑さから、異なる Organizations にアクセスするために 異なる SSH キーを使用することを要求されるべきではありません。

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

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

オンプレミスのようなエクスペリエンス

現在、オンプレミスは SaaS オファリングと比較して多くの利点を持っています。 オンプレミスでは、ユーザー管理、アクセスコントロール、またはインスタンス全体の設定を含むすべての側面を制御できます。

SaaS とオンプレミスの差異は顧客にとって問題であり、 異なるユーザーエクスペリエンスをもたらします。

破壊的変更を最小限に抑える

Cells の導入は、サポートされる GitLab.com ワークフローの変更を意味します。 Cells は説得力のあるユーザーエクスペリエンスを提供する限り、GitLab の使い方に影響を与えるかもしれません。 導入された各変更が運用価値またはユーザー価値、理想的には両方を提供することが望まれます。

あらゆる Cells アーキテクチャは、破壊的変更を導入しないこと、 または導入する場合は変更をサポートするための長い期間を設けることに集中すべきです。 破壊的変更の導入は Cells の採用率と効果を低下させ、 アーキテクチャのロールアウトをよりリスクの高いものにします。

破壊的変更の異なる重大度を区別することが重要です:

• 必須: 新しいアーキテクチャへの移行が設計上の破壊的変更を伴う場合。 この場合、顧客はすぐに新しいワークフロー、新しい API、または新しいエンドポイントを使用しなければならず、 すべての変更に一度に適応することが求められます。顧客はロールバックのオプションが制限されています。

• オプション: 新しいアーキテクチャへの移行が破壊的変更の導入を強制しない場合。 この場合、顧客は導入された変更（新しいワークフロー、新しい API、または新しいエンドポイント）に徐々に適応できますが、 システムの主要な側面は以前と同様に機能し続けます。 顧客は以前の既知の動作状態にロールバックする方法を持っています。

リージョンのサポートを可能にする

リージョンのサポートにより、異なる可用性ゾーン、 または完全に異なるデータセンターで GitLab を実行できるようにする必要があります。

これには、ユーザーが欧州、米国西部、米国東部などに Organizations を作成できるようにすること、 また GitLab Inc. が異なるクラウドインフラストラクチャプロバイダー（Google Cloud、AWS）を使用して 顧客にサービスを提供できるようにすることが含まれますが、これらに限定されません。

Cells は、Organizations を実行している既存の顧客が、GitLab によって GitLab.com でサポートされる 異なるデプロイリージョン/データセンター間で Organization を移動できるようにします。

セルフマネージド顧客への影響を制限する（Omnibus/CNG）

Cells の導入は小規模なインストールに影響を与えるべきではありません。 Cells はリソース要件が増加する Cells に関心がない限り、セルフマネージド顧客が追加コンポーネントを実行することを要求すべきではありません。

10 倍のヘッドルームを提供する

Cells アーキテクチャは少なくとも 10 倍のヘッドルームを提供する必要があります。そのため、私たちのアーキテクチャは 10 個の Cells を実行するのに適したものでなければなりません。10 個以上の Cells の実行に伴う複雑性を最初から解決する必要はありません。

100 倍のヘッドルームを提供する

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

サービス可用性の向上

Cells アーキテクチャは、クラスターの特定の Cells に配置することで 一部の顧客により良い SLA を提供できるようにする必要があります:

• Cells はスパイクのある正当な使用によって引き起こされるノイジーネイバーの影響を軽減する必要があります。
• Cells は例えば CI が暗号通貨マイニングに使用されるような悪用による影響を軽減する必要があります。

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

現在の GitLab.com アーキテクチャは非常にコスト効率が高いです。 Cells の導入は、データ分散によりより多くのインフラストラクチャコンポーネントをもたらします:

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

Cells の統一されたデプロイ方法

提案される Cells アーキテクチャは、クラスターで 100 個以上の Cells を実行する必要性を見込んでいます。 これは運用上のオーバーヘッドになります。Cells アーキテクチャが デプロイ、監視、ログ、ディザスターリカバリー、および顧客サポートのために 既存のインフラストラクチャツールをできる限り再利用することが強く望まれます。

混在デプロイで動作する Cells

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

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

Cell 内で異なるバージョンを使用しても他の Cells に影響を与えてはなりません。

シングル Cell 障害への高い耐障害性

単一の Cell が利用不能になっても、他の Cells が正常に機能できなくなるべきではありません:

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

小規模 Cells

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

小規模 Cells を実行できることは、個々の Cell デプロイの複雑性の低減をもたらす可能性があります:

• 容量を増やすための最初の手法として、シングルノードの垂直スケーリングを優先する（CPU 数、利用可能メモリを増やす）。
• 停止時のリカバリー時間を短縮するために Cell に保存されるデータの量を削減する。
• データが少ないほど、データベースマイグレーションが速くなり、レイテンシが改善され、ユーザー向けのパフォーマンスが向上します。

堅牢なロールバックおよびディザスターリカバリーシナリオ

Cells アーキテクチャのロールアウトは、GitLab.com の運用方法の根本的な変更です。 これには多数の新コンポーネントの導入と、異なる Cells 間でのデータの水平分散が伴います。

何かが問題になることはいずれ起こると予想されます。Cells アーキテクチャの各デプロイフェーズは、 以前の動作状態にロールバックする方法を提供する必要があります。これには、ユーザー向けの変更と インフラストラクチャにデプロイされたコンポーネントの両方が含まれます。

既存の GitLab.com データベースのスケーリング

既存の GitLab.com データベースは Cells をデプロイしながらも成長し続けます。 Cells アーキテクチャは、できるだけ早く Cell 1（既存の GitLab.com）の 容量を増やす方法を提供する必要があります。

Cells の再バランシング

Cells 上のデータ分散はいずれかの時点で不均一になることが予想されます。

Cells の再バランシング問題はかなり複雑ですが、ある規模では 不均衡な Cells の実行コストと比較してプラスの ROI をもたらす可能性があります。

これは、既存の Cells 間で顧客データを選択的に移行する方法を理解することを 意味するかもしれません。

顧客が GitLab.com から Dedicated に移行できる

Cells はより高い分離を持つアーキテクチャを強制します。しかし、一部の顧客は SaaS GitLab.com から GitLab Dedicated に移行したいと思うことが予想されます。

これは GitLab.com クラスターから Dedicated にデータを選択的に移行できることを意味します。 これは以下の方法で実現できます:

• 顧客を GitLab.com クラスター上の Dedicated Cell に移行する。
• Cell を GitLab.com クラスターから独立したスタンドアロンの Dedicated Cell に切り離す。

開発環境での容易な利用

Cells アーキテクチャは開発者が必要に応じてローカルで実行しやすくする必要があります:

• クラスター全体の機能を実装できる。
• Cells が利用不能な状態をモデル化できる。

非ゴール

以下の目標はこのドキュメントの対象外です。ある時点でこれらが考慮されましたが、 上記のゴールと要件からの気をそらすものとして除外されました。

別個の GitLab インスタンス間のフェデレーション

Cells アーキテクチャは、一部のデータが共有される信頼された クラスター内通信を提供することを目的としています。フェデレーションは、 完全に別個の外部インスタンス間のデータフローの問題を解決することを目的としています。

Dedicated インスタンスの GitLab.com への統合

既存の Dedicated インスタンスが GitLab.com クラスターに参加することは意図されていません。

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

Cells はクラウドでより多くのマネージドサービスを使用する方向への他の取り組みに 干渉すべきではありません。

Cells によるカナリアデプロイの置き換え

Cells を持つことで、変更を一度に単一の Cells にロールアウトできるため、 カナリアデプロイを実行する必要がなくなります。 今日のカナリアデプロイの主な利点は、内部ユーザーに先にコード変更をロールアウトできることです。 Cells では、内部ユーザーが特定の Cell に存在し、その Cell を最初にデプロイできます。

さらに Cells は今日のカナリアにおける一部の問題を解決するかもしれません。 例えば、ユーザーのサブセットに対して Sidekiq コードをアップグレードする方法がないといった問題です。

用語集

Cell

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

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

• 各 Cell は他の Cells から独立しています
• インフラストラクチャコンポーネントは Cell 内の Organizations とそのトップレベルグループによって共有されます
• 水平スケーラビリティを提供するために追加の Cells をプロビジョニングできます
• 障害が発生した Cell は他の Cells の障害につながりません
• ノイジーネイバー効果は Cell 内に限定されます
• Cells は Organizations には見えません - 実装の詳細です
• Cells は異なる地理的リージョンに配置される場合があります（例: EU、US、JP、UK）
• 初期プロビジョニング時に、GitLab Dedicated ツールによってプロビジョニングされた GitLab インスタンスをクラスターに参加するよう設定し、Cell として機能させることができます

非推奨の同義語: GitLab インスタンス、クラスター、シャード、Pod

レガシー Cell

既存の GitLab.com インフラストラクチャはアプリケーションの観点から Cell として動作します。 これをレガシーと呼ぶのは、既存の顧客が存在し、 古いプロビジョニングツール（GitLab Dedicated ツールではない）を使用しているためです。 最終的には、レガシー Cell からプロビジョニングする Cells に顧客を移行したいと考えています。

クラスター

クラスターとは Cells の集合体です。

非推奨の同義語: Whale、GitLab Dedicated インスタンス、インスタンス

Organizations

Organization とは 1 つまたは複数のトップレベルグループのための包括的な傘となるエンティティです。Organizations はデフォルトで互いに分離されており、クロス名前空間機能は単一の Organization 内に存在する名前空間に対してのみ機能します。

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

Organizations は既知の概念であり、例えば AWS や GCP にも存在します。

Organizations は以下の前提で機能します:

1. ユーザーは自分の Organization 内で起こることを気にします。
2. 機能は Organization 内で動作する必要があります。
3. Organizations 間で動作する必要があるのはごく少数の機能だけです。
4. ユーザーは自分が閲覧するページの大多数が一度に単一の Organization にスコープされていることを理解しています。
5. Organizations は単一の Cell に存在します。Organization は複数の Cells にまたがることはありません。
6. Cell はマルチテナントになります。効率とコストの観点から、Cell は複数の Organizations を収容します。
7. Organization は顧客のための意図されたトップレベルエンティティです。単一の顧客に対して複数の Organizations の機能の集計をサポートする機能は構築しません。つまり、1 人の顧客に対して 1 つの Organization のみがプロビジョニングされます。

プロパティ:

• トップレベルグループは Organizations に属します。
• Organizations はデフォルトで互いに分離されており、クロスグループ機能は単一の Organization 内に存在するグループに対してのみ機能します。
• 個人の名前空間は Organization に属してはなりません。

非推奨の同義語: 課金エンティティ、顧客

トップレベルグループ

例:

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

• gitlab-org は トップレベルグループ です; Organization のすべてのグループとプロジェクトのルート
• gitlab は プロジェクト です; Organization のプロジェクト。

トップレベルグループは事実上の Organization エンティティとして機能してきました。Organizations の作成により、トップレベルグループは Organizations の配下に入れ子にされます。

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

• 同じ Organization に属するトップレベルグループは同じ Cell に存在します。
• トップレベルグループは同じ Organization に属する他のトップレベルグループと対話できます。

非推奨の同義語: ルートレベル名前空間

ユーザー

ユーザーはグローバルに利用可能であり、単一の Cell に制限されません。ユーザーは単一の Organization に属しますが、さまざまな権限でグループとプロジェクトのメンバーシップを通じて多くの Organizations に参加できます。Organizations 内で、ユーザーは複数のトップレベルグループを作成できます。ユーザーアクティビティは単一の Organization に限定されませんが、貢献（例: To-Do）は Organization 内のみで集計されます。これにより、Cells 間での集計が不要になります。

• ユーザーはすべての Cells 間でグローバルに共有されます。
• ユーザーは複数のトップレベルグループを作成できます。
• ユーザーは複数のトップレベルグループのメンバーになれます。
• ユーザーは 1 つの Organization に属します。!395736 を参照してください。
• ユーザーは異なる Organizations のグループやプロジェクトのメンバーになれます。
• ユーザーは Organizations を管理できます。
• ユーザーアクティビティは Organization 内で集計されます。
• すべてのユーザーは 1 つの個人の名前空間を持っています。

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