참조 아키텍처

Tier: Free, Premium, Ultimate Offering: Self-Managed

GitLab 참조 아키텍처는 시작점으로 사용할 권장 가능한 확장 가능하고 탄력적인 배포를 제공하기 위해 GitLab 테스트 플랫폼 및 지원팀에 의해 설계되고 테스트되었습니다.

사용 가능한 참조 아키텍처

다음과 같은 참조 아키텍처가 권장 시작점으로 사용 가능합니다.

아키텍처는 사용자 수 또는 초당 요청(RPS)에 따라 피크 부하를 기준으로 명명되었습니다. 후자는 평균 실제 데이터를 기반으로 계산되었습니다.

note
각 아키텍처는 확장 가능하고 탄력적으로 설계되었습니다. 따라서 작업 부하에 따라 필요에 따라 조정할 수 있습니다. 이는 대형 단일리포지터리 사용나 주목할만한 추가 작업 부하와 같은 알려진 중복 시나리오에서 고려될 수 있습니다.

각 참조 아키텍처가 무엇에 대해 테스트되었는지에 대한 자세한 내용은 각 페이지의 “테스트 방법론” 섹션을 참조하십시오.

GitLab 패키지 (Omnibus)

다음은 Linux 패키지 기반의 참조 아키텍처 디렉터리입니다.

클라우드 네이티브 하이브리드

다음은 클라우드 네이티브 하이브리드 참조 아키텍처 디렉터리입니다. 여기서 권장하는 특정 컴포넌트를 Kubernetes에서 실행할 수 있습니다.

시작하기 전에

먼저 고려해야 할 첫 번째 선택은 Self-Managed 접근 방식이 여러분과 여러분의 요구 사항에 적합한지 여부입니다.

운영 환경에서의 어떤 응용 프로그램을 실행하는 것은 복잡합니다. GitLab에도 동일하게 적용됩니다. 가능한한 이를 원활하게 만들긴 하지만 여전히 일반적인 복잡성이 존재합니다. 선택한 설계에 따라 다르지만 일반적으로 하드웨어, 운영 체제, 네트워킹, 리포지터리, 보안, GitLab 자체 등 모든 측면을 관리해야 할 것입니다. 이는 환경의 초기 설정 및 장기적인 유지 보수 모두에 관련됩니다.

따라서, 자신만의 관리 솔루션에 대한 작업지식을 갖추지 않은 경우, 프로페셔널 서비스팀에서 구현 서비스를 제공하지만 더 관리형 솔루션을 원하는 고객에게는 GitLab SaaS 또는 GitLab Dedicated 등의 기타 옵션을 탐색하는 것이 권장됩니다.

Self-Managed 방식을 고려 중이라면 어떤 아키텍처를 사용할지 결정, 대형 단일리포지터리, 추가 작업 부하 섹션들을 특히 자세히 읽으실 것을 강력히 권장합니다.

시작할 아키텍처 결정

참조 아키텍처는 성능, 내구성 및 비용 사이의 균형을 맞출 수 있도록 설계되었습니다.

그러나 규모에 맞게 GitLab을 설정하는 것은 여전히 요구 사항을 충족하고 어디에서 시작해야 할지 알기가 어려울 수 있습니다.

일반적인 가이드로써, 환경을 더 성능 및/또는 내구성있게 원할 경우, 더 복잡해지게 될 것입니다.

이 섹션에서는 시작할 참조 아키텍처를 선택하는 데 고려해야 할 사항을 설명합니다.

예상 부하

가장 먼저 확인해야 할 것은 환경에서 예상되는 피크 부하가 무엇인가 하는 것입니다.

각 아키텍처는 피크 초당 요청(RPS) 또는 사용자 수 부하로 설명됩니다. 각 아키텍처는 각 엔드포인트 유형(API, Web, Git)의 디렉터리된 RPS에 대해 테스트되며, 여기에는 사용자 수와 자동화된 유사한 점 중에서의 전형적인 피크 부하가 포함됩니다.

기존 메트릭(예: Prometheus)이나 추정을 통해 환경에서 처리해야 할 예상 최대 RPS를 찾아 대응하는 아키텍처를 선택하는 것이 강력히 권장됩니다.

의심스러울 때에는 가장 가까운 사용자 수를 선택하고 그에 맞게 확장하세요

예상 최대 RPS를 알 수 없는 경우, 일단 사용자 수를 기반으로 선택한 후 환경을 유심히 모니터링하여 RPS를 확인하고, 아키텍처가 필요할 때 그에 맞게 확장하는 것이 권장됩니다.

독립형 (HA 아님)

2,000명 이하 사용자를 서비스하는 환경에 대해 일반적으로는 HA가 없는 단일 노드나 다중 노드 환경을 배포하여 독립형 방식을 권장합니다. 이 접근 방식을 통해 자동화된 백업을 활용하여 RPO/RTO 수준을 제공하고 HA에 따른 복잡성을 피할 수 있습니다.

독립형 설정, 특히 단일 노드 환경의 경우 다양한 설치 옵션과 특정 클라우드 제공업체 마켓플레이스를 통한 직접 배포 등의 관리 방법이 가능하며, 이는 복잡성을 더욱 줄일 수 있습니다.

고가용성 (HA)

고가용성은 GitLab 환경의 모든 컴포넌트가 다양한 메커니즘을 통해 장애를 처리할 수 있음을 보장합니다. 그러나 이를 달성하는 것은 복잡할 뿐 아니라 요구되는 환경도 상당히 큽니다.

3,000명 이상 사용자를 서비스하는 환경에 대해 일반적으로는 이 수준에서는 장애가 더 많은 사용자들에게 더 큰 영향을 미치므로 HA 전략을 사용하도록 권장합니다. 이 범위의 모든 아키텍처는 이러한 이유로 설계상으로 HA가 통합되어 있습니다.

고가용성 (HA)이 필요한가요?

위에서 언급한 것처럼, HA를 달성하는 것은 비용이 발생합니다. 각 컴포넌트를 복제해야 하므로 추가적인 실제 및 유지 관리 비용이 발생합니다.

3,000명 미만의 많은 고객들에게는 백업 전략이 충분하고 심지어 더 선호되는 경우도 있습니다. 복구 시간은 더 오래 걸리지만, 이로 인해 훨씬 작은 아키텍처와 결과적으로 더 적은 유지 관리 비용이 발생합니다.

그러므로 일반적으로 다음과 같은 상황에서만 HA를 채택하도록 권장합니다:

  • 3,000명 이상 사용자를 보유한 경우
  • GitLab이 중단되면 극심한 업무에 영향을 미칠 것으로 예상되는 경우

크기 축소된 고가용성 (HA) 접근 방식

사용자 수가 적은 경우에도 HA가 필요한 경우, 3,000명 사용자 아키텍처를 조정하여 이를 달성할 수 있습니다.

제로 다운타임 업그레이드

제로 다운타임 업그레이드는 HA가 있는 표준 참조 아키텍처 환경에서 사용 가능하며 (클라우드 네이티브 하이브리드는 지원되지 않음), 업그레이드 중에 환경을 유지할 수 있게 합니다. 하지만 이로 인해 프로세스가 복잡해지며 문서에서 자세히 설명되어 있는 제한 사항도 있습니다.

이 프로세스를 진행할 때, HA 메커니즘이 적용되면 여전히 잠시간의 다운타임이 있을 수 있다는 사실을 염두에 둘 가치가 있습니다.

일반적으로 업그레이드에 필요한 다운타임은 상당히 많지 않아야 하므로, 이 기능은 필수적인 경우에만 권장됩니다.

클라우드 네이티브 하이브리드 (Kubernetes HA)

추가적인 HA 복원성의 추가적인 레이어로서 특정 컴포넌트를 Kubernetes에서 배포하여 클라우드 네이티브 하이브리드 참조 아키텍처로 알려져 있습니다. Kubernetes에서 서비스를 실행하는 것은 복잡하다는 것이 잘 알려져 있으며, 이러한 설정은 Kubernetes에 대한 뛰어난 작동 지식과 경험이 있는 경우에만 권장됩니다.

GitLab Geo (크로스 리전 분산/재해 복구)

GitLab Geo를 사용하면 서로 다른 지역에 분산된 환경을 구축하여 완전한 재해 복구(DR) 설정을 할 수 있습니다. GitLab Geo는 적어도 두 개의 별도 환경이 필요합니다.

  • 하나의 주 사이트
  • 주 복제 역할을 하는 하나 이상의 보조 사이트

주 사이트가 사용 불가능해지면 하나의 보조 사이트로 장애 극복할 수 있습니다.

이 고급 및 복잡한 설정은 환경에 대한 DR이 필수적인 요구 사항인 경우에만 수행해야 합니다. 또한 각 사이트가 기본 설정과 동일한 아키텍처인지 또는 각 사이트가 HA로 구성되었는지 등의 추가적인 결정을 내려야 합니다.

대규모 단일 리포지터리 / 추가 작업 부하

대형 단일 리포지터리나 중요한 추가 작업 부하가 있는 경우, 이는 환경의 성능에 영향을 미칠 수 있으며, 상황에 따라 조정이 필요할 수 있습니다.

이러한 경우에 해당된다면, 고객 성공 매니저나 지원팀에 문의하여 추가 지침을 받는 것이 좋습니다.

클라우드 제공업체 서비스

이전에 설명한 모든 전략에 대해, PostgreSQL 데이터베이스 또는 Redis와 같은 클라우드 제공업체 서비스에 대한 지원이 가능합니다.

자세한 정보는 권장하는 클라우드 제공업체 및 서비스를 참조하십시오.

결정 트리

아래에서는 위에 설명한 가이드를 결정 트리 형태로 나타냈습니다. 먼저 전체 가이드를 꼼꼼히 읽으신 후에 결정 트리를 참고하시기를 권장합니다.

%%{init: { 'theme': 'base' } }%% graph TD L0A(<b>어떤 참조 아키텍처를 사용해야 할까요?</b>) L1A(<b>예상 부하</a>에 따라 참조 아키텍처가 다른가요?) L2A("3,000명 이상 등록된 사용자와 동등한지?") L2B("2,000명 이하 등록된 사용자와 동등한지?") L3A("<a href=#do-you-need-high-availability-ha>HA가 필요한가요?</a><br>(또는 제로 다운타임 업그레이드를 희망하시나요?)") L3B[쿠버네티스에서 특정 컴포넌트의 추가적인 복원력을 원하시고 경험이 계십니까?] L4A><b>권장 사항</b><br><br/><br/>60 RPS / 3,000명 등록된 사용자 아키텍처와 HA 및 지원되는 축소 정보] L4B><b>권장 사항</b><br><br/><br/>등록된 사용자 수에 가장 가까운 아키텍처와 HA] L4C><b>권장 사항</b><br><br/><br/>등록된 사용자 수에 가장 가까운 클라우드 네이티브 하이브리드 아키텍처] L4D><b>권장 사항</b><br><br/><br/>백업을 사용하는 환경과 함께 약간의 복원 시간을 가진 20 RPS / 1,000명 또는 40 RPS / 2,000명 등록된 사용자 아키텍처"] L0A --> L1A L1A --> L2A L1A --> L2B L2A -->|예| L3B L3B -->|예| L4C L3B -->|아니오| L4B L2B --> L3A L3A -->|예| L4A L3A -->|아니오| L4D L5A("<a href=#gitlab-geo-cross-regional-distribution-disaster--recovery>교차 리전 분산 또는 재해 복구가 필요하세요?</a>") --> |예| L6A><b>추가 권장 사항</b><br><br> GitLab Geo] L4A ~~~ L5A L4B ~~~ L5A L4C ~~~ L5A L4D ~~~ L5A L5B("<a href=#large-monorepos>대형 단일 리포지터리</a>가 있거나</br> 상당한 <a href=#additional-workloads>추가 작업 부하</a>가 있습니까?") --> |예| L6B><b>추가 권장 사항</b><br><br> 고객 성공 매니저 또는 지원 담당자에 문의] L4A ~~~ L5B L4B ~~~ L5B L4C ~~~ L5B L4D ~~~ L5B classDef default fill:#FCA326 linkStyle default fill:none,stroke:#7759C2

요구 사항

참조 아키텍처를 구현하기 전에 다음 요구 사항과 지침을 참조하십시오.

지원되는 CPU

참조 아키텍처는 주로 GCP 및 AWS와 같은 다양한 클라우드 제공 업체에서 빌드되고 테스트되며, CPU 대상은 호환성의 범위를 보장하기 위해 가장 일반적인 데노미네이터로 설정됩니다.

다른 요구 사항 (예: 메모리 또는 네트워크 대역폭) 및 클라우드 제공 업체 가용성에 따라 구조 전체적으로 다양한 기계 유형이 사용되지만, 상기 대상 CPU가 잘 동작할 것으로 예상됩니다.

원한다면 더 최신의 기계 유형 시리즈를 선택하고 결과적으로 향상된 성능을 얻을 수 있습니다.

또한 ARM CPU는 Linux 패키지 환경 및 해당하는 경우 클라우드 제공자 서비스에 지원됩니다.

note
일관되지 않은 성능으로 인해 “burstable” 인스턴스 유형은 권장되지 않습니다.

지원되는 디스크 유형

일반적인 지침으로, 대부분의 표준 디스크 유형은 GitLab에서 작동할 것으로 예상되지만 다음과 같은 구체적인 업데이트를 주의해야 합니다:

  • Gitaly는 읽기 작업에 대해 초당 8,000 개의 IOPS(입출력 작업 코드) 및 쓰기 작업에 대해 2,000 개의 IOPS가 필요합니다.
  • 일관성 없는 성능으로 인해 “burstable” 디스크 유형의 사용은 권장하지 않습니다.

상기 표준 외의 디스크 유형은 GitLab에서 작동할 것으로 예상되며, 내구성 또는 비용과 같은 특정 요구 사항에 따라 각각의 선택이 달라집니다.

지원되는 인프라

일반적으로 GitLab은 유명한 클라우드 제공 업체 (AWS, GCP, Azure)와 그들의 서비스 또는 참조 아키텍처의 각 세부 사항과 본 섹션의 모든 요구 사항을 충족하는 Self-Managed형(ESXi) 등 대부분의 인프라에서 실행되어야 합니다.

그러나 이는 모든 가능한 순열에 대해 보장을 구성하지는 않습니다.

자세한 내용은 권장 클라우드 제공 업체 및 서비스를 참조하십시오.

대규모 단일 리포지터리

참조 아키텍처는 최적의 관행을 따르는 다양한 크기의 리포지터리에서 테스트되었습니다.

그러나, 대형 단일 리포지터리(수 기가바이트 이상)는 Git의 성능 및 이에 따른 환경에 상당한 영향을 미칠 수 있습니다. 그러한 존재 및 사용 방식은 Gitaly를 통해 기본 인프라까지 중대한 부하를 줄 수 있습니다.

caution
이에 해당하는 경우 해당 문서를 참조하거나 추가 지침을 위해 귀하의 고객 성공 관리자 또는 지원 팀에 문의하는 것이 강력히 권장됩니다.

따라서 대규모 단일 리포지터리는 상당한 비용을 유발합니다. 이러한 리포지터리가 있는 경우 최상의 성능을 보장하고 비용을 관리하기 위해 다음 지침이 따라지도록 권장합니다:

  • 대규모 단일 리포지터리 최적화. 이진 파일을 저장하지 않는 LFS와 리포지터리 크기를 줄이는 기타 방법을 사용하는 등의 기능을 사용하면 성능을 현격히 향상할 수 있습니다.
  • 단일 리포지터리에 따라 추가 환경 사양이 필요할 수 있습니다. 특히 Gitaly의 경우 증가된 리소스와 함께 Praefect, GitLab Rails 및 로드 밸런서가 추가로 필요할 수 있습니다. 이는 리포지터리 자체 및 해당하는 사용에 따라 달라집니다.
  • 단일 리포지터리가 상당히 큰 경우(20기가바이트 이상) 추가적인 전략이 필요할 수 있으며, 이에는 환경 사양을 더욱 증가시키는 것이나 어떤 경우에는 단일 리포지터리를 위한 별도의 Gitaly 백엔드가 필요할 수 있습니다.
  • 대형 단일 리포지터리의 경우 네트워크 및 디스크 대역폭 역시 고려해야 할 사항입니다. 매우 무거운 경우에는 많은 병렬 클론(예: CI)이 발생하면 대역폭 포화가 발생할 수 있습니다. 이러한 시나리오에서는 가능한 한 전체 복제를 줄이는 것이 강력히 권장되며, 그렇지 않은 경우에는 대역폭을 증가시키기 위해 추가 환경 사양이 필요하지만, 이는 클라우드 제공 업체에 따라 다를 수 있습니다.

추가 워크로드

이 참조 아키텍처는 실제 데이터를 기반으로 한 표준 GitLab 설정에 대해 설계 및 테스트되었습니다.

그러나 추가 워크로드는 후속 조치를 유도하여 작업의 영향을 배로 증가시킬 수 있습니다. 예를 들어 다음을 사용하는 경우 권장 사양을 조정해야 할 수 있습니다.

일반적인 원칙으로 모든 추가 워크로드의 영향을 메트릭하여 필요에 따라 변경을 통보하는 데 견고한 모니터링이 있어야 합니다. 또한 추가 지침을 얻기 위해 고객 성공 관리자 또는 지원 팀에 연락하는 것이 강력히 권장됩니다.

로드 밸런서

참조 아키텍처는 클래스에 따라 최대 두 개의 로드 밸런서를 사용합니다.

  • 외부 로드 밸런서 - 주로 레일 등 외부에 노출되는 컴포넌트에 대한 트래픽을 처리합니다.
  • 내부 로드 밸런서 - Praefect 또는 PgBouncer와 같이 HA(High Availability) 방식으로 배포된 선택적인 내부 컴포넌트에 대한 트래픽을 처리합니다.

어떤 로드 밸런서를 사용할지 또는 정확한 구성은 GitLab 문서의 범위를 벗어납니다. 가장 일반적인 옵션은 머신 노드에 로드 밸런서를 설정하거나 클라우드 제공 업체가 제공하는 서비스를 사용하는 것입니다. 클라우드 네이티브 하이브리드 환경을 배포하는 경우 차트는 쿠버네티스 인그레스를 통해 외부 로드 밸런서를 설정할 수 있습니다.

각 참조 아키텍처 클래스에 대해 시작하기 위해 지정된 기본 머신 크기가 있지만 사용할 로드 밸런서 및 작업 양에 따라 이를 조정해야 할 수 있습니다. 특히 머신에는 고려해야 할 네트워크 대역폭이 다양할 수 있습니다.

로드 밸런서에 대한 추가 지침의 다음 섹션을 참고하십시오.

균형 조정 알고리즘

능 여기서 가능한 한 균일하게 연결을 분산하여 성능을 보장하기 위해 가능한 한 최소 연결 기반 로드 밸런싱 알고리즘 또는 해당하는 것을 사용하는 것이 좋습니다.

실제로 연결을 동등하게 분배하지 않는다는 알려진 이유로 round-robin 알고리즘의 사용을 권장하지 않습니다.

네트워크 대역폭

머신에 배포된 경우 로드 밸런서의 총 네트워크 대역폭은 클라우드 제공 업체별로 상당히 다를 수 있습니다. 특히 AWS와 같은 일부 클라우드 제공 업체는 언제든지 대역폭을 결정하는데 크레딧을 사용하는 버스트 시스템으로 운영할 수 있습니다.

로드 밸런서가 필요한 환경의 네트워크 대역폭은 데이터 형태 및 작업량과 같은 다양한 요인에 의존합니다. 각 참조 아키텍처 클래스에 대한 권장 기본 크기는 실제 데이터를 기반으로 선택되어 있으나 일부 시나리오에서는 대규모 단일 리포지터리의 지속적인 복제와 같은 경우 이 크기를 조정해야 할 수 있습니다.

스왑 없음

스왑은 참조 아키텍처에서 권장되지 않습니다. 성능에 큰 영향을 미치는 실패 안전 장치입니다. 참조 아키텍처는 대부분의 경우에 충분한 메모리를 갖고 있어 스왑이 필요하지 않도록 설계되었습니다.

Praefect PostgreSQL

Praefect는 자체 데이터베이스 서버가 필요하며 완전한 고가용성을 달성하기 위해서는 서드파티 PostgreSQL 데이터베이스 솔루션이 필요합니다.

우리는 앞으로 이러한 제한 사항에 대한 내장된 솔루션을 제공할 예정입니다. 그 동안에는 고가용성이 아닌 PostgreSQL 서버를 Linux 패키지를 사용하여 설치할 수 있습니다. 자세한 내용은 다음 이슈를 참조하세요:

권장하는 클라우드 공급자 및 서비스

note
다음 디렉터리은 모두를 열거한 것이 아닙니다. 일반적으로 여기에 나열되지 않은 다른 클라우드 공급자도 동일한 사양으로 작동할 수 있지만, 이것은 확인되지 않았습니다. 또한 여기에 나열되지 않은 다른 클라우드 공급자 서비스의 경우, 각 구현이 현저하게 다를 수 있으므로 프로덕션용에 앞서 철저히 테스트하는 것이 좋습니다.

테스트 및 실제 사용을 통해, 다음 클라우드 공급자에서는 참조 아키텍처를 권장합니다:

참조 아키텍처 GCP AWS Azure 기본 금속
Linux 패키지 🟢 🟢 🟢1 🟢
클라우드 네이티브 하이브리드 🟢 🟢

또한, 참조 아키텍처의 일환으로 다음 클라우드 공급자 서비스를 사용하는 것을 권장합니다:

클라우드 서비스 GCP AWS Azure 기본 금속
객체 리포지터리 🟢   Cloud Storage 🟢   S3 🟢   Azure Blob Storage 🟢   MinIO
데이터베이스 🟢   Cloud SQL1 🟢   RDS 🟢   Azure Database for PostgreSQL Flexible Server
Redis 🟢   Memorystore 🟢   ElastiCache 🟢   Azure Cache for Redis (Premium)
  1. GCP Cloud SQL의 경우 Enterprise Plus edition를 사용하는 것이 대체로 최적의 성능을 보장합니다. 특히 대규모 환경(500 RPS / 25,000 사용자 이상)의 경우에는 max 연결 수를 워크로드에 따라 서비스의 기본값보다 높게 조정해야 할 수 있습니다.
  2. 좋은 성능을 보장하기 위해 Azure Cache for Redis의 Premium 티어를 배포하는 것이 강력히 권장됩니다.

데이터베이스 서비스의 권장 사항

외부 데이터베이스 서비스를 사용하는 경우, 표준적이고 성능이 우수하며 지원되는 버전을 실행해야 합니다.

서드파티 외부 서비스를 사용하려는 경우:

  1. HA Linux 패키지 PostgreSQL 설정은 PostgreSQL, PgBouncer 및 Consul을 포함합니다. 이러한 구성요소는 서드파티 외부 서비스를 사용할 때 더 이상 필요하지 않을 것입니다.
  2. HA를 달성하기 위해 필요한 노드 수는 Linux 패키지와 비교했을 때 서비스에 따라 다를 수 있으며, 비슷하게 일치시켜야 할 필요는 없습니다.
  3. 가능하다면 데이터베이스 부하 분산을 위해 Read Replicas를 활성화하는 것이 일반적으로 권장됩니다. 특히 대규모 환경(200 RPS / 10,000 사용자 이상)에서는 표준 Linux 패키지 배포의 노드 수와 일치시키는 것이 좋습니다.
  4. 서비스에 풀러가 제공된다면 전체 부하를 병목 현상 없이 처리할 수 있는지 확인하는 것이 일반적으로 권장됩니다. 예를 들어, Azure Database for PostgreSQL Flexible Server는 데이터베이스 앞에 PgBouncer 풀러를 선택적으로 배포할 수 있지만, PgBouncer는 싱글 스레드이므로 병목 현상을 일으킬 수 있습니다. 그러나 데이터베이스 부하 분산을 사용하는 경우, 이를 각 노드에 분산하여 병목 현상을 보상할 수 있습니다.
  5. GitLab Geo를 사용할 경우 서비스가 Cross Region 복제를 지원해야 합니다.

Redis 서비스의 권장 사항

외부 Redis 서비스를 사용하기로 선택한 경우, 표준적이고 성능이 우수하며 지원되는 버전을 실행해야 합니다. 특히 이는 GitLab에서 지원하지 않는 Cluster 모드로 실행되어야 합니다.

Redis는 주로 싱글 스레드입니다. 200 RPS / 10,000 사용자 이상을 대상으로 하는 환경의 경우, 최적의 성능을 얻기 위해 Cache와 Persistent 데이터로 구분하여 별도의 인스턴스를 나누는 것이 좋습니다.

객체 리포지터리의 권장 사항

GitLab은 지원되는 객체 리포지터리 제공업체에 대한 테스트를 진행했으며, 작동하기를 기대합니다.

일반적으로, S3 호환성을 완벽하게 갖춘 신뢰할 수 있는 솔루션을 사용하는 것이 권장됩니다.

지원되지 않는 데이터베이스 서비스

몇 가지 데이터베이스 클라우드 공급자 서비스는 위의 사항을 지원하지 않는 것으로 알려져 있거나 다른 문제가 있어 권장되지 않습니다:

제안된 참조 아키텍처에서 벗어난 경우

일반적인 지침으로써, 참조 아키텍처에서 멀어질수록 해당 아키텍처에 대한 지원을 받기 어려워집니다. 어떠한 이탈도 복잡성을 추가하여 잠재적인 문제점을 찾는 데 어려움을 줄 수 있습니다.

참조 아키텍처는 공식 리눅스 패키지 또는 Helm Charts를 사용하여 여러 컴포넌트를 설치하고 구성합니다. 이러한 컴포넌트들은 별도의 기계(가상화된 또는 베어 메탈)에 설치되며, 기계 하드웨어 요구 사항은 “구성” 열에 나열되어 있으며, GCP/AWS/Azure 열에 해당하는 VM 표준 사이즈로 나열되어 있습니다. 사용 가능한 참조 아키텍처 각각에 대해 해당합니다.

Docker(또는 Docker Compose)를 사용하여 동일한 사양의 컴포넌트를 실행하는 것 역시 문제가 없을 것입니다. Docker는 지원 관련해서 잘 알려져 있기 때문입니다. 그러나 여전히 추가적인 레이어이며, 쉽게 컨테이너 내에서 strace를 실행하지 못하는 등의 지원 복잡성을 추가할 수 있습니다.

지원되지 않는 디자인

우리는 GitLab 환경 디자인에 대한 다양한 지원을 하려고 노력하고 있지만, 확실히 작동하지 않는 특정 접근 방법들이 있으며, 결과적으로 지원되지 않습니다. 이러한 접근 방법은 다음 섹션에 자세히 설명되어 있습니다.

Kubernetes에서 상태가 있는 컴포넌트

Kubernetes에서 Gitaly Cluster와 같은 상태가 있는 컴포넌트를 실행하는 것은 지원되지 않습니다.

Gitaly Cluster는 전통적인 가상 머신에서만 지원됩니다. Kubernetes는 엄격한 메모리 제한을 강제하지만, Git 메모리 사용량은 예측할 수 없으며 이로 인해 Gitaly 파드의 무작위 OOM 종료가 발생하여 중대한 장애와 잠재적인 데이터 손실을 야기할 수 있습니다. 이와 같은 이유로 Gitaly는 Kubernetes에서 테스트되지 않거나 지원되지 않습니다. 자세한 내용은 epic 6127을 참조하십시오.

이는 지원되지 않는 항목으로 명시하지 않는 한, PostgreSQL 및 Redis와 같은 다른 써드파티 상태가 있는 컴포넌트에도 해당되지만, 원하시는 경우 이러한 컴포넌트에 대해 지원되는 클라우드 제공 업체 서비스와 같은 다른 써드파티 솔루션을 탐색할 수 있습니다.

상태가 있는 노드의 오토스케일링

일반적인 지침으로써, GitLab의 상태가 없는 컴포넌트만 Auto Scaling 그룹에서 실행할 수 있습니다. 즉, GitLab Rails와 Sidekiq이 해당됩니다. 다른 상태를 갖는 컴포넌트인 Gitaly과 같은 다른 컴포넌트는 이러한 방식으로 지원되지 않습니다 (이슈 2997를 참조하십시오).

이는 지원되지 않는 항목으로 명시하지 않는 한, PostgreSQL 및 Redis와 같은 다른 써드파티 상태가 있는 컴포넌트에도 해당되지만, 원하시는 경우 이러한 컴포넌트에 대해 지원되는 클라우드 제공 업체 서비스와 같은 다른 써드파티 솔루션을 탐색할 수 있습니다.

그러나 클라우드 네이티브 하이브리드 설정은 일반적으로 ASG보다 선호되며, 데이터베이스 마이그레이션 및 Mailroom과 같은 특정 컴포넌트가 Kubernetes에서 더 잘 처리되기 때문입니다.

여러 데이터 센터에 환경 확장

하나의 GitLab 환경을 여러 데이터 센터에 확장하는 것은 지원되지 않습니다. 한 데이터 센터가 다운된 경우 잠재적인 스플릿 브레인 상황이 발생할 수 있기 때문입니다. 예를 들어, GitLab 설치의 여러 컴포넌트인 Consul, Redis Sentinel 및 Praefect는 올바르게 작동하려면 홀수 개의 쿼럼이 필요하며, 여러 데이터 센터로 분산되면 이러한 사항에 영향을 미칠 수 있습니다.

여러 데이터 센터 또는 지역에 GitLab를 배포하기 위해 우리는 포괄적인 솔루션으로 GitLab Geo를 제공합니다.

유효성 및 테스트 결과

테스트 플랫폼 팀은 참조 아키텍처에 대한 규칙 준수여부를 확인하기 위해 정기적인 연기 및 성능 테스트를 수행합니다.

테스트 수행 이유

품질 부서는 GitLab의 성능을 메트릭하고 개선하는 데에 중점을 두며, 자기관리형 고객이 신뢰할 수 있는 성능을 보장할 수 있는 참조 아키텍처를 작성하고 검증합니다.

자세한 내용은 핸드북 페이지를 참조하십시오.

테스트 수행 방법

테스트는 모든 참조 아키텍처 및 클라우드 제공자에 대해 자동화되고 ad-hoc 방식으로 수행됩니다. 이를 위해 두 가지 도구를 사용합니다.

모든 클라우드 제공자 상의 컴포넌트 간 네트워크 지연은 <5 ms로 메트릭되었습니다. 이는 관측 결과이며 명시적인 권장 사항이 아닙니다.

우리는 테스트에 적용되는 아키텍처가 다른 아키텍처에도 적용될 수 있는 좋은 범위를 갖고 있는 “스마트 테스트” 접근을 지향합니다. 테스트는 10k Linux 패키지 설치에 초점을 맞추며, 테스트 결과 이러한 아키텍처와 클라우드 제공자들에서 유사하게 성능을 발휘하는 것으로 나타났습니다. 참조 아키텍처는 플랫폼에 구애받지 않도록 설계되었으며, 모든 것이 리눅스 패키지를 통해 VM에서 실행됩니다. 테스트는 주로 GCP에서 수행되지만, ad-hoc 테스트 결과, 다른 클라우드 제공자 또는 온프레미스(베어 메탈)에서 동일한 사양의 하드웨어에서 유사한 성능을 발휘한다고 입증되었습니다.

참조 아키텍처에 대한 테스트는 GitLab Performance Tool을 사용하여 특정 코딩된 워크로드에서 수행되며, 테스트에 사용된 처리량은 샘플 고객 데이터를 기반으로 계산되었습니다. 자신의 규모에 해당하는 참조 아키텍처를 선택하십시오.

각 엔드포인트 유형은 초당 요청 수(RPS)로 테스트됩니다:

  • API: 20 RPS
  • Web: 2 RPS
  • Git (Pull): 2 RPS
  • Git (Push): 0.4 RPS (가장 가까운 정수로 반올림)

위의 RPS 목표는 CI 및 기타 작업을 포함한 사용자 수에 따른 전체 환경 부하에 대한 실제 고객 데이터를 기반으로 선택되었습니다.

결과 해석 방법

note
QA 팀이 GitLab 성능 테스트 도구를 어떻게 활용하는지에 대한 블로그 글을 읽어보십시오.

테스트는 공개적으로 수행되며, 모든 결과가 공유됩니다.

아래 표는 참조 아키텍처에 대해 수행된 테스트와 그 주기에 대한 세부 정보를 제공합니다. 추가적인 테스트는 지속적으로 평가되며, 표는 그에 따라 업데이트됩니다.

참조
아키텍처 		GCP (* 베어 메탈을 대신한 프록시) AWS Azure
리눅스 패키지 클라우드 네이티브 하이브리드 리눅스 패키지 클라우드 네이티브 하이브리드 리눅스 패키지
1k 주간
2k 주간 계획 중
3k 주간 주간
5k 주간
10k 매일 주간 주간 주간
25k 주간
50k 주간

실행 비용

시작점으로, 다음 표는 각 클라우드 제공업체의 Linux 패키지를 통해 GCP, AWS 및 Azure의 다른 참조 아키텍처에 대한 초기 비용을 상세히 나타냅니다.

그러나 다음 주의 사항을 알아두세요:

  • 이것들은 Linux 패키지 환경에 대한 대략적인 견적에 불과합니다.
  • 디스크, 네트워크 또는 오브젝트 스토리지와 같은 동적 요소는 고려되지 않습니다.
  • Cloud Native Hybrid의 성격 상, 해당 배포에 대한 정적인 비용 계산은 불가능합니다.
  • 각 구성에 따라 매우 다르기 때문에, 베어 메탈 비용은 여기에 포함되지 않았습니다.

위와 같은 이유로, 고유한 설정 및 사용에 가능한 가깝게 계산기를 조정하여 보다 정확한 견적을 얻기를 강력히 권장합니다.

참조 아키텍처 GCP AWS Azure
Linux 패키지 계산된 비용 계산된 비용 계산된 비용
1k      
2k      
3k      
5k      
10k      
25k      
50k      

참조 아키텍처 환경 유지하기

참조 아키텍처 환경을 유지하는 것은 일반적으로 다른 GitLab 환경을 유지하는 것과 크게 다르지 않으며, 이 문서의 다른 섹션에서 자세히 다루고 있습니다.

이 섹션에서는 관련 영역에 대한 문서 링크와 특정 참조 아키텍처 참고 사항을 찾을 수 있습니다.

환경 확장

참조 아키텍처는 시작점으로 설계되었으며, 탄력적이고 확장 가능합니다. 배포 후에도 추가 성능 용량이나 비용 절감과 같은 이유로 환경을 여러분의 특정 요구에 맞게 조정하기를 바라며, 이러한 조정은 부분적 또는 전체적으로 진행될 수 있습니다. 이는 기대되는 바이며, 따라서 메트릭이 특정 컴포넌트의 고갈을 시사하면 그에 따라 환경을 점진적이거나 전체적으로 더 큰 아키텍처로 확장할 수 있습니다.

note
특정 컴포넌트가 계속해서 주어진 자원을 고갈시키는 경우, 확장을 수행하기 전에 반드시 지원 팀에 문의하는 것이 강력히 권장됩니다. 특히 해당 구성요소의 중대한 확장을 계획 중이라면 더욱 그렇습니다.

대부분의 컴포넌트에 대해 세로 및 가로 확장을 적용할 수 있습니다. 그러나 그러기 전에 다음 주의 사항을 알아두세요:

  • Puma나 Sidekiq를 세로로 확장할 때, 업무자(worker)의 수를 추가 사양을 사용하도록 조정해야 합니다. Puma는 다음 구성(reconfigure)에서 자동으로 확장되지만, Sidekiq는 사전에 설정을 변경해야 합니다.
  • Redis와 PgBouncer는 주로 single threaded입니다. 이러한 컴포넌트가 CPU 고갈을 겪는 경우에는 가로로 확장해야 할 수도 있습니다.
  • 일부 컴포넌트를 크게 확장하는 것은 환경 성능에 영향을 미칠 수 있는 주된 파장을 야기할 수 있습니다. 자세한 지침은 아래 전용 섹션을 참조.

반면에, 환경이 과다 구성되어 있다는 견적이 탄탄하게 있는 경우, 이와 유사하게 축소할 수 있습니다. 그러나 이에 대한 문제가 없도록 확인하기 위해 축소할 때는 반복적인 접근 방식을 취해야 합니다.

스케일링의 파급 효과

일부 경우에는 특정 컴포넌트의 규모를 상당히 확장하는 것이 하류 컴포넌트에 파급 효과를 가져와 성능에 영향을 미칠 수 있습니다. 참조 아키텍처는 컴포넌트 간에 균형을 고려하여 설계되어, 상호 의존하는 컴포넌트들의 사양이 일치하도록 보장합니다. 따라서 특히 컴포넌트의 확장이 두드러질 때 해당 컴포넌트가 의존하는 다른 컴포넌트로 추가 처리량이 전달되어, 다시 그 컴포넌트들을 확장해야 할 수도 있음을 발견할 수 있습니다.

참고: 참조 아키텍처는 상류 컴포넌트의 확장을 수용할 탄성을 갖추고 있습니다. 그러나 환경에 중대한 변경을 가하기 전에 안전을 위해 우리의 지원팀에 문의하는 것이 일반적으로 권장됩니다.

다음과 같은 컴포넌트들은 크게 확장된 경우 다른 컴포넌트들에 영향을 미칠 수 있습니다.

  • Puma와 Sidekiq - Puma 또는 Sidekiq 워커의 크게 확장된 부분은 내부로드 밸런서, PostgreSQL (현재 PgBouncer가 있는 경우), Gitaly (현재 Praefect가 있는 경우) 및 Redis에 대한 높은 동시 연결로 이어질 것입니다.
    • Redis는 주로 단일 스레드이며, 증가된 처리량으로 CPU 고갈이 발생할 경우 현재 결합된 클러스터를 사용 중인 경우 다른 인스턴스(캐시/지속)로 분할해야 할 수도 있습니다.
    • PgBouncer도 단일 스레드이지만, 규모를 확장하면 새로운 풀이 추가되어 전체 Postgres 연결 수가 증가하게 됩니다. 이것은 Postgres 연결 관리에 경험이 있다면에만 권장되며, 의심스러운 경우 도움을 구해야 할 것입니다.
  • Gitaly 클러스터 / PostgreSQL - 추가 노드의 크게 확장되면 주 노드로의 증가된 복제 호출로 인해 HO 시스템과 성능에 악영향을 미칠 수 있습니다.

비HA에서 HA 아키텍처로의 스케일링

대부분의 경우에서 수직 스케일링은 환경의 리소스를 증가시키는 것만 필요합니다. 그러나 HA 환경으로 이동하는 경우, 다음 컴포넌트를 각각의 HA 형태로 전환하기 위해 해당하는 문서를 따라 추가 단계가 필요할 것입니다.

업그레이드

참조 아키텍처 환경의 업그레이드는 다른 GitLab 환경과 동일합니다. 주요 GitLab 업그레이드 섹션에는 이에 대한 절차에 대한 자세한 단계가 나와 있습니다.

다운타임 없는 업그레이드도 가능합니다.

참고: 참조 아키텍처를 생성한 순서로 업그레이드해야 합니다.

모니터링

인프라 및 GitLab 자체를 모니터링하기 위한 다양한 옵션이 있으며, 더 많은 정보를 위해 선택한 모니터링 솔루션의 문서를 참조하세요.

GitLab 애플리케이션에는 Prometheus 및 다양한 Prometheus 호환 내보내기 프로그램이 번들로 제공되어 귀하의 솔루션에 연결할 수 있습니다.

업데이트 기록

다음은 참조 아키텍처의 주목할 만한 업데이트 역사입니다 (2021-01-01 이후, 오름차순), 우리는 이를 분기마다 최소 한 번 업데이트하기로 목표로 합니다.

전체 변경 이력은 GitLab 프로젝트에서 찾을 수 있습니다.

2024년:

  • 2024-04: GCP의 Cloud Native Hybrid에 대한 Webservice 노드 권장 사이징을 업데이트했으며, NGINX pod 권장을 Webservice 노드 풀에서 DaemonSet으로 실행하도록 조정했습니다.
  • 2024-04: 권장 메모리 대상을 16 GB로 조정하여 20 RPS / 1,000 사용자 아키텍처 명세를 업데이트했습니다.
  • 2024-04: 보다 명확한 명세 및 적절한 사이징을 위한 RPS를 포함한 참조 아키텍처 제목을 업데이트했습니다.
  • 2024-02: VM에 배포된 경우 Load Balancer 노드에 대한 권장 사이징을 업데이트했으며, 네트워크 대역폭 고려 사항에 대한 노트를 추가했습니다.
  • 2024-02: 예제에서 더 이상 필요하지 않은 deprecated 된 Sidekiq Max Concurrency 설정을 제거했습니다.
  • 2024-02: 2k에서 Sidekiq를 비활성화시킬 때의 Sidekiq 권장을 조정하고 아키텍처 다이어그램을 업데이트했습니다.
  • 2024-01: 모든 참조 아키텍처 크기 및 최신 클라우드 서비스에 대한 Azure에 대한 권장을 업데이트했습니다.

2023년:

  • 2023-12-12: 로드 밸런서에 대한 차례있는 제공이 예상대로 작동하는 것으로 업데이트한 노트를 추가했습니다.
  • 2023-11-03: 각 참조 아키텍처의 설계 목적, 사용된 테스트 방법론과 환경의 확장 방법에 대한 자세한 정보를 추가했습니다.
  • 2023-11-03: 디스크 유형, 객체 리포지터리 및 모니터링에 대한 내용을 추가했습니다.
  • 2023-10-25: Linux 패키지 역할을 사용하는 Sidekiq 구성 예제를 조정했습니다.
  • 2023-10-15: 3k 및 5k를 위한 개별 노드를 포함하는 Sidekiq 권장을 조정했으며, Instance 유형 및 수를 조정했습니다.
  • 2023-10-08: 대형 모노레포 사용에 대한 경고에 대한 확장 형식으로 추가했습니다.
  • 2023-10-04: 새로운 이름인 Toolbox에 대한 Task Runner pod의 이름을 업데이트했습니다.
  • 2023-10-02: 10k 이상의 분리된 캐시 및 persistent 서비스를 위한 Redis 외부 서비스 사용에 대한 확장 안내를 추가했습니다.
  • 2023-09-21: Kubernetes에서 Gitaly를 실행하는 데 관한 도전에 대한 자세한 정보를 확장했습니다.
  • 2023-09-20: deprecation 및 삭제 후에 Grafana에 대한 참조를 제거했습니다.
  • 2023-08-30: 결정 트리 하위 섹션인 Geo에 대한 개요를 확장했습니다.
  • 2023-08-08: 리눅스 패키지용 Sidekiq 역할을 사용하도록 구성 예제를 전환했습니다.
  • 2023-08-03: 50k 아키텍처에서의 AWS Machine 타입 오타를 수정했습니다.
  • 2023-11-03: 각 참조 아키텍처의 설계 목적, 사용된 테스트 방법론과 환경의 확장 방법에 대한 자세한 정보를 추가했습니다.
  • 2023-11-03: 디스크 유형, 객체 리포지터리 및 모니터링에 대한 내용을 추가했습니다.
  • 2023-10-25: Linux 패키지 역할을 사용하는 Sidekiq 구성 예제를 조정했습니다.
  • 2023-10-15: 3k 및 5k를 위한 개별 노드를 포함하는 Sidekiq 권장을 조정했으며, Instance 유형 및 수를 조정했습니다.
  • 2023-10-08: 대형 모노레포 사용에 대한 경고에 대한 확장 형식으로 추가했습니다.
  • 2023-10-04: 새로운 이름인 Toolbox에 대한 Task Runner pod의 이름을 업데이트했습니다.
  • 2023-10-02: 10k 이상의 분리된 캐시 및 persistent 서비스를 위한 Redis 외부 서비스 사용에 대한 확장 안내를 추가했습니다.
  • 2023-09-21: Kubernetes에서 Gitaly를 실행하는 데 관한 도전에 대한 자세한 내용을 확장했습니다.
  • 2023-09-20: deprecation 및 삭제 후에 Grafana에 대한 참조를 제거했습니다.
  • 2023-08-30: 결정 트리 하위 섹션인 Geo에 대한 개요를 확장했습니다.
  • 2023-08-08: 리눅스 패키지용 Sidekiq 역할을 사용하도록 구성 예제를 전환했습니다.
  • 2023-08-03: 50k 아키텍처에서의 AWS Machine 타입 오타를 수정했습니다.
  • 2023-06-30: 더 이상 필요하지 않은 설정을 제거하고 대신 Linux 패키지의 기본 설정을 사용하도록 PostgreSQL 구성 예제를 업데이트했습니다.
  • 2023-06-30: Google Memorystore가 권장되는 것을 나타내기 위해 메인 페이지에 명시적인 예제를 추가했습니다.
  • 2023-06-11: 3k 및 5k 아키텍처의 IP 예제를 수정했습니다.
  • 2023-05-25: 외부 Cloud Provider 서비스의 사용에 대한 다양한 참고 사항을 확장했으며, 10k 환경 이상을 위한 분리된 Redis 서버를 권장했습니다.
  • 2023-05-03: 5 대신에 6이 필요하다는 올바른 Redis 6 사용 요구 사항을 반영하기 위해 문서를 업데이트했습니다.
  • 2023-04-28: Azure PostgreSQL Flexible 서비스에서 지원되지 않는 Azure Active Directory 인증 방식에 대한 노트를 추가했습니다.
  • 2023-03-23: 알려진 지원되지 않는 디자인에 대한 자세한 정보를 더 추가했습니다.
  • 2023-03-16: 모든 컴포넌트가 연결되도록 올바른 구성 파일을 가지도록 Redis 다중 노드에 대한 Redis 구성 예제를 업데이트했습니다.
  • 2023-03-15: Gitaly 구성 예제를 새로운 형