| Status | Authors | Coach | DRIs | Owning Stage | Created |
|---|---|---|---|---|---|
| proposed | - |
이 문서는 진행 중인 작업이며 Cells 디자인의 매우 초기 단계를 나타냅니다. 중요한 측면은 문서화되어 있지 않지만, 우리는 미래에 이를 추가할 것으로 기대하고 있습니다. 이것은 Cells에 대한 한 가지 가능한 아키텍처이며, 우리는 구현할 접근 방식을 결정하기 전에 대안과 대조하고자 합니다. 이 문서는 구현하지 않기로 결정한 경우에도 선택한 이 접근 방식을 선택하지 않은 이유를 문서화하기 위해 유지될 것입니다.
Cells: 데이터 마이그레이션
대형 Cells에서 데이터를 작은 Cells로 이동하는 방법을 제공하는 것이 Cells 아키텍처에 필수적입니다. 이 문서는 이러한 유형의 분할을 제공하는 여러 접근 방식을 설명합니다.
이미 Cells의 예상된 격리 제약 조건을 위반하는 데이터에 대한 처리도 필요합니다. 예를 들어 참조는 여러 조직에 걸칠 수 없습니다. 기존의 기능 중 하나인 linked issues와 같이 사용자는 계층 구조에 관계없이 모든 프로젝트 간에 문제를 연결할 수 있었습니다. 이와 같은 유사한 기능이 많이 있습니다. 이러한 모든 데이터는 다른 Cells 간에 분할되기 전에 어떤 식으로든 마이그레이션되어야 할 것입니다. 이는 일부 데이터가 삭제되어야 할 수도 있거나, 기능이 변경되어야 하거나, 새로운 방식으로 모델링되어야 한다는 것을 의미할 수 있습니다. 이렇게 하기 전에 조직을 다른 Cells 간으로 적절하게 분할하거나 마이그레이션하기 위해 네트워크 자원이 있어야 합니다.
다양한 Cells 간의 스키마 이탈은 다른 데이터베이스의 필연적인 결과이며, 이는 Cells 간의 데이터 마이그레이션 능력에도 영향을 미칠 것입니다. 다른 스키마는 Cells 간의 데이터를 신뢰할 수 있게 복제하는 능력에 영향을 미치며, 특히 데이터가 올바르게 복제되었는지를 검증하는 능력에 영향을 미칠 것입니다. 스키마가 동기화되어야만 Cells 간에 데이터를 이동할 수 있도록 강제될지도 모르며(배포와 리밸런싱 프로세스를 늦춤), 또는 아마도 새로운 스키마에서 이전 스키마로만 마이그레이션해야 할 수도 있을 것입니다(복잡해질 수 있음).
1. 정의
2. 데이터 흐름
3. 제안
3.1. 대형 Cells 분할
단일 Cell은 많은 Cells로 분할될 수 있습니다. 이는 단일 Cell을 기존의 복제본 중에서 정확한 복제본을 생성하는 것이 더 쉽기 때문에 기반이 됩니다. 이 복제본들 중 일부는 마이그레이션된 후에 먼저 권한을 갖게 됩니다. 또한, 이러한 복제본들을 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에 대한 모든 접근은 해당 Cell이 데이터를 처리할 권한이 있는지 확인하기 위해routes의cell_id를 기반으로 유효성을 검사합니다.
이 제안의 더 많은 도전과제
- Elasticsearch에는 스트리밍 복제 능력이 없지만, 전체 Elasticsearch 인덱스를 스냅샷으로 만들고 다시 만들 수는 있지만, 이는 몇 시간이 소요됩니다. 마이그레이션 중에 Elasticsearch 색인을 일시 중지하여 처리할 수 있지만, 이는 여전히 마이그레이션 프로세스와 조정이 필요합니다.
- Redis, Gitaly, CI Postgres, Main Postgres, registry Postgres, 기타 새로운 데이터 저장소의 동기화는 온라인 시스템에서 스냅샷을 찍으면 오랜 시간 동안 쓰기 다운타임이 발생할 가능성이 높습니다. 다른 데이터 저장소를 동시에 마이그레이션하는 경우, 장애 조치를 위해 쓰기 다운타임이 더 길어질 수 있습니다. 또한, 모든 이러한 시스템에 대한 업데이트를 신뢰할 수 있는 지점을 실제로 찾아야할 것입니다. 이러한 신뢰성 있는 지점을 찾는 것은 어려울 것으로 예상되며, 지금까지는 예상에 어긋나는 코드 경로 또는 다른 예상치 못한 코드 경로로 인해 모든 Rails 서비스를 중지함으로써만 신뢰할 수 있었습니다.
- 모든 고아 데이터를 효율적으로 삭제하는 방법. 반의 조직에 속한 모든
ci_builds를 찾는 것은 조인을 해야 한다면 매우 비용이 많이 들 것입니다. 아직 우리는 모든 테이블에organization_id열을 저장할지 여부를 결정하지 않았지만, 이것은 유용할 수 있는 유형의 것입니다.
3.2. 기존 Cell에서 조직 마이그레이션
이는 분할과 다른데, 우리는 단일 조직에 속한 데이터를 논리적이고 선택적으로 복제하려고 합니다. 지금은 Gitaly에서만 이 유형의 선택적인 복제를 구현했습니다. 여기서는 Git 저장소를 한 Gitaly 노드에서 다른 노드로 최소한의 다운타임으로 마이그레이션할 수 있습니다.
이 모델에서는 특정 조직에 속한 모든 리소스(데이터베이스 행, 객체 저장소 파일, Git 저장소 등)를 식별해야합니다. 그리고 그것들을 다른(아마도 기존의) Cells로 복사해 넣습니다. 이상적으로는 변경된 모든 데이터를 실시간으로 논리적으로 복제할 수 있도록 하지만, Cell이 이 조직에 대해 권한을 가질 수 있도록 분할과 유사하게 변경합니다.
- 조직에 속한 모든 리소스를 식별하기가 어렵습니다.
- 조직에 대한 다운타임이 필요하거나 실시간 변경 사항을 식별하기 위한 강력한 시스템이 필요합니다.
- 선택적인 PostgreSQL 논리적 복제를 수행하려면 프로젝트 가져오기/내보내기보다 더 견고한 전체 데이터베이스 구조 분석이 필요할 것으로 예상됩니다.
이 제안의 추가적인 어려움
- 논리적 복제는 아직 우리의 규모에 따라 성능이 떨어집니다. 심지어 논리적 복제를 사용할 수 있다고 해도, 모든 방법으로
organizations테이블에 조인하여 단일 조직과 관련된 데이터를 효율적으로 필터링하는 방법이 없습니다. 이는 논리적 복제를 심각하게 늦출 것입니다.