| 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 0을 업데이트하는 것도 쉬워지는데, 전체 시스템을 복제할 수 있는 기존 복제 솔루션 때문입니다: Geo, PostgreSQL 물리적 복제 등.
- 조직의 모든 데이터는 여러 Cells로 나누어져서는 안 됩니다.
- 분할은 온라인으로 수행할 수 있어야 합니다.
- 새 Cells에는 기존 데이터가 포함되어서는 안 됩니다.
- N Cells에는 Cell 0의 정확한 복제본이 포함되어야 합니다.
- Cell 0의 데이터는 분할해야 할 N 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, 기본 PostgreSQL, 레지스트리 PostgreSQL 및 기타 새 데이터 리포지터리의 스냅샷을 온라인 시스템으로 동기화하는 것은 긴 다운타임을 야기할 가능성이 높습니다. 동시에 여러 데이터 리포지터리를 마이그레이션하는 경우 실패 조치의 쓰기 다운타임이 길어질 것입니다. 우리는 또한 응용 프로그램에서 모든 이러한 시스템에 대한 업데이트를 신뢰할 수 있는 신뢰성 있는 위치를 찾아야 할 것입니다. 이전에는 예기치 않은 코드 경로 또는 기타 놀라운 코드 경로로 인해 모든 Rails 서비스를 종료함으로써 신뢰할 수밖에 없었습니다.
- 모든 오직 데이터를 효율적으로 삭제하는 방법. 조인을 해야하는 경우 반의 조직에 속한 모든
ci_builds를 찾는 것은 매우 비용이 많이 든다. 아직organization_id열을 모든 테이블에 저장할 것인지 결정하지 않았지만, 이것이 도움이 될 수 있는 유형의 것이라고 여겨집니다.
3.2. 기존 Cell에서 조직 마이그레이션
이것은 분할과는 다르며, 하나의 조직에 속한 데이터를 논리적이고 선택적으로 복제할 수 있도록 의도되었습니다. 오늘날 이러한 유형의 선택적 복제는 Gitaly에서만 구현되어 있으며, 여기서는 Git 리포지터리를 최소한의 다운타임으로 다른 Gitaly 노드로 마이그레이션할 수 있습니다.
이 모델에서는 주어진 조직에 속한 모든 리소스를 식별해야 합니다: 데이터베이스 행, 객체 리포지터리 파일, Git 리포지터리 등을 다른 기존 Cell로 선택적으로 복사합니다. 이상적으로 모든 변경된 데이터의 논리적 복제를 실시할 수 있도록 하지만, 분할과 유사하게 이 조직을 위한 권한이 있는 Cell을 결정하는 것과 같은 변경은 필요합니다.
- 하나의 조직에 속한 모든 리소스를 식별하는 것이 어렵습니다.
- 조직을 위한 다운타임이 필요하거나 실시간 변경을 식별하기 위한 견고한 시스템이 필요합니다.
- 선택적인 PostgreSQL 논리적 복제를 수행하기 위해서는 프로젝트의 가치실현을 수행하기 위해(프로젝트 보다 더 견고함) 필요합니다.
이 제안의 더 많은 도전 과제
- 논리적 복제는 아직도 우리의 규모에 미치지 못할 정도로 효율적이지 않습니다. 논리적 복제를 사용할 수 있더라도 단일 조직과 관련된 데이터를 효율적으로 필터링하는 방법이 없으므로 모든 방식으로 조인하는 것은 논리적 복제를 심각하게 느리게 만들 것입니다.