This page contains information related to upcoming products, features, and functionality. It is important to note that the information presented is for informational purposes only. Please do not rely on this information for purchasing or planning purposes. The development, release, and timing of any products, features, or functionality may be subject to change or delay and remain at the sole discretion of GitLab Inc.

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는 조직을 샤딩 키로 사용하는 것에 의존하며, 이를 통해 데이터를 다른 셀 간에 분산시킬 수 있게 됩니다. 초기에 조직을 배포할 때에는 현재 GitLab.com 배포인 Cell 1에서 작업할 것입니다. 새롭게 생성된 조직은 Cell 1에 만들어질 것입니다. 셀이 준비되면 Cell 2를 배포하고 Cell 1에서 조직을 Cell 2로 이전하기 시작할 것입니다. 작업량을 이동하는 것은 저희가 데이터를 서버 플리트에 걸쳐 다시 균형을 맞출 수 있게 해주는 중요한 것입니다. 그리고 결국 훨씬 더 작은 GitLab 인스턴스(및 데이터베이스)를 실행할 수 있게 될 것입니다.

오늘날, 우리가 사용자에게 다른 조직의 데이터에 연결할 수 있는 조직을 생성하도록 허용한다면, 이러한 링크들은 조직이 다른 셀로 이동할 때(다른 조직이 없기 때문에) 갑자기 깨지게 될 것입니다. 그 이유 때문에 우리는 사용자들이 아직 같은 셀에 있는 조직일지라도 조직 경계를 넘어가는 어떠한 링크도 생성할 수 없도록 처음부터 조직을 고객들에게 전파해야 합니다. 그렇지 않으면, 우리는 셀 간에 이동할 수 없는 혼재된 관련 데이터를 더 많이 만들게 되며 그 요구 사항을 충족시키지 못한다면, 우리는 실제로 샤딩 키로서 사용될 수 없는 새로운 최상위 데이터 래퍼인 조직을 만들어 낼 위험에 빠지게 됩니다.

Cells 프로젝트는 초반에 최상위 그룹을 샤딩할 수 있을 것이라는 가정으로 시작되었습니다. 우리는 빠르게 알게 되었습니다. 응용 프로그램에서 최상위 그룹을 격리시키는 제약 조건이 없다는 것을 꽤 빨리 깨달았습니다. 많은 사용자(우리를 포함하여)가 여러 최상위 그룹을 만들고 이를 통해 데이터를 서로 연결한 것이었습니다. 그래서 우리는 유일한 샤딩 키를 만드는 것이 가능한 유일한 방법은 최상위 그룹을 둘러싼 또 다른 래퍼를 생성하는 것이라고 결정하였습니다. 조직은 이미 우리 고객들이 원하던 더 많은 관리 기능을 얻기 위해 존재하였고, 여러 최상위 그룹을 걸쳐 데이터를 집계하려고 하는 것이었습니다. 그래서 이가 합리적인 선택이 되었습니다. 다시 말해서, 이는 우리가 최상위 그룹에서 한 것과 같은 방식으로 여러 조직들을 얽히게 두려고 할 수 없음을 깨달으킨다.

어떻게?

우리는 더 강력한 개발자를 향한 제약조건과 고객을 대상으로한 여러 가지 POC(Proof of Concept)를 제공하겠다는 것을 증명하기 위해 여러 POC가 구현되었습니다. GitLab 애플리케이션 및 데이터베이스에서 설명된 격리 제약을 강제하는데 있어.

이것들은 다음과 같습니다.

이 POC들이 극복하려고 하는 주요 제약 조건은 GitLab 애플리케이션 또는 데이터베이스에 데이터가 속한 조직(또는 프로젝트 또는 네임스페이스)를 식별하는 표준 방법조차 없다는 것입니다. 이는 첫 번째 단계가 데이터베이스에서 모델이나 행에 대한 부상위 조직을 효율적으로 찾기 위한 표준 방법을 구현하는 것입니다.

제안된 솔루션은 ‘gitlab_main_cell’, ‘gitlab_ci’ 및 ‘gitlab_pm’(셀 로컬) 데이터베이스에 존재하는 모든 테이블이 projects, namespaces 또는 organizations에 대한 참조인 유효한 샤딩 키를 포함하도록 하는 것입니다. 처음에는 모든 것에 organization_id를 강제하려고 고려하였으나, 기본 조직에서 큰 그룹을 이전해야 하는 고객에게는 너무 비용이 많이 들 것이라고 결정하였습니다. 추가적인 이점은 절반 이상의 테이블이 이미 이러한 열 중 하나를 가지고 있다는 것입니다. 또한, 최상위 그룹에 일관된 데이터를 적용할 수 없다면 새로운 조직으로 이동해야 하는 최상위 그룹을 확인할 수 없을 것이기 때문에 이 또한 이를 추가합니다.

일단 우리가 일관된 샤딩 키를 갖게 되면 이를 사용하여 삽입된 모든 데이터가 어떠한 조직 경계도 넘어가지 않는지를 검증할 수 있게 됩니다. 우리는 또한 이러한 샤딩 키를 사용하여 다음을 결정할 수 있게 됩니다.

기존 기본 조직의 네임스페이스가 이미 격리되어 있기 때문에 안전하게 새 조직으로 마이그레이션될 수 있는지 여부
네임스페이스 소유자가 새 조직으로 마이그레이션하기 전에 어떤 링크를 제거해야 하는지 유효성을 검사할 필요
하나의 그룹으로 격리된 일련의 네임스페이스가 한 그룹으로 함께 대량 이동될 수 있는지 여부

상세 단계

이러한 샤딩 키를 추가해야 하는 요구사항 및 선택 방법에 대해 설명하는 개발자용 설명서를 구현합니다.
db/docs에 샤딩 키를 선언하고 이미 샤딩 키를 가지고 있는 모든 테이블에 자동으로 채우는 방법을 추가합니다.
CI 파이프라인 및/또는 DB 마이그레이션에서 샤딩 키를 갖지 않는 새로운 테이블을 생성하지 못하도록 하는 자동화를 구현합니다.
db/docs에서 원하는 샤딩 키와 그것이 이전된 부모 테이블에 대한 경로를 선언하는 방법을 추가합니다. 이는 임시적으로 샤딩 키가 없는 테이블에만 필요합니다.
가능한 최대한 “원하는 샤딩 키”를 자동으로 채우려고 시도하고 MR을 다른 팀에 넘깁니다.
나머지 “원하는 샤딩 키”를 매뉴얼으로 채우려고 다른 팀에 이슈를 만들고 추가합니다.
후에 이슈를 번지하여 남은 “원하는 샤딩 키”를 매뉴얼으로 채워서 마이그레이션을 시작하고 자동화합니다.
모든 테이블에 샤딩 키 또는 “원하는 샤딩 키”를 적용한 후에, 새롭게 삽입된 데이터가 어떠한 조직 경계도 넘어가지 못하도록 강제할 POC의 진화된 버전을 출시합니다. 이는 외래 키 이상의 것에 확장할 수도 있으며, 모델에서 설명된 관계도 포함해야 합니다. 이는 일시적으로 런타임에서 “원하는 샤딩 키”로부터 샤딩 키를 추론할 수는 있지만, 이는 모든 테이블에 샤딩 키를 백필하는 동안 less performant한 옵션이 될 것이며 우리에게 이를 차단하는데 도움을 줄 수 있을 것이다.
샤딩 키가 누락된 ~300개의 테이블의 마이그레이션을 완료합니다:
1. Tenant Scale 팀은 처음 몇 개의 테이블을 마이그레이션합니다.
2. 우리는 진행 사항을 보여주는 대시보드를 만들고 자동으로 추론할 수 있는 샤딩 키에 대한 자동 MR을 계속 만들고 추론할 수 없는 모든 샤딩 키에 대한 이슈를 자동화합니다.
모든 셀 로컬 테이블의 기존 샤딩 키 열이 신뢰할 수 있는지 확인합니다. 이는 이러한 열이 실제로 적절하지 않을 용도에 사용되지는 않았는지 확인하기 위해 팀에 이슈를 할당하여 확인하는 것을 필요로 합니다.
고객들이 새로운 조직을 만들 수 있도록 하되 네임스페이스를 마이그레이션할 수 있는 옵션은 제외합니다. 모든 네임스페이스는 새로운 조직에서 새롭게 만들어져야 합니다.
POC과 유사한 GitLab의 새 기능을 구현합니다. 이것은 네임스페이스 소유자가 그들의 네임스페이스가 완전히 격리되었는지 볼 수 있는 기능을 허용합니다.
네임스페이스 소유자가 기존 네임스페이스를 하나의 조직에서 다른 조직으로 마이그레이션할 수 있게 하는 기능을 구현합니다. 아마도 이것은 이전 단계에서 구현된 격리된 네임스페이스의 존재 여부에 따라 가능하게 될 것입니다.
네임스페이스가 격리되어 있는지 유효성을 검사할 수 있는 기능을 확장하여 사용자가 소유한 여러 네임스페이스를 선택하고 선택한 네임스페이스 그룹이 격리되어 있는지를 유효성을 검사할 수 있게 합니다. 선택된 네임스페이스들 간의 링크는 그대로 유지됩니다.
네임스페이스 소유자가 하나의 조직에서 다른 조직으로 여러 기존 네임스페이스를 마이그레이션할 수 있는 기능을 구현합니다. 이전 단계에서 구현된 격리된 네임스페이스만이 이동할 수 있을 것입니다.
우리는 여러 고객이 새로운 조직으로 마이그레이션할 수 있도록 사용하지 않는 링크를 정리하는 더 나은 도구를 개발합니다. 이 단계는 실제로 정리할 링크가 있는 몇몇 기존 고객에 의존합니다.

이러한 노력의 구현은 #11670에서 추적될 것입니다.

고려된 대안

조직간에 교차해야 하는 데이터를 클러스터 전체 테이블로 추가

우리는 셀 아키텍처에서 클러스터 수준의 데이터(예: 사용자)를 가질 계획이므로, 조직 경계를 넘나드는 필요가 있는 데이터를 클러스터 전체로 만들 수 있을 것으로 보입니다. 이것은 문제를 해결할 수 있는 옵션이 될 수 있습니다.

이것은 일부 기능에 대한 제한된 옵션이 될 수 있으며 일부 중요한 워크플로에 필수적일 수 있습니다. 그러나 이것이 기본 옵션으로 채택되어서는 안 되며, 그렇게 되면 결국 셀 아키텍처의 수평 확장 목표를 달성하지 못하게 될 것입니다. 그룹을 다른 그룹과 공유하는 등의 기능은 적용될 때 우리 애플리케이션에서 성능이 최악으로 나타날 수 있는 기능들과 밀접하게 관련되어 있습니다. 우리는 셀에 데이터베이스를 분할하여 확장 여유 공간을 늘리고 이러한 기능들을 지원하는 데 발생하는 문제를 줄일 수 있기를 희망합니다.

아무것도 하지 않고, 이상 현상을 허용 가능한 예외 사례로 취급하기

이 아이디어는 깊게 탐구되지 않았지만, 고객 데이터를 셀 간에 이동할 때 이러한 이상 현상이 데이터 손실로 나타날 것으로 기각되었습니다. 데이터 손실은 특히 고객들이 서버 간 이동에 동의하지 않을 때 매우 심각한 종류의 버그입니다.

문제별로 이러한 문제들을 해결하기

예를 들어, 서로 다른 조직에 속한 프로젝트 간에 이슈 링크를 추가하는 것을 방지하는 애플리케이션 규칙을 구현함으로써 이것이 가능할 수 있습니다. 우리는 팀들에게 문의하여 해당 기능을 찾아내야 하며, 그들은 이를 특수한 경우의 비즈니스 규칙으로 수정해야 할 것입니다.

이것은 신뢰할 만한, 덜 견고한 옵션일 수 있지만, 우리 시스템에 대한 신뢰를 크게 부여해주지는 않습니다. 모든 조직 데이터가 격리되었음을 보장할 수 있는 강력한 방법이 없다면, 우리는 구현하는 각 기능이 매뉴얼으로 점검되었음을 믿어야 합니다. 이로 인해 뭔가를 놓치게 될 실제 위험이 생깁니다. 또 다른 도전 과제는 우리 격리 제약 조건에 대해 확신이 없다면 다양한 관련 없는 버그들을 데이터 손실 가능성에 연결하게 될 수 있습니다. 따라서, 관련 없는 다양한 버그들을 디버깅하는 데 토끼굴이 될 수 있습니다.