GitLab 참조 아키텍처는 GitLab을 대규모로 배포하기 위한 권장 프로덕션 환경 설계입니다. 각 아키텍처는 그대로 사용하거나 요구 사항에 맞게 조정할 수 있는 상세 사양을 제공합니다.

시작하기 전에#

먼저 GitLab Self-Managed가 조직과 요구 사항에 맞는 선택인지 검토합니다.

프로덕션에서 애플리케이션을 운영하는 일은 복잡하며 GitLab도 마찬가지입니다. GitLab은 이 과정을 최대한 매끄럽게 만들고자 하지만, 설계에 따른 일반적인 복잡성은 여전히 남습니다. 일반적으로 하드웨어, 운영 체제, 네트워킹, 스토리지, 보안, GitLab 자체 등 모든 영역을 직접 관리해야 합니다. 여기에는 환경 초기 구축과 장기 유지 관리가 모두 포함됩니다.

이 방식을 선택한다면 프로덕션에서 애플리케이션을 운영하고 유지 관리하는 실무 지식이 필요합니다. 그러한 여건이 아니라면 GitLab 전문 서비스 팀이 구축 서비스를 제공합니다. 장기적으로 관리형 솔루션을 원한다면 GitLab.com이나 GitLab Dedicated 같은 다른 제품을 검토할 수 있습니다.

GitLab Self-Managed 방식을 고려한다면 이 페이지 전체를 읽어 보기를 권장하며, 특히 다음 섹션을 참고합니다:

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

시작할 아키텍처 결정#

참조 아키텍처는 성능, 복원력, 비용의 균형을 맞춘 설계입니다. 일반적인 워크로드 패턴을 근거로 한 권장 시작점입니다. 다만 대부분의 배포는 모니터링으로 확인한 실제 사용량에 맞춘 튜닝이 필요합니다.

일반적으로 환경의 성능이나 복원력을 높일수록 구성은 더 복잡해집니다.

예상 부하#

적정 아키텍처 크기는 주로 환경의 예상 최대 부하에 따라 결정됩니다. 초당 요청 수(RPS)가 GitLab 인프라 크기를 정하는 주요 지표이지만, 다른 요소도 함께 작용할 수 있습니다.

종합적인 RPS 분석과 데이터 기반 크기 결정은 참조 아키텍처 크기 결정을 참고합니다. 이 문서에서는 다음을 제공합니다:

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

RPS를 빠르게 추정하는 방법으로는 다음과 같은 선택지가 있습니다:

• 다음과 같은 Prometheus 쿼리:

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

• GitLab RPS Analyzer.

• 기타 모니터링 솔루션.

• 로드 밸런서 통계.

RPS를 파악할 수 없는 경우, Linux 패키지 및 Cloud Native Hybrid 아키텍처에는 대안 크기 결정 방법으로 사용자 수 환산값이 제공됩니다. 이 사용자 수는 수동 사용량과 자동화 사용량을 모두 고려해 일반적인 RPS 값으로 매핑되어 있습니다.

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

다음 참조 아키텍처를 환경 구축의 권장 시작점으로 사용할 수 있습니다.

Linux 패키지(Omnibus)#

Linux 패키지 기반 참조 아키텍처는 모든 GitLab 구성 요소를 패키지와 함께 가상 머신에 배포합니다. 일부 구성 요소(PostgreSQL, Redis, Object Storage)는 선택적으로 클라우드 공급자 서비스를 사용할 수 있습니다.

다음 RPS 목표는 일반적인 워크로드 구성을 반영합니다. 일반적이지 않은 워크로드는 RPS 구성 이해를 참고합니다.

Cloud Native Hybrid#

Cloud Native Hybrid 참조 아키텍처는 일부 무상태 구성 요소(Webservice, Sidekiq)를 Helm Charts로 Kubernetes에 배포하고, 나머지 구성 요소(PostgreSQL, Redis, Object Storage)는 가상 머신에 두거나 클라우드 공급자 서비스를 사용합니다.

Cloud Native#

Cloud Native 아키텍처는 모든 GitLab 구성 요소를 Kubernetes에 배포하고, PostgreSQL, Redis, Object Storage는 외부 관리형 서비스를 사용합니다. 표준화된 네 가지 크기가 대부분의 프로덕션 배포를 포괄합니다. 일반적이지 않은 워크로드는 참조 아키텍처 크기 결정을 참고합니다. 신규 배포에는 이 아키텍처를 권장합니다.

불확실한 경우 크게 시작해 모니터링한 뒤 축소#

필요한 환경 크기가 확실하지 않다면 더 큰 크기로 시작해 모니터링한 뒤, 지표가 뒷받침하면 그에 맞게 축소하는 방법을 고려합니다.

크게 시작한 뒤 축소하는 방식은 다음과 같은 경우에 적절합니다:

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

예를 들어 사용자가 3,000명이지만 동시 부하를 크게 높이는 자동화가 있다는 점을 알고 있다면, 100 RPS / 5천 사용자급 환경으로 시작해 모니터링한 뒤 지표가 뒷받침하면 모든 구성 요소를 한 번에 또는 하나씩 축소할 수 있습니다.

독립형(비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를 갖춘 표준 환경.
• GitLab 18.9 이상에서는 Cloud Native Hybrid 환경도 해당합니다.

무중단 업그레이드를 사용하면 업그레이드 중에도 환경을 계속 운영할 수 있습니다. 다만 그만큼 절차가 복잡하고, 문서에 자세히 설명된 제약도 있습니다.

이 절차를 진행할 때 HA 메커니즘이 동작하는 짧은 순간에는 중단이 발생할 수 있다는 점을 알아 둡니다.

대부분의 경우 업그레이드에 필요한 중단 시간은 길지 않습니다. 무중단이 핵심 요구 사항일 때만 이 방식을 사용합니다.

GitLab Geo(리전 간 분산/재해 복구)#

GitLab Geo를 사용하면 완전한 재해 복구(DR) 구성을 갖춘 상태로 서로 다른 리전에 분산된 환경을 구축할 수 있습니다. GitLab Geo에는 최소 두 개의 별도 환경이 필요합니다:

• 기본 사이트 1개.
• 복제본 역할을 하는 보조 사이트 1개 이상.

기본 사이트를 사용할 수 없게 되면 보조 사이트 중 하나로 페일오버할 수 있습니다.

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

대용량 모노리포나 상당한 추가 워크로드는 환경 성능에 큰 영향을 줄 수 있습니다. 상황에 따라 일부 조정이 필요할 수 있습니다.

이러한 요소에 대한 종합적인 분석은 참조 아키텍처 크기 결정을 참고합니다. 이 문서에서는 다음을 제공합니다:

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

이러한 상황에 해당한다면 GitLab 담당자나 지원 팀에 문의해 추가 안내를 받습니다.

클라우드 공급자 서비스#

앞서 설명한 모든 전략에서 PostgreSQL 데이터베이스나 Redis/Valkey처럼 동등한 클라우드 공급자 서비스로 일부 GitLab 구성 요소를 운영할 수 있습니다.

자세한 내용은 인프라 및 서비스를 참고합니다.

의사결정 트리#

다음 의사결정 트리를 보기 전에 앞에서 설명한 지침을 전체적으로 먼저 읽습니다.

%%{init: { "fontFamily": "GitLab Sans" }}%%
graph TD
    accTitle: Decision tree for reference architecture selection
    accDescr: Key considerations for selecting architecture type and size, including Gitaly Cluster requirements, expected load, and HA requirements.
L0A(<b>What Reference Architecture should I use?</b>)
L_CNQ("Do you need Gitaly Cluster (Praefect)<br>for repository-level HA?")
L_CN><b>Recommendation</b><br><br>Cloud Native architecture<br>Select the size closest to your RPS]
L1A(<b>What is your expected load?</b>)
L2A("60 RPS / 3,000 users or more?")
L2B("40 RPS / 2,000 users or less?")
L3A("Do you need HA?<br>(or zero-downtime upgrades)")
L3B[Do you have experience with<br/>and want additional resilience<br/>with select components in Kubernetes?]
L4A><b>Recommendation</b><br><br>60 RPS / 3,000 user architecture with HA<br>and supported reductions]
L4B><b>Recommendation</b><br><br>Architecture closest to expected load with HA]
L4C><b>Recommendation</b><br><br>Cloud Native Hybrid architecture<br>closest to expected load]
L4D>"<b>Recommendation</b><br><br>Standalone 20 RPS / 1,000 user or 40 RPS / 2,000 user<br/>architecture with Backups"]
L0A --> L_CNQ
L_CNQ -->|No| L_CN
L_CNQ -->|Yes| L1A
L1A --> L2A
L1A --> L2B
L2A -->|Yes| L3B
L3B -->|Yes| L4C
L3B -->|No| L4B
L2B --> L3A
L3A -->|Yes| L4A
L3A -->|No| L4D
L5A("Do you need cross regional distribution</br> or disaster recovery?") --> |Yes| L6A><b>Additional Recommendation</b><br><br> GitLab Geo]
L_CN ~~~ L5A
L4A ~~~ L5A
L4B ~~~ L5A
L4C ~~~ L5A
L4D ~~~ L5A
L5B("Do you have Large Monorepos or expect</br> to have substantial additional workloads?") --> |Yes| L6B><b>Additional Recommendations</b><br><br>Start large, monitor and scale down<br><br> Contact GitLab representative or Support]
L_CN ~~~ L5B
L4A ~~~ L5B
L4B ~~~ L5B
L4C ~~~ L5B
L4D ~~~ L5B

요구 사항#

참조 아키텍처를 구현하기 전에 하드웨어·구성 요소·인프라 요구 사항은 설치 요구 사항을, 워크로드 평가 방법은 참조 아키텍처 크기 결정을 참고합니다.

추가 워크로드#

이 아키텍처는 실제 데이터를 기반으로 표준 GitLab 구성을 대상으로 설계하고 테스트했습니다.

다만 추가 워크로드는 후속 작업을 유발해 작업의 영향을 몇 배로 키울 수 있습니다. 다음을 사용한다면 이를 보완하도록 제안 사양을 조정해야 할 수 있습니다:

• 노드의 보안 소프트웨어.
• 대용량 리포지터리를 대상으로 하는 수백 개의 동시 CI job.
• 높은 빈도로 실행되는 사용자 정의 스크립트.
• 대규모 프로젝트 다수의 통합.
• 사용자 기반이 큰 프로젝트의 기능 플래그.
• 서버 훅.
• 시스템 훅.

일반적으로 추가 워크로드의 영향을 측정하고 필요한 변경을 판단하려면 충실한 모니터링 체계를 갖춰야 합니다. GitLab 담당자나 지원 팀에 문의해 추가 안내를 받습니다.

인프라 및 서비스#

이 아키텍처는 클라우드 공급자든 온프레미스든 사양을 충족하는 모든 인프라에서 동작합니다. 지원되는 인프라와 Kubernetes 요구 사항은 설치 요구 사항을 참고합니다.

PostgreSQL, Redis/Valkey, 오브젝트 스토리지의 관리형 클라우드 공급자 서비스는 GitLab 구성 요소용 클라우드 서비스를 참고합니다.

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

참조 아키텍처에서 멀어질수록 지원을 받기가 어려워집니다. 편차가 생길 때마다 잠재적인 문제 해결을 어렵게 만드는 복잡성이 한 겹씩 더해집니다.

이 아키텍처는 공식 Linux 패키지나 Helm Charts로 여러 구성 요소를 설치하고 구성합니다. 구성 요소는 각각 별도 머신(가상화 또는 베어메탈)에 설치됩니다. 머신 하드웨어 요구 사항은 각 참조 아키텍처 페이지의 "Configuration" 칼럼에 정리되어 있습니다. 이에 상응하는 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 참조 아키텍처를 참고합니다.

하나의 환경을 여러 리전에 배포#

GitLab은 단일 환경을 여러 리전에 걸쳐 배포하는 구성을 지원하지 않습니다. 이러한 구성은 과도한 네트워크 지연이나, 리전 간 연결이 끊겼을 때의 스플릿 브레인처럼 심각한 문제로 이어질 수 있습니다.

Consul, Redis Sentinel, Praefect처럼 동기식 복제를 수행하거나 정상 동작을 위해 홀수 개 노드가 필요한 GitLab 구성 요소가 여럿 있습니다. 지연이 큰 여러 리전에 이러한 구성 요소를 분산하면 해당 기능과 전체 시스템 성능이 크게 저하될 수 있습니다.

이 제약은 Cloud Native Hybrid 대안을 포함해 모든 GitLab 환경 구성에 적용됩니다.

여러 데이터 센터나 리전에 GitLab을 배포하는 경우에는 종합 솔루션으로 GitLab Geo를 제공합니다.

사양 도출 방식#

사양은 실제 고객 데이터와 수시 성능 테스트를 근거로 정합니다.

테스트 수행 방법#

테스트는 샘플 고객 데이터에서 도출한 코드화된 워크로드로 수행하며, 환경 배포에는 Terraform과 Ansible을 사용하는 GitLab Environment Toolkit(GET)을, 성능 테스트에는 k6을 사용하는 GitLab Performance Tool(GPT)을 함께 활용합니다.

테스트는 주로 GCP와 AWS에서 표준 컴퓨팅 제품(GCP는 n1 시리즈, AWS는 m5 시리즈)을 기준 구성으로 삼아 수행합니다. 이 머신 유형은 폭넓은 호환성을 확보하기 위한 최소 공통 기준으로 선택했습니다. 사양은 표준 범용 x86 컴퓨팅을 기준으로 산정했으며, vCPU와 메모리 요구 사항을 충족하거나 상회하는 머신 유형이면 최신 CPU 세대와 ARM 기반 인스턴스를 포함해 동작할 것으로 예상합니다. 이 아키텍처는 다른 클라우드 공급자든 온프레미스든 사양을 충족하는 하드웨어에서 비슷한 성능을 낼 것으로 예상합니다.

성능 목표#

각 참조 아키텍처는 실제 고객 데이터를 기반으로 한 처리량 목표에 맞춰 테스트합니다. 사용자 1,000명당 다음 값을 테스트합니다:

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

위 RPS 목표는 CI와 기타 워크로드를 포함해 사용자 수에 해당하는 전체 환경 부하의 실제 고객 데이터를 근거로 선정했습니다.

테스트 커버리지 및 결과#

테스트는 Linux 패키지 환경과 Cloud Native 환경에 걸쳐 참조 아키텍처 목표를 효과적으로 검증하고 충분한 커버리지를 확보하도록 설계했습니다. 테스트 대상 환경과 구성은 커버리지와 비용 대비 가치의 균형을 위해 정기적으로 검토하며, 시간이 지나면서 바뀔 수 있습니다.

테스트에는 향후 정식 포함을 검토 중인 프로토타입 변형도 포함됩니다. 테스트 결과는 참조 아키텍처 위키에 공개되어 있습니다.

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

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

이 절에서는 관련 영역의 문서 링크와 아키텍처별 참고 사항을 안내합니다.

환경 확장#

참조 아키텍처는 최종 구성이 아니라 일반적인 워크로드 패턴을 근거로 검증한 시작점입니다. 대부분의 프로덕션 배포는 모니터링으로 드러나는 실제 사용 패턴에 맞춘 조정이 필요합니다. 아키텍처는 전 구간에서 확장할 수 있고, 워크로드 특성이 분명해지면 반복해서 조정할 수 있습니다. 확장은 구성 요소 단위로 하거나, 지표가 지속적인 리소스 압박을 나타낼 때 다음 아키텍처 크기로 한 번에 옮기는 방식으로 할 수 있습니다.

확장할 시기#

대부분의 배포는 실제 워크로드 패턴을 관찰한 뒤 조정하는 편이 좋습니다. 확장을 촉발하는 일반적인 상황은 다음과 같습니다:

리소스 크기 조정:

• API 중심 워크로드, 특히 API 트래픽이 전체 RPS의 90%를 넘는 경우 Webservice/Rails 용량 증설(RPS 구성 이해 참고)
• 모노리포 비중이 큰 환경이나 리포지터리 크기가 2 GB를 넘는 경우 Gitaly 확장(구성 요소 조정 항목 파악 참고)
• CI/CD 처리량이 많거나 백그라운드 job 처리가 많은 경우 Sidekiq 워커 조정

구성 튜닝:

• 동시 액세스 패턴에 맞춘 Gitaly 리포지터리 cgroup 수 설정(Gitaly cgroups 참고)
• job 처리 최적화를 위한 Sidekiq 큐 우선순위 구성(특정 job 클래스 처리 참고)

아키텍처 개선:

• 읽기 비중이 큰 워크로드를 위한 PostgreSQL 읽기 복제본 추가
• job 유형에 따라 Sidekiq를 전용 풀로 분리
• 트래픽이 급격히 치솟는 환경의 최소 인스턴스 수 조정

이러한 조정은 일반적이고 예상된 과정입니다. 참조 아키텍처가 기반을 제공하고, 최적 구성은 각자의 워크로드 모니터링으로 결정합니다. 환경을 체계적으로 평가하려면 참조 아키텍처 크기 결정을 참고합니다.

GitLab Duo Agent Platform을 위한 확장#

GitLab Duo Agent Platform은 표준 GitLab 워크로드 외에 추가 인프라 요구 사항을 만듭니다. Agent Platform 워크플로는 GitLab Rails API를 통해 실행되고, Sidekiq로 job을 비동기 처리하며, 코드 컨텍스트와 분석을 위해 리포지터리 데이터에 접근합니다.

Agent Platform 사용량은 사용자 수가 아니라 자동화와 에이전트 활동에 따라 늘어나므로, 참조 아키텍처 RPS 목표의 근거가 된 트래픽 패턴을 따르지 않습니다. 사용자 수에 맞게 올바르게 크기를 정한 환경도 에이전트 워크로드 때문에 지속적인 리소스 압박을 받을 수 있습니다. 표준 크기 산정이 Agent Platform 사용량까지 반영한다고 가정하지 말고, 아래 구성 요소를 직접 모니터링합니다.

주요 구성 요소별 영향은 다음과 같습니다:

• Rails(Webservice/Puma) - Agent Platform API 요청이 전체 요청 부하에 더해지며, AI 응답 스트리밍용 WebSocket 연결은 Workhorse가 관리합니다
• Sidekiq - AI 완성 job과 워크플로 상태 업데이트가 백그라운드 job으로 처리됩니다
• PostgreSQL - 에이전트 워크플로 세션과 상태 데이터가 데이터베이스에 저장됩니다
• Gitaly - 코드 컨텍스트를 위한 리포지터리 파일 접근과 에이전트가 생성한 변경 사항의 커밋 작업이 발생합니다

Agent Platform 도입을 계획하는 환경에서는 다음을 진행합니다:

• 표준 워크로드 RPS를 기준으로 권장 아키텍처 크기를 배포합니다
• 초기 롤아웃 중 Rails CPU 사용률을 모니터링합니다
• Sidekiq CPU 사용률과 job 큐 적재량을 모니터링합니다
• 워크플로 상태 관리로 트랜잭션 비율이 늘어나는지 PostgreSQL을 모니터링합니다
• 코드 분석 기능으로 파일 접근 패턴이 늘어나는지 Gitaly를 모니터링합니다

이 구성 요소를 모니터링하는 Prometheus 쿼리 예시는 Prometheus 샘플 쿼리를 참고합니다.

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

리소스 요구 사항은 Agent Platform 사용 강도와 활성화한 기능에 따라 달라집니다. 권장 아키텍처 크기는 Agent Platform 도입의 시작점으로 보고, 충분한 여유 용량이 보장된다고 여기지 말고 관측한 지표에 따라 확장합니다.

확장 방법#

대부분의 구성 요소는 통상적인 방식으로 수직·수평 확장을 적용할 수 있습니다. 다만 그 전에 다음 주의 사항을 확인합니다:

• Puma나 Sidekiq를 수직으로 확장할 때는 추가된 사양을 활용하도록 워커 수를 조정해야 합니다. Puma 워커 수는 보통 자동으로 조정되지만, Sidekiq는 수동 구성이 필요할 수 있습니다.
• Redis와 PgBouncer는 기본적으로 단일 스레드입니다. 이 구성 요소에서 CPU 소진이 나타나면 수평으로 확장해야 할 수 있습니다.
• Linux 패키지 배포에서 Consul, Redis Sentinel, Praefect 구성 요소는 HA 형태로 배포할 때 투표 쿼럼을 위해 홀수 개 노드가 필요합니다.
• 특정 구성 요소를 크게 확장하면 환경 성능에 영향을 주는 연쇄 효과가 나타날 수 있습니다. 자세한 안내는 확장의 연쇄 효과를 참고합니다.

반대로 환경이 과잉 프로비저닝되었음을 보여 주는 신뢰할 수 있는 지표가 있다면 축소할 수 있습니다. 축소할 때는 문제가 없는지 확인하면서 반복적으로 진행합니다.

확장의 연쇄 효과#

구성 요소를 크게 확장하면 경우에 따라 다운스트림 구성 요소에 연쇄 효과가 생겨 성능에 영향을 줄 수 있습니다. 이 아키텍처는 서로 의존하는 구성 요소의 사양이 균형을 이루도록 설계했습니다. 특히 한 구성 요소를 확장하면 그 구성 요소가 의존하는 다른 구성 요소로 처리량이 더 넘어갈 수 있습니다. 그 결과 의존 관계에 있는 다른 구성 요소도 함께 확장해야 할 수 있습니다. 이를 판단하려면 확장 전에 모든 의존 서비스의 포화 지표를 모니터링합니다. 서로 의존하는 구성 요소 여러 개가 포화를 보이면 순차적으로 확장하기보다 조율해 함께 확장하며, 병목이 구성 요소 사이를 옮겨 다니지 않게 합니다.

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

• Puma 및 Sidekiq - Puma나 Sidekiq 워커를 크게 늘리면 내부 로드 밸런서, PostgreSQL(PgBouncer가 있으면 PgBouncer 경유), Gitaly(Praefect가 있으면 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 프로젝트에서 확인할 수 있습니다.