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. As with all projects, the items mentioned on this page are subject to change or delay. The development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.
StatusAuthorsCoachDRIsOwning StageCreated
accepted @ayufan @fzimmer @DylanGriffith @lohrc @tkuah @ayufan @lohrc devops enablement 2022-09-07

細胞

このドキュメントは作業途中であり、Cellsの設計のごく初期の状態を表しています。重要な点は文書化されていませんが、将来的に追加されることを期待しています。

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

Cellsについての詳細はこちらもご覧ください：

ワークストリーム

Cellsアーキテクチャ全体を一度に出荷することはできません。その代わりに、プロジェクトで必要となる主要なワークストリームを定義しています。

生産準備に到達するために、すべての目標を達成する必要はありません。(GA)General Availability には間に合わないものもありますが、Cells を本番稼動させるには十分です。

1.データアクセスレイヤー

Cells を本番稼動させる前に、Cells アーキテクチャを受け入れるコードベースを準備する必要があります。この準備には以下が含まれます：

  • Cells 間でのデータ共有の許可。
  • セル間のデータトラバースを発見するためのツールの更新。
  • クロスセル・データ・トラバーサルに関するコード・プラクティスの定義。
  • データ親和性を定義するためのデータモデルの分析。

この目的の下、以下のステップが予想されます：

  1. データベースレベルのデータアクセスレイヤでクラスター全体のデータを共有できるようにします。

    セルは共有データを含むデータベースに接続できます。例えば、アプリケーション設定、ユーザー、ルーティング情報など。

  2. データベース・レベルのアクセスとAPI指向のアクセス・レイヤーの効率性を評価します。

    データのサブセットのみを共有する場合の、データマイグレーション、更新の弾力性、相互接続されたシステムに対するデータベースレベルのデータアクセスの結果を再考します。

  3. クラスター固有の識別子

    すべてのオブジェクトには、クラスター全体でデータにアクセスするために使用できる一意の識別子があります。割り当てられたプロジェクト、イシュー、その他のオブジェクトのIDはクラスター固有です。

  4. クラスター全体の削除

    セル2で削除されたエンティティが相互参照されている場合、クラスター全体で適切に削除または無効化されます。既存の緩い外部キーを再利用して、セル間のデータ削除を拡張する可能性があります。

  5. データアクセスレイヤ

    クラスター全体でデータを共有できる安定したデータアクセス（バージョン管理）レイヤーを実装するようにします。

  6. データベースのマイグレーション

    マイグレーションをセル間で独立して実行できるようにし、他のセルに影響を与えない方法で共有データのマイグレーションを安全に処理します。

2.必須ワークフロー

Cellsを実用的なものにするためには、Cellsをベータ品質とみなす前に、必要不可欠なワークフローを定義し、サポートする必要があります。必須ワークフローとは、アプリケーションの機能の大部分をカバーするもので、製品をほぼ使用可能にするものですが、いくつかの注意点があります。

現在のアプローチは、ワークフローを上から下に定義することです。この順序は、項目の優先順位を定義します。このリストは、私たちが基本的なものを修正する初期段階の後に、他のチームがワークフローを修正することを期待しているため、網羅的ではありません。

プロジェクトがベータフェーズの準備ができたとみなすには、以下に定義されたすべての機能がCellsによってサポートされていることが期待されます。以下のケースでは、ワークフローはその機能に適切に帰属するテーブルのセットを定義します。場合によっては、使用方法が曖昧なテーブルを分解する必要があります。例えば、uploads ユーザーのアバターやアップロードされたコメントの添付ファイルを保存 uploadsするために使用されます。uploads （グループ/プロジェクトレベルの添付ファイルを記述）とglobal_uploads （ユーザーアバターなどを記述）に分割されることがuploads 予想さ uploadsれます。

最初の2-3四半期を除いて、この作業は非常に並行して行われます。group::tennの規模は、他のチームがCellsと連携するための機能セットを修正するのに役立つと期待されています。最初の2-3四半期は、データの一般的な分割を定義し、必要なツールを構築するために必要です。

  1. インスタンス全体の設定はクラスター全体で共有されます。

    管理エリアセクションの大部分はクラスター全体で共有されます。

  2. ユーザーアカウントはクラスター全体で共有されます。

    その目的はusers をクラスター全体にするためです。

  3. ユーザーはグループを作成することができます。

    その目的は、users の分解を実行することですnamespaces。 namespaces

  4. ユーザーはプロジェクトを作成できます。

    その目的は、users の分解を行うことですprojects。 projects

  5. ユーザーはクラスターで共有されているプロフィールアバターを変更することができます。

    クラスターで共有されているグローバルアップロードを修正するため。

  6. ユーザーは Git リポジトリにプッシュできます。

    Projectsテーブルからの本質的な結合が適切にCell-localに帰属するようにするためで、その結果、本質的なGitワークフローがサポートされます。

  7. ユーザーはCIパイプラインを実行できます。

    その目的は、ci_pipelines (ci_stages,ci_builds,ci_job_artifactsのような)と隣接するテーブルが適切にCell-localに帰属するようにすることです。

  8. ユーザーはイシューを作成し、マージリクエストを作成し、グリーンになってからマージすることができます。

    その目的は、issues とmerge requests がCell-localに正しく帰属するようにすることです。

  9. ユーザーはグループとプロジェクトのメンバーを管理できます。

    members テーブルは、Cell-local またはcluster-wideのいずれかに正しく帰属します。

  10. ユーザーはインスタンス全体の Runner を管理できます。

    その目的は、全ての CI Runner を Cell-local にすること。インスタンスワイドな Runner は実際には Cell-local な Runner になります。ユーザーインターフェイスのビューを提供し、クラスター単位ではなくセル単位ですべてのランナーを管理することが期待されています。

  11. ユーザーは組織の一部であり、組織からの情報のみを見ることができます。

    目的はセルごとに多くの組織を持つことですが、決して一つの組織が多くのセルにまたがることはありません。これは、組織内に表示される情報が分離されており、他のセルから情報を取得する必要がないことを保証するために必要です。

3.追加ワークフロー

グループの決定によっては、これらの追加ワークフローをサポートする必要があるかもしれません。このリストは、必要な作業を網羅したものではありません。

  1. ユーザーはすべてのグループレベルの機能を使用できます。
  2. ユーザーは、すべてのプロジェクトレベルの機能を使用できます。
  3. ユーザーは、組織内の他のグループとグループを共有することができます。
  4. ユーザーがシステムのWebhookを作成できます。
  5. ユーザーは、パッケージをアップロードし、管理することができます。
  6. ユーザーは、セキュリティ検出機能を管理することができます。
  7. ユーザーはKubernetesインテグレーションを管理できます。
  8. 未定

4.ルーティング層

ルーティングレイヤーは、すべてのセルが単一のドメイン（例えば、gitlab.com ）の下に表示され、別々のドメインにナビゲートする必要がなく、一貫したユーザーエクスペリエンスを提供することを目的としています。

ユーザーはhttps://gitlab.com を使ってCell対応のGitLabにアクセスすることができます。URLのアクセスに応じて、特定の情報を提供できる適切なCellに透過的にプロキシされます。例えば

  • https://gitlab.com/users/sign_in への全てのリクエストは全ての Cell にランダムにディストリビューションされます。
  • 例えば、https://gitlab.com/gitlab-org/gitlab/-/tree/master へのリクエストは常に Cell 5 に送られます。
  • https://gitlab.com/my-username/my-project へのリクエストは常にセル1に送られます。

  1. テクノロジー

    ルーティングサービスをどの技術で書くかを決めます。その選択は、最適な言語と、ルーティングレイヤーのデプロイ方法と場所に依存します。サービスをマルチクラウドにする必要がある場合、CDNプロバイダーにデプロイする必要があるかもしれません。その場合、CDNプロバイダーと互換性のある技術を使ってサービスを記述する必要があります。

  2. セル・ディスカバリー。

    ルーティング・サービスはすべてのセルを発見し、その状態を監視できる必要があります。

  3. ルーターエンドポイントの分類。

    ステートレスルーティングサービスはエンドポイントに関する情報を Cell の一つから取得してキャッシュします。入ってくるリクエスト（そのフィンガープリント）を正確に記述できるようなプロトコルを実装する必要があります。ネガティブキャッシュとキャッシュエビクションのメカニズムも実装する必要があります。

  4. GraphQL とその他のあいまいなエンドポイント。

    ほとんどのエンドポイントは、一意のシャーディング・キー「Organization」を持っており、これを直接または間接的に（グループやプロジェクトを経由して）使用することで、エンドポイントを分類することができます。エンドポイントの中には、使い方が曖昧なもの（シャーディング・キーをエンコードしていないもの）や、シャーディング・キーがペイロードの奥深くに格納されているものがあります。このような場合、/api/graphql のようなエンドポイントをどのように扱うかを決める必要があります。

5.セルのデプロイ

私たちは多くのセルを運用します。それらを簡単に管理するためには、デプロイ、管理、マイグレーション、モニタリングの方法など、Cell の一貫したデプロイ手順が必要です。

GitLab 専用のツールやコントロール・プレーンを使うことになるでしょう。

  1. GCPをサポートするためにGitLab Dedicatedを拡張します。
  2. 未定

6.マイグレーション

プロダクションに到達し、新しい組織に新しいセルを保存できるようになった場合、大きなセルを小さなセルに分割する必要があります。

  1. GitLab Geoを使ってCellをクローンします。

    GitLab Geoを使ってCellをクローンすることが目的です。

  2. クローンすることでCellを分割します。

    Cellをクローンしたら、Organizationsのルーティング情報を変更します。Organizations will encode acell_id. When we update the cell_id it will automatically make the given Cell authoritative to handle traffic for the given Organization.

  3. 以前のCellから冗長なデータを削除します。

    組織は現在、多くのCellに格納されているので、我々はcell_id を変更すると、我々はorganization_idに基づいて、他のすべてのCellからデータを削除する必要があります。

機能の可用性

私たちは、Support for Experiment、Beta、Generally Availableの機能に従っています。

1.実験

期待しています：

  • Cellデプロイツールを使用して、ステージング環境または別のテスト環境に別ドメイン（例：cell2.staging.gitlab.com ）を使用してCellをデプロイすることができます。
  • ユーザーは組織、グループ、プロジェクトを作成し、いくつかの重要なワークフローを実行することができます。
  • 単一のドメイン下ですべてのリクエストに対応するルーターを実行できることは期待されていません。
  • 追加セルに保存されたデータの損失が予想されます。
  • ツールの検証のため、多くのセルを解体し、新しいセルを作成することが予想されます。

2.ベータ

期待しています：

  • 1つのドメイン（例：staging.gitlab.com ）で多くのCellを動かすことができます。
  • 必須ワークフローで定義されたすべての機能がサポートされています。
  • ルーティングレイヤーのすべての側面が最終化されているわけではありません。
  • 追加Cellがデータ損失を最小限に抑えながら安定することを期待しています。

3.GA

期待しています：

4.ポストGA

期待しています：

反復計画

提供される反復は、与えられた主要な作業の流れの特定のステップを解決することに焦点を当てます。データ分割のためにコードベースを準備するために、より多くの変更を必要とするため、初期の反復はかなり遅くなることが予想されます。

1回の反復は、1四半期分の作業を表します。

  1. イテレーション1- FY24Q1 - 完了

    • データアクセスレイヤ：管理エリアの初期設定はクラスター全体で共有。
    • 必須ワークフロー：データベースレベルのデータアクセスレイヤでクラスター全体のデータを共有可能

  2. イテレーション2- FY24Q2 - 進行中

    • 必須ワークフロー：クラスター間でユーザーアカウントを共有。
    • 必須ワークフローユーザーはグループを作成できます。

  3. イテレーション3- FY24Q3 - 計画中

    • 必須ワークフローユーザーはプロジェクトを作成できます。
    • ルーティングテクノロジー
    • データアクセスレイヤー：データベースレベルのアクセスとAPI指向のアクセス層の効率性を評価

  4. イテレーション4- FY24Q4

    • 必須ワークフロー：ユーザーはGitリポジトリにプッシュできます。
    • 必須ワークフロー：ユーザーはイシューの作成、マージリクエストの作成、グリーンリクエスト後のマージが可能です。
    • データアクセスレイヤー：クラスター固有の識別子。
    • ルーティングセルディスカバリー
    • ルーティングルーターエンドポイントの分類。
    • セルデプロイ：GCPをサポートするためにGitLab Dedicatedを拡張。

  5. イテレーション5 - FY25Q1

    • 必須ワークフロー：ユーザーはCIパイプラインを実行することができます。
    • 必須ワークフロー：インスタンス全体の設定はクラスター全体で共有されます。
    • 必須ワークフロー：ユーザーはクラスターで共有されるプロフィールアバターを変更できます。
    • 必須ワークフロー：ユーザーはイシューの作成、マージリクエストの作成、グリーンリクエスト後のマージが可能です。
    • 必須ワークフローユーザーはグループとプロジェクトのメンバーを管理できます。
    • 必須ワークフロー：ユーザーはインスタンス全体のRunnerを管理できます。
    • 必須ワークフロー：ユーザーは組織の一部であり、組織からの情報のみを見ることができます。
    • ルーティング：GraphQLおよびその他の曖昧なエンドポイント。
    • データアクセスレイヤー：データベースレベルのデータアクセスレイヤーでクラスター全体のデータを共有できるようにします。
    • データアクセスレイヤ：クラスター全体の削除。
    • データアクセスレイヤ：データアクセスレイヤ。
    • データアクセスレイヤー：データベースのマイグレーション。
  6. イテレーション6 - FY25Q2
    • 未定
  7. イテレーション7 - FY25Q3
    • 未定
  8. イテレーション8 - FY25Q4
    • 未定

技術提案

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

影響を受ける機能

Cellsアーキテクチャは多くの機能に影響を与え、その一部は書き換えや大幅な変更が必要となります。以下は、影響を受けることが分かっている機能のリストと、暫定的な解決案です。

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

以下の影響する機能のリストは、Cells の影響を見積もり、解決策を提案するための作業が必要なプレースホルダーを表しています。

よくある質問

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

新しいCellsアーキテクチャは、GitLab.comを拡張するためのものです。これを実現する方法は、OrganizationをCellsに移動させることですが、アプリケーションが他のOrganizationから隔離されていても、異なるOrganizationはサーバーリソースを共有することができます。しかし、それらは全て既存のGitLab SaaSドメイン名gitlab.comの下でオペレーションを行います。また、セルはusersやグループやプロジェクトのルーティング情報など、いくつかの共通データを共有します。例えば、異なるCellに存在する異なるOrganizationsに属していても、2人のユーザーが同じユーザー名を持つことはありません。

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

一方、GitLab Dedicatedは、どのような組織にも完全に隔離されたGitLabインスタンスを提供することを目的としています。このインスタンスは独自のカスタムドメイン名で実行され、GitLab SaaSを含む他のGitLabインスタンスから完全に隔離されています。例えば、GitLab Dedicatedのユーザーは、GitLab.comで既に使用されている異なるユニークなユーザー名を持つ必要はありません。

異なるCell同士で通信できますか？

イテレーション 3 までは、Cell 間は共通のデータを含む共有データベースを介してのみ通信していました。イテレーション4では、より分離された信頼性を提供するために、セル同士がAPIを介して呼び合うオプションを評価する予定です。

セルはどのようにプロビジョニングされるのですか？

GitLab.comクラスターのCellはGitLab Dedicatedインスタンスを使用します。GitLab Dedicatedインスタンスがプロビジョニングされると、GitLab.comクラスターに参加し、Cellになることができます。GitLab Dedicatedインスタンスに以前のデータが含まれていないことが一つの条件となります。

共有リソースにアクセスするために、Cellは非公開サービスコネクトを使用します。

設計に関する議論も参照してください。

セルトポロジーとは何ですか？

デザイン・ディスカッションをご覧ください。

組織のユーザーはどのように正しいセルにルーティングされますか？

未定

ユーザーはセルと組織でどのように認証するのですか？

デザイン・ディスカッションをご覧ください。

セルのバランスはどのように調整されますか？

未定

セルはディザスタリカバリ機能をどのように導入できますか？

未定

決定ログ

  • 2022-03-15:Google Cloud をクラウドサービスに。詳細はイシュー396641をご覧ください。