| Status | Authors | Coach | DRIs | Owning Stage | Created |
|---|---|---|---|---|---|
| proposed | - |
このドキュメントは作業中のものであり、セルズの設計のごく初期の状態を表しています。重要な点は文書化されていませんが、将来的には追加される予定です。これはCellsの可能性のあるアーキテクチャの一つであり、どのアプローチを実装するか決める前に、代替案と比較検討するつもりです。この文書化は、このアプローチを選ばなかった理由を文書化できるよう、これを実装しないと決めた場合でも残しておきます。
セルズデータマイグレーション
大きなセルから小さなセルへデータをマイグレーションする方法を提供することは、Cells アーキテクチャにとって不可欠です。このドキュメントでは、この種の分割を提供するための様々なアプローチについて説明します。
また、例えば参照が複数の組織にまたがることができないなど、データが既にCellsの期待される分離制約に違反しているケースを処理する必要があります。リンクされたイシューのような既存の機能により、ユーザはプロジェクトの階層に関係なく、あらゆるプロジェクトにまたがるイシューをリンクできることが分かっています。同様の機能はたくさんあります。これらのデータはすべて、異なるセルに分割する前に何らかの方法でマイグレーションする必要があります。つまり、セル間で組織を適切に分割またはマイグレーションする前に、一部のデータを削除したり、機能を変更したり、モデリングを少し変えたりする必要があります。
異なるセル間でスキーマが異なることは、異なるデータベースの必然的な結果であり、セル間のデータマイグレーションにも影響します。異なるスキーマは、セル間でデータを確実に複製する能力に影響を与え、特にデータが正しく複製されているかどうかを検証する能力に影響を与えます。スキーマがすべて同期しているときにしかセル間でデータを移行できない（デプロイとリバランシング・プロセスが遅くなる）か、新しいスキーマから古いスキーマへのマイグレーションしかできない可能性があり、これは複雑です。
1.定義
2.データフロー
3.提案
3.1.大きなセルの分割
一つのセルは多くのセルに分割することができます。これは、既存のCellの正確なクローンを多くのレプリカで作成する方が簡単であり、そのうちのいくつかをマイグレーション後にオーソリティ化するという原則に基づいています。システム全体をレプリケートできる既存のレプリケーション・ソリューションがあるため、それらのレプリカをCell 0で最新の状態に保つこともはるかに簡単です：Geo、PostgreSQLの物理レプリケーションなどです。
- 組織の全データを多くのセルに分割する必要はありません。
- 分割はオンラインで可能であるべきです。
- 新しいセルに既存のデータを含めることはできません。
- N セルにはセル 0 の正確な複製が含まれます。
- セル 0 のデータは分割が必要なセル数だけライブ・レプリケートされます。
- Cell 0とN-Cellの間でコンセンサスが得られたら、マイグレーションされるOrganizationはクラスター全体で読み取り専用にマークされます。
-
cell-100のgitlab-orgのように、最新のデータを保持する権威あるCellを示すために、分割されるすべてのOrganizationに対してroutesが更新されます。 - セル0上の
gitlab-org、その他の非オーソリティN-Cell上のデータは休止中であり、将来削除される予定です。 - 指定された Cell 上の
gitlab-orgへのアクセスはすべてroutesのcell_idについて検証され、指定された Cell がデータを処理する権威があることを確認します。
この提案の課題
- Elasticsearch にはストリーミングレプリケーション機能はありませんが、Elasticsearch インデックス全体をスナップショットして再作成することは可能です。インデックスのダウンタイムは大きなイシューではないので、マイグレーション中の最初のCellでElasticsearchのインデックス作成を一時停止することで対応できますが、それでもマイグレーションプロセスと調整する必要があります。
- Redis、Gitaly、CI Postgres、Main Postgres、レジストリ Postgres、その他の新しいデータストアのスナップショットをオンラインシステムで同期すると、長いダウンタイムなしにギャップが発生する可能性が高いです。同期ポイントを選択し、同期ポイントで書き込みを停止してマイグレーションを実行する必要があります。同時にマイグレーションするデータストアが多ければ多いほど、フェイルオーバーのための書き込み停止時間は長くなります。また、これらすべてのシステムに対する更新を高い信頼性で実際にブロックするために、アプリケーション内で信頼できる場所を見つける必要があります。過去には、Railsのすべてのサービスをシャットダウンすることでしか確信が持てませんでした。非同期ワークロードやその他の意外なコードパスのために、Railsのどのプロセスもいつでもこれらのいずれかに直接書き込むことができたからです。
- 孤児となったデータを効率的に削除する方法。半分のOrganizationsに関連するすべての
ci_builds、joinを行うには非常にコストがかかります。すべてのテーブルにorganization_id列を格納するかどうかはまだ決定していませんが、このような場合に役立ちます。
3.2.既存のセルからの組織のマイグレーション
これはスプリットとは異なり、1つの組織に属するデータの論理的かつ選択的なレプリケーションを行うものです。今日、この種の選択的レプリケーションはGitalyによってのみ実装されており、最小限のダウンタイムで単一のGitalyノードから別のノードにGitリポジトリをマイグレーションすることができます。
このモデルでは、ある組織に属するすべてのリソース（データベースの行、オブジェクトストレージのファイル、Gitリポジトリなど）を特定し、それらを選択的に別の（おそらく既存の）Cellにコピーしてデータをインポートする必要があります。理想的には、変更されたすべてのデータの論理的なレプリケーションをライブで実行できるようにすることです。
- 組織に属するすべてのリソースを識別することは困難です。
- 組織のダウンタイムか、ライブの変更を識別するための堅牢なシステムが必要です。
- 選択的なPostgreSQL論理レプリケーションを実行するためには、（プロジェクトのインポート/エクスポートよりも堅牢な）完全なデータベース構造分析が必要になるでしょう。
この提案の課題
- 論理レプリケーションは、私たちの規模に追いつくにはまだ十分なパフォーマンスではありません。仮に論理レプリケーションを使用できたとしても、
organizationsテーブルまで結合することなく、1つの組織に関連するデータをフィルタリングする効率的な方法はまだありません。