| Status | Authors | Coach | DRIs | Owning Stage | Created |
|---|---|---|---|---|---|
| proposed | devops data stores | - |
유역구조의 유연한 참조 아키텍처
용어집
- 참조 아키텍처(Reference Architecture): GitLab 인스턴스를 배포하기 위한 참조 아키텍처로, 테스트 플랫폼 팀이 정의하고 참조 아키텍처 문서에 문서화한 것.
- 셀 아키텍처(Cell Architecture): 모든 셀에서 공유되는 반복적으로 버전이 업데이트된 아키텍처 정의.
- 셀 서브-아키타입(Cell Sub-Archetype): 셀 플릿에 배포된 제한적인 아키텍처 차이 세트. 테넌트 모델 및 이스트루멘터, 공급업자에서 오버레이(Overlays)로 구현됨.
- 오버레이(Overlays): 일관적이고 결정적인 방식으로 참조 아키텍처를 조정하는 방법. 예를 들어, 디스크 성능을 높이거나 포스트그레스 용량을 늘리는 등 여러 오버레이가 존재함.
- 탐랜드(Tamland): GitLab SaaS 인스턴스, GitLab.com, GitLab Dedicated 및 셀을 포함한 수용량 예측 도구.
맥락
셀즈 Fastboot 오프사이트에서 셀에 대한 참조 아키텍처의 사용에 대해 논의되었습니다.
이 토론의 주요 포인트는 다음과 같습니다:
- GitLab 참조 아키텍처 문서에 명시되어 있듯, 참조 아키텍처는 환경을 정의하기 위한 시작점으로, 환경을 변경할 수 있는 불변의 정의로서가 아닙니다.
- “DevSecOps 플랫폼의 모든 기능을 갖춘 단일 애플리케이션”인 GitLab 애플리케이션은 매우 다양한 사용 사례를 다루며, 부하는 인스턴스에서 사용자가 생성하는 특정 워크로드에 따라 달라집니다. 단순히 인스턴스의 활성 사용자 수에만 의존하는 것이 아닙니다.
- 셀 부하를 균형 있게 유지하기 위해 노력이 기울여질 것입니다. 이에는 Premium 및 무료 조직, 상호 보완적인 시간대에 위치한 조직 등을 한 셀에서 균형 있게 유지하거나, 예를 들어 데이터베이스 및 Gitaly 사용자의 부하를 균형 있게 유지하기 위한 사용자 워크로드(예: 한 셀에서 중대한 데이터베이스 및 Gitaly 사용자 부하 균형 유지)도 포함됩니다. 그러나 최적의 조직 균형을 유지하더라도 셀은 확실히 수평 및 수직으로 확장하여 워크로드 요구 사항을 충족해야 할 필요가 있습니다.
- 전용 테넌트 인스턴스는 이미 용량 계획을 위해 탐랜드를 배포하고 있습니다. 그러나 용량 계획 프로세스는 아직 완전히 확립되지 않은 상태입니다. 이 프로세스를 셀에도 활용할 수 있을 것입니다.
- SaaS 스펙트럼의 맨 끝에 대한 상세한 사례로서, GitLab.com:
- 참조 아키텍처를 사용하지 않습니다.
- 사용자 워크로드 및 활동에 따라 시간이 지남에 따라 반동적으로 조정됩니다.
참조 아키텍처에 대한 어떤 변경이 가능한가?
참조 아키텍처를 수정하는 데 사용할 수 있는 다양한 유형의 변경 사항이 있습니다.
- 형태적 변경(Changes in Shape): 예를 들어, SaaS 전용 로깅 및 분석 컴포넌트와 같이 GitLab.com만 필요로 하는 컴포넌트의 추가를 포함할 수 있습니다. GitLab.com 제품 제공 및 Self-Managed형 제품 제공 간의 차이로 인해 아키텍처 변경이 필요할 수 있습니다. 이러한 변경 사항은 이 문서의 범위를 벗어납니다.
- 저장용량 확장(Storage Capacity Scaling): 장기적으로, GitLab 인스턴스의 저장 요구 사항은 CPU, 메모리 및 기타 리소스 요구 사항보다 더 차분하게 증가합니다. 이는 테넌트/셀이 더 많은 저장용량을 지원하기 위해 확장 가능해야 함을 의미합니다.
- 수직 확장(Vertical Scaling): 참조 아키텍처는 머신/인스턴스 유형을 지정합니다. 이는 특정 워크로드에 더 적합한 크거나 성능이 우수한 유형으로 조정될 수 있으며, 더 저렴하거나 작은 유형으로 조정될 수도 있습니다.
- 수평 확장(Horizontal Scaling): 참조 아키텍처는 각 서비스를 실행하는 노드/pod/인스턴스의 수(또는 최소 및 최대 수)를 지정합니다. 이는 워크로드에 맞게 조정될 수 있습니다.
결정
- 셀은 참조 아키텍처를 초기 출발 상태로 사용하되, 부하에 따라 조정될 것입니다.
- 저장용량 변경, 수직 스케일 변경 및 수평 스케일 변경은 셀 아키텍처에 반복적으로 적용되며, 참조 아키텍처에서 시간이 지남에 따라 차이를 가져올 것입니다. 이러한 변경 사항은 모든 셀에 적용될 것입니다.
- 탐랜드 용량 계획은 포화 사건 발생 전에 확장 작업이 수행되도록 보장하기 위해 사용될 것입니다.
- Org Mover가 트래픽을 다시 균형있게 유지하는 주요 메커니즘으로 사용되지만, 시간이 지남에 따라 특정 워크로드를 처리하기 위해 제한된 수의 셀 서브-아키타입이 정의되어야 할 것으로 예상되며, 이는 전용이 이미 오버레이를 사용하여 제한된 테넌트 사용자 정의를 제공하는 방식과 유사하게 필요에 따라 정의될 것입니다.
다양한 유형의 스케일링 변경
- 셀 아키텍처의 저장용량은 기본값으로 유지되어야 하며, 포스트그레스, Gitaly 등의 디스크 공간에 대한 값은 테넌트 모델에서 구성 가능해야 합니다. 이를 통해 셀이 개별적인 저장 용량이 필요하기 전에 리밸런싱이나 아키텍처 반복 없이 추가 저장 용량을 위해 크기를 조정할 수 있습니다.
- 수직 및 수평 스케일링 변경은 셀 아키텍처 또는 적절한 경우 서브-아키타입/오버레이에서 구현되어야 합니다.
결과
셀은 시간이 지남에 따라 참조 아키텍처로부터 드리프트할 것인 동종의 셀 아키텍처를 사용할 것입니다. 이러한 변경 사항을 적용함에 따라 SaaS 플랫폼 팀은 향후 참조 아키텍처의 반복에 조언을 제공하기 위해 테스트 플랫폼 팀에 비공식적인 피드백을 제공할 수 있습니다.
셀 아키텍처는 (Instrumentor에서 정의됨) 모든 셀에서 공유될 것이지만, 특정 워크로드를 다루기 위해 제한된 수의 서브-아키타입이 개발될 수 있을 것입니다.
이는 오버레이를 사용하여 확장 가능한 프로세스로 관리되어야 할 것입니다. 오버레이 추가에 대한 제한 사항에 대한 자세한 내용은 테넌트 모델 문서를 확인하십시오.
탐랜드 용량 계획 프로세스는 셀의 포화를 모니터링하는 데 배포되어야 할 것입니다.
향후 탐랜드 예측에 따라 셀이 Gitaly 디스크 공간 포화로 향할 경우, 자동화된 프로세스가 미래에 적용될 수 있으며, 이를 통해 Gitaly 디스크의 크기 또는 노드 수를 증가시키는 등 스케일링 프로세스를 자동화할 수 있을 것입니다.
대체 방안
변형이 없는 참조 아키텍처
참조 아키텍처는 엄격하게 준수될 수 있습니다. 새로운 참조 아키텍처를 정의해야 합니다. 이러한 아키텍처는 고객에게 직접적으로 유용하지는 않을 것으로 예상됩니다. 또한 GitLab SaaS 내부 고객에게만 적용될 것입니다.
게다가, 이것은 Cell 스케일링에 대한 책임을 간접적으로 참조 아키텍처 정의 팀, 즉 Test Platforms 팀에 떠넘기게 될 것이며, 이로 인해 스케일링 프로세스가 느려지고 Cell 인프라의 관리에 비효율성을 초래할 것입니다.
변형이 없는 Cell 아키텍처
하나의 Cell 아키텍처만 모든 셀에 배포될 수 있습니다.
포화에 대처하는 유일한 옵션은 단일 아키텍처를 확장하여, 모든 셀의 리소스를 증가시키거나, 조직을 리밸런싱하여 다른 셀로 이동시켜 노이즈 이웃 효과를 피하는 것입니다.
이는 많은 셀이 과다하게 공급될 수 있어서 일부 셀만 올바르게 공급될 수 있도록 하는 비효율적인 방법입니다.
게다가, 다른 고객과 혼자 있을 정도로 시끄러워서, 그 자체의 셀에서 조직을 실행하는 것은 비싸다.