Cells: 組織移行

サマリー

すべてのユーザーデータは Organization でラップされます。これは隔離を提供し、ある Cell から別の Cell へ、特に Legacy Cell から組織を移動することを可能にします。

Protocells では、組織に移動した後 Cell に移行できるトップレベルグループから構成されるコホートを定義します。

コホートの 定義 は作業の最初の部分ですが、組織を Legacy Cell から Cell へ移動するためのツーリングも構築する必要があります。

この設計ドキュメントは、組織をソースから宛先に移動する移行ツーリングに焦点を当てています。コホートとトップレベルグループの移行については言及するのみで、それらの実装の詳細には踏み込みません。

動機

Cells は、GitLab.com を水平方向にスケールするという主要な目標を達成した場合にのみ成功します。スケールするためには、データベースのスケーリング限界に達する前に負荷を恒久的に取り除くため、Legacy Cell にある既存のデータを新しい Cell に移動する必要があります。この移行機能は、GitLab の成長に伴って GitLab.com サービスを将来にわたって安定させるために不可欠です。

目標

1. 中断可能性: 計算リソースの障害やオペレーターによる停止などで移行が中断された場合、中断した箇所から再開できるべきです。
2. ハンズオフ: 移行はバックグラウンドで実行されるべきで、チームメンバーのラップトップ上で移行を実行する必要はありません。
3. コードの再利用: Geo はデータを 1 つの GitLab インスタンスから別のインスタンスに複製するために構築されました。私たちは同じことを組織レベルで行っています。
4. データ損失なし: ソース Cell にあるすべてのデータが宛先 Cell でも利用可能であるべきです。これは、Object Storage、Postgres、Advanced Search、Exact Code Search、Git、Container Registry など、すべてのデータタイプを考慮する必要があることを意味します。
5. Cell のダウンタイムなし: 組織を移行する際、ソース Cell および宛先 Cell は、転送されている組織以外についてはダウンタイムが発生してはなりません。
6. 可視のダウンタイムなし: 組織は、私たちが彼らのデータを移行していることに気づくべきではありません。ゼロダウンタイムを達成することは決してできず、ある程度のダウンタイムや読み取り専用の状態から始めますが、より顕著な顧客を移行するにつれてこれを継続的に改善していきます。
7. 大規模組織のサポート: テラバイト規模のデータを適切な期間内に移行できるようにします。これは、ツーリングをデータに対してスケーラブルにする必要があることを意味します。
8. 並行性: 複数の組織を、互いに影響を与えずに同時に移行できるようにします。
9. Cell ローカル: 移行は、すべての移行に対する単一障害点を防ぐため、宛先 Cell 上で行われるべきです。
10. 最小限の使い捨て作業: 移行ツーリングを何度も書き直すのではなく、反復するべきです。
11. 可観測性: 任意の時点で、移行がどこにあるか、そして問題があるかどうかを知る必要があります。
12. Cell 認識: 移行ツーリングは、リクエストを正しい Cell にルーティングし始めるため、Topology Service の情報も更新する必要があります。
13. ユーザー可視のパフォーマンス影響なし: 移行は、ソースまたは宛先 Cell どちらのパフォーマンスも低下させてはなりません。
14. ロールバック機能: 組織をソースに戻して移行することは できません。ロールバックがどのように処理されるかについての決定は、Protocells への組織データ移行のロールバック戦略 を参照してください。
15. ドライランサポート: オペレーターは、実際にデータを移動することなく、検証と時間見積もりで移行をテストできるべきです。
16. セキュリティ: 転送中のすべてのデータは暗号化されるべきであり、Cell 間通信は適切な認証と認可を使用する必要があります。

非目標

• どの組織がどのセルに存在するかの決定。
• セルフホストインストールのサポート。
• 災害復旧ツーリングの代替となること。

コホート定義

Protocells の終了条件 を満たすためには、上位 1,000 のアクティブな名前空間 (これは データベース時間の約 67% を消費する) のかなりの部分を移行する必要があると予想されます。

コホートは、GitLab のルート名前空間とそのデータのセットで、他のセルに段階的に転送/移行するための単一のコレクションとして選択されます。

コホートの命名規約: 本番コホートに進む前に正常に完了する必要があるため、テストコホートに対しては 0 を使用します。後続のコホート (A、B、C など) は、順次的な依存関係なく並列に実行できることを示すために文字を使用します。

• [1]: 20% という目標は、上位 1000 の名前空間が消費する データベース時間 67% の 1/3 から導かれています。
• [2]: 10% という目標は、ロングテールのデータベース時間 33% の 1/3 を移動する可能性から来ています。

移行設計ドキュメント

Database Migration Service (DMS)

1. DMS Blueprint - AWS DMS を使用して PostgreSQL データを GCP から AWS に移行する戦略
2. DMS Integration with Dedicated Tooling - DMS を Instrumentor、AMP、および Tenant Model Schema に統合する

コホート移行計画

1. Cohort 0: Test Migration - 100 のテスト TLG の初期移行で、エンドツーエンドのプロセスを検証

意思決定

1. ADR-002 Rollback strategy for organization data migrations to Protocells - 組織データ移行のための切り戻しおよび fix-forward アプローチ
2. ADR-003 Org Mover Control Plane - Org Mover の高レベルなコントロールプレーンの意思決定

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