Cells: 組織移行

概要

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

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

コホートの定義が作業の最初の部分ですが、Legacy Cell から Cell に Organization を移動するためのツールも構築する必要があります。

このデザインドキュメントは、ソースから宛先に Organization を移動する移行ツールに焦点を当てています。コホートとトップレベルグループの移行についてのみ言及し、それらの実装の詳細には触れません。

動機

Cells は GitLab.com を水平スケールするという主要な目標を達成して初めて成功します。スケールするためには、データベーススケーリングの限界に達する前に負荷を永続的に削減するために、Legacy Cell にある既存データを新しい Cell に移行する必要があります。この移行機能は、GitLab が成長するにつれて GitLab.com サービスを将来に備えるために不可欠です。

ゴール

1. 中断可能: コンピューターの障害やオペレーターによる停止など、移行が中断された場合は、中断した箇所から再開できる必要があります。
2. 手放し: 移行はバックグラウンドで実行され、チームメンバーのラップトップで移行を実行する必要がありません。
3. コードの再利用: Geo は一方の GitLab インスタンスから別のインスタンスへデータを複製するために構築されており、私たちも同じことをしていますが、Organization レベルで行います。
4. データ損失なし: ソース Cell に存在するすべてのデータが宛先 Cell で利用可能である必要があります。つまり、Object Storage、Postgres、Advanced Search、Exact Code Search、Git、Container Registry などのすべてのデータタイプを考慮する必要があります。
5. Cell のダウンタイムなし: Organization を移行する際、ソース Cell と宛先 Cell は転送される Organization を除いてダウンタイムを発生させてはなりません。
6. 目に見えるダウンタイムなし: Organization はデータ移行中であることを認識すべきではありません。ゼロダウンタイムは実現できませんが、最初はある程度のダウンタイム/読み取り専用から始め、プロファイルの高い顧客を移行するにつれて継続的に改善します。
7. 大規模 Organization のサポート: テラバイト規模のデータを適時に移行できる必要があります。つまり、ツールをデータにスケーラブルにする必要があります。
8. 並行性: 複数の Organization を互いに影響を与えることなく同時に移行できる必要があります。
9. Cell ローカル: すべての移行に対する単一障害点を防ぐために、移行は宛先 Cell で実行される必要があります。
10. 最小限の使い捨て作業: 移行ツールを複数回書き直すのではなく、イテレーションする必要があります。
11. オブザーバビリティ: 常に移行の状況と問題の有無を把握できる必要があります。
12. Cell 対応: 移行ツールは、Topology Service の情報も更新して、正しい Cell へのリクエストルーティングを開始する必要があります。
13. ユーザーに見えるパフォーマンス影響なし: 移行はソースまたは宛先 Cell のいずれのパフォーマンスも低下させてはなりません。
14. ロールバック機能: Organization をソースの宛先に戻す必要がある場合、これが可能である必要があります。
15. ドライラン サポート: オペレーターは実際にデータを移動することなく、検証と時間見積もりでテスト移行を実行できる必要があります。
16. セキュリティ: 転送中のすべてのデータは暗号化され、Cell 間の通信は適切な認証と認可を使用する必要があります。

非ゴール

• どの Organization がどの Cell に存在するかの決定。
• セルフホスト型インストールのサポート。
• 任意の災害復旧ツールの代替となること。

コホート定義

Protocells の終了基準を満たすために、上位 1,000 のアクティブな名前空間の相当部分を移行する必要があると予想されます。これらはデータベース時間の約 67% を消費しています。

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

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

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

移行設計ドキュメント

データベース移行サービス（DMS）

1. DMS ブループリント - AWS DMS を使用した GCP から AWS への PostgreSQL データ移行戦略
2. DMS と専用ツールの統合 - DMS を Instrumentor、AMP、テナントモデルスキーマに統合する

コホート移行計画

1. コホート 0: テスト移行 - エンドツーエンドプロセスを検証するための 100 テスト TLG の初期移行

決定事項

• ADR-001: コホート B 基準 - アクティブオプトインベータコホートの資格と登録基準

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