| Status | Authors | Coach | DRIs | Owning Stage | Created |
|---|---|---|---|---|---|
| ongoing |
@lohrc
@alexpooley
|
@ayufan
|
@lohrc
| devops data stores | 2023-04-05 |
조직
이 문서는 진행 중인 작업이며 현재의 조직 디자인 상태를 나타냅니다.
용어
- 조직(Organization): 조직은 하나 이상의 최상위 그룹의 총괄입니다. 조직은 기본적으로 서로 격리되어 있으며, 크로스 네임스페이스 기능은 기본적으로 하나의 조직 내에 있는 네임스페이스에 대해서만 작동합니다.
-
최상위 그룹(Top-level Group): 최상위 그룹은 다른 모든 그룹의 최상위 그룹의 이름입니다. 그룹 및 프로젝트는 최상위 그룹 아래에 중첩됩니다.
- Cell: 셀(Cell)은 여러 조직을 포함하는 인프라 컴포넌트의 집합입니다. 셀에 제공된 인프라 컴포넌트는 조직간에 공유되지만 다른 셀과는 공유되지 않습니다. 이러한 인프라 컴포넌트의 격리로 인해 셀은 서로 독립적입니다.
- User: 조직은 여러 사용자를 보유합니다. 조직에 가입하면 해당 조직의 사용자가 됩니다.
- Member: 조직 내의 그룹이나 프로젝트에 사용자를 추가하면 그 사용자는 구성원이 됩니다. 구성원은 항상 사용자이지만 사용자는 조직 내의 그룹이나 프로젝트의 구성원이 될 필요는 없습니다. 예를 들어 사용자는 조직에 가입 초대를 수락했지만 해당 조직의 어떤 그룹이나 프로젝트의 구성원이 아닐 수 있습니다.
- Non-User: 조직의 비사용자는 해당 특정 조직의 일부가 아닌 사용자를 의미합니다. 비사용자는 조직의 공개 그룹 및 프로젝트와 상호 작용할 수 있으며 이에 대한 이슈를 제기하고 댓글을 남길 수 있습니다.
요약
조직은 다음과 같은 문제를 해결합니다:
- 최상위 그룹을 그루핑하는 기능을 제공합니다. 예를 들어, 아래의 최상위 그룹은
GitLab조직에 속할 것입니다:https://gitlab.com/gitlab-org/https://gitlab.com/gitlab-com/
- 다양한 조직을 격리하는 것을 가능하게 합니다. 동일한 조직의 최상위 그룹은 서로 상호 작용할 수 있지만 다른 조직의 그룹과는 상호 작용할 수 없도록 하여 조직에 명확한 경계를 제공합니다. 이는 Self-Managed형 인스턴스와 유사합니다. 격리는 성능과 가용성에 긍정적인 영향을 미치도록 설계되어 있습니다. 사용자 대시보드 등을 조직 범위로 설정할 수 있기 때문입니다.
- 셀과의 통합을 가능케 합니다. 조직을 격리하는 것은 서로 다른 셀에 할당하고 분배하는 것을 가능하게 합니다.
- 등급 체계를 정의하는 필요성을 제거합니다. 조직은 의미 있는 계층/엔티티 집합(조직, 최상위 그룹 등)으로 채워질 수 있는 컨테이너입니다.
- 사용자 프로필을 중앙에서 제어할 수 있도록 합니다. 조직별 사용자 프로필을 사용하여 관리자가 사용자의 회사 역할을 제어하거나 사용자 이메일을 강제할 수 있으며 사용자가 조직의 일부임을 시각적으로 나타낼 수 있습니다. 예를 들어 댓글에 “GitLab 직원” 스탬프를 추가하는 것 등이 있습니다.
- 조직은 GitLab.com에 온프레미스와 유사한 경험을 제공합니다. 조직 관리자는 대부분의 구성이 조직 수준에서 제어되는 인스턴스 동등한 관리자 영역 설정에 액세스할 수 있습니다.
동기
목표
조직은 GitLab 경험을 관리하는데 있어 조직이 더 나은 경험을 만들도록 초점을 맞추고 있습니다. 조직과 셀을 소개함으로써 GitLab.com의 신뢰성, 성능 및 가용성을 향상시킬 수 있습니다. - 더 넓은 수요층: 많은 인스턴스 수준의 기능이 관리자 전용입니다. GitLab.com 사용자들을 그 방식으로 차단하고 싶지 않습니다. 이전에는 Self-Managed형 사용자만 가능했던 관리 기능을 GitLab.com 사용자에게도 제공하고자 합니다. 이것은 또한 오랜 기간 동안 GitLab.com 사용자들에게 GitLab.com 관리자들로부터 더 많은 독립성을 부여하고자 한다는 것을 의미합니다. 현재는 Self-Managed형 관리자가 수행할 수 있는 작업들이 GitLab.com 사용자들이 GitLab.com 관리자들에게 요청해야 하는 조치들이 있습니다. 예를 들어, 악의적인 사용자를 금지시키는 것 등이 있습니다. - 향상된 사용자 경험: 프로젝트 및 그룹 수준에서 제공되는 기능 간의 불일치로 인해 탐색 및 사용성 문제가 발생합니다. 또한, 조직 수준 기능에 대한 전용 장소가 없습니다. - 집계: 조직의 모든 그룹 및 프로젝트에서 데이터를 집계할 수 있습니다. - 조직은 동일한 소유자(개인 네임스페이스 포함) 아래의 모든 그룹 및 프로젝트의 설정, 데이터 및 기능을 포함합니다. - 계층적 동작: 조직은 동일한 조직에 의해 소유된 모든 프로젝트와 그룹에 동작을 계층적으로 전파합니다. 조직 수준에서 설정이 하위 수준에서 재정의할 수 있는지 여부를 결정할 수 있습니다. - 고객에게 최소한의 부담: 조직을 추가해도 기존 그룹 및 프로젝트 경로가 변경되지 않도록하여 URL 변경의 영향을 최소화해야 합니다.
비목표
세포의 전제 조직으로서 조직을 제공함이 시급하기 때문에 현재 Namespace 프레임워크에서 조직 기능을 구축하는 것은 목표가 아닙니다.
제안
우리는 조직을 새로운 가벼운 개체로 만들어 필요한 기능과 워크플로우만을 갖도록 합니다. 이미 그룹 및 프로젝트에 많은 기능이 있고 그룹 자체가 사실상 이미 최상위 개체입니다. 최상위 그룹은 적어도 GitLab.com에서 계속 이러한 목적을 제공할 수 있기 때문에 조직에 중요한 설정을 제외한 중요한 기능을 추가할 필요가 없을 것으로 보입니다. 인프라 관점에서 군집 전체적인 공유 데이터는 최소(양적으로 작음)이어야 하며 적게 쓰여야 합니다.
모든 인스턴스는 기본 조직을 설정할 것입니다.
이점
- 조직 아래로 이동하는 그룹의 URL에 대한 변경사항이 없으므로 최상위 그룹을 이동하는 것이 매우 쉬워집니다.
- 최종 그룹에 대한 변환 과정이 없기 때문에 낮은 리스크 롤아웃 전략이 있습니다. -
- 조직은 성능과 명확성을 위해 별도의 테이블에 있는 것으로 식별을 위한 핵심이 됩니다.
단점
- 지금은 기존 최상위 그룹에 대한 기능이 없는 인스턴스(또는 조직이 아닌 것) 기능을 계속해서 구축하는 데 어떻게 피할 지 불명확합니다, 특히 보고서의 많은 부분. GitLab.com에서는 최상위 그룹이 이미 이 기능을 갖고 있기 때문에 문제가 되지 않지만, Self-Managed에서는 도전적인 과제입니다. Self-Managed에서 내장된 조직(또는 아예 없음)을 소개하면 그룹에 추가하는 작업과 함께 인스턴스/조직 수준의 보고 기능을 계속해서 구축해야 할 것으로 보입니다.
- 청구서는 최상위 그룹에서 조직 수준으로 이동해야 할 수 있습니다.
데이터 탐색
초기 데이터 탐색에서 사용자 및 조직에 대한 다음 정보를 검색했습니다:
- 조직에 연결된 사용자 중 매우 많은 수(98%)가 단일 조직과만 연관되어 있습니다. 이는 약 2%의 사용자가 여러 조직을 이동할 것으로 예상됨을 의미합니다.
- 대부분의 사용자(78%)는 단일 최상위 그룹의 멤버입니다.
- 현재의 최상위 그룹 중 25%는 조직과 일치됩니다.
- 이러한 최상위 그룹 중 대부분(83%)은 일부 최상위 그룹을 가진 조직과 관련이 있습니다.
- 여러 최상위 그룹을 가진 조직의 경우(중앙) 평균 최상위 그룹 수는 3입니다.
- 여러 최상위 그룹을 가진 조직에 일치된 대부분의 최상위 그룹은 하나의 조직으로 통합되기를 의도하는 것으로 생각됩니다(82%).
- 여러 최상위 그룹을 가진 조직에 일치된 대부분의 최상위 그룹은 단일 가격 제공(59%)을 사용합니다.
- 대부분의 현재 최상위 그룹은 공개적인 것으로 설정되어 있습니다.(85%)
- 0.5% 미만의 최상위 그룹이 다른 최상위 그룹과 그룹을 공유합니다. 그러나 이는 조직을 도입함으로써 최상위 그룹 간의 76,000개의 기존 링크를 잠재적으로 끊을 수 있음을 의미합니다.
이 분석을 통해 조직 롤아웃 시 유사한 행동을 기대할 것으로 예상됩니다.
디자인 및 구현 세부 정보
셀은 세 단계로 구성됩니다: 셀 1.0, 셀 1.5 및 셀 2.0입니다. 각 단계별로 사용 가능한 조직 기능은 아래에 설명되어 있습니다.
조직 MVC
Cells 1.0의 조직 (FY24Q2-FY25Q2)
Cells 1.0의 조직 MVC에는 다음과 같은 기능이 포함될 것입니다:
- 여러 조직을 만들 수 있도록 인스턴스 설정. GitLab.com에서는 기본적으로 활성화되며, Self-Managed GitLab에서는 비활성화됩니다.
- 조직의 모든 생성된 조직이 “조직” 섹션의 “관리자 영역”에 나열됩니다.
- GitLab.com의 모든 기존 최상위 그룹은 “기본 조직”의 일부입니다.
- 조직 소유자. 조직을 만들면 해당 사용자가 조직 소유자로 지정됩니다. 한 번 설정되면 조직 소유자는 다른 조직 소유자를 지정할 수 있습니다.
- 조직 사용자. 사용자는 Cells 1.0에 대해 하나의 조직에만 속할 수 있습니다. 사용자가 속하려는 각 조직마다 새 계정을 생성해야 합니다. 사용자는 조직에서만 삭제할 수 있고 삭제될 수 없습니다.
- 조직 생성 양식. 조직명, ID, 설명 및 아바타를 포함합니다. 조직 설정은 조직 소유자가 편집할 수 있습니다.
- 설정 흐름. 새 사용자는 새로운 조직을 만들 수 있습니다. 또한 그들은 조직 내에서 새로운 최상위 그룹을 만들 수 있습니다.
- 비공개 가시성. 초기에 조직은 “비공개”만 가능합니다. 비공개 조직은 해당 비공개 조직의 사용자만 볼 수 있습니다. 비공개 그룹 및 프로젝트만 포함할 수 있습니다. 유일한 예외는 기본 셀의 기본 조직으로, 이는 “공개”이며, 현재 GitLab.com의 모든 기존 그룹 및 프로젝트를 포함합니다.
- 조직 설정 페이지. 조직을 제거할 수 있는 추가 기능이 있습니다. 기본 조직의 삭제가 방지됩니다.
- 그룹. 그룹 생성, 편집 및 삭제 기능과 조직 소유자 및 사용자가 액세스할 수 있는 그룹 개요가 포함됩니다.
- 프로젝트. 프로젝트 생성, 편집 및 삭제 기능과 조직 소유자 및 사용자가 액세스할 수 있는 프로젝트 개요가 포함됩니다.
- 개인 네임스페이스. 사용자는 연관된 각 조직마다 개인 네임스페이스를 받습니다.
- 사용자 프로필. 각 사용자 프로필은 조직에 대한 범위를 가질 것입니다.
- 격리. 조직 자체는 완전히 격리되지 않으며, 격리는 보조 셀에 따라 결과적으로 발생합니다. 조직 격리의 1단계를 완료하는 것에 목표로 하며, ‘샤딩 키’ 및 ‘원하는 샤딩 키’ 규칙을 정의하는 것에 목표로 합니다.
Cells 1.5의 조직 (FY25Q3-FY25Q3)
Cells 1.5의 맥락에서 조직은 다음과 같은 기능을 포함할 것입니다.
- 조직 사용자는 한 계정을 사용하여 여러 조직에 속할 수 있습니다. 사용자는 조직 전환기를 사용하여 조직간에 이동할 수 있습니다. 비엔터프라이즈 사용자는 조직에서 제거되거나 나갈 수 있습니다.
- 조직이 완전히 격리됩니다. 조직 격리의 2단계를 완료하는 것에 목표로 하며, 격리 제약 조건을 구현하는 것에 목표로 합니다.
Cells 2.0의 조직 (FY25Q4-FY26Q1)
Cells 2.0의 맥락에서 조직은 다음과 같은 기능을 포함할 것입니다.
- 공개적인 가시성. 조직은 이제 ‘공개’일 수 있으며, 공개 및 비공개 그룹 및 프로젝트를 모두 포함할 수 있습니다.
- 사용자는 기존 최상위 그룹을 조직으로 이전할 수 있습니다.
조직 액세스
조직 사용자를 참조하세요.
역할 및 권한
조직은 소유자 역할을 가집니다. 사용자와 비교하여, 그들은 다음 작업을 수행할 수 있습니다:
| 작업 | 소유자 | 사용자 |
|---|---|---|
| 조직 설정 보기 | ✓ | |
| 조직 설정 편집 | ✓ | |
| 조직 삭제 | ✓ | |
| 사용자 제거 | ✓ | |
| 조직 전면 페이지 보기 | ✓ | ✓ |
| 그룹 개요 보기 | ✓ | ✓ (1) |
| 프로젝트 개요 보기 | ✓ | ✓ (1) |
| 사용자 개요 보기 | ✓ | ✓ (2) |
| 조직 활동 페이지 보기 | ✓ | ✓ (1) |
| 최상위 그룹을 조직으로 이전하는 것이 소유자인 경우 | ✓ |
(1) 사용자는 액세스 가능한 내용만 볼 수 있습니다. (2) 사용자는 액세스 가능한 그룹 및 프로젝트의 사용자만 볼 수 있습니다.
Groups 및 프로젝트 수준에서의 역할은 현재의 것과 동일합니다.
조직 소유자와 인스턴스 관리자 간의 관계
(인스턴스) 관리자 역할을 가진 사용자는 현재 Self-Managed GitLab 인스턴스를 관리할 수 있습니다. 기능이 조직 수준으로 이동됨에 따라 조직 소유자는 현재 관리자만 액세스할 수 있는 기능에 더 많이 액세스할 수 있게 될 것입니다. 저희 SaaS 플랫폼에서 이것은 현재 GitLab 팀 구성원에게 의존하지 않고 기업이 자체 조직을 효율적으로 관리하는 데 도움이 됩니다. SaaS에서는 인스턴스 관리자와 조직 소유자가 다른 사용자일 것으로 예상됩니다. Self-Managed 인스턴스는 일반적으로 단일 조직에 적용되므로 여기서는 두 역할을 동일한 사용자가 수행할 수 있습니다. 사용자가 시스템을 남용하는 경우와 같은 상황에는 인스턴스 관리자가 개입이 필요할 수 있습니다. 이 경우, 인스턴스 관리자의 조치가 조직 소유자의 조치를 우선합니다. 예를 들어, 인스턴스 관리자는 조직 소유자를 대신하여 사용자를 금지하거나 삭제할 수 있습니다.
라우팅
현재 사용자, 프로젝트, 네임스페이스 및 컨테이너 이미지만이 https://gitlab.com/<path>/-/에서 글로벌하게 고유해야 하는 경로 가능한 엔티티로 간주됩니다.
초기에는 조직 경로가 스코프 사용 안 됨일 것입니다.
조직은 기존 그룹 및 프로젝트 경로를 변경하지 않아야 하는 것이 설계 목표 중 하나입니다.
기타 도메인에 대한 조직의 영향
공유 데이터베이스에는 극히 적게 쓰이는 테이블이 있어야 합니다. 공유 데이터베이스에서 고트래픽 또는 대량의 데이터가 있는 경우, 이는 확장성의 단일 병목 현상이 될 수 있으며 Cells의 수평 확장 목표를 잃게 됩니다. Cells가 작동하기 위한 주요 요구 사항 중 하나인 격리를 고려하면, 기존 기능은 대부분 조직의 범위로 제한됩니다. 이에 대한 예외는 클러스터 전체 공유 데이터베이스에 저장되는 사용자입니다. 특정 기능에 대한 깊은 탐구에 대해서는 Cells에 의해 영향을 받는 기능 디렉터리을 참조하세요.
조직과 충족 사이의 조정
조직에 대한 충족 업그레이드는 Cells 프로젝트와는 다른 타임라인에서 진행될 것이며, 모든 Cells 타임라인의 블로커로 간주되어서는 안 됩니다.
Cells 1.0에서는 결제가 최상위 그룹에서 발생합니다. 다시 말해, Cells 1.0의 경우, GitLab.com SaaS 고객은 결제를 통합하기 위해 단일 최상위 그룹을 사용해야 합니다.
저희는 현재 미래 아키텍처 디자인을 평가 중입니다 (예: Zuora 결제 계정이 조직에 맞춰지는 방식) 그러나 아직 북스타 방향을 결정하지 않았으며, Cells 반복이 어떻게 또는 그에 맞게 어떻게 정렬되는지 확인하지 않았습니다.
조직에서의 오픈 소스 기여
조직의 도입으로 현재 오픈 소스 워크플로우의 여러 측면에 영향을 받을 것으로 예상됩니다. 우리는 이 문제에서 이 특정 문제에 대해 심층 연구를 진행하고 있습니다.
Post-MVC 반복
조직의 초기 롤아웃 이후에는 GitLab의 구현과 관련된 고객 요구를 해결하기 위해 다음과 같은 기능이 추가됩니다.
- 조직이 사용자를 초대할 수 있습니다.
- 조직 격리의 3단계를 완료, 기존 네임스페이스를 기본 조직에서 새로운 조직으로 이동할 수 있도록 만드는 것이 목표입니다.
- GitLab.com의 일부인 조직에 내부 가시성이 제공됩니다.
- 조직 외부에서 사용자를 초대하는 것을 제한합니다.
- 기업 사용자는 조직 수준에서 이용할 수 있습니다.
- 조직은 사용자를 차단할 수 있습니다.
- 프로젝트는 조직 수준의 프로젝트 개요에서 생성할 수 있습니다.
- 그룹은 조직 수준의 그룹 개요에서 생성할 수 있습니다.
- 청구서를 최상위 그룹에서 조직으로 이동합니다.
- 조직 수준에서 감사 이벤트가 발생합니다.
- 조직 수준에서 합병 요청 승인 규칙을 설정하고 모든 그룹과 프로젝트로 전파합니다.
- 조직 수준의 보안 정책.
- 조직 수준의 취약점 보고 및 의존성 디렉터리.
- 보안 검사를 강제하는 계단식 조직 설정.
- 조직 수준의 머지 요청 승인 정책.
- 준수 프레임워크.
- 조직 수준에서 쿠버네티스 공유를 위한 에이전트 지원.
조직 롤아웃
조직을 성공적으로 롤아웃하기 위해 다음 단계를 제안합니다:
- 단계 1: 롤아웃
- 조직은 ‘기본 조직’ 개념을 사용하여 롤아웃됩니다. GitLab.com의 모든 기존 최상위 그룹은 이미 이 ‘기본 조직’의 일부입니다. 조직 UI는 피처 플래그가 걸려 있으며, 초기에는 특정 사용자 집합을 위해 활성화될 수 있으며, 이 단계의 끝에서 전역 사용자 풀로 확장될 수 있습니다. 이렇게 함으로써 사용자들은 이미 조직 개념과 조직 UI에 익숙해져 있을 것입니다. ‘기본 조직’을 활성화시켜도 기능에 영향을 미치지 않습니다. 자세한 내용은 문제 #418225를 참조하십시오.
- 단계 2: 임시 온보딩 변경
- 새 고객은 새로운 조직을 처음부터 만들 수 있습니다. 최상위 그룹은 아직 새로운 조직으로 이동되지 않으므로 모든 콘텐츠는 조직에서 새롭게 생성되어야 합니다.
- 단계 3: 기존 고객의 이전
- GitLab, 조직,은 셀 중 하나로 이전될 엔터티 중 하나가 될 것입니다. GitLab에 속한 모든 최상위 그룹을 새로운 GitLab 조직으로 이동시킵니다. 이는
gitLab-org와gitLab-com최상위 그룹을 포함합니다. 자세한 내용은 문제 #418228를 참조하십시오. - 기본 조직에서 다른 조직으로의 최상위 그룹 이전이 가능해지면, 기존 고객은 자체 조직을 생성하고 최상위 그룹을 해당 조직으로 이동할 수 있습니다. 조직 만들기는 선택 사항으로 남습니다.
- GitLab, 조직,은 셀 중 하나로 이전될 엔터티 중 하나가 될 것입니다. GitLab에 속한 모든 최상위 그룹을 새로운 GitLab 조직으로 이동시킵니다. 이는
- 단계 4: 영구 온보딩 변경
- 모든 새로운 고객은 새 조직을 만드는 옵션만 가질 수 있습니다.
- 단계 5: 대상 지향적 노력
- 조직은 배너 메시지 등을 통해 홍보됩니다. CSM을 통한 대규모 고객과의 대화를 통해 대상 고객에게 홍보됩니다. 별도의 조직 생성은 여전히 자발적인 조치로 남겨집니다.
- 조직의 가치 제안을 강화합니다. 예를 들어, 요금 청구를 조직 수준으로 이동하여 더 많은 고객이 독립적인 조직으로 이동할 동기를 부여합니다. 채택은 모니터링됩니다.
로드 분산을 목표로하는 데 필요로 하는 것이 없을 경우, 강제 옵션은 고려되지 않을 것입니다.
대체 솔루션
조직을 구축하는 대체 접근 방식은 최상위 그룹을 조직으로 변환하는 것입니다. 이 접근 방식의 주요 장점은 네임스페이스 프레임워크를 바탕으로하여 기능을 구축할 수 있으며, 이미 그룹 수준에서 사용 가능한 기능을 활용할 수 있다는 것입니다. 같은 기능을 여러 번 구축하는 것을 피할 수 있을 것입니다. 그러나 조직은 셀의 중요한 주도 요인으로 확인되었습니다. 셀을 빠르게 제공하기 위해, 우리는 가벼운 디자인을 통해 조직을 제공하는 가장 빠르고 간단한 방법을 선택하기로 결정했습니다. 두 조직 제안을 비교한 자세한 내용은 여기에서 찾을 수 있습니다.
자주 묻는 질문
조직: 자주 묻는 질문을 참조하십시오.
결정 로그
- 2023-05-10: 청구는 조직 MVC의 일부가 아닙니다
- 2023-05-15: 조직 라우팅 설정