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의 많은 기능들이 데이터를 연결할 수 있습니다. 조직 격리로 금지되는 몇 가지 예시는 다음과 같습니다:

  1. 관련 이슈: 사용자들은 조직 A의 프로젝트에서 발생한 이슈를 조직 B의 프로젝트의 다른 이슈에 연결할 수 없습니다.
  2. 프로젝트 또는 그룹을 그룹과 공유: 사용자들은 조직 A의 그룹이나 프로젝트를 다른 조직 B의 그룹 또는 프로젝트와 공유할 수 없습니다.
  3. 시스템 노트: 사용자들은 조직 A의 이슈에 시스템 노트가 추가되지 않습니다. 이는 조직 B의 이슈에서 언급될 때에만 추가됩니다.

왜?

GitLab Cells은 조직을 샤딩 키로 사용하며, 이는 서로 다른 셀들 간에 데이터를 분할할 수 있게 해줍니다. 최초에는 조직을 배포할 때 단일 셀 셀 1에서 작업할 것입니다. 셀 1은 현재의 GitLab.com 배포입니다. 새로 생성된 조직들은 셀 1에 생성됩니다. 셀 배포가 준비되면 셀 2를 배포하고 셀 1에서 셀 2로 조직을 이관하기 시작할 것입니다. 워크로드를 이관하는 것은 서버의 플릿에서 데이터를 재배치하고 최종적으로 훨씬 작은 GitLab 인스턴스(및 데이터베이스)를 실행할 수 있도록 하는 데 중요합니다.

오늘날이라면 사용자들이 다른 조직으로 이동할 때 갑작스럽게 이러한 링크들이 깨지게 될 것입니다(다른 조직에 대해 알지 못하기 때문에). 따라서 우리는 조직이 동일한 셀에 있을 때에도 조직 경계를 넘는 어떠한 링크도 생성할 수 없도록 고객에게 조직을 롤아웃하기 시작하는 순간부터 보장해야 합니다. 그렇지 않을 경우, 셀 간에 이동할 수 없는 더 많은 혼합된 관련 데이터를 생성할 위험이 있습니다. 격리 요구 사항을 충족하지 않으면 실제로 샤딩 키로 사용될 수 없는 새로운 최상위 데이터 래퍼(조직)가 생성될 위험이 있습니다.

Cells 프로젝트는 초기에 최상위 그룹으로 샤딩할 수 있을 것으로 가정했습니다. 우리는 빠르게 애플리케이션에서 최상위 그룹을 격리하는 데 제약 사항이 없음을 깨달았습니다. 많은 사용자(우리 자신 포함)가 여러 최상위 그룹을 생성하고 그들 사이에 데이터를 연결했습니다. 따라서 우리는 실제로 최상위 그룹 주위에 또 다른 래퍼를 생성하는 것이 유일한 타당한 샤딩 키를 만드는 유일한 방법이라고 결정했습니다. 조직은 이미 우리 고객들이 관리 기능을 더 확대하려고 했던 것이며, 여러 최상위 그룹에 걸쳐 데이터를 집계하려고 했던 것이기 때문에 이것은 논리적인 선택이 되었습니다. 다시 한 번, 이것은 우리가 최상위 그룹과 같은 방식으로 여러 조직을 헷갈리게 허용해서는 안 된다는 것을 깨닫게 합니다. 그렇지 않으면 우리는 처음에 있었던 곳으로 되돌아가게 될 것입니다.

어떻게?

강력한 개발자를 위한 제약 사항과 고객을 위한 제약 사항을 제공할 것이라는 것을 증명하기 위해 여러 POCs가 구현되었습니다. 이들은 다음과 같습니다:

  1. 모든 테이블의 project_id 및 namespace_id 열을 기반으로 조직 격리 강제
  2. 모든 테이블의 organization_id를 기반으로 조직 격리 강제
  3. 최상위 그룹이 조직으로 이동되는 것이 격리되었는지 확인

이들 POC가 극복하려고 하고 있는 주요 제약 사항은 GitLab 애플리케이션이나 데이터베이스에서 아무 테이블이나 행이 어떤 조직(또는 프로젝트 또는 네임스페이스)에 속하는지 식별할 수 있는 표준 방법이 없다는 것입니다. 첫 번째 단계는 데이터베이스 모델의 모든 테이블에서 유효한 샤딩 키를 포함하는 표준 방법을 구현하는 것입니다.

제안된 솔루션은 gitlab_main_cell, gitlab_ci 및 gitlab_pm (셀 로컬) 데이터베이스에 있는 모든 테이블이 projects, namespaces 또는 organizations을 참조하는 유효한 샤딩 키를 포함하도록 하는 것입니다. 처음에는 모든 것에 organization_id를 강제해야 한다고 생각했지만, 기본 조직에서 큰 그룹을 이동해야 하는 고객들에게 비용이 너무 많이 들 것으로 판명되었습니다. 추가적인 혜택은 우리 테이블 중 절반 이상이 이미 이러한 열 중 하나를 보유하고 있다는 것입니다. 게다가 만약 최상위 그룹에 데이터를 일관되게 할당할 수 없다면, 새로운 조직로 이동할 수 있는지를 확인할 수 없을 것입니다.

일단 일관된 샤딩 키를 가지면 이것들을 사용하여 삽입된 데이터가 어떠한 조직 경계를 넘지 않도록 유효성을 검사할 수 있습니다. 또한 이러한 샤딩 키를 사용하여 다음과 같은 사항을 결정할 수 있습니다:

  • 기본 조직의 기존 네임스페이스가 이미 격리되어 새로운 조직으로 안전하게 이동될 수 있는지
  • 네임스페이스 소유자가 새로운 조직으로 이관하기 전에 몇 가지 링크를 제거해야 하는지
  • 여러 네임스페이스가 그룹으로 격리되어 있고 새로운 조직으로 대량 이관될 수 있는지

자세한 단계

  1. 이러한 샤딩 키를 추가해야 하는 요구 사항과 어떻게 선택해야하는지에 대해 개발자를 대상으로 한 문서를 구현하세요.
  2. db/docs에 샤딩 키를 선언할 수 있는 방법을 추가하고 이미 존재하는 테이블에 대하여 자동으로 채워넣기
  3. CI 파이프라인 및/또는 DB 마이그레이션에서 샤딩 키가 없을 경우 새로운 테이블을 만들지 못하도록 하는 자동화를 구현하세요.
  4. db/docs에서 원하는 샤딩 키 및 이를 마이그레이션하는 부모 테이블의 경로를 선언할 수 있는 방안을 구현하세요. 샤딩 키가 없는 테이블에 대해서만 임시로 필요할 것입니다.
  5. 가능한 많은 “원하는 샤딩 키”를 자동으로 채우려고 노력하고 다른 팀에 MR을 위임하세요.
  6. 나머지 “원하는 샤딩 키”를 매뉴얼으로 채우도록 다른 팀에 이슈를 확장해주세요
  7. 남은 테이블에 대한 샤딩 키를 매뉴얼으로 만들고 자동화하기 시작하세요
  8. 모든 테이블이 샤딩 키 또는 “원하는 샤딩 키”를 가지고 있으면, 새롭게 삽입된 데이터가 조직 경계를 넘지 못하도록 강제할 POC의 확대된 버전을 출시할 것입니다. 이렇게 하려면 외래 키 이상의 것에 대해서 확장할 필요가 있을 수 있으며, 모델에 설명된 모든 관계 또한 포함되어야 합니다. 이를 위해 런타임에서 “원하는 샤딩 키”로부터 샤딩 키를 유추하지만 모든 테이블에 샤딩 키를 후행 채워야 하는 경우가 있으므로 성능이 좋지 않을 수 있지만 격리 규칙과 격리의 사용자 경험을 구현하는 데 장애를 제거할 수 있습니다.
  9. 대략 300개의 테이블이 누락된 샤딩 키를 마이그레이션 완료:
    1. 테넌트 스케일 팀은 처음 몇 개의 테이블을 마이그레이션합니다.
    2. 진행 내역을 보여주는 대시보드를 작성하고 자동으로 유추될 수 있는 샤딩 키에 대한 자동화된 MR을 계속 만들고 자동으로 유추할 수 없는 모든 샤딩 키에 대한 문제를 자동화함
  10. 모든 셀 로컬 테이블의 기존 샤딩 키 열이 신뢰할 수 있는 샤딩 키로 가정될 수 있는지 확인하도록 검증하세요. 이것은 이러한 열이 실제로 다른 목적으로 사용되지 않고 있음을 확인하는 팀에 이슈를 할당하는 것을 필요로 할 것입니다.
  11. 고객들이 새로운 조직을 생성하지만 네임스페이스를 이동하도록 선택할 수 없도록 허용해주세요. 모든 네임스페이스는 새로운 조직에서 새롭게 생성되어야 합니다.
  12. POC와 유사한 GitLab의 새로운 기능, 네임스페이스 소유자가 자신의 네임스페이스가 완전히 격리되었는지를 확인할 수 있게 함
  13. 네임스페이스 소유자가 기존의 네임스페이스를 한 조직에서 다른 조직으로 이관할 수 있도록 하는 기능 구현. 아마도 이전 단계에서 구현된 것과 같이 기존 고객들이 기본 조직에서 새롭게 생성된 조직으로 네임스페이스를 이관하길 원할 것입니다. 이전 단게에서 구현된 것처럼 격리된 네임스페이스만을 이동할 수 있을 것입니다.
  14. 네임스페이스가 격리되어 있는지를 확인하는 기능을 확장하여 사용자가 소유한 여러 네임스페이스를 선택하고 해당 선택된 그룹의 네임스페이스가 격리되어 있는지를 확인할 수 있게 함. 선택된 네임스페이스들 간의 링크는 유지될 것입니다.
  15. 네임스페이스 소유자가 한 조직에서 다른 조직으로 여러 기존의 네임스페이스를 이관할 수 있는 기능을 구현. 이전 단계에서 구현된 것처럼 격리된 네임스페이스만을 이동할 수 있을 것입니다.
  16. 고객이 새로운 조직으로의 이관을 위해 불필요한 링크 정리를 도와주기 위한 더 나은 도구를 구현함. 이 단계는 실제로 정리할 링크가 있는 몇몇 고객에 의존할 것입니다.

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

고려된 대안

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

Cells 아키텍처에서 클러스터 수준의 일부 데이터(예: 사용자)를 계획 중이므로, 조직 간 경계를 넘어야 하는 모든 데이터를 클러스터 전체로 만들 수 있을 것으로 보입니다. 이를 통해 문제를 해결할 수 있을 것입니다.

이는 일부 기능의 옵션으로 선택될 수 있으며, 일부 중요한 워크플로에 대해 필요할 수 있습니다. 그러나 이것이 기본 옵션으로 채택되어서는 안 됩니다. 왜냐하면 이는 최종적으로 Cells 아키텍처가 수평 확장 목표를 달성하지 못하게 할 수 있기 때문입니다. 그룹을 다른 그룹과 공유하는 기능과 같은 기능은 우리의 응용 프로그램에서 확장성과 관련하여 가장 성능이 좋지 않은 기능과 매우 긴밀하게 연결되어 있습니다. Cells로 데이터베이스를 분할함으로써 더 많은 확장 여유 공간을 확보하고 이러한 기능을 지원하는 데 관련된 문제를 줄일 수 있기를 희망합니다.

이상 현상을 접근할 필요가 없고 수용 가능한 예외 사항으로 취급

이 아이디어는 깊이 탐구되지 않았으며, 이상 현상은 고객 데이터를 셀 간에 이동하는 동안 데이터 유실로 나타날 것이고, 이는 수용 가능한 예외 사항으로 거부됩니다. 데이터 유실은 특히 고객이 서버 간 이동을 선택하지 않을 때 매우 심각한 종류의 버그입니다.

문제를 기능별로 해결

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

이것은 덜 견고한 옵션이 될 수 있지만, 시스템에 대한 신뢰를 많이 주지는 않습니다. 모든 조직 데이터가 격리되었음을 보장할 견고한 방법이 없다면, 우리는 구현하는 각 기능이 매뉴얼으로 확인되었음을 신뢰해야 합니다. 이는 우리가 무언가를 놓치는 실제 위험을 만들어내며, 다시 한 번 고객 데이터 유실 문제가 발생할 것입니다. 또 다른 도전 과제는 격리 제약 조건에 대해 자신감이 없다면 우리가 가능한 데이터 유실로 이어질 수 있는 다양한 관련 없는 버그들을 가능성이 있다고 생각하게 됩니다. 따라서 서로 관련이 없는 여러 버그를 디버깅하기 위해 토끼굴이 될 수 있습니다.