| Status | Authors | Coach | DRIs | Owning Stage | Created |
|---|---|---|---|---|---|
| proposed | - |
이 문서는 작업 중인 상태이며 Cells 설계의 매우 초기 상태를 나타냅니다. 중요한 측면이 문서화되지 않았지만, 향후 추가할 것으로 예상됩니다. 이것은 Cells에 대한 하나의 가능한 아키텍처이며, 이를 구현할 접근 방법을 결정하기 전에 대안과 대조하고자 합니다. 이 접근 방법을 선택하지 않기로 결정하더라도 선택 이유를 문서화하기 위해 이 문서는 유지될 것입니다.
Cells: 데이터 마이그레이션
큰 Cells에서 데이터를 작은 Cells로 마이그레이션하는 방법을 제공하는 것은 Cells 아키텍처에서 중요합니다. 이 문서에서는 이러한 유형의 분할을 제공하기 위한 여러 방법을 설명합니다.
또한 Cells의 예상된 격리 제약 조건을 위반하는 데이터의 경우도 처리해야 합니다. 예를 들어 참조가 여러 조직에 걸쳐서는 안 되는데 이미 그러한 경우가 발생하는 등의 경우입니다. 기존의 기능인 연결된 이슈와 같은 것들이 모든 프로젝트 간에 문제 없이 연결되도록 허용되었다는 것을 알고 있습니다. 많은 유사한 기능들이 있습니다. 이러한 모든 데이터는 다른 Cells 간에 분할되기 전에 어떤 식으로든 마이그레이션되어야 할 것입니다. 이는 어떤 데이터는 삭제되어야 할 수도 있고, 기능을 변경하고 모델을 약간 다르게 만들어야 할 수도 있음을 의미합니다. 그런 다음 적절히 분할하거나 조직을 다른 Cells로 마이그레이션하기 전에 사전에 생성된 스키마의 차이가 나타난다면 마이그레이션 과정에서 스키마의 동기화는 데이터를 신뢰할 수 있는 방식으로 복제하는 능력에 영향을 미치게 됩니다.
Cells 간의 스키마 위반은 데이터의 신뢰할 수 있는 복제 능력과 특히 데이터가 올바르게 복제되었는지를 확인하는 능력에도 영향을 미칩니다. 이로 인해 스키마가 동기화되어 있는 경우에만 Cells 간에 데이터를 이동할 수 있도록 강제될 수 있으며(배포 속도가 느려지고 다시 균형 잡는 프로세스가 느려질 수 있음), 또는 아예 더 최신 스키마에서 더 오래된 스키마로만 마이그레이션할 수도 있는데, 이것은 복잡할 것입니다.
1. 정의
2. 데이터 흐름
3. 제안
3.1. 큰 Cells 분할
단일 Cell은 여러 Cells로 분할될 수 있습니다. 이는 기존 Cell의 정확한 복제본을 만드는 것이 훨씬 쉽기 때문에 이루어집니다. 복제본 중 일부는 마이그레이션이 진행될 때 권한이 있는 Cell이 될 것입니다. Cell 0를 유지하기 위한 복제본을 현재의 복제 솔루션을 통해 유지하는 것이 훨씬 쉽기 때문에 Cell 0에 대한 정확한 복제본을 가지고 있는 것도 훨씬 쉽습니다: Geo, PostgreSQL 물리적 복제 등.
- 조직의 모든 데이터는 여러 Cells에 걸쳐 분할되어서는 안 됩니다.
- 분할은 온라인에서 가능해야 합니다.
- 새로운 Cells에는 기존 데이터가 포함되어서는 안 됩니다.
- N Cells는 Cell 0의 정확한 복제본을 포함합니다.
- Cell 0의 데이터는 분할해야 할 여러 Cells로 실시간으로 복제됩니다.
- Cell 0와 N-Cells 간에 합의가 이루어지면 마이그레이션할 조직은 전체 클러스터에서 읽기 전용으로 표시됩니다.
-
routes는 분할할 모든 조직에 대해 최신 데이터를 보유하고 있는 권한있는 Cell을 나타내기 위해 업데이트됩니다. 예:cell-100에서gitlab-org. - Cell 0에서
gitlab-org의 데이터 및 기타 권한이 없는 N-Cells에 있는 데이터가 비활성화되며 향후 제거될 것입니다. - 특정 Cell에서
gitlab-org에 대한 모든 액세스는routes의cell_id에 대한 유효성을 검증하여 주어진 Cell이 데이터를 처리하기 위한 권한이 있는지 확인합니다.
이 제안의 추가적인 도전 과제
- Elasticsearch에는 스트리밍 복제 능력이 없지만, 전체 Elasticsearch 인덱스를 스냅샷으로 찍고 다시 생성할 수 있습니다. 하지만 이 과정은 몇 시간이 걸립니다. 마이그레이션 중에 Elasticsearch 인덱싱을 일시 중지할 수 있으므로 인덱싱 다운타임이 큰 문제가 되지는 않지만, 이것도 마이그레이션 과정과 조율되어야 합니다.
- Redis, Gitaly, CI PostgreSQL, Main PostgreSQL, 레지스트리 PostgreSQL, 기타 새로운 데이터스토어 스냅샷을 온라인 시스템에서 동기화하는 것은 긴 다운타임 없이는 갭이 발생할 가능성이 높을 것입니다. 동시에 이러한 시스템 전부를 마이그레이션하기 위해 쓰기 중단 시간이 더 길어질 것입니다. 또한 이러한 시스템 전부에 대한 업데이트를 신뢰할 만한 위치에서 차단하기 위해 신뢰성이 있는 장소를 찾아야 할 것입니다. 이전에는 비동기 워크로드나 다른 예상치 못한 코드 경로로 인해 언제든지 어떤 Rails 프로세스든 이러한 시스템에 직접 쓰기할 수 있기 때문에 우리는 모든 Rails 서비스를 중지함으로써만 확실하다고 여겼습니다.
- 모든 고아 데이터를 효율적으로 삭제하는 방법. 절반의 조직에 관련된 모든
ci_builds를 찾는 것은 조인을 해야 한다면 매우 비용이 많이 드는 일일 것입니다. 우리는 아직 모든 테이블에organization_id열을 저장하길 원할지 여부를 결정하지는 않았지만, 이것이 도움이 될 것이라는 것은 분명합니다.
3.2. 기존 Cells에서 조직 마이그레이션
이는 분할과는 다르며, 하나의 조직에 속한 데이터를 논리적이고 선택적으로 복제하는 것을 의도하고 있습니다. 현재 이러한 선택적 복제는 Gitaly에서만 구현되어 있으며 여기에서는 Git 리포지터리를 최소한의 다운타임으로 다른 Gitaly 노드로 마이그레이션할 수 있습니다.
이 모델에서는 특정 조직에 속하는 모든 리소스를 식별해야 합니다: 데이터베이스 행, 오브젝트 스토리지 파일, Git 리포지터리 등과 같은 것들을 식별하고 다른(아마도 존재하는) Cell로 복사합니다. 모든 변경된 데이터의 논리적 복제를 실시할 수 있다는 것이 이상적이지만, 실제로는 어떤 Cell이 해당 조직에 대해 권한이 있는지 변경하는 것과 유사합니다.
- 하나의 조직에 속한 모든 리소스를 식별하는 것은 어려울 것입니다.
- 해당 조직에 대한 다운타임이 필요하거나 실시간 변경을 식별하는 강력한 시스템이 필요할 것입니다.
- 견고한 구조적 PostgreSQL 논리적 복제를 수행하기 위해 전체 데이터베이스 구조 분석이 필요할 것입니다(Project import/export보다 강력함).
이 제안의 추가적인 도전 과제
- 논리적 복제는 여전히 우리의 규모와는 성능적으로 맞지 않습니다. 논리적 복제를 사용할 수 있다고 하더라도, 데이터베이스 테이블까지 모두 조인해야 하는 효율적인 방법이 없을 뿐더러 논리적 복제를 크게 느리게 만들 것입니다.