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