참조 아키텍처: Cloud Native First (베타)

요약

Cloud Native First 참조 아키텍처는 워크로드 특성에 따른 네 가지 표준화된 크기(S/M/L/XL)를 갖춘 현대적인 클라우드 네이티브 배포 패턴을 위해 설계되었습니다. 이 아키텍처들은 베타 상태입니다. Cloud Native First 아키텍처는 Kubernetes와 외부 서비스에 걸쳐 GitLab 구성요소를 배포합니다:

Cloud Native First 참조 아키텍처는 워크로드 특성에 따른 네 가지 표준화된 크기(S/M/L/XL)를 갖춘 현대적인 클라우드 네이티브 배포 패턴을 위해 설계되었습니다. 이 아키텍처는 모든 GitLab 구성요소를 Kubernetes에 배포하는 반면, PostgreSQL, Redis 및 Object Storage는 관리형 서비스 또는 온프레미스 옵션을 포함한 외부 서드파티 솔루션을 사용합니다.

Note

이 아키텍처들은 베타 상태입니다. 피드백을 환영하며 프로덕션 사용 데이터를 기반으로 사양을 계속 개선해 나갈 예정입니다.

아키텍처 개요#

Cloud Native First 아키텍처는 Kubernetes와 외부 서비스에 걸쳐 GitLab 구성요소를 배포합니다:

PlantUML 다이어그램 (36줄)

소스 코드 보기

@startuml kubernetes
skinparam linetype ortho
card "Kubernetes via Helm Charts" as kubernetes {
collections "Webservice Pods\n//Auto-scaling//" as web #32CD32
collections "Sidekiq Pods\n//Auto-scaling//" as sidekiq #ff8dd1
collections "Gitaly Pods\n//StatefulSets//" as gitaly #FF8C00
collections "Supporting Pods\n//Gateway API / Ingress, Toolbox//" as support #e76a9b
}
card "External Services" as external {
collections "PostgreSQL" as database #4EA7FF
collections "Redis Cache" as redis_cache #FF6347
collections "Redis Persistent" as redis_persistent #FF6347
cloud "Object Storage" as object_storage #white
}
kubernetes -[hidden]---> external
web -[#32CD32,norank]--> object_storage
web -[#32CD32,norank]--> redis_cache
web -[#32CD32,norank]--> redis_persistent
web -[#32CD32,norank]--> database
sidekiq -[#ff8dd1,norank]--> object_storage
sidekiq -[#ff8dd1,norank]--> redis_cache
sidekiq -[#ff8dd1,norank]--> redis_persistent
sidekiq -[#ff8dd1,norank]--> database
@enduml

Kubernetes 구성요소:

Webservice - 웹 요청 처리
Sidekiq - 백그라운드 작업 처리
Gitaly - 영구 볼륨이 있는 StatefulSets를 사용하여 Git 저장소 관리
지원 서비스 - Gateway API / Ingress, Toolbox 및 모니터링 구성요소

Note

Kubernetes의 Gitaly는 Gitaly 샤딩(비클러스터) 방식으로만 배포되며 무중단 업그레이드를 지원하지 않습니다. 각 Gitaly 파드는 처리하는 저장소에 대한 단일 장애 지점입니다. Gitaly 클러스터(Praefect)는 Kubernetes에서 지원되지 않습니다.

자동 장애 조치 기능이 있는 Gitaly 고가용성이 필요한 경우, 상태 비저장 구성요소를 Kubernetes에서 실행하는 동시에 가상 머신에 Gitaly 클러스터를 배포하는 Cloud Native Hybrid 아키텍처를 고려하십시오. Kubernetes에서 Gitaly의 요구 사항 및 제한 사항은 Kubernetes의 Gitaly를 참조하십시오.

외부 서비스:

PostgreSQL - 고가용성을 위한 선택적 스탠바이 복제본과 추가 안정성 및 성능을 위한 읽기 복제본으로 배포되는 관리형 데이터베이스 서비스
Redis - 각각 고가용성을 위한 선택적 스탠바이 복제본으로 배포되는 별도의 캐시 및 영구 인스턴스
Object Storage - 아티팩트 및 패키지를 위한 S3, Google Cloud Storage 또는 Azure Blob Storage 같은 Object Storage 서비스

권장 관리형 서비스 제공자(GCP Cloud SQL, AWS RDS, Azure Database 등)는 권장 클라우드 제공자 및 서비스를 참조하십시오.

사용 가능한 아키텍처#

이 아키텍처들은 일반적인 프로덕션 워크로드 패턴을 나타내는 목표 RPS 범위를 기반으로 설계되었습니다. RPS 목표는 시작점으로 제공되며, 실제 용량 요구 사항은 워크로드 구성 및 사용 패턴에 따라 다릅니다. RPS 구성 및 조정이 필요한 시기에 대한 지침은 RPS 구성 이해를 참조하십시오.

크기	목표 RPS	의도한 워크로드
S	≤100	가벼운 개발 활동과 최소한의 자동화를 가진 팀
M	≤200	중간 개발 속도와 표준 CI/CD 사용을 가진 조직
L	≤500	활발한 개발 활동과 상당한 자동화를 가진 대규모 팀
XL	≤1000	집중적인 워크로드와 광범위한 통합을 가진 엔터프라이즈 배포

예상 부하를 결정하고 적절한 크기를 선택하는 방법에 대한 자세한 지침은 참조 아키텍처 크기 선정 가이드를 참조하십시오.

주요 이점#

Cloud Native First 아키텍처는 다음을 제공합니다:

자가 복구 인프라 - Kubernetes는 실패한 파드를 자동으로 재시작하고 정상 노드에 워크로드를 다시 예약합니다
동적 리소스 스케일링 - Horizontal Pod Autoscaler와 Cluster Autoscaler가 실제 수요에 따라 용량을 조정합니다
단순화된 배포 - GitLab 구성요소에 대한 전통적인 VM 관리 없이 모두 Kubernetes를 통해 오케스트레이션됩니다
운영 오버헤드 감소 - PostgreSQL, Redis 및 Object Storage의 관리형 서비스로 데이터베이스 및 캐시 유지 관리가 필요 없습니다
기본 고가용성 - 모든 구성요소에 대한 자동 장애 조치 기능이 있는 멀티 영역 배포
향상된 비용 효율성 - 피크 용량을 유지하면서 수요가 낮은 기간에 리소스가 축소됩니다

요구 사항#

Cloud Native First 아키텍처를 배포하기 전에 다음을 확인하십시오:

지원되는 Kubernetes 클러스터 및 기타 Charts 전제 조건이 갖춰져 있어야 합니다
데이터베이스, 사용자 및 확장이 구성된 외부 PostgreSQL 인스턴스
외부 Redis 인스턴스
Object Storage 서비스 (S3, Google Cloud Storage, Azure Blob Storage 또는 기타)

네트워킹, 머신 유형 및 클라우드 제공자 서비스를 포함한 전체 요구 사항은 참조 아키텍처 요구 사항을 참조하십시오.

Kubernetes의 Gitaly 특정 요구 사항 및 제한 사항은 Kubernetes의 Gitaly 요구 사항을 참조하십시오.

소형 (S)#

목표 부하: ≤100 RPS | 가벼운 전체 부하

워크로드 특성:

총 RPS 범위: 초당 ≤100 요청
Git 작업: 가벼운 Git push 및 pull 활동
저장소 크기: 활발하게 사용되는 모노레포에는 적합하지 않음
CI/CD 사용: 가벼운 동시 파이프라인 실행
API 트래픽: 자동화된 워크로드를 위한 가벼운 용량
사용자 패턴: 사용량 급증에 대한 약간의 회복력

Kubernetes 구성요소#

구성요소	파드당 리소스	최소 파드/워커	최대 파드/워커	노드 구성 예시
Webservice	2 vCPU, 3 GB (request), 4 GB (limit)	12 파드 (24 워커)	18 파드 (36 워커)	GCP: 6 × n2-standard-8 AWS: 6 × c6i.2xlarge
Sidekiq	900m vCPU, 2 GB (request), 4 GB (limit)	8 워커	12 워커	GCP: 3 × n2-standard-4 AWS: 3 × m6i.xlarge
Gitaly	7 vCPU, 30 GB (request and limit)	3 파드	3 파드	GCP: 3 × n2-standard-8 AWS: 3 × m6i.2xlarge
Supporting	서비스별 변동	12 vCPU, 48 GB	12 vCPU, 48 GB	GCP: 3 × n2-standard-4 AWS: 3 × c6i.xlarge

파드 스케일링 구성#

구성요소	최소 → 최대 파드	최소 → 최대 워커	파드당 리소스	파드당 워커
Webservice	12 → 18	24 → 36	2 vCPU, 3 GB (request), 4 GB (limit)	2
Sidekiq	8 → 12	8 → 12	900m vCPU, 2 GB (request), 4 GB (limit)	1
Gitaly	3 (자동 스케일링 없음)	해당 없음	7 vCPU, 30 GB (request and limit)	해당 없음

Gitaly 참고 사항: Git cgroups: 27 GB, 버퍼: 3 GB. 저장소 cgroup이 1로 설정됩니다. 튜닝 지침은 Gitaly cgroups 구성을 참조하십시오.

외부 서비스#

서비스	구성	GCP 동급	AWS 동급
PostgreSQL	8 vCPU, 32 GB	n2-standard-8	m6i.2xlarge
Redis - Cache	2 vCPU, 8 GB	n2-standard-2	m6i.large
Redis - Persistent	2 vCPU, 8 GB	n2-standard-2	m6i.large
Object Storage	클라우드 제공자 서비스	Google Cloud Storage	Amazon S3

중형 (M)#

목표 부하: ≤200 RPS | 중간 전체 부하

워크로드 특성:

총 RPS 범위: 초당 ≤200 요청
Git 작업: 중간 Git push 및 pull 활동
저장소 크기: 가볍게 사용되는 모노레포 지원. 크거나 많이 사용되는 모노레포에는 성능 수정자가 필요할 수 있습니다
CI/CD 사용: 중간 파이프라인 동시성
API 트래픽: 표준 자동화 워크로드 지원
사용자 패턴: 사용량 변동에 대한 좋은 회복력

Kubernetes 구성요소#

구성요소	파드당 리소스	최소 파드/워커	최대 파드/워커	노드 구성 예시
Webservice	2 vCPU, 3 GB (request), 4 GB (limit)	28 파드 (56 워커)	42 파드 (84 워커)	GCP: 6 × n2-standard-16 AWS: 6 × c6i.4xlarge
Sidekiq	900m vCPU, 2 GB (request), 4 GB (limit)	16 워커	24 워커	GCP: 3 × n2-standard-8 AWS: 3 × m6i.2xlarge
Gitaly	15 vCPU, 62 GB (request and limit)	3 파드	3 파드	GCP: 3 × n2-standard-16 AWS: 3 × m6i.4xlarge
Supporting	서비스별 변동	12 vCPU, 48 GB	12 vCPU, 48 GB	GCP: 3 × n2-standard-4 AWS: 3 × c6i.xlarge

파드 스케일링 구성#

구성요소	최소 → 최대 파드	최소 → 최대 워커	파드당 리소스	파드당 워커
Webservice	28 → 42	56 → 84	2 vCPU, 3 GB (request), 4 GB (limit)	2
Sidekiq	16 → 24	16 → 24	900m vCPU, 2 GB (request), 4 GB (limit)	1
Gitaly	3 (자동 스케일링 없음)	해당 없음	15 vCPU, 62 GB (request and limit)	해당 없음

Gitaly 참고 사항: Git cgroups: 56 GB, 버퍼: 6 GB. 저장소 cgroup이 1로 설정됩니다. 튜닝 지침은 Gitaly cgroups 구성을 참조하십시오.

외부 서비스#

서비스	구성	GCP 동급	AWS 동급
PostgreSQL	16 vCPU, 64 GB	n2-standard-16	m6i.4xlarge
Redis - Cache	2 vCPU, 8 GB	n2-standard-2	m6i.large
Redis - Persistent	2 vCPU, 8 GB	n2-standard-2	m6i.large
Object Storage	클라우드 제공자 서비스	Google Cloud Storage	Amazon S3

대형 (L)#

목표 부하: ≤500 RPS | 무거운 전체 부하

워크로드 특성:

총 RPS 범위: 초당 ≤500 요청
Git 작업: 무거운 Git push 및 pull 활동
저장소 크기: 중간 정도로 사용되는 모노레포 지원. 크거나 많이 사용되는 모노레포에는 성능 수정자가 필요할 수 있습니다
CI/CD 사용: 적절한 Sidekiq 스케일링을 통한 무거운 파이프라인 사용
API 트래픽: 상당한 자동화 워크로드 지원
사용자 패턴: 사용량 변동에 대한 강한 회복력

Kubernetes 구성요소#

구성요소	파드당 리소스	최소 파드/워커	최대 파드/워커	노드 구성 예시
Webservice	2 vCPU, 3 GB (request), 4 GB (limit)	56 파드 (112 워커)	84 파드 (168 워커)	GCP: 6 × n2-standard-32 AWS: 6 × c6i.8xlarge
Sidekiq	900m vCPU, 2 GB (request), 4 GB (limit)	32 워커	48 워커	GCP: 6 × n2-standard-8 AWS: 6 × m6i.2xlarge
Gitaly	31 vCPU, 126 GB (request and limit)	3 파드	3 파드	GCP: 3 × n2-standard-32 AWS: 3 × m6i.8xlarge
Supporting	서비스별 변동	12 vCPU, 48 GB	12 vCPU, 48 GB	GCP: 3 × n2-standard-4 AWS: 3 × c6i.xlarge

파드 스케일링 구성#

구성요소	최소 → 최대 파드	최소 → 최대 워커	파드당 리소스	파드당 워커
Webservice	56 → 84	112 → 168	2 vCPU, 3 GB (request), 4 GB (limit)	2
Sidekiq	32 → 48	32 → 48	900m vCPU, 2 GB (request), 4 GB (limit)	1
Gitaly	3 (자동 스케일링 없음)	해당 없음	31 vCPU, 126 GB (request and limit)	해당 없음

Gitaly 참고 사항: Git cgroups: 120 GB, 버퍼: 6 GB. 저장소 cgroup이 1로 설정됩니다. 튜닝 지침은 Gitaly cgroups 구성을 참조하십시오.

외부 서비스#

서비스	구성	GCP 동급	AWS 동급
PostgreSQL	32 vCPU, 128 GB	n2-standard-32	m6i.8xlarge
Redis - Cache	2 vCPU, 16 GB	n2-highmem-2	r6i.large
Redis - Persistent	2 vCPU, 16 GB	n2-highmem-2	r6i.large
Object Storage	클라우드 제공자 서비스	Google Cloud Storage	Amazon S3

특대형 (XL)#

목표 부하: ≤1000 RPS | 집중적인 전체 부하

워크로드 특성:

총 RPS 범위: 초당 ≤1000 요청
Git 작업: 집중적인 Git push 및 pull 활동
저장소 크기: 많이 사용되는 모노레포 지원. 크거나 집중적으로 사용되는 모노레포에는 성능 수정자가 필요할 수 있습니다
CI/CD 사용: 집중적인 CI/CD 워크로드
API 트래픽: 무거운 자동화 및 통합 트래픽
사용자 패턴: 다양한 액세스 패턴을 위해 설계됨

Kubernetes 구성요소#

구성요소	파드당 리소스	최소 파드/워커	최대 파드/워커	노드 구성 예시
Webservice	2 vCPU, 3 GB (request), 4 GB (limit)	110 파드 (220 워커)	165 파드 (330 워커)	GCP: 6 × n2-standard-64 AWS: 6 × c6i.16xlarge
Sidekiq	900m vCPU, 2 GB (request), 4 GB (limit)	64 워커	96 워커	GCP: 6 × n2-standard-16 AWS: 6 × m6i.4xlarge
Gitaly	63 vCPU, 254 GB (request and limit)	3 파드	3 파드	GCP: 3 × n2-standard-64 AWS: 3 × m6i.16xlarge
Supporting	서비스별 변동	24 vCPU, 96 GB	24 vCPU, 96 GB	GCP: 3 × n2-standard-8 AWS: 3 × c6i.2xlarge

파드 스케일링 구성#

구성요소	최소 → 최대 파드	최소 → 최대 워커	파드당 리소스	파드당 워커
Webservice	110 → 165	220 → 330	2 vCPU, 3 GB (request), 4 GB (limit)	2
Sidekiq	64 → 96	64 → 96	900m vCPU, 2 GB (request), 4 GB (limit)	1
Gitaly	3 (자동 스케일링 없음)	해당 없음	63 vCPU, 254 GB (request and limit)	해당 없음

Gitaly 참고 사항: Git cgroups: 248 GB, 버퍼: 6 GB. 저장소 cgroup이 1로 설정됩니다. 튜닝 지침은 Gitaly cgroups 구성을 참조하십시오.

외부 서비스#

서비스	구성	GCP 동급	AWS 동급
PostgreSQL	64 vCPU, 256 GB	n2-standard-64	m6i.16xlarge
Redis - Cache	2 vCPU, 16 GB	n2-highmem-2	r6i.large
Redis - Persistent	2 vCPU, 16 GB	n2-highmem-2	r6i.large
Object Storage	클라우드 제공자 서비스	Google Cloud Storage	Amazon S3

추가 정보#

이 섹션에서는 머신 유형 선택, 구성요소별 고려 사항 및 스케일링 전략을 포함하여 Cloud Native First 아키텍처를 배포하고 운영하기 위한 보충 지침을 제공합니다.

머신 유형 지침#

표시된 머신 유형은 검증 및 테스트에 사용되는 예시입니다. 다음을 사용할 수 있습니다:

최신 세대 머신 유형
ARM 기반 인스턴스 (AWS Graviton)
사양을 충족하거나 초과하는 다른 머신 패밀리
특정 요구에 맞게 크기가 조정된 사용자 정의 머신 유형

일관성 없는 성능으로 인해 버스터블 인스턴스 유형을 사용하지 마십시오.

자세한 내용은 지원되는 머신 유형을 참조하십시오.

Gitaly 고려 사항#

Cloud Native First 아키텍처의 Kubernetes의 Gitaly는 다음 사양을 가진 StatefulSets를 사용합니다:

전용 노드 배치 - Gitaly 파드는 시끄러운 이웃 문제를 피하기 위해 전용 노드에 배포됩니다.
리소스 할당 - 파드 요청 및 제한이 오버헤드를 뺀 노드 용량으로 설정됩니다 (Kubernetes 시스템 프로세스를 위해 2 GB 메모리, 1 vCPU 예약).
Git cgroups 메모리 - 기본적으로 10% 버퍼로 할당되며, 더 큰 파드의 경우 최대 6 GB로 제한됩니다. 예를 들어, 소형은 3 GB 버퍼로 Git cgroups에 27 GB를 할당하는 반면, 중형 이상의 크기는 6 GB 캡을 사용합니다(중형은 6 GB 버퍼로 56 GB cgroups).

Gitaly 배포 모드:

설계상 Kubernetes의 Gitaly(비클러스터)는 각 파드에 저장된 저장소에 대한 단일 장애 지점 서비스입니다. 데이터는 파드당 단일 인스턴스에서 소싱되고 제공됩니다. 각 Gitaly 파드는 자체 저장소 세트를 관리하여 저장소 배포를 통한 Git 저장소의 수평적 스케일링을 제공합니다.

Gitaly 클러스터(Praefect)는 Cloud Native First 아키텍처에서 지원되지 않습니다. Kubernetes의 Gitaly 배포 제한 사항에 대한 내용은 Kubernetes의 Gitaly를 참조하십시오.

저장소 배포:

여러 Gitaly 스토리지가 구성된 경우(예: default, storage1, storage2), GitLab은 기본적으로 모든 새 저장소를 default 스토리지에 만듭니다. 모든 Gitaly 파드에 걸쳐 저장소를 배포하려면 스토리지 가중치를 구성하여 부하를 분산하십시오.

저장소 스토리지 가중치 구성 지침은 새 저장소가 저장될 위치 구성을 참조하십시오.

Gitaly cgroups 구성#

Gitaly는 cgroups를 사용하여 개별 Git 작업으로 인한 리소스 고갈로부터 보호합니다. 기본 구성은 저장소 cgroup 수를 1로 설정하며, 이는 오버서브스크립션을 통해 모든 단일 저장소가 전체 파드 리소스를 사용할 수 있는 시작점을 제공합니다.

그러나 이 구성이 모든 워크로드에 최적화되지 않을 수 있습니다. 많은 활성 저장소 또는 특정 리소스 격리 요구 사항이 있는 환경의 경우, 관찰된 사용 패턴에 따라 cgroups 구성을 조정해야 합니다. 여기에는 저장소 cgroup 수와 메모리 할당 조정이 포함됩니다.

Gitaly cgroups 측정, 조정 및 구성에 대한 자세한 지침은 Gitaly cgroups를 참조하십시오.

대형 모노레포(2 GB 이상) 또는 집중적인 Git 워크로드의 경우 추가 Gitaly 조정이 필요할 수 있습니다. 자세한 지침은 참조 아키텍처 크기 선정 가이드를 참조하십시오.

외부 서비스 참고 사항#

PostgreSQL은 고가용성을 위한 스탠바이 복제본으로 배포할 수 있습니다. 추가 안정성 및 성능을 위해 읽기 복제본을 추가할 수 있습니다. 대규모 환경(L, XL)은 데이터베이스 부하를 분산하기 위해 읽기 복제본에서 더 많은 이점을 얻습니다.
Redis 인스턴스는 고가용성을 위한 스탠바이 복제본으로 배포할 수 있습니다. GCP에서 Memorystore 인스턴스는 메모리로만 구성됩니다. 머신 사양은 참고용으로 표시됩니다.
인스턴스 구성이 포함된 모든 클라우드 제공자 서비스의 경우, 탄력적인 클라우드 아키텍처 관행에 맞추기 위해 세 개의 다른 가용성 영역에 최소 세 개의 노드를 구현하는 것이 권장됩니다.

자동 스케일링 및 최소 파드 수#

모든 아키텍처는 Kubernetes Horizontal Pod Autoscaler(HPA) 및 Cluster Autoscaler를 사용하여 용량을 관리합니다:

Webservice - 보수적인 최소 파드 수로 CPU 활용률에 따라 스케일링
Sidekiq - CPU 활용률에 따라 스케일링
Cluster Autoscaler - 파드 리소스 요청에 따라 자동으로 노드 프로비저닝 및 제거

내부 테스트를 통해 다음 목표를 달성하기 위해 최소 파드 수는 최대의 약 2/3로 설정됩니다:

수요 증가 시 응답적인 스케일링
노드 장애 또는 업그레이드 중 충분한 용량
수요가 낮은 기간의 비용 최적화

워크로드 패턴을 잘 이해하고 있는 경우 필요에 따라 최솟값을 조정할 수 있습니다:

급격한 트래픽 급증 또는 엄격한 성능 SLA가 있는 환경의 경우 최솟값 증가
모니터링에서 지속적인 부하가 기본값보다 낮게 유지되는 것이 확인된 후 최솟값 감소

고급 스케일링#

Cloud Native First 아키텍처는 기본 사양을 초과하여 스케일링되도록 설계되었습니다. 환경에 다음이 있는 경우 용량을 조정해야 할 수 있습니다:

나열된 RPS 목표보다 지속적으로 높은 처리량
비정형 워크로드 구성 (RPS 구성 이해 참조)
대형 모노레포 (2 GB 이상)
상당한 추가 워크로드
광범위한 GitLab Duo Agent Platform 사용

스케일링 전략은 구성요소 유형에 따라 다릅니다.

수평 스케일링 (Webservice 및 Sidekiq)#

용량 증가를 위해 최대 복제본 수와 노드 풀 용량을 조정하여 수평으로 스케일링합니다:

Webservice - Helm 값에서 maxReplicas를 늘리고 Webservice 노드 풀에 해당 노드를 추가합니다
Sidekiq - 더 높은 작업 처리량을 처리하기 위해 maxReplicas를 늘리고 Sidekiq 노드 풀에 노드를 추가합니다

수평 스케일링은 이러한 상태 비저장 구성요소에 권장되는 방법입니다.

수직 스케일링 (PostgreSQL, Redis, Gitaly)#

상태 저장 구성요소의 경우 인스턴스 또는 파드 사양을 늘립니다:

PostgreSQL 및 Redis - 관리형 서비스 제공자를 통해 더 큰 인스턴스 유형으로 업그레이드합니다.
Gitaly - 파드당 CPU 및 메모리 사양을 늘립니다. 이를 위해 Gitaly 노드 풀에 더 큰 노드 유형이 필요하며 Git cgroups 메모리 할당에 해당하는 조정이 필요합니다.

Sidekiq 큐 최적화#

기본적으로 Sidekiq는 모든 작업 유형을 단일 큐에서 처리합니다. 다양한 워크로드 패턴이 있는 환경의 경우 작업 특성에 따라 별도의 큐를 구성할 수 있습니다:

높은 긴급도 큐 - CI 파이프라인 처리 및 웹훅 전달과 같은 시간에 민감한 작업용
CPU 집약적 큐 - 동시성 설정을 조정한 컴퓨팅 집약적 작업용
기본 큐 - 표준 백그라운드 처리용

큐 분리는 작업 처리 신뢰성을 향상시키고 무거운 자동화 워크로드를 가진 대규모 환경(L, XL)에서 낮은 우선순위 작업이 시간에 민감한 작업을 차단하는 것을 방지할 수 있습니다.

Sidekiq 큐 구성에 대한 자세한 내용은 특정 작업 클래스 처리를 참조하십시오.

GitLab Duo Agent Platform 스케일링#

GitLab Duo Agent Platform은 표준 GitLab 워크로드를 넘어서는 추가 인프라 요구 사항을 도입합니다. Agent Platform 도입을 위한 모니터링 및 스케일링에 대한 자세한 지침은 GitLab Duo Agent Platform 스케일링을 참조하십시오.

스케일링 고려 사항#

구성요소를 크게 스케일링할 때:

종속 구성요소의 리소스 포화를 모니터링합니다. Webservice 또는 Sidekiq의 부하 증가는 PostgreSQL 및 Gitaly에 영향을 줄 수 있습니다.
프로덕션 외 환경에서 먼저 스케일링 변경 사항을 테스트합니다.
서비스 간 병목 현상 이동을 방지하기 위해 상호 의존적인 구성요소를 함께 스케일링합니다.

포괄적인 스케일링 지침은 환경 스케일링을 참조하십시오.

배포#

Cloud Native First 아키텍처는 Helm 차트와 외부 서비스 제공자를 사용하여 직접 또는 GitLab Environment Toolkit을 통해 배포할 수 있습니다.

GitLab Environment Toolkit#

GitLab Environment Toolkit은 다음을 통해 자동화된 배포를 제공합니다:

클라우드 리소스를 위한 Infrastructure as Code (Terraform)
자동화된 Helm 차트 구성
각 아키텍처 크기에 대한 사전 검증된 설정
단순화된 업그레이드 및 유지 관리

배포 지침은 GitLab Environment Toolkit 문서를 참조하십시오.

수동 배포#

수동 배포를 위한 사전 요건:

필요한 데이터베이스, 사용자 및 권한이 설정된 외부 PostgreSQL
구성 및 액세스 가능한 외부 Redis 인스턴스
생성된 Object Storage 버킷
필요에 따라 인증을 위한 Kubernetes 시크릿 생성 (PostgreSQL 비밀번호, Redis 비밀번호, Object Storage 자격 증명, GitLab 시크릿)

자세한 전제 조건 및 시크릿 구성은 GitLab 차트 전제 조건 및 시크릿 구성을 참조하십시오.

Helm 차트를 사용한 수동 배포:

전제 조건에 설명된 대로 필요한 외부 서비스 및 시크릿을 설정합니다
적절한 노드 풀과 자동 스케일러로 Kubernetes 클러스터를 구성합니다
Helm 차트 구성 섹션에 표시된 Helm 값 구성을 적용합니다
helm install을 사용하여 GitLab을 배포합니다

자세한 수동 배포 단계는 Kubernetes에 GitLab 설치를 참조하십시오.

Helm 차트 구성#

완전한 Helm 차트 구성 예시와 자세한 배포 지침은 GitLab Charts 저장소를 참조하십시오.

Cloud Native First 아키텍처의 주요 구성 영역:

리소스 사양 - 파드 CPU 및 메모리 제한이 위의 각 아키텍처 크기 사양과 일치합니다
자동 스케일링 - HPA 구성이 최소 파드 수를 최대의 2/3로 설정하고 CPU 기반 스케일링 목표를 설정합니다
노드 배치 - 노드 선택기를 통해 적절한 노드 풀에 워크로드가 배포되도록 합니다 (예: webservice, sidekiq, gitaly, support)
외부 서비스 - PostgreSQL, Redis 및 Object Storage 연결 세부 정보
Gitaly - cgroups, 영속성 및 스토리지 배포를 포함하는 StatefulSet 구성

아키텍처별 복제본 수 및 리소스 값은 위의 각 크기 섹션의 사양을 참조하십시오.

Note

Cloud Native First 아키텍처는 베타 상태입니다. 기능이 일반 공개로 진행됨에 따라 특정 Helm 차트 구성 예시가 Charts 저장소에 추가될 예정입니다. 위의 각 아키텍처 크기 섹션의 사양을 사용하여 Helm 값 구성을 구성하십시오.

다음 단계#

배포 후 환경은 일반적으로 실제 워크로드 패턴에 맞추기 위한 모니터링 및 튜닝이 필요합니다.

모니터링 및 검증#

리소스 활용률 모니터링 - Prometheus를 사용하여 모든 구성요소의 CPU, 메모리 및 큐 깊이를 추적합니다
RPS 가정 검증 - 실제 RPS 분석을 가정된 80/10/10 구성과 비교합니다
잠재적 조정 사항 식별 - 지속적으로 70% 이상의 활용률에 있는 구성요소를 찾습니다
Gitaly cgroups 검토 - 저장소 액세스 패턴에 따라 저장소 cgroup 수 조정을 고려합니다

필요에 따라 조정#

참조 아키텍처는 시작점입니다. 많은 환경에서 다음을 기반으로 조정이 필요합니다:

실제 워크로드 구성 - API/웹/Git 분할이 일반적인 패턴과 크게 다른 경우, RPS 구성 이해를 참조하십시오
저장소 특성 - 모노레포 크기, 클론 빈도 및 액세스 패턴에 구성요소별 조정이 필요할 수 있습니다
성장 패턴 - 사용자 수 증가, CI/CD 확장 또는 자동화 스케일링

구성요소별 조정 지침은 고급 스케일링을 참조하십시오.

선택적 기능 구성#

요구 사항에 따라 GitLab의 추가 선택적 기능을 구성할 수 있습니다. 자세한 내용은 GitLab 설치 후 단계를 참조하십시오.

Note

선택적 기능에 추가 용량이 필요할 수 있습니다. 요구 사항은 기능별 문서를 참조하십시오.

참조 아키텍처: Cloud Native First (베타)

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

원문 보기

번역일: 2026-05-22

요약

Note

이 아키텍처들은 베타 상태입니다. 피드백을 환영하며 프로덕션 사용 데이터를 기반으로 사양을 계속 개선해 나갈 예정입니다.

아키텍처 개요#

Cloud Native First 아키텍처는 Kubernetes와 외부 서비스에 걸쳐 GitLab 구성요소를 배포합니다:

PlantUML 다이어그램 (36줄)

소스 코드 보기

@startuml kubernetes
skinparam linetype ortho
card "Kubernetes via Helm Charts" as kubernetes {
collections "Webservice Pods\n//Auto-scaling//" as web #32CD32
collections "Sidekiq Pods\n//Auto-scaling//" as sidekiq #ff8dd1
collections "Gitaly Pods\n//StatefulSets//" as gitaly #FF8C00
collections "Supporting Pods\n//Gateway API / Ingress, Toolbox//" as support #e76a9b
}
card "External Services" as external {
collections "PostgreSQL" as database #4EA7FF
collections "Redis Cache" as redis_cache #FF6347
collections "Redis Persistent" as redis_persistent #FF6347
cloud "Object Storage" as object_storage #white
}
kubernetes -[hidden]---> external
web -[#32CD32,norank]--> object_storage
web -[#32CD32,norank]--> redis_cache
web -[#32CD32,norank]--> redis_persistent
web -[#32CD32,norank]--> database
sidekiq -[#ff8dd1,norank]--> object_storage
sidekiq -[#ff8dd1,norank]--> redis_cache
sidekiq -[#ff8dd1,norank]--> redis_persistent
sidekiq -[#ff8dd1,norank]--> database
@enduml

Kubernetes 구성요소:

Webservice - 웹 요청 처리
Sidekiq - 백그라운드 작업 처리
Gitaly - 영구 볼륨이 있는 StatefulSets를 사용하여 Git 저장소 관리
지원 서비스 - Gateway API / Ingress, Toolbox 및 모니터링 구성요소

Note

외부 서비스:

PostgreSQL - 고가용성을 위한 선택적 스탠바이 복제본과 추가 안정성 및 성능을 위한 읽기 복제본으로 배포되는 관리형 데이터베이스 서비스
Redis - 각각 고가용성을 위한 선택적 스탠바이 복제본으로 배포되는 별도의 캐시 및 영구 인스턴스
Object Storage - 아티팩트 및 패키지를 위한 S3, Google Cloud Storage 또는 Azure Blob Storage 같은 Object Storage 서비스

권장 관리형 서비스 제공자(GCP Cloud SQL, AWS RDS, Azure Database 등)는 권장 클라우드 제공자 및 서비스를 참조하십시오.

사용 가능한 아키텍처#

크기	목표 RPS	의도한 워크로드
S	≤100	가벼운 개발 활동과 최소한의 자동화를 가진 팀
M	≤200	중간 개발 속도와 표준 CI/CD 사용을 가진 조직
L	≤500	활발한 개발 활동과 상당한 자동화를 가진 대규모 팀
XL	≤1000	집중적인 워크로드와 광범위한 통합을 가진 엔터프라이즈 배포

예상 부하를 결정하고 적절한 크기를 선택하는 방법에 대한 자세한 지침은 참조 아키텍처 크기 선정 가이드를 참조하십시오.

주요 이점#

Cloud Native First 아키텍처는 다음을 제공합니다:

자가 복구 인프라 - Kubernetes는 실패한 파드를 자동으로 재시작하고 정상 노드에 워크로드를 다시 예약합니다
동적 리소스 스케일링 - Horizontal Pod Autoscaler와 Cluster Autoscaler가 실제 수요에 따라 용량을 조정합니다
단순화된 배포 - GitLab 구성요소에 대한 전통적인 VM 관리 없이 모두 Kubernetes를 통해 오케스트레이션됩니다
운영 오버헤드 감소 - PostgreSQL, Redis 및 Object Storage의 관리형 서비스로 데이터베이스 및 캐시 유지 관리가 필요 없습니다
기본 고가용성 - 모든 구성요소에 대한 자동 장애 조치 기능이 있는 멀티 영역 배포
향상된 비용 효율성 - 피크 용량을 유지하면서 수요가 낮은 기간에 리소스가 축소됩니다

요구 사항#

Cloud Native First 아키텍처를 배포하기 전에 다음을 확인하십시오:

지원되는 Kubernetes 클러스터 및 기타 Charts 전제 조건이 갖춰져 있어야 합니다
데이터베이스, 사용자 및 확장이 구성된 외부 PostgreSQL 인스턴스
외부 Redis 인스턴스
Object Storage 서비스 (S3, Google Cloud Storage, Azure Blob Storage 또는 기타)

네트워킹, 머신 유형 및 클라우드 제공자 서비스를 포함한 전체 요구 사항은 참조 아키텍처 요구 사항을 참조하십시오.

Kubernetes의 Gitaly 특정 요구 사항 및 제한 사항은 Kubernetes의 Gitaly 요구 사항을 참조하십시오.

소형 (S)#

목표 부하: ≤100 RPS | 가벼운 전체 부하

워크로드 특성:

총 RPS 범위: 초당 ≤100 요청
Git 작업: 가벼운 Git push 및 pull 활동
저장소 크기: 활발하게 사용되는 모노레포에는 적합하지 않음
CI/CD 사용: 가벼운 동시 파이프라인 실행
API 트래픽: 자동화된 워크로드를 위한 가벼운 용량
사용자 패턴: 사용량 급증에 대한 약간의 회복력

Kubernetes 구성요소#

구성요소	파드당 리소스	최소 파드/워커	최대 파드/워커	노드 구성 예시
Webservice	2 vCPU, 3 GB (request), 4 GB (limit)	12 파드 (24 워커)	18 파드 (36 워커)	GCP: 6 × n2-standard-8 AWS: 6 × c6i.2xlarge
Sidekiq	900m vCPU, 2 GB (request), 4 GB (limit)	8 워커	12 워커	GCP: 3 × n2-standard-4 AWS: 3 × m6i.xlarge
Gitaly	7 vCPU, 30 GB (request and limit)	3 파드	3 파드	GCP: 3 × n2-standard-8 AWS: 3 × m6i.2xlarge
Supporting	서비스별 변동	12 vCPU, 48 GB	12 vCPU, 48 GB	GCP: 3 × n2-standard-4 AWS: 3 × c6i.xlarge

파드 스케일링 구성#

구성요소	최소 → 최대 파드	최소 → 최대 워커	파드당 리소스	파드당 워커
Webservice	12 → 18	24 → 36	2 vCPU, 3 GB (request), 4 GB (limit)	2
Sidekiq	8 → 12	8 → 12	900m vCPU, 2 GB (request), 4 GB (limit)	1
Gitaly	3 (자동 스케일링 없음)	해당 없음	7 vCPU, 30 GB (request and limit)	해당 없음

Gitaly 참고 사항: Git cgroups: 27 GB, 버퍼: 3 GB. 저장소 cgroup이 1로 설정됩니다. 튜닝 지침은 Gitaly cgroups 구성을 참조하십시오.

외부 서비스#

서비스	구성	GCP 동급	AWS 동급
PostgreSQL	8 vCPU, 32 GB	n2-standard-8	m6i.2xlarge
Redis - Cache	2 vCPU, 8 GB	n2-standard-2	m6i.large
Redis - Persistent	2 vCPU, 8 GB	n2-standard-2	m6i.large
Object Storage	클라우드 제공자 서비스	Google Cloud Storage	Amazon S3

중형 (M)#

목표 부하: ≤200 RPS | 중간 전체 부하

워크로드 특성:

총 RPS 범위: 초당 ≤200 요청
Git 작업: 중간 Git push 및 pull 활동
저장소 크기: 가볍게 사용되는 모노레포 지원. 크거나 많이 사용되는 모노레포에는 성능 수정자가 필요할 수 있습니다
CI/CD 사용: 중간 파이프라인 동시성
API 트래픽: 표준 자동화 워크로드 지원
사용자 패턴: 사용량 변동에 대한 좋은 회복력

Kubernetes 구성요소#

구성요소	파드당 리소스	최소 파드/워커	최대 파드/워커	노드 구성 예시
Webservice	2 vCPU, 3 GB (request), 4 GB (limit)	28 파드 (56 워커)	42 파드 (84 워커)	GCP: 6 × n2-standard-16 AWS: 6 × c6i.4xlarge
Sidekiq	900m vCPU, 2 GB (request), 4 GB (limit)	16 워커	24 워커	GCP: 3 × n2-standard-8 AWS: 3 × m6i.2xlarge
Gitaly	15 vCPU, 62 GB (request and limit)	3 파드	3 파드	GCP: 3 × n2-standard-16 AWS: 3 × m6i.4xlarge
Supporting	서비스별 변동	12 vCPU, 48 GB	12 vCPU, 48 GB	GCP: 3 × n2-standard-4 AWS: 3 × c6i.xlarge

파드 스케일링 구성#

구성요소	최소 → 최대 파드	최소 → 최대 워커	파드당 리소스	파드당 워커
Webservice	28 → 42	56 → 84	2 vCPU, 3 GB (request), 4 GB (limit)	2
Sidekiq	16 → 24	16 → 24	900m vCPU, 2 GB (request), 4 GB (limit)	1
Gitaly	3 (자동 스케일링 없음)	해당 없음	15 vCPU, 62 GB (request and limit)	해당 없음

Gitaly 참고 사항: Git cgroups: 56 GB, 버퍼: 6 GB. 저장소 cgroup이 1로 설정됩니다. 튜닝 지침은 Gitaly cgroups 구성을 참조하십시오.

외부 서비스#

서비스	구성	GCP 동급	AWS 동급
PostgreSQL	16 vCPU, 64 GB	n2-standard-16	m6i.4xlarge
Redis - Cache	2 vCPU, 8 GB	n2-standard-2	m6i.large
Redis - Persistent	2 vCPU, 8 GB	n2-standard-2	m6i.large
Object Storage	클라우드 제공자 서비스	Google Cloud Storage	Amazon S3

대형 (L)#

목표 부하: ≤500 RPS | 무거운 전체 부하

워크로드 특성:

총 RPS 범위: 초당 ≤500 요청
Git 작업: 무거운 Git push 및 pull 활동
저장소 크기: 중간 정도로 사용되는 모노레포 지원. 크거나 많이 사용되는 모노레포에는 성능 수정자가 필요할 수 있습니다
CI/CD 사용: 적절한 Sidekiq 스케일링을 통한 무거운 파이프라인 사용
API 트래픽: 상당한 자동화 워크로드 지원
사용자 패턴: 사용량 변동에 대한 강한 회복력

Kubernetes 구성요소#

구성요소	파드당 리소스	최소 파드/워커	최대 파드/워커	노드 구성 예시
Webservice	2 vCPU, 3 GB (request), 4 GB (limit)	56 파드 (112 워커)	84 파드 (168 워커)	GCP: 6 × n2-standard-32 AWS: 6 × c6i.8xlarge
Sidekiq	900m vCPU, 2 GB (request), 4 GB (limit)	32 워커	48 워커	GCP: 6 × n2-standard-8 AWS: 6 × m6i.2xlarge
Gitaly	31 vCPU, 126 GB (request and limit)	3 파드	3 파드	GCP: 3 × n2-standard-32 AWS: 3 × m6i.8xlarge
Supporting	서비스별 변동	12 vCPU, 48 GB	12 vCPU, 48 GB	GCP: 3 × n2-standard-4 AWS: 3 × c6i.xlarge

파드 스케일링 구성#

구성요소	최소 → 최대 파드	최소 → 최대 워커	파드당 리소스	파드당 워커
Webservice	56 → 84	112 → 168	2 vCPU, 3 GB (request), 4 GB (limit)	2
Sidekiq	32 → 48	32 → 48	900m vCPU, 2 GB (request), 4 GB (limit)	1
Gitaly	3 (자동 스케일링 없음)	해당 없음	31 vCPU, 126 GB (request and limit)	해당 없음

Gitaly 참고 사항: Git cgroups: 120 GB, 버퍼: 6 GB. 저장소 cgroup이 1로 설정됩니다. 튜닝 지침은 Gitaly cgroups 구성을 참조하십시오.

외부 서비스#

서비스	구성	GCP 동급	AWS 동급
PostgreSQL	32 vCPU, 128 GB	n2-standard-32	m6i.8xlarge
Redis - Cache	2 vCPU, 16 GB	n2-highmem-2	r6i.large
Redis - Persistent	2 vCPU, 16 GB	n2-highmem-2	r6i.large
Object Storage	클라우드 제공자 서비스	Google Cloud Storage	Amazon S3

특대형 (XL)#

목표 부하: ≤1000 RPS | 집중적인 전체 부하

워크로드 특성:

총 RPS 범위: 초당 ≤1000 요청
Git 작업: 집중적인 Git push 및 pull 활동
저장소 크기: 많이 사용되는 모노레포 지원. 크거나 집중적으로 사용되는 모노레포에는 성능 수정자가 필요할 수 있습니다
CI/CD 사용: 집중적인 CI/CD 워크로드
API 트래픽: 무거운 자동화 및 통합 트래픽
사용자 패턴: 다양한 액세스 패턴을 위해 설계됨

Kubernetes 구성요소#

구성요소	파드당 리소스	최소 파드/워커	최대 파드/워커	노드 구성 예시
Webservice	2 vCPU, 3 GB (request), 4 GB (limit)	110 파드 (220 워커)	165 파드 (330 워커)	GCP: 6 × n2-standard-64 AWS: 6 × c6i.16xlarge
Sidekiq	900m vCPU, 2 GB (request), 4 GB (limit)	64 워커	96 워커	GCP: 6 × n2-standard-16 AWS: 6 × m6i.4xlarge
Gitaly	63 vCPU, 254 GB (request and limit)	3 파드	3 파드	GCP: 3 × n2-standard-64 AWS: 3 × m6i.16xlarge
Supporting	서비스별 변동	24 vCPU, 96 GB	24 vCPU, 96 GB	GCP: 3 × n2-standard-8 AWS: 3 × c6i.2xlarge

파드 스케일링 구성#

구성요소	최소 → 최대 파드	최소 → 최대 워커	파드당 리소스	파드당 워커
Webservice	110 → 165	220 → 330	2 vCPU, 3 GB (request), 4 GB (limit)	2
Sidekiq	64 → 96	64 → 96	900m vCPU, 2 GB (request), 4 GB (limit)	1
Gitaly	3 (자동 스케일링 없음)	해당 없음	63 vCPU, 254 GB (request and limit)	해당 없음

Gitaly 참고 사항: Git cgroups: 248 GB, 버퍼: 6 GB. 저장소 cgroup이 1로 설정됩니다. 튜닝 지침은 Gitaly cgroups 구성을 참조하십시오.

외부 서비스#

서비스	구성	GCP 동급	AWS 동급
PostgreSQL	64 vCPU, 256 GB	n2-standard-64	m6i.16xlarge
Redis - Cache	2 vCPU, 16 GB	n2-highmem-2	r6i.large
Redis - Persistent	2 vCPU, 16 GB	n2-highmem-2	r6i.large
Object Storage	클라우드 제공자 서비스	Google Cloud Storage	Amazon S3

추가 정보#

머신 유형 지침#

표시된 머신 유형은 검증 및 테스트에 사용되는 예시입니다. 다음을 사용할 수 있습니다:

최신 세대 머신 유형
ARM 기반 인스턴스 (AWS Graviton)
사양을 충족하거나 초과하는 다른 머신 패밀리
특정 요구에 맞게 크기가 조정된 사용자 정의 머신 유형

일관성 없는 성능으로 인해 버스터블 인스턴스 유형을 사용하지 마십시오.

자세한 내용은 지원되는 머신 유형을 참조하십시오.

Gitaly 고려 사항#

Cloud Native First 아키텍처의 Kubernetes의 Gitaly는 다음 사양을 가진 StatefulSets를 사용합니다:

전용 노드 배치 - Gitaly 파드는 시끄러운 이웃 문제를 피하기 위해 전용 노드에 배포됩니다.
리소스 할당 - 파드 요청 및 제한이 오버헤드를 뺀 노드 용량으로 설정됩니다 (Kubernetes 시스템 프로세스를 위해 2 GB 메모리, 1 vCPU 예약).
Git cgroups 메모리 - 기본적으로 10% 버퍼로 할당되며, 더 큰 파드의 경우 최대 6 GB로 제한됩니다. 예를 들어, 소형은 3 GB 버퍼로 Git cgroups에 27 GB를 할당하는 반면, 중형 이상의 크기는 6 GB 캡을 사용합니다(중형은 6 GB 버퍼로 56 GB cgroups).

Gitaly 배포 모드:

저장소 배포:

저장소 스토리지 가중치 구성 지침은 새 저장소가 저장될 위치 구성을 참조하십시오.

Gitaly cgroups 구성#

Gitaly cgroups 측정, 조정 및 구성에 대한 자세한 지침은 Gitaly cgroups를 참조하십시오.

외부 서비스 참고 사항#

PostgreSQL은 고가용성을 위한 스탠바이 복제본으로 배포할 수 있습니다. 추가 안정성 및 성능을 위해 읽기 복제본을 추가할 수 있습니다. 대규모 환경(L, XL)은 데이터베이스 부하를 분산하기 위해 읽기 복제본에서 더 많은 이점을 얻습니다.
Redis 인스턴스는 고가용성을 위한 스탠바이 복제본으로 배포할 수 있습니다. GCP에서 Memorystore 인스턴스는 메모리로만 구성됩니다. 머신 사양은 참고용으로 표시됩니다.
인스턴스 구성이 포함된 모든 클라우드 제공자 서비스의 경우, 탄력적인 클라우드 아키텍처 관행에 맞추기 위해 세 개의 다른 가용성 영역에 최소 세 개의 노드를 구현하는 것이 권장됩니다.

자동 스케일링 및 최소 파드 수#

모든 아키텍처는 Kubernetes Horizontal Pod Autoscaler(HPA) 및 Cluster Autoscaler를 사용하여 용량을 관리합니다:

Webservice - 보수적인 최소 파드 수로 CPU 활용률에 따라 스케일링
Sidekiq - CPU 활용률에 따라 스케일링
Cluster Autoscaler - 파드 리소스 요청에 따라 자동으로 노드 프로비저닝 및 제거

내부 테스트를 통해 다음 목표를 달성하기 위해 최소 파드 수는 최대의 약 2/3로 설정됩니다:

수요 증가 시 응답적인 스케일링
노드 장애 또는 업그레이드 중 충분한 용량
수요가 낮은 기간의 비용 최적화

워크로드 패턴을 잘 이해하고 있는 경우 필요에 따라 최솟값을 조정할 수 있습니다:

급격한 트래픽 급증 또는 엄격한 성능 SLA가 있는 환경의 경우 최솟값 증가
모니터링에서 지속적인 부하가 기본값보다 낮게 유지되는 것이 확인된 후 최솟값 감소

고급 스케일링#

Cloud Native First 아키텍처는 기본 사양을 초과하여 스케일링되도록 설계되었습니다. 환경에 다음이 있는 경우 용량을 조정해야 할 수 있습니다:

나열된 RPS 목표보다 지속적으로 높은 처리량
비정형 워크로드 구성 (RPS 구성 이해 참조)
대형 모노레포 (2 GB 이상)
상당한 추가 워크로드
광범위한 GitLab Duo Agent Platform 사용

스케일링 전략은 구성요소 유형에 따라 다릅니다.

수평 스케일링 (Webservice 및 Sidekiq)#

용량 증가를 위해 최대 복제본 수와 노드 풀 용량을 조정하여 수평으로 스케일링합니다:

Webservice - Helm 값에서 maxReplicas를 늘리고 Webservice 노드 풀에 해당 노드를 추가합니다
Sidekiq - 더 높은 작업 처리량을 처리하기 위해 maxReplicas를 늘리고 Sidekiq 노드 풀에 노드를 추가합니다

수평 스케일링은 이러한 상태 비저장 구성요소에 권장되는 방법입니다.

수직 스케일링 (PostgreSQL, Redis, Gitaly)#

상태 저장 구성요소의 경우 인스턴스 또는 파드 사양을 늘립니다:

PostgreSQL 및 Redis - 관리형 서비스 제공자를 통해 더 큰 인스턴스 유형으로 업그레이드합니다.
Gitaly - 파드당 CPU 및 메모리 사양을 늘립니다. 이를 위해 Gitaly 노드 풀에 더 큰 노드 유형이 필요하며 Git cgroups 메모리 할당에 해당하는 조정이 필요합니다.

Sidekiq 큐 최적화#

높은 긴급도 큐 - CI 파이프라인 처리 및 웹훅 전달과 같은 시간에 민감한 작업용
CPU 집약적 큐 - 동시성 설정을 조정한 컴퓨팅 집약적 작업용
기본 큐 - 표준 백그라운드 처리용

Sidekiq 큐 구성에 대한 자세한 내용은 특정 작업 클래스 처리를 참조하십시오.

GitLab Duo Agent Platform 스케일링#

스케일링 고려 사항#

구성요소를 크게 스케일링할 때:

종속 구성요소의 리소스 포화를 모니터링합니다. Webservice 또는 Sidekiq의 부하 증가는 PostgreSQL 및 Gitaly에 영향을 줄 수 있습니다.
프로덕션 외 환경에서 먼저 스케일링 변경 사항을 테스트합니다.
서비스 간 병목 현상 이동을 방지하기 위해 상호 의존적인 구성요소를 함께 스케일링합니다.

포괄적인 스케일링 지침은 환경 스케일링을 참조하십시오.

배포#

Cloud Native First 아키텍처는 Helm 차트와 외부 서비스 제공자를 사용하여 직접 또는 GitLab Environment Toolkit을 통해 배포할 수 있습니다.

GitLab Environment Toolkit#

GitLab Environment Toolkit은 다음을 통해 자동화된 배포를 제공합니다:

클라우드 리소스를 위한 Infrastructure as Code (Terraform)
자동화된 Helm 차트 구성
각 아키텍처 크기에 대한 사전 검증된 설정
단순화된 업그레이드 및 유지 관리

배포 지침은 GitLab Environment Toolkit 문서를 참조하십시오.

수동 배포#

수동 배포를 위한 사전 요건:

필요한 데이터베이스, 사용자 및 권한이 설정된 외부 PostgreSQL
구성 및 액세스 가능한 외부 Redis 인스턴스
생성된 Object Storage 버킷
필요에 따라 인증을 위한 Kubernetes 시크릿 생성 (PostgreSQL 비밀번호, Redis 비밀번호, Object Storage 자격 증명, GitLab 시크릿)

자세한 전제 조건 및 시크릿 구성은 GitLab 차트 전제 조건 및 시크릿 구성을 참조하십시오.

Helm 차트를 사용한 수동 배포:

전제 조건에 설명된 대로 필요한 외부 서비스 및 시크릿을 설정합니다
적절한 노드 풀과 자동 스케일러로 Kubernetes 클러스터를 구성합니다
Helm 차트 구성 섹션에 표시된 Helm 값 구성을 적용합니다
helm install을 사용하여 GitLab을 배포합니다

자세한 수동 배포 단계는 Kubernetes에 GitLab 설치를 참조하십시오.

Helm 차트 구성#

완전한 Helm 차트 구성 예시와 자세한 배포 지침은 GitLab Charts 저장소를 참조하십시오.

Cloud Native First 아키텍처의 주요 구성 영역:

리소스 사양 - 파드 CPU 및 메모리 제한이 위의 각 아키텍처 크기 사양과 일치합니다
자동 스케일링 - HPA 구성이 최소 파드 수를 최대의 2/3로 설정하고 CPU 기반 스케일링 목표를 설정합니다
노드 배치 - 노드 선택기를 통해 적절한 노드 풀에 워크로드가 배포되도록 합니다 (예: webservice, sidekiq, gitaly, support)
외부 서비스 - PostgreSQL, Redis 및 Object Storage 연결 세부 정보
Gitaly - cgroups, 영속성 및 스토리지 배포를 포함하는 StatefulSet 구성

아키텍처별 복제본 수 및 리소스 값은 위의 각 크기 섹션의 사양을 참조하십시오.

Note

다음 단계#

배포 후 환경은 일반적으로 실제 워크로드 패턴에 맞추기 위한 모니터링 및 튜닝이 필요합니다.

모니터링 및 검증#

리소스 활용률 모니터링 - Prometheus를 사용하여 모든 구성요소의 CPU, 메모리 및 큐 깊이를 추적합니다
RPS 가정 검증 - 실제 RPS 분석을 가정된 80/10/10 구성과 비교합니다
잠재적 조정 사항 식별 - 지속적으로 70% 이상의 활용률에 있는 구성요소를 찾습니다
Gitaly cgroups 검토 - 저장소 액세스 패턴에 따라 저장소 cgroup 수 조정을 고려합니다

필요에 따라 조정#

참조 아키텍처는 시작점입니다. 많은 환경에서 다음을 기반으로 조정이 필요합니다:

실제 워크로드 구성 - API/웹/Git 분할이 일반적인 패턴과 크게 다른 경우, RPS 구성 이해를 참조하십시오
저장소 특성 - 모노레포 크기, 클론 빈도 및 액세스 패턴에 구성요소별 조정이 필요할 수 있습니다
성장 패턴 - 사용자 수 증가, CI/CD 확장 또는 자동화 스케일링

구성요소별 조정 지침은 고급 스케일링을 참조하십시오.

선택적 기능 구성#

요구 사항에 따라 GitLab의 추가 선택적 기능을 구성할 수 있습니다. 자세한 내용은 GitLab 설치 후 단계를 참조하십시오.

Note

선택적 기능에 추가 용량이 필요할 수 있습니다. 요구 사항은 기능별 문서를 참조하십시오.