• 무엇?
• 왜?
• 어떻게?
• 상세 단계
• 고려된 대안
  • 조직 간을 이동해야 하는 모든 데이터를 클러스터 전체 테이블에 추가
  • 아무것도 하지 않고 이러한 이상 현상을 수용 가능한 예외 사례로 취급
  • 각 기능별 문제 해결

조직 격리

이 청사진은 조직을 격리하는 요구 사항을 상세히 설명합니다. 비디오 소개를 시청하여 조직 격리가 무엇이며 왜 필요한지에 대한 요약을 확인하세요. 조직에 대해 더 읽어보세요.

무엇?

GitLab의 모든 셀 지역 데이터 및 기능(클러스터의 모든 셀에 존재해야 하는 몇 가지 사항을 제외한 모든 데이터)는 격리되어야 합니다. 격리란 데이터나 기능이 결코 조직 경계를 넘어서서는 안 된다는 것을 의미합니다. GitLab의 많은 기능은 데이터를 서로 연결할 수 있습니다. 조직 격리에 의해 금지되는 몇 가지 예는 다음과 같습니다.

1. 관련 이슈: 사용자는 조직 A의 프로젝트에서 이슈를 가져와 조직 B의 프로젝트의 다른 이슈와 관련시킬 수 없을 것입니다.
2. 프로젝트/그룹 공유: 사용자는 조직 A의 그룹 또는 프로젝트를 조직 B의 다른 그룹이나 프로젝트와 공유할 수 없을 것입니다.
3. 시스템 노트: 사용자는 조직 A의 이슈에 시스템 노트가 추가되지 않을 것입니다. 왜냐하면 이 이슈가 조직 B의 이슈의 코멘트에서 언급되었기 때문입니다.

왜?

GitLab Cells은 다른 셀 사이에 데이터를 분할할 수 있게 하는 조직을 샤딩 키로 사용합니다. 초기에는 조직을 롤아웃할 때, 우리는 단일 셀 셀 1과 함께 작업할 것입니다. 셀 1은 현재의 GitLab.com 배포입니다. 새로 생성된 조직은 셀 1에서 생성될 것입니다. 셀이 준비되면 셀 2를 배포하고 셀 1에서 조직을 셀 2로 이주하기 시작할 것입니다. 작업 부하를 이주하는 것은 우리에게 서버의 플릿 전체에 데이터를 다시 균형잡는 것과 최종적으로 훨씬 작은 GitLab 인스턴스(및 데이터베이스)를 실행하는 것을 가능하게 하는 데 중요합니다.

오늘날 우리가 사용자들이 다른 조직에서 데이터에 연결하도록 허용한다면, 이러한 링크들은 조직이 다른 셀로 이동될 때 갑자기 깨질 것입니다(왜냐하면 이러한 다른 조직에 대해 알지 못하기 때문입니다). 그래서 이 이유 때문에 당연히 조직이 여전히 같은 셀에 있는 경우에도 조직 경계를 교차하는 어떤 링크도 만들 수 없도록 고강도로 보장해야 합니다. 만약 이것을 하지 않는다면, 우리는 셀 사이에 이주할 수 없는 더 많이 혼란스러운 관련 데이터들을 생산할 것입니다. 격리 요구 사항을 충족시키지 않는다면, 실제로 샤딩 키로 사용할 수 없는 새로운 최상위 데이터 래퍼인 조직을 만드는 위험을 감수합니다.

Cells 프로젝트는 처음에 최상위 그룹으로 샤딩할 수 있을 것으로 가정했습니다. 우리는 빨리 최상위 그룹을 격리시키는 애플리케이션의 제약이 없음을 깨달았습니다. 많은 사용자(우리를 포함하여)가 여러 최상위 그룹을 생성하고 이들 사이에서 데이터를 연결했습니다. 그래서 우리는 샤딩 키를 만들기 위해 최상위 그룹 주변에 또 다른 래퍼를 만들어야 한다는 유일한 방법이라고 결정했습니다. 조직은 이미 우리 고객들이 원하던 것으로서, 자체 관리에서 가능한 더 많은 관리 기능과 여러 최상위 그룹 전체에서 데이터를 집계하려고 했습니다, 그래서 이것은 논리적인 선택이 되었습니다. 다시 말해, 이것은 우리에게 최상위 그룹과 같은 방식으로 여러 조직을 섞어 놓을 수 없는 것을 깨달았다는 여정으로 이끌었습니다. 그렇지 않으면 우리는 처음 시작한 곳으로 되돌아가게 될 것입니다.

어떻게?

GitLab 애플리케이션 및 데이터베이스에서 개발자를 향한 강력한 제한 및 설명된 격리 제약을 제공하는 방법을 보여주기 위해 여러 POC(Point of Contact)가 구현되었습니다. 이들은 다음과 같습니다.

1. 프로젝트_id 및 namespace_id 열을 기반으로 한 조직 격리 강제화
2. organization_id를 기반으로 한 조직 격리 강제화
3. 최상위 그룹이 조직으로 이주될 수 있는지 여부 확인

이들 POC가 극복하려고 했던 주된 제약은 GitLab 애플리케이션이나 데이터베이스에는 모델이나 행에 대해 부모 조직을 효율적으로 찾을 수 있는 표준적인 방법이 없다는 것이었습니다. 이는 가장 먼저 데이터베이스의 각 테이블이 gitlab_main_cell, gitlab_ci, gitlab_pm(셀 지역 데이터베이스)에 존재하는 모든 테이블이 projects, namespaces, organizations를 참조하는 유효한 샤딩 키를 포함하도록 하는 것입니다. 우리는 처음에 모든 것에게 organization_id를 부여하는 것을 고려했지만, 이는 기본 조직에서 큰 그룹을 이주해야 하는 고객들에게 비용이 너무 많이 들 것으로 판단했습니다. 추가된 혜택은 우리 테이블 중 절반 이상이 이미 이러한 열 중 하나를 가지고 있다는 것입니다. 게다가 만약 우리가 최상위 그룹에게 일관적으로 데이터를 할당하지 않는다면, 우리는 새로운 조직으로 이주할 수 있는 최상위 그룹을 확인하지 못할 것입니다.

일관된 샤딩 키가 있다면, 이들을 사용하여 삽입된 모든 데이터가 어떤 조직 경계도 넘지 않도록 유효성을 검사할 수 있습니다. 우리는 또한 이러한 샤딩 키를 사용하여 다음과 같이 결정할 수 있습니다.

• 기본 조직의 기존 네임스페이스가 이미 격리되었기 때문에 새로운 조직으로 안전하게 이주할 수 있는지 여부.
• 네임스페이스 소유자는 새로운 조직으로 이주하기 전에 어떤 링크를 제거해야 하는지.
• 일련의 네임스페이스가 그룹으로 격리되어 있고 대량으로 새로운 조직으로 이주될 수 있는지.

상세 단계

1. ‘db/docs’에 sharding 키를 추가하는 요구 사항을 설명하는 개발자를 위한 문서를 구현하고 어떻게 선택해야 하는지 설명합니다.
2. ‘db/docs’에 sharding 키를 선언하고 이미 sharding 키가 있는 모든 테이블에 자동으로 채워 넣는 방법을 추가합니다.
3. CI 파이프라인 및/또는 DB 마이그레이션에서 샤딩 키 없이 새 테이블을 생성할 수 없도록 자동화를 구현합니다.
4. 사람들이 ‘db/docs’에서 원하는 sharding 키를 선언할 수 있는 방법을 구현하고, 마이그레이션된 부모 테이블로의 경로도 추가합니다. 샤딩 키가 없는 테이블에 임시로 필요합니다.
5. 가능한 한 많은 “원하는 sharding key”를 자동화하여 MR(Merge Request)을 다른 팀에 위임합니다.
6. 다른 팀에 문제를 위임하여 “원하는 sharding key”를 수동으로 채웁니다.
7. 테이블의 샤딩 키를 채우는 마이그레이션을 수동으로 시작하고 자동화합니다.
8. 모든 테이블이 샤딩 키 또는 “원하는 sharding key”을 보유하면 제안서를 통해 새로운 데이터가 조직 경계를 넘을 수 없도록 하는 POC의 진화 버전을 출시합니다. 이는 외래 키 이상으로 확장되어 임시적으로 런타임에서 “원하는 sharding key”에서 sharding 키를 추론할 수 있도록 허용하며, 모든 테이블에 sharding 키를 백필할 동안 성능이 떨어질 수 있지만, 고립 규칙 및 고립 사용자 경험을 구현하는 데 방해를 제거할 수 있습니다.
9. 샤딩 키가 없는 약 300개의 테이블 마이그레이션 완료:
   1. 테넌트 스케일 팀이 처음 몇 개의 테이블을 마이그레이션합니다.
   2. 진행 상황을 보여주는 대시보드를 구축하고 자동으로 추론할 수 있는 sharding 키에 대한 자동화된 MR을 계속 생성하고 자동 생성할 수 없는 sharding 키에 대한 문제를 자동으로 생성합니다.
10. 모든 셀 로컬 테이블의 기존 sharding 키 열이 신뢰할 수 있는지 확인하는 검증을 완료합니다. 이를 위해 이러한 열이 실제로 적합하지 않은 다른 용도로 사용되지 않는지 확인하기 위해 팀에 이슈를 할당합니다.
11. 고객이 새로운 조직을 생성하는 데 네임스페이스를 마이그레이션할 수 없도록 허용합니다. 모든 네임스페이스는 새로운 조직에서 새로 생성되어야 합니다.
12. POC와 유사한 GitLab의 새로운 기능을 구현합니다. 이 기능을 통해 네임스페이스 소유자는 자신의 네임스페이스가 완전히 격리되었는지 확인할 수 있습니다.
13. 네임스페이스 소유자가 기존 네임스페이스를 한 조직에서 다른 조직으로 마이그레이션할 수 있는 기능을 구현합니다. 아마도 기존 고객이 기본 조직에서 자신의 네임스페이스를 새로 생성된 조직으로 마이그레이션하려는 경우일 것입니다. 이전 단계에서 구현된 고립된 네임스페이스만 이동할 수 있습니다.
14. 네임스페이스가 격리되었는지를 확인하는 기능을 확장하여 사용자가 소유한 여러 네임스페이스를 선택하고 선택한 네임스페이스 그룹이 격리되었는지를 확인할 수 있도록 합니다. 선택한 네임스페이스 간의 링크는 유지됩니다.
15. 네임스페이스 소유자가 기존의 여러 네임스페이스를 한 조직에서 다른 조직으로 마이그레이션할 수 있는 기능을 구현합니다. 이전 단계에서 구현된 고립된 네임스페이스만 이동할 수 있습니다.
16. 네임스페이스 소유자가 자신의 네임스페이스 외에 원치 않는 링크를 정리하는 데 도움이 되는 툴을 개발하여 더 많은 고객이 새 조직으로 마이그레이션할 수 있도록 합니다. 이 단계는 실제로 정리할 링크의 양에 따라 종속되어 있을 것입니다.

이 노력의 구현은 #11670에서 추적됩니다.

고려된 대안

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

Cells 아키텍처에서 클러스터 수준에 일부 데이터(예: 사용자)를 갖도록 계획하고 있으므로, 조직 간을 이동해야 하는 모든 데이터를 클러스터 전체로 만들 수 있습니다. 이것이 문제를 해결할 수 있습니다.

이것은 제한된 특정한 기능을 위해 선택할 수 있는 옵션이 될 수 있으며, 일부 중요한 워크플로에는 필요할 수 있습니다. 그러나 이것은 기본 옵션이 되어서는 안 되며, 이는 최종적으로 Cells 아키텍처가 수평 스케일링 목표를 달성하지 못하게 될 수 있기 때문입니다. 그룹을 다른 그룹과 공유하는 기능은 우리 애플리케이션에서 확장 가능성과 관련하여 가장 성능이슈가 심한 기능 중 일부와 매우 밀접하게 관련되어 있습니다. 셀로 데이터베이스를 분할함으로써 더 많은 스케일링 여유 공간을 확보하고 이러한 기능을 지원하는 데 관련된 문제를 줄이길 희망합니다.

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

이 아이디어는 심도 있게 탐구되지 않았지만, 이상 현상이 발생함에 따라 데이터 손실이 발생하며, 특히 고객들이 서버 간 이동에 동의하지 않는 경우에는 매우 심각한 버그입니다.

각 기능별 문제 해결

예를 들어, 서로 다른 조직의 프로젝트 사이에 이슈 링크를 추가하는 사용자를 막는 애플리케이션 규칙을 구현함으로서 이 문제를 해결할 수 있습니다. 우리는 팀에게 질문하여 이러한 기능을 모두 찾아야 하며, 그들은 모두 특수한 사례 비즈니스 규칙으로 수정해야 합니다.

이것은 실행 가능하고 견고하지 않은 옵션이 될 수 있지만, 우리 시스템에 대한 신뢰를 크게 높여주지는 않습니다. 모든 조직 데이터가 격리되었음을 보장하는 견고한 방법이 없다면, 우리가 구현하는 각 기능이 수동으로 확인되었음을 신뢰해야 합니다. 이는 무언가를 놓치는 실제 위험을 초래하며, 다시 고객 데이터 손실에 이를 수 있습니다. 여기에 또 다른 도전 과제는, 격리 제약 조건에 대한 신뢰가 부족하다면, 우리는 여러 가지 관련 없는 버그를 데이터 손실로 연결할 수도 있습니다. 따라서 이러한 문제 해결은 관련 없는 여러 버그를 디버깅하는 것으로 변할 수 있습니다.