Status | Authors | Coach | DRIs | Owning Stage | Created |
---|---|---|---|---|---|
ongoing |
@DylanGriffith
|
@None
|
@lohrc
@alexpooley
| devops data stores | 2023-10-11 |
조직 격리
이 설계안은 조직이 격리되어야 하는 요구 사항에 대한 세부 정보를 제공합니다. 동영상 소개를 시청하여 조직 격리가 무엇이며 왜 필요한지에 대한 요약을 확인하세요. 조직에 대해 자세히 알아보세요.
무엇?
GitLab 내의 모든 셀 로컬 데이터 및 기능(클러스터의 모든 셀에서 존재해야 하는 몇 가지 것을 제외한 모든 데이터)은 격리되어야 합니다. 격리란 데이터나 기능이 절대적으로 조직 경계를 넘지 못함을 의미합니다. GitLab의 많은 기능들이 데이터를 연결할 수 있습니다. 조직 격리로 금지되는 몇 가지 예시는 다음과 같습니다:
-
관련 이슈: 사용자들은
조직 A
의 프로젝트에서 발생한 이슈를조직 B
의 프로젝트의 다른 이슈에 연결할 수 없습니다. -
프로젝트 또는 그룹을 그룹과 공유: 사용자들은
조직 A
의 그룹이나 프로젝트를 다른조직 B
의 그룹 또는 프로젝트와 공유할 수 없습니다. -
시스템 노트: 사용자들은
조직 A
의 이슈에 시스템 노트가 추가되지 않습니다. 이는조직 B
의 이슈에서 언급될 때에만 추가됩니다.
왜?
GitLab Cells은 조직을 샤딩 키로 사용하며, 이는 서로 다른 셀들 간에 데이터를 분할할 수 있게 해줍니다.
최초에는 조직을 배포할 때 단일 셀 셀 1
에서 작업할 것입니다.
셀 1
은 현재의 GitLab.com 배포입니다.
새로 생성된 조직들은 셀 1
에 생성됩니다.
셀 배포가 준비되면 셀 2
를 배포하고 셀 1
에서 셀 2
로 조직을 이관하기 시작할 것입니다.
워크로드를 이관하는 것은 서버의 플릿에서 데이터를 재배치하고 최종적으로 훨씬 작은 GitLab 인스턴스(및 데이터베이스)를 실행할 수 있도록 하는 데 중요합니다.
오늘날이라면 사용자들이 다른 조직으로 이동할 때 갑작스럽게 이러한 링크들이 깨지게 될 것입니다(다른 조직에 대해 알지 못하기 때문에). 따라서 우리는 조직이 동일한 셀에 있을 때에도 조직 경계를 넘는 어떠한 링크도 생성할 수 없도록 고객에게 조직을 롤아웃하기 시작하는 순간부터 보장해야 합니다. 그렇지 않을 경우, 셀 간에 이동할 수 없는 더 많은 혼합된 관련 데이터를 생성할 위험이 있습니다. 격리 요구 사항을 충족하지 않으면 실제로 샤딩 키로 사용될 수 없는 새로운 최상위 데이터 래퍼(조직)가 생성될 위험이 있습니다.
Cells 프로젝트는 초기에 최상위 그룹으로 샤딩할 수 있을 것으로 가정했습니다. 우리는 빠르게 애플리케이션에서 최상위 그룹을 격리하는 데 제약 사항이 없음을 깨달았습니다. 많은 사용자(우리 자신 포함)가 여러 최상위 그룹을 생성하고 그들 사이에 데이터를 연결했습니다. 따라서 우리는 실제로 최상위 그룹 주위에 또 다른 래퍼를 생성하는 것이 유일한 타당한 샤딩 키를 만드는 유일한 방법이라고 결정했습니다. 조직은 이미 우리 고객들이 관리 기능을 더 확대하려고 했던 것이며, 여러 최상위 그룹에 걸쳐 데이터를 집계하려고 했던 것이기 때문에 이것은 논리적인 선택이 되었습니다. 다시 한 번, 이것은 우리가 최상위 그룹과 같은 방식으로 여러 조직을 헷갈리게 허용해서는 안 된다는 것을 깨닫게 합니다. 그렇지 않으면 우리는 처음에 있었던 곳으로 되돌아가게 될 것입니다.
어떻게?
강력한 개발자를 위한 제약 사항과 고객을 위한 제약 사항을 제공할 것이라는 것을 증명하기 위해 여러 POCs가 구현되었습니다. 이들은 다음과 같습니다:
- 모든 테이블의
project_id
및namespace_id
열을 기반으로 조직 격리 강제 - 모든 테이블의
organization_id
를 기반으로 조직 격리 강제 - 최상위 그룹이 조직으로 이동되는 것이 격리되었는지 확인
이들 POC가 극복하려고 하고 있는 주요 제약 사항은 GitLab 애플리케이션이나 데이터베이스에서 아무 테이블이나 행이 어떤 조직(또는 프로젝트 또는 네임스페이스)에 속하는지 식별할 수 있는 표준 방법이 없다는 것입니다. 첫 번째 단계는 데이터베이스 모델의 모든 테이블에서 유효한 샤딩 키를 포함하는 표준 방법을 구현하는 것입니다.
제안된 솔루션은 gitlab_main_cell
, gitlab_ci
및 gitlab_pm
(셀 로컬) 데이터베이스에 있는 모든 테이블이 projects
, namespaces
또는 organizations
을 참조하는 유효한 샤딩 키를 포함하도록 하는 것입니다.
처음에는 모든 것에 organization_id
를 강제해야 한다고 생각했지만, 기본 조직에서 큰 그룹을 이동해야 하는 고객들에게 비용이 너무 많이 들 것으로 판명되었습니다.
추가적인 혜택은 우리 테이블 중 절반 이상이 이미 이러한 열 중 하나를 보유하고 있다는 것입니다.
게다가 만약 최상위 그룹에 데이터를 일관되게 할당할 수 없다면, 새로운 조직로 이동할 수 있는지를 확인할 수 없을 것입니다.
일단 일관된 샤딩 키를 가지면 이것들을 사용하여 삽입된 데이터가 어떠한 조직 경계를 넘지 않도록 유효성을 검사할 수 있습니다. 또한 이러한 샤딩 키를 사용하여 다음과 같은 사항을 결정할 수 있습니다:
- 기본 조직의 기존 네임스페이스가 이미 격리되어 새로운 조직으로 안전하게 이동될 수 있는지
- 네임스페이스 소유자가 새로운 조직으로 이관하기 전에 몇 가지 링크를 제거해야 하는지
- 여러 네임스페이스가 그룹으로 격리되어 있고 새로운 조직으로 대량 이관될 수 있는지
자세한 단계
- 이러한 샤딩 키를 추가해야 하는 요구 사항과 어떻게 선택해야하는지에 대해 개발자를 대상으로 한 문서를 구현하세요.
-
db/docs
에 샤딩 키를 선언할 수 있는 방법을 추가하고 이미 존재하는 테이블에 대하여 자동으로 채워넣기 - CI 파이프라인 및/또는 DB 마이그레이션에서 샤딩 키가 없을 경우 새로운 테이블을 만들지 못하도록 하는 자동화를 구현하세요.
-
db/docs
에서 원하는 샤딩 키 및 이를 마이그레이션하는 부모 테이블의 경로를 선언할 수 있는 방안을 구현하세요. 샤딩 키가 없는 테이블에 대해서만 임시로 필요할 것입니다. - 가능한 많은 “원하는 샤딩 키”를 자동으로 채우려고 노력하고 다른 팀에 MR을 위임하세요.
- 나머지 “원하는 샤딩 키”를 매뉴얼으로 채우도록 다른 팀에 이슈를 확장해주세요
- 남은 테이블에 대한 샤딩 키를 매뉴얼으로 만들고 자동화하기 시작하세요
- 모든 테이블이 샤딩 키 또는 “원하는 샤딩 키”를 가지고 있으면, 새롭게 삽입된 데이터가 조직 경계를 넘지 못하도록 강제할 POC의 확대된 버전을 출시할 것입니다. 이렇게 하려면 외래 키 이상의 것에 대해서 확장할 필요가 있을 수 있으며, 모델에 설명된 모든 관계 또한 포함되어야 합니다. 이를 위해 런타임에서 “원하는 샤딩 키”로부터 샤딩 키를 유추하지만 모든 테이블에 샤딩 키를 후행 채워야 하는 경우가 있으므로 성능이 좋지 않을 수 있지만 격리 규칙과 격리의 사용자 경험을 구현하는 데 장애를 제거할 수 있습니다.
- 대략 300개의 테이블이 누락된 샤딩 키를 마이그레이션 완료:
- 테넌트 스케일 팀은 처음 몇 개의 테이블을 마이그레이션합니다.
- 진행 내역을 보여주는 대시보드를 작성하고 자동으로 유추될 수 있는 샤딩 키에 대한 자동화된 MR을 계속 만들고 자동으로 유추할 수 없는 모든 샤딩 키에 대한 문제를 자동화함
- 모든 셀 로컬 테이블의 기존 샤딩 키 열이 신뢰할 수 있는 샤딩 키로 가정될 수 있는지 확인하도록 검증하세요. 이것은 이러한 열이 실제로 다른 목적으로 사용되지 않고 있음을 확인하는 팀에 이슈를 할당하는 것을 필요로 할 것입니다.
- 고객들이 새로운 조직을 생성하지만 네임스페이스를 이동하도록 선택할 수 없도록 허용해주세요. 모든 네임스페이스는 새로운 조직에서 새롭게 생성되어야 합니다.
- POC와 유사한 GitLab의 새로운 기능, 네임스페이스 소유자가 자신의 네임스페이스가 완전히 격리되었는지를 확인할 수 있게 함
- 네임스페이스 소유자가 기존의 네임스페이스를 한 조직에서 다른 조직으로 이관할 수 있도록 하는 기능 구현. 아마도 이전 단계에서 구현된 것과 같이 기존 고객들이 기본 조직에서 새롭게 생성된 조직으로 네임스페이스를 이관하길 원할 것입니다. 이전 단게에서 구현된 것처럼 격리된 네임스페이스만을 이동할 수 있을 것입니다.
- 네임스페이스가 격리되어 있는지를 확인하는 기능을 확장하여 사용자가 소유한 여러 네임스페이스를 선택하고 해당 선택된 그룹의 네임스페이스가 격리되어 있는지를 확인할 수 있게 함. 선택된 네임스페이스들 간의 링크는 유지될 것입니다.
- 네임스페이스 소유자가 한 조직에서 다른 조직으로 여러 기존의 네임스페이스를 이관할 수 있는 기능을 구현. 이전 단계에서 구현된 것처럼 격리된 네임스페이스만을 이동할 수 있을 것입니다.
- 고객이 새로운 조직으로의 이관을 위해 불필요한 링크 정리를 도와주기 위한 더 나은 도구를 구현함. 이 단계는 실제로 정리할 링크가 있는 몇몇 고객에 의존할 것입니다.
이러한 노력의 구현은 #11670에서 추적될 것입니다.
고려된 대안
조직 간에 교차해야 하는 모든 데이터를 클러스터 전체 테이블로 추가
Cells 아키텍처에서 클러스터 수준의 일부 데이터(예: 사용자)를 계획 중이므로, 조직 간 경계를 넘어야 하는 모든 데이터를 클러스터 전체로 만들 수 있을 것으로 보입니다. 이를 통해 문제를 해결할 수 있을 것입니다.
이는 일부 기능의 옵션으로 선택될 수 있으며, 일부 중요한 워크플로에 대해 필요할 수 있습니다. 그러나 이것이 기본 옵션으로 채택되어서는 안 됩니다. 왜냐하면 이는 최종적으로 Cells 아키텍처가 수평 확장 목표를 달성하지 못하게 할 수 있기 때문입니다. 그룹을 다른 그룹과 공유하는 기능과 같은 기능은 우리의 응용 프로그램에서 확장성과 관련하여 가장 성능이 좋지 않은 기능과 매우 긴밀하게 연결되어 있습니다. Cells로 데이터베이스를 분할함으로써 더 많은 확장 여유 공간을 확보하고 이러한 기능을 지원하는 데 관련된 문제를 줄일 수 있기를 희망합니다.
이상 현상을 접근할 필요가 없고 수용 가능한 예외 사항으로 취급
이 아이디어는 깊이 탐구되지 않았으며, 이상 현상은 고객 데이터를 셀 간에 이동하는 동안 데이터 유실로 나타날 것이고, 이는 수용 가능한 예외 사항으로 거부됩니다. 데이터 유실은 특히 고객이 서버 간 이동을 선택하지 않을 때 매우 심각한 종류의 버그입니다.
문제를 기능별로 해결
예를 들어, 서로 다른 조직 간에 프로젝트 사이의 이슈 링크 추가를 방지하는 애플리케이션 규칙을 구현함으로써 이것이 가능할 수 있습니다. 우리는 팀에게 물어서 이러한 기능을 모두 찾아야하며, 그들은 이 모든 기능을 특수한 경우의 비즈니스 규칙으로 수정해야 할 것입니다.
이것은 덜 견고한 옵션이 될 수 있지만, 시스템에 대한 신뢰를 많이 주지는 않습니다. 모든 조직 데이터가 격리되었음을 보장할 견고한 방법이 없다면, 우리는 구현하는 각 기능이 매뉴얼으로 확인되었음을 신뢰해야 합니다. 이는 우리가 무언가를 놓치는 실제 위험을 만들어내며, 다시 한 번 고객 데이터 유실 문제가 발생할 것입니다. 또 다른 도전 과제는 격리 제약 조건에 대해 자신감이 없다면 우리가 가능한 데이터 유실로 이어질 수 있는 다양한 관련 없는 버그들을 가능성이 있다고 생각하게 됩니다. 따라서 서로 관련이 없는 여러 버그를 디버깅하기 위해 토끼굴이 될 수 있습니다.