GitLab 참조 아키텍처는 GitLab을 대규모로 배포하기 위한 검증된 프로덕션 준비 환경 설계입니다. 각 아키텍처는 요구 사항에 따라 사용하거나 조정할 수 있는 세부 사양을 제공합니다.

시작하기 전에#

먼저 GitLab Self-Managed가 귀사와 요구 사항에 적합한 선택인지 고려하세요.

프로덕션에서 모든 애플리케이션을 실행하는 것은 복잡하며 GitLab도 마찬가지입니다. 이를 최대한 원활하게 하려고 노력하지만 설계에 따른 일반적인 복잡성이 여전히 존재합니다. 일반적으로 하드웨어, 운영 체제, 네트워킹, 스토리지, 보안, GitLab 자체 등 모든 측면을 관리해야 합니다. 여기에는 환경의 초기 설정과 장기적인 유지 관리가 모두 포함됩니다.

이 방향을 선택하는 경우 프로덕션에서 애플리케이션을 실행하고 유지 관리하는 실무 지식이 있어야 합니다. 이러한 상황이 아닌 경우 전문 서비스 팀이 구현 서비스를 제공합니다. 장기적으로 보다 관리되는 솔루션을 원하는 경우 GitLab SaaS 또는 GitLab Dedicated와 같은 다른 제품을 살펴볼 수 있습니다.

GitLab Self-Managed 방식을 고려하는 경우, 다음 섹션을 특히 포함하여 이 페이지를 전체적으로 읽어보기를 권장합니다:

• 시작할 아키텍처 결정
• 대용량 모노리포
• 추가 워크로드
• 환경 모니터링 및 조정

시작할 아키텍처 결정#

참조 아키텍처는 성능, 복원력, 비용이라는 세 가지 중요한 요소 사이의 균형을 맞추도록 설계되었습니다. 이는 일반적인 워크로드 패턴을 기반으로 대규모 GitLab 배포를 위한 검증된 시작점을 제공합니다. 초기 배포를 더 쉽게 만들어 주지만 대부분의 환경은 모니터링을 통해 나타나는 실제 사용 패턴에 따라 튜닝의 이점을 누립니다. 적절한 시작점을 선택하는 것이 중요하지만 특정 워크로드 특성에 따라 조정할 것으로 예상합니다.

일반적인 지침으로, 환경의 성능이나 복원력을 높이려면 더 복잡해집니다.

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

예상 부하#

올바른 아키텍처 크기는 주로 환경의 예상 최고 부하에 따라 달라집니다. 초당 요청(RPS)이 GitLab 인프라 크기 결정의 주요 지표이지만 다른 요소도 적용될 수 있습니다.

포괄적인 RPS 분석 및 데이터 기반 크기 결정은 참조 아키텍처 크기 결정을 참조하세요. 여기서 제공하는 내용:

• 최고 및 지속 RPS 지표 추출을 위한 상세 PromQL 쿼리
• 구성 요소별 조정을 식별하기 위한 워크로드 패턴 분석 및 RPS 구성 지침
• 모노리포, 네트워크 사용량, 성장 계획에 대한 평가 방법

빠른 RPS 추정을 위한 잠재적인 옵션:

• 다음과 같은 Prometheus 쿼리:

  sum(irate(gitlab_transaction_duration_seconds_count{controller!~'HealthController|MetricsController'}[1m])) by (controller, action)
  

• GitLab RPS 분석기.

• 기타 모니터링 솔루션.

• 로드 밸런서 통계.

RPS를 결정할 수 없는 경우 Linux 패키지 및 Cloud Native Hybrid 아키텍처의 대안적인 크기 결정 방법으로 사용자 수 등가값이 제공됩니다. 이 수치는 수동 및 자동화된 사용량을 모두 고려하여 일반적인 RPS 값으로 매핑됩니다.

사용 가능한 참조 아키텍처#

다음 참조 아키텍처는 환경을 위한 권장 시작점으로 사용할 수 있습니다.

Linux 패키지(Omnibus)#

Linux 패키지 기반 참조 아키텍처는 패키지를 사용하여 가상 머신에 모든 GitLab 구성 요소를 배포합니다. 선택 구성 요소(PostgreSQL, Redis, 오브젝트 스토리지)는 선택적으로 클라우드 공급자 서비스를 사용할 수 있습니다.

다음 RPS 목표는 일반적인 워크로드 구성을 반영합니다. 비정형 워크로드의 경우 RPS 구성 이해를 참조하세요.

Cloud Native Hybrid#

Cloud Native Hybrid 참조 아키텍처는 Helm 차트를 사용하여 Kubernetes에서 선택한 상태 비저장 구성 요소(Webservice, Sidekiq)를 배포하고, 선택한 구성 요소(PostgreSQL, Redis, 오브젝트 스토리지)는 가상 머신 또는 클라우드 공급자 서비스에 남아 있습니다.

Cloud Native First(베타)#

Cloud Native First 아키텍처는 워크로드 특성에 따라 4가지 표준화된 크기(S/M/L/XL)로 최신 배포 방법을 대상으로 하는 차세대 아키텍처입니다. 이 아키텍처는 Kubernetes에 모든 GitLab 구성 요소를 배포하고, PostgreSQL, Redis, 오브젝트 스토리지는 관리형 서비스 또는 온프레미스 옵션을 포함한 외부 타사 솔루션을 사용합니다.

이 아키텍처는 Kubernetes 오케스트레이션을 통해 운영 오버헤드를 줄이고 배포를 단순화하며 복원력을 향상시킵니다.

자세한 내용은 Cloud Native First 참조 아키텍처를 참조하세요.

불확실한 경우 크게 시작하고 모니터링한 후 축소하세요#

필요한 환경 크기가 불확실한 경우, 더 큰 크기로 시작하고 모니터링한 후 지표가 상황을 지지한다면 축소하는 것을 고려하세요.

크게 시작하고 축소하는 방식은 다음과 같은 경우에 신중한 접근 방법입니다:

• RPS를 결정할 수 없는 경우
• 환경 부하가 예상보다 비정형적으로 높을 수 있는 경우
• 대용량 모노리포나 주목할 만한 추가 워크로드가 있는 경우

예를 들어, 3,000명의 사용자가 있지만 동시 부하를 크게 증가시키는 자동화가 실행 중인 경우, 100 RPS/5,000 사용자 클래스 환경으로 시작하고 모니터링하여 지표가 지지한다면 모든 구성 요소를 한 번에 또는 하나씩 축소할 수 있습니다.

독립형(비HA)#

2,000명 이하의 사용자를 위한 환경에서는 일반적으로 비HA, 단일 또는 다중 노드 환경을 배포하는 독립형 방식을 따르는 것을 권장합니다. 이 방식으로 자동화된 백업과 같은 복구 전략을 사용할 수 있습니다. 이러한 전략은 HA에 따른 복잡성을 피하면서 좋은 수준의 복구 시간 목표(RTO) 또는 복구 지점 목표(RPO)를 제공합니다.

독립형 설정, 특히 단일 노드 환경의 경우 설치 및 관리를 위한 다양한 옵션을 사용할 수 있습니다. 복잡성을 더 줄이는 특정 클라우드 공급자 마켓플레이스를 사용하여 직접 배포하는 기능도 옵션에 포함됩니다.

고가용성(HA)#

고가용성은 GitLab 설정의 모든 구성 요소가 다양한 메커니즘을 통해 장애를 처리할 수 있도록 합니다. 그러나 이를 달성하는 것은 복잡하며 필요한 환경이 상당히 클 수 있습니다.

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

고가용성(HA)이 필요하신가요?#

앞서 언급했듯이 HA를 달성하는 데는 비용이 발생합니다. 각 구성 요소를 배수로 늘려야 하므로 환경 요구 사항이 상당히 크며, 이로 인해 추가적인 실제 비용과 유지 관리 비용이 발생합니다.

3,000명 미만의 많은 고객의 경우, 백업 전략으로도 충분하며 심지어 더 바람직하다는 것을 알게 되었습니다. 복구 시간은 더 느리지만 훨씬 작은 아키텍처와 그에 따른 낮은 유지 관리 비용을 의미합니다.

일반적인 지침으로, 다음 시나리오에서만 HA를 사용하세요:

• 3,000명 이상의 사용자가 있는 경우.
• GitLab 중단이 워크플로우에 심각한 영향을 미치는 경우.

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

더 적은 사용자를 위해 여전히 HA가 필요한 경우, 조정된 3K 아키텍처로 이를 달성할 수 있습니다.

무중단 업그레이드#

무중단 업그레이드는 HA가 있는 표준 환경에서 사용할 수 있습니다(Cloud Native Hybrid는 지원되지 않음). 이를 통해 업그레이드 중에도 환경을 계속 운영할 수 있습니다. 그러나 이 프로세스는 결과적으로 더 복잡하며 문서에 자세히 설명된 일부 제한 사항이 있습니다.

이 프로세스를 진행할 때 HA 메커니즘이 적용될 때 짧은 다운타임 순간이 여전히 있을 수 있습니다.

대부분의 경우 업그레이드에 필요한 다운타임은 크지 않습니다. 이것이 주요 요구 사항인 경우에만 이 방식을 사용하세요.

GitLab Geo(광역 배포/재해 복구)#

GitLab Geo를 사용하면 전체 재해 복구(DR) 설정이 갖춰진 다른 지역의 분산 환경을 달성할 수 있습니다. GitLab Geo에는 최소 두 개의 별도 환경이 필요합니다:

• 하나의 기본 사이트.
• 복제본으로 사용되는 하나 이상의 보조 사이트.

기본 사이트를 사용할 수 없게 되면 보조 사이트 중 하나로 장애 조치할 수 있습니다.

대용량 모노리포/추가 워크로드#

대용량 모노리포 또는 상당한 추가 워크로드는 환경 성능에 눈에 띄게 영향을 미칠 수 있습니다. 컨텍스트에 따라 일부 조정이 필요할 수 있습니다.

이러한 요소에 대한 포괄적인 분석은 참조 아키텍처 크기 결정을 참조하세요:

• 인프라에 대한 모노리포 영향에 대한 상세 평가 방법론.
• 다양한 워크로드 패턴에 대한 구성 요소별 확장 권장 사항.
• 대용량 데이터 전송 시나리오를 위한 네트워크 대역폭 분석.

이 상황이 해당되는 경우 GitLab 담당자 또는 지원 팀에 추가 지침을 문의하세요.

클라우드 공급자 서비스#

앞서 설명한 모든 전략에 대해 PostgreSQL 데이터베이스 또는 Redis와 같은 동등한 클라우드 공급자 서비스에서 일부 GitLab 구성 요소를 실행할 수 있습니다.

자세한 내용은 권장 클라우드 공급자 및 서비스를 참조하세요.

의사결정 트리#

다음 의사결정 트리를 참조하기 전에 먼저 위에서 문서화된 지침을 전체적으로 읽어보세요.

%%{init: { "fontFamily": "GitLab Sans" }}%%
graph TD
    accTitle: Decision tree for reference architecture selection
    accDescr: Key considerations for selecting architecture including expected load, HA requirements, and additional workload factors.
L0A(<b>어떤 참조 아키텍처를 사용해야 할까요?</b>)
L1A(<b>예상 부하는 얼마인가요?</b>)
L2A("60 RPS / 3,000 사용자 이상?")
L2B("40 RPS / 2,000 사용자 이하?")
L3A("HA가 필요한가요?<br>(또는 무중단 업그레이드)")
L3B[Kubernetes에서 구성 요소를<br/>선택하여 추가 복원력을<br/>원하고 경험이 있나요?]
L4A><b>권장 사항</b><br><br>HA가 있는 60 RPS / 3,000 사용자 아키텍처<br>및 지원되는 감소]
L4B><b>권장 사항</b><br><br>HA가 있는 예상 부하에 가장 가까운 아키텍처]
L4C><b>권장 사항</b><br><br>예상 부하에 가장 가까운<br>Cloud Native Hybrid 아키텍처]
L4D>"<b>권장 사항</b><br><br>백업이 있는 독립형 20 RPS / 1,000 사용자<br/>또는 40 RPS / 2,000 사용자 아키텍처"]
L0A --> L1A
L1A --> L2A
L1A --> L2B
L2A -->|예| L3B
L3B -->|예| L4C
L3B -->|아니요| L4B
L2B --> L3A
L3A -->|예| L4A
L3A -->|아니요| L4D
L5A("광역 배포나 재해 복구가</br> 필요한가요?") --> |예| L6A><b>추가 권장 사항</b><br><br> GitLab Geo]
L4A ~~~ L5A
L4B ~~~ L5A
L4C ~~~ L5A
L4D ~~~ L5A
L5B("대용량 모노리포가 있거나</br> 상당한 추가 워크로드가 예상되나요?") --> |예| L6B><b>추가 권장 사항</b><br><br>크게 시작하고 모니터링 후 축소<br><br> GitLab 담당자 또는 지원팀에 문의]
L4A ~~~ L5B
L4B ~~~ L5B
L4C ~~~ L5B
L4D ~~~ L5B

요구 사항#

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

지원되는 머신 유형#

아키텍처는 일관된 성능을 보장하면서 머신 유형 선택이 유연하도록 설계되었습니다. 각 참조 아키텍처에서 특정 머신 유형 예시를 제공하지만 이는 규범적인 기본값으로 의도된 것이 아닙니다.

다음과 같이 각 구성 요소의 지정된 요구 사항을 충족하거나 초과하는 모든 머신 유형을 사용할 수 있습니다:

• 최신 세대 머신 유형(예: GCP n2 시리즈 또는 AWS m6 시리즈)
• ARM 기반 인스턴스(예: AWS Graviton)와 같은 다른 아키텍처
• 특정 워크로드 특성(예: 더 높은 네트워크 대역폭)에 더 잘 맞는 대체 머신 유형 패밀리

이 지침은 AWS RDS와 같은 모든 클라우드 공급자 서비스에도 적용됩니다.

테스트하는 머신 유형과 방법에 대한 자세한 내용은 검증 및 테스트 결과를 참조하세요.

지원되는 디스크 유형#

대부분의 표준 디스크 유형은 GitLab에서 작동할 것으로 예상됩니다. 그러나 다음과 같은 특정 주의 사항을 숙지하세요:

• Gitaly에는 Gitaly 스토리지에 대한 특정 디스크 요구 사항이 있습니다.
• 성능이 일관되지 않으므로 "버스트 가능한" 디스크 유형 사용은 권장하지 않습니다.

다른 디스크 유형은 GitLab에서 작동할 것으로 예상됩니다. 내구성이나 비용과 같은 요구 사항에 따라 선택하세요.

지원되는 인프라#

GitLab은 평판 있는 클라우드 공급자(AWS, GCP, Azure) 및 해당 서비스, 또는 다음 두 가지 모두를 충족하는 자체 관리(ESXi)와 같은 대부분의 인프라에서 실행되어야 합니다:

• 각 아키텍처에 자세히 설명된 사양.
• 이 섹션의 모든 요구 사항.

그러나 이것이 모든 가능한 순열과의 호환성을 보장하지는 않습니다.

자세한 내용은 권장 클라우드 공급자 및 서비스를 참조하세요.

네트워킹(고가용성)#

아래는 고가용성 방식으로 GitLab을 실행하기 위한 네트워크 요구 사항입니다.

네트워크 지연#

네트워크 지연은 데이터베이스 복제와 같은 GitLab 애플리케이션 전반에 걸친 동기식 복제를 허용하기 위해 가능한 한 낮아야 합니다. 일반적으로 5ms 미만이어야 합니다.

가용성 영역(클라우드 공급자)#

가용성 영역에 걸친 배포가 지원되며 추가적인 복원력을 위해 일반적으로 권장됩니다. GitLab 애플리케이션 요구 사항에 맞게 홀수의 영역을 사용해야 합니다. 일부 구성 요소는 쿼럼 투표에 홀수 노드를 사용합니다.

데이터 센터(자체 호스팅)#

여러 자체 호스팅 데이터 센터에 걸친 배포는 가능하지만 신중한 고려가 필요합니다. 이를 위해서는 센터 간 동기식 가능 지연, 스플릿 브레인 시나리오를 방지하기 위한 견고한 이중화 네트워크 링크, 동일한 지리적 지역에 위치한 모든 센터, 적절한 쿼럼 투표를 위한 홀수 센터(가용성 영역처럼)에 걸친 배포가 필요합니다.

대용량 모노리포#

아키텍처는 모범 사례를 따르는 다양한 크기의 리포지터리로 테스트되었습니다.

그러나 대용량 모노리포(수 기가바이트 이상)는 Git 성능에 크게 영향을 미칠 수 있으며 이는 환경 자체에 영향을 줍니다. 모노리포의 존재와 사용 방법은 Gitaly부터 기반 인프라까지 전체 시스템에 상당한 부담을 줄 수 있습니다.

성능 영향은 대체로 소프트웨어 특성상의 문제입니다. 추가 하드웨어 리소스는 수확 체감에 이릅니다.

대용량 모노리포에는 주목할 만한 비용이 따릅니다. 이러한 리포지터리가 있는 경우 좋은 성능을 보장하고 비용을 절감하기 위해 다음 지침을 따르세요:

• 대용량 모노리포 최적화. LFS를 사용하여 바이너리를 저장하지 않고 리포지터리 크기를 줄이는 기타 방법을 사용하면 성능을 크게 향상시키고 비용을 절감할 수 있습니다.
• 모노리포에 따라 보상을 위해 환경 사양 증가가 필요할 수 있습니다. Gitaly는 Praefect, GitLab Rails, 로드 밸런서와 함께 추가 리소스가 필요할 수 있습니다. 이는 모노리포 자체와 사용 방법에 따라 다릅니다.
• 모노리포가 상당히 크면(20GB 이상) 더 많이 증가된 사양 또는 경우에 따라 모노리포 전용 별도의 Gitaly 백엔드와 같은 추가 전략이 필요할 수 있습니다.
• 네트워크 및 디스크 대역폭은 대용량 모노리포에서 또 다른 잠재적 고려 사항입니다. 매우 과중한 경우 동시 클론 수가 많으면(CI와 같은) 대역폭이 포화될 수 있습니다. 이 시나리오에서는 전체 클론을 최대한 줄이세요. 그렇지 않으면 대역폭 증가를 위해 추가 환경 사양이 필요할 수 있습니다. 이는 클라우드 공급자에 따라 다릅니다.

추가 워크로드#

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

그러나 추가 워크로드는 후속 작업을 트리거하여 운영 영향을 배가시킬 수 있습니다. 다음을 사용하는 경우 보상하기 위해 제안된 사양을 조정해야 할 수 있습니다:

• 노드의 보안 소프트웨어.
• 대용량 리포지터리에 대한 수백 개의 동시 CI 작업.
• 높은 빈도로 실행되는 사용자 정의 스크립트.
• 많은 대규모 프로젝트의 통합.
• 서버 훅.
• 시스템 훅.

일반적으로 추가 워크로드의 영향을 측정하고 필요한 변경 사항을 알리기 위해 강력한 모니터링이 있어야 합니다. 추가 지침을 위해 GitLab 담당자 또는 지원 팀에 문의하세요.

로드 밸런서#

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

• 외부 로드 밸런서 - 주로 Rails인 외부 노출 구성 요소로의 트래픽을 처리합니다.
• 내부 로드 밸런서 - Praefect 또는 PgBouncer와 같이 HA 방식으로 배포된 선택 내부 구성 요소로의 트래픽을 처리합니다.

사용할 로드 밸런서 또는 정확한 구성에 대한 세부 사항은 GitLab 문서의 범위를 벗어납니다. 가장 일반적인 옵션은 머신 노드에 로드 밸런서를 설정하거나 클라우드 공급자가 제공하는 서비스를 사용하는 것입니다. Cloud Native Hybrid 환경을 배포하는 경우 차트가 Kubernetes Ingress를 사용하여 외부 로드 밸런서 설정을 처리할 수 있습니다.

각 아키텍처 클래스에는 머신에 직접 배포하기 위한 권장 기본 머신 크기가 포함되어 있습니다. 그러나 선택한 로드 밸런서와 예상 워크로드와 같은 요소에 따라 조정이 필요할 수 있습니다. 참고로 머신은 고려해야 할 네트워크 대역폭이 다양할 수 있습니다.

다음 섹션에서는 로드 밸런서에 대한 추가 지침을 제공합니다.

균형 조정 알고리즘#

노드에 대한 호출을 균등하게 분산하고 좋은 성능을 보장하려면 가능한 경우 최소 연결 기반 로드 밸런싱 알고리즘 또는 이에 상응하는 것을 사용하세요.

라운드 로빈 알고리즘은 실제로 연결을 균등하게 분산하지 못하는 것으로 알려져 있으므로 사용하지 않는 것이 좋습니다.

네트워크 대역폭#

머신에 배포할 때 로드 밸런서에 사용 가능한 총 네트워크 대역폭은 클라우드 공급자에 따라 크게 다를 수 있습니다. AWS와 같은 일부 클라우드 공급자는 언제든지 대역폭을 결정하기 위한 크레딧이 있는 버스트 시스템에서 운영될 수 있습니다.

로드 밸런서에 필요한 네트워크 대역폭은 데이터 형태와 워크로드와 같은 요소에 따라 다릅니다. 각 아키텍처 클래스의 권장 기본 크기는 실제 데이터를 기반으로 선택되었습니다. 그러나 대용량 모노리포의 일관된 클론, GitLab 컨테이너 레지스트리의 과중한 사용, 대용량 CI 아티팩트, 또는 대용량 파일의 빈번한 전송과 관련된 모든 워크로드와 같은 일부 시나리오에서는 그에 따라 크기를 조정해야 할 수 있습니다.

스왑 없음#

스왑은 참조 아키텍처에서 권장하지 않습니다. 성능에 크게 영향을 미치는 안전망입니다. 아키텍처는 스왑의 필요성을 피하기 위해 대부분의 경우 충분한 메모리를 갖도록 설계되었습니다.

Praefect PostgreSQL#

Praefect에는 자체 데이터베이스 서버가 필요합니다. 완전한 HA를 달성하려면 타사 PostgreSQL 데이터베이스 솔루션이 필요합니다.

향후 이러한 제한에 대한 내장 솔루션을 제공하기를 희망합니다. 그동안 비HA PostgreSQL 서버는 사양이 반영하는 대로 Linux 패키지를 사용하여 설정할 수 있습니다. 자세한 내용은 다음 이슈를 참조하세요:

• omnibus-gitlab#7292.
• gitaly#3398.

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

다음 아키텍처는 테스트와 실제 사용을 기반으로 다음 클라우드 공급자에 권장됩니다:

또한 다음 클라우드 공급자 서비스가 아키텍처의 일부로 사용하도록 권장됩니다:

1. 좋은 성능을 보장하려면 Azure Cache for Redis의 프리미엄 티어를 배포하세요.
2. 최적의 성능을 위해, 특히 더 큰 환경(500 RPS / 25k 사용자 이상)에서는 GCP Cloud SQL에 Enterprise Plus 에디션을 사용하세요. 워크로드에 따라 서비스의 기본값보다 최대 연결 수를 높게 조정해야 할 수 있습니다.

데이터베이스 서비스를 위한 모범 사례#

Linux 패키지에 번들된 PostgreSQL, PgBouncer, Consul 서비스 검색 구성 요소 대신 PostgreSQL용 타사 외부 서비스를 사용할 수 있습니다.

지원되는 PostgreSQL 버전을 실행하는 평판 있는 공급자를 사용하세요. 다음 서비스는 잘 작동하는 것으로 알려져 있습니다:

• Google Cloud SQL.
• Amazon RDS.

구성 고려 사항#

외부 데이터베이스 서비스를 사용할 때 다음을 고려하세요:

• 최적의 성능을 위해 읽기 복제본과 함께 데이터베이스 로드 밸런싱을 활성화하세요. 표준 Linux 패키지 배포에서 사용되는 것과 노드 수를 맞추세요. 이 방식은 더 큰 환경(초당 200 요청 또는 10,000명 이상의 사용자)에서 특히 중요합니다.
• 고가용성 노드 요구 사항은 서비스별로 다를 수 있으며 Linux 패키지 설치와 다를 수 있습니다.
• GitLab Geo의 경우 서비스가 교차 지역 복제를 지원하는지 확인하세요.

연결 관리#

외부 데이터베이스 서비스의 최적 연결 처리를 위해:

• 읽기 복제본에 연결을 분산하기 위해 데이터베이스 로드 밸런싱을 사용하세요.
• 환경 크기와 워크로드에 맞게 PostgreSQL 연결 수 구성을 조정하세요. 성능을 기반으로 모니터링하고 조정하세요.
• 추가 연결 풀링이 필요한 경우 자체 PgBouncer를 배포하세요. 다른 타사 풀링 솔루션이 작동할 수 있지만 검증되지 않았습니다.

클라우드 공급자 풀링 서비스는 다음과 같은 제한 사항이 있으며 호환되지 않거나 권장하지 않습니다:

• AWS RDS Proxy: GitLab에서 사용하도록 검증되지 않았습니다.
• Azure Database for PostgreSQL PgBouncer: 제한된 관찰 가능성을 가진 단일 스레드 아키텍처. 과중한 부하에서 병목 현상을 일으킬 수 있습니다.

데이터베이스 서비스 호환성#

다음 데이터베이스 클라우드 공급자 서비스는 호환되지 않거나 권장하지 않습니다:

• Amazon Aurora는 호환되지 않으며 지원되지 않습니다. 자세한 내용은 14.4.0을 참조하세요.
• Google AlloyDB와 Amazon RDS Multi-AZ DB 클러스터는 테스트되지 않았으며 권장하지 않습니다. 두 솔루션 모두 GitLab Geo에서 작동할 것으로 예상되지 않습니다.
  • Amazon RDS Multi-AZ DB 인스턴스는 별도의 제품이며 지원됩니다.

Redis 서비스를 위한 모범 사례#

표준적이고 성능이 좋으며 지원되는 버전을 실행하는 외부 Redis 서비스를 사용하세요. 서비스는 다음을 지원해야 합니다:

• Redis 독립형(기본 x 복제본) 모드 - Redis 클러스터 모드는 특별히 지원되지 않음
• 복제를 통한 고가용성
• Redis 축출 정책 설정 기능

Redis는 주로 단일 스레드입니다. 200 RPS/10,000 사용자 클래스 이상을 대상으로 하는 환경의 경우, 최적의 성능을 달성하기 위해 인스턴스를 캐시와 영구 데이터로 분리하세요.

오브젝트 스토리지를 위한 모범 사례#

GitLab은 작동할 것으로 예상되는 다양한 오브젝트 스토리지 공급자에 대해 테스트되었습니다.

완전한 S3 호환성을 갖춘 평판 있는 솔루션을 사용하세요.

제안된 참조 아키텍처에서 벗어나기#

참조 아키텍처에서 멀어질수록 지원을 받기가 더 어려워집니다. 각 편차는 잠재적인 문제 해결을 복잡하게 하는 복잡성 레이어를 도입합니다.

이 아키텍처는 공식 Linux 패키지 또는 Helm 차트를 사용하여 다양한 구성 요소를 설치하고 구성합니다. 구성 요소는 별도의 머신(가상화 또는 베어 메탈)에 설치됩니다. 머신 하드웨어 요구 사항은 특정 참조 아키텍처 페이지의 "구성" 열에 나열됩니다. 이에 상응하는 VM 표준 크기는 각 사용 가능한 아키텍처의 GCP/AWS/Azure 열에 나열됩니다.

Docker Compose를 포함한 Docker에서 GitLab 구성 요소를 실행할 수 있습니다. Docker는 잘 지원되며 환경 전반에 걸쳐 일관된 사양을 제공합니다. 그러나 여전히 추가 레이어이며 일부 지원 복잡성을 추가할 수 있습니다. 예를 들어 컨테이너에서 strace를 실행할 수 없는 경우가 있습니다.

지원되지 않는 설계#

GitLab 환경 설계에 대한 좋은 지원 범위를 제공하려고 노력하지만 일부 방식은 효과적으로 작동하지 않습니다. 다음 섹션에서는 지원되지 않는 이러한 방식을 자세히 설명합니다.

Kubernetes의 상태 저장 구성 요소#

Postgres 및 Redis와 같은 상태 저장 구성 요소를 Kubernetes에서 실행하는 것은 지원되지 않습니다.

지원되지 않는 것으로 특별히 명시되지 않는 한 지원되는 다른 클라우드 공급자 서비스를 사용할 수 있습니다.

개별 Gitaly 노드는 제한된 가용성으로 Kubernetes에 배포할 수 있습니다. 이는 각 리포지터리가 단일 노드에 저장되는 비HA 솔루션을 제공합니다. Gitaly 배포 옵션 및 제한 사항에 대한 컨텍스트는 Kubernetes의 Gitaly를 참조하세요.

완전한 클라우드 네이티브 설정의 일환으로 Kubernetes에 Gitaly를 배포하는 참조 아키텍처의 경우 Cloud Native First 참조 아키텍처(베타)를 참조하세요.

상태 저장 노드의 자동 확장#

일반적인 지침으로, GitLab의 상태 비저장 구성 요소인 GitLab Rails와 Sidekiq만 자동 확장 그룹에서 실행할 수 있습니다. Gitaly와 같이 상태가 있는 다른 구성 요소는 이 방식으로 지원되지 않습니다. 자세한 내용은 이슈 2997을 참조하세요.

이는 Postgres 및 Redis와 같은 상태 저장 구성 요소에도 적용됩니다. 지원되지 않는 것으로 특별히 명시되지 않는 한 지원되는 다른 클라우드 공급자 서비스를 사용할 수 있습니다.

Cloud Native Hybrid 설정은 일반적으로 자동 확장 그룹보다 선호됩니다. Kubernetes는 데이터베이스 마이그레이션과 Mailroom과 같이 단일 노드에서만 실행할 수 있는 구성 요소를 더 잘 처리합니다.

하나의 환경을 여러 지역에 배포#

GitLab은 단일 환경을 여러 지역에 걸쳐 배포하는 것을 지원하지 않습니다. 이러한 설정은 지역 간 연결이 실패하는 경우 과도한 네트워크 지연이나 스플릿 브레인 시나리오와 같은 중요한 문제를 초래할 수 있습니다.

일부 GitLab 구성 요소는 동기식 복제를 수행하거나 Consul, Redis Sentinel, Praefect와 같이 올바르게 기능하기 위해 홀수 노드가 필요합니다. 높은 지연을 가진 여러 지역에 걸쳐 이러한 구성 요소를 배포하면 해당 기능과 전체 시스템 성능에 심각한 영향을 줄 수 있습니다.

이 제한은 Cloud Native Hybrid 대안을 포함한 모든 잠재적인 GitLab 환경 설정에 적용됩니다.

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

검증 및 테스트 결과#

GitLab은 이러한 아키텍처가 호환성을 유지하도록 정기적으로 스모크 및 성능 테스트를 수행합니다.

테스트 수행 방법#

테스트는 샘플 고객 데이터에서 파생된 특정 코딩된 워크로드를 사용하여 수행됩니다. Terraform 및 Ansible과 함께 환경 배포를 위한 GitLab Environment Toolkit(GET)과 k6을 사용한 성능 테스트를 위한 GitLab Performance Tool(GPT)을 모두 활용합니다.

테스트는 기본 구성으로 GCP와 AWS에서 주로 표준 컴퓨팅 제품(GCP는 n1 시리즈, AWS는 m5 시리즈)을 사용하여 수행됩니다. 이 머신 유형은 광범위한 호환성을 보장하기 위한 최소 공통 분모 목표로 선택되었습니다. CPU 및 메모리 요구 사항을 충족하는 다른 또는 최신 머신 유형 사용은 완전히 지원됩니다. 자세한 내용은 지원되는 머신 유형을 참조하세요. 아키텍처는 다른 클라우드 공급자 또는 온프레미스에서 사양을 충족하는 모든 하드웨어에서 유사하게 수행될 것으로 예상됩니다.

성능 목표#

각 참조 아키텍처는 실제 고객 데이터를 기반으로 한 특정 처리량 목표에 대해 테스트됩니다. 1,000명의 사용자마다 다음을 테스트합니다:

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

나열된 RPS 목표는 CI 및 기타 워크로드를 포함하여 사용자 수에 해당하는 총 환경 부하의 실제 고객 데이터를 기반으로 선택되었습니다.

테스트 커버리지 및 결과#

테스트는 Linux 패키지 및 Cloud Native 환경에 걸쳐 참조 아키텍처 목표를 위한 효과적이고 좋은 커버리지를 제공하도록 설계되었습니다. 테스트되는 특정 환경 및 구성은 정기적으로 검토하여 최적의 커버리지와 비용 대비 가치 균형을 보장하며 시간이 지남에 따라 변경될 수 있습니다.

테스트에는 잠재적인 미래 포함을 위해 탐색 중인 이러한 아키텍처의 프로토타입 변형도 포함됩니다. 테스트 결과는 참조 아키텍처 위키에 공개적으로 제공됩니다.

참조 아키텍처 환경 유지 관리#

참조 아키텍처 환경 유지 관리는 일반적으로 다른 GitLab 환경과 동일합니다.

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

환경 확장#

참조 아키텍처는 최종 구성이 아닌 일반적인 워크로드 패턴에 기반한 검증된 시작점으로 설계되었습니다. 대부분의 프로덕션 배포는 모니터링을 통해 나타나는 실제 사용 패턴에 따른 조정으로 이점을 얻습니다. 아키텍처는 전체적으로 확장 가능하며 워크로드 특성이 명확해지면 반복적으로 조정할 수 있습니다. 확장은 지표가 지속적인 리소스 압박을 나타낼 때 구성 요소별로 또는 다음 아키텍처 크기로 전체적으로 수행할 수 있습니다.

확장할 시기#

대부분의 배포는 실제 워크로드 패턴을 관찰한 후 조정으로 이점을 얻습니다. 확장을 트리거하는 일반적인 시나리오:

리소스 크기 조정:

• API 트래픽이 총 RPS의 90%를 초과할 때 API 과중 워크로드에 대한 Webservice/Rails 용량 증가(RPS 구성 이해 참조)
• 모노리포 과중 환경 또는 리포지터리 크기가 2GB를 초과할 때 Gitaly 확장(구성 요소 조정 식별 참조)
• 높은 CI/CD 처리량 또는 과중한 백그라운드 작업 처리에 대한 Sidekiq 워커 조정

구성 튜닝:

• 동시 액세스 패턴에 따른 Gitaly 리포지터리 cgroup 수 설정(Gitaly cgroup 참조)
• 작업 처리 최적화를 위한 Sidekiq 큐 우선순위 구성(특정 작업 클래스 처리 참조)

아키텍처 개선:

• 읽기 과중 워크로드에 대한 PostgreSQL 읽기 복제본 추가
• 다양한 작업 유형에 대한 Sidekiq를 전문 풀로 분리
• 트래픽이 급격하게 급증하는 환경에 대한 최소 인스턴스 수 조정

이러한 조정은 일반적이며 예상됩니다. 참조 아키텍처가 기반을 제공하지만 특정 워크로드를 모니터링하여 최적의 구성을 결정합니다. 환경의 체계적인 평가를 위해 참조 아키텍처 크기 결정을 참조하세요.

GitLab Duo Agent Platform을 위한 확장#

GitLab Duo Agent Platform은 표준 GitLab 워크로드 이상의 추가 인프라 요구 사항을 도입합니다. Agent Platform 워크플로우는 GitLab Rails API를 통해 실행되고, Sidekiq를 통해 비동기적으로 작업을 처리하며, 코드 컨텍스트 및 분석을 위한 리포지터리 데이터에 액세스합니다.

주요 구성 요소 영향:

• Rails(Webservice/Puma) - Agent Platform API 요청이 전체 요청 부하에 추가되고 AI 응답 스트리밍을 위한 WebSocket 연결이 Workhorse에 의해 관리됨
• Sidekiq - AI 완성 작업 및 워크플로우 상태 업데이트가 백그라운드 작업으로 처리됨
• PostgreSQL - 에이전트 워크플로우 세션 및 상태 데이터가 데이터베이스에 저장됨
• Gitaly - 코드 컨텍스트에 대한 리포지터리 파일 액세스 및 에이전트 생성 변경 사항에 대한 커밋 작업

Agent Platform 도입을 계획하는 환경의 경우:

• 표준 워크로드 RPS를 기반으로 권장 아키텍처 크기 배포
• 초기 롤아웃 중 Rails CPU 사용률 모니터링
• Sidekiq CPU 사용률 및 작업 큐 깊이 모니터링
• 워크플로우 상태 관리로 인한 트랜잭션 비율 증가에 대한 PostgreSQL 모니터링
• 코드 분석 기능의 파일 액세스 패턴 증가에 대한 Gitaly 모니터링

이러한 구성 요소를 모니터링하기 위한 Prometheus 쿼리 예시는 Prometheus 샘플 쿼리를 참조하세요.

지속적인 리소스 압박이 관찰되면 영향받는 구성 요소의 용량을 늘려 확장하세요. Kubernetes 배포에서는 Pod 복제본 및 노드 풀 용량을 늘립니다. Linux 패키지 배포에서는 노드를 추가하여 수평 확장하거나 노드 사양을 늘려 수직 확장합니다.

리소스 요구 사항은 Agent Platform 사용 강도와 활성화된 특정 기능에 따라 다릅니다. 참조 아키텍처는 표준 GitLab 워크로드와 함께 일반적인 Agent Platform 사용 패턴에 충분한 기본 용량을 제공합니다.

확장 방법#

대부분의 구성 요소의 경우 일반적으로 수직 및 수평 확장을 적용할 수 있습니다. 그러나 그 전에 다음 주의 사항을 숙지하세요:

• Puma 또는 Sidekiq를 수직으로 확장할 때 추가 사양을 사용하도록 워커 수를 조정해야 합니다. Puma 워커 수는 일반적으로 자동으로 조정되지만 Sidekiq는 수동 구성이 필요할 수 있습니다.
• Redis와 PgBouncer는 주로 단일 스레드입니다. 이러한 구성 요소에서 CPU 소진이 발생하는 경우 수평으로 확장해야 할 수 있습니다.
• Linux 패키지 배포에서 Consul, Redis Sentinel, Praefect 구성 요소는 HA 형태로 배포할 때 투표 쿼럼을 위해 홀수 노드가 필요합니다.
• 특정 구성 요소를 크게 확장하면 환경 성능에 영향을 미치는 눈에 띄는 연쇄 효과가 발생할 수 있습니다. 자세한 지침은 확장의 연쇄 효과를 참조하세요.

반대로 환경이 과잉 프로비저닝되었음을 보여주는 강력한 지표가 있는 경우 축소할 수 있습니다. 문제가 없는지 확인하기 위해 축소할 때 반복적인 방식을 취해야 합니다.

확장의 연쇄 효과#

경우에 따라 구성 요소를 크게 확장하면 다운스트림 구성 요소에 대한 연쇄 효과가 발생하여 성능에 영향을 미칠 수 있습니다. 아키텍처는 서로 의존하는 구성 요소가 사양 측면에서 일치하도록 균형을 염두에 두고 설계되었습니다. 특히 구성 요소를 확장하면 해당 구성 요소가 의존하는 다른 구성 요소에 전달되는 추가 처리량이 발생할 수 있습니다. 결과적으로 이러한 다른 종속 구성 요소도 확장해야 할 수 있습니다. 이를 결정하려면 확장 전에 모든 종속 서비스의 포화 지표를 모니터링하세요. 여러 상호 의존 구성 요소가 포화를 보이면 병목 현상이 구성 요소 사이에서 단순히 이동하는 것을 방지하기 위해 순차적이 아닌 조율된 방식으로 함께 확장해야 합니다.

다음 구성 요소는 크게 확장되었을 때 다른 구성 요소에 영향을 줄 수 있습니다:

• Puma 및 Sidekiq - Puma 또는 Sidekiq 워커를 크게 확장하면 내부 로드 밸런서, PostgreSQL(있는 경우 PgBouncer를 통해), Gitaly(있는 경우 Praefect를 통해) 및 Redis에 대한 동시 연결이 증가합니다.
  • Redis는 주로 단일 스레드입니다. 경우에 따라 처리량 증가로 인해 결합된 클러스터에서 CPU 소진이 발생하면 Redis를 별도의 인스턴스(예: 캐시 및 영구)로 분리해야 할 수 있습니다.
  • PgBouncer도 단일 스레드이지만 확장하면 새 풀이 추가되어 Postgres에 대한 총 연결이 증가할 수 있습니다. Postgres 연결 관리 경험이 있는 경우에만 이 작업을 수행하고 의심스러운 경우 도움을 요청하는 것을 강력히 권장합니다.
• Gitaly 클러스터(Praefect)/PostgreSQL - 추가 노드의 눈에 띄는 확장은 기본 노드에 대한 복제 호출이 증가하여 HA 시스템 및 성능에 해로운 영향을 줄 수 있습니다.

비HA에서 HA 아키텍처로 확장#

대부분의 경우 환경의 리소스를 늘리기 위해 수직 확장만 필요합니다. 그러나 HA 환경으로 이동하는 경우 HA 형태로 전환하기 위해 다음 구성 요소에 대한 추가 단계가 필요합니다.

자세한 내용은 다음 문서를 참조하세요:

• Redis에서 Redis Sentinel이 있는 다중 노드 Redis로
• Postgres에서 Consul + PgBouncer가 있는 다중 노드 Postgres로
• Gitaly에서 Gitaly 클러스터(Praefect)로

업그레이드#

참조 아키텍처 환경을 업그레이드하는 것은 다른 GitLab 환경과 동일합니다. 자세한 내용은 GitLab 업그레이드를 참조하세요. 무중단 업그레이드도 사용 가능합니다.

모니터링#

다양한 옵션을 사용하여 인프라 및 GitLab을 모니터링할 수 있습니다. 자세한 내용은 선택한 모니터링 솔루션의 문서를 참조하세요.

업데이트 기록#

변경 사항의 전체 기록은 GitLab 프로젝트에서 확인할 수 있습니다.