GitLab 을 클러스터로 구성한다는 말은 문맥에 따라 다른 것을 가리킨다. 먼저 무엇이 목적인지 정한다.
| 목적 | 구성 |
|---|---|
| GitLab 서비스 자체의 무중단 | 역할별 노드 분리 + Gitaly Cluster |
| 컨테이너 환경에서의 운영 편의 | Kubernetes 위에 Helm 차트로 배포 |
| CI 처리량 확대 | GitLab 서버는 하나, Runner 만 늘린다 |
세 번째가 가장 흔한 요구이고 가장 싸다. 빌드가 밀리는 문제라면 서버를 이중화할 이유가 없다. Runner 를 늘리고 동시 실행 수를 올리면 된다.
단일 노드 설치(Omnibus)는 여러 구성 요소를 한 프로세스 묶음으로 올린다. 이것을 쪼개 각각 별도 노드에 두는 것이 GitLab 의 참조 아키텍처다.
| 구성 요소 | 역할 | 이중화 방식 |
|---|---|---|
| 로드밸런서 | 외부 진입 | HAProxy · Nginx · 클라우드 LB |
| Rails (Puma) | 웹·API | 여러 대. 무상태이므로 수평 확장 |
| Sidekiq | 백그라운드 작업 | 여러 대 |
| Gitaly | Git 저장소 접근 | Gitaly Cluster(Praefect)로 복제 |
| PostgreSQL | 메타데이터 | 스트리밍 복제 + Patroni |
| Redis | 캐시·큐·세션 | Sentinel |
| 객체 저장소 | 아티팩트·LFS·업로드 | S3 호환 스토리지 |
주의할 점이 둘 있다. NFS 로 Git 저장소를 공유하는 구성은 더 이상 지원되지 않는다. 저장소 이중화는 Gitaly Cluster 로 한다. 그리고 Redis 는 용도별로 인스턴스를 나누는 것이 권장되므로, 캐시용과 큐용을 같은 인스턴스에 몰아 두지 않는다.
이 구성은 노드가 열 대를 넘어가고 운영 난도가 확연히 올라간다. GitLab 이 공개한 참조 아키텍처는 사용자 수 기준으로 권장 규모를 제시하므로, 실제 사용자 수를 먼저 재고 그 문서의 규모 구간에 맞춰 설계한다.
helm repo add gitlab https://charts.gitlab.io
helm repo update
helm upgrade --install gitlab gitlab/gitlab \
--namespace gitlab --create-namespace \
--set global.hosts.domain=example.com \
--set global.edition=ce \
--set certmanager-issuer.email=admin@example.com
차트가 PostgreSQL · Redis · MinIO 를 함께 띄우지만 이 내장 인스턴스들은 평가용이다. 운영에서는 외부 관리형 서비스나 별도 구축한 인스턴스를 연결한다.
--set postgresql.install=false \
--set global.psql.host=pg.internal \
--set redis.install=false \
--set global.redis.host=redis.internal
자원 요구가 크다. 최소 구성으로도 노드 여러 대에 걸쳐 수십 GiB 메모리를 쓴다. Gitaly 는 상태를 갖는 구성 요소라 PVC 설계와 백업을 따로 챙겨야 한다.
gitlab-runner register --url https://gitlab.example.com/ --token "${RUNNER_TOKEN}"
/etc/gitlab-runner/config.toml 에서 동시 실행 수를 올린다.
concurrent = 8
[[runners]]
name = "docker-runner-1"
executor = "docker"
[runners.docker]
image = "alpine:3"
Kubernetes executor 를 쓰면 작업마다 Pod 를 띄워 필요할 때만 자원을 쓴다. 태그로 작업을 특정 Runner 에 몰아 주면 무거운 빌드와 가벼운 검사를 분리할 수 있다.
이중화를 결정하기 전에 지금 무엇이 병목인지 재 본다. 대부분은 디스크 I/O 이거나 Gitaly 의 특정 저장소 부하이지, 웹 노드가 모자라서가 아니다.
gitlab-ctl status
gitlab-rake gitlab:check
GitLab 은 자체 Prometheus 를 포함하므로 Puma 대기열·Sidekiq 큐 길이·Gitaly 지연을 지표로 볼 수 있다. 이 값을 근거로 어느 계층을 늘릴지 정한다.