CHAPTER 06 · 고객 문의 7번

06. 온프레미스 서버 권장 사양

고객 문의 — On-Premise 구축 시 서버 권장사양(CPU, Memory, Disk 종류/용량, HA 고려 등) - 200/300/400명 기준

요약 답변

GitLab 공식 사이징은 "사용자 수"가 아니라 초당 요청 수(RPS) 기준입니다. 최신 공식 기준에서 200/300/400명 규모는 모두 "Up to 20 RPS or 1,000 users" 단일 아키텍처 범위에 들어갑니다. 이 아키텍처의 공식 단일 노드 사양은 8 vCPU / 16 GB 메모리이고, 비HA 단일 노드 구성이 공식 권장입니다.

즉 세 규모 모두 공식 기준으로는 같은 사양입니다. 다만 실무에서는 공식 사양의 2배 하드웨어를 권장하고, 업그레이드 시에는 백업 디스크 쪽에 현재 데이터 용량의 약 2.5배 공간을 준비해야 합니다. 아래 표에서 공식값과 권고값을 분리했습니다.

규모별 권장 사양

구분	200명	300명	400명	근거
공식 아키텍처	Up to 20 RPS / 1,000 users	동일	동일	공식 RA
공식 CPU	8 vCPU	8 vCPU	8 vCPU	공식
공식 메모리	16 GB	16 GB	16 GB	공식
실무 권고 CPU	16 vCPU	16 vCPU	16 vCPU (CI 부하 시 상향)	인포그랩 권고 (공식의 2배)
실무 권고 메모리	32 GB	32 GB	32 GB	인포그랩 권고 (공식의 2배)
백업 디스크	현재 데이터의 약 2.5배 여유	동일	동일	인포그랩 권고 (업그레이드 작업 공간)
애플리케이션 디스크	40 GB+ (SSD/NVMe)	동일	동일	공식 최소치
DB(PostgreSQL) 디스크	5~10 GB+ (Premium 기준)	동일	동일	공식
저장소(Gitaly) 디스크	전체 저장소 합계 + 여유	동일 (2년 증가분 반영 권고)	동일	공식 + 권고
구성 형태	단일 노드 (비HA)	단일 노드 (비HA)	단일 노드, 필요 시 부분 분리	공식
Runner	별도 VM 권고	별도 VM 1~2대 권고	별도 VM 2대 이상 권고	인포그램 권고

실무 권고 명시: GitLab 공식 기준은 8 vCPU / 16 GB이지만, 실제 운영에서는 공식 사양의 2배(16 vCPU / 32 GB) 를 권장합니다. 또한 업그레이드 작업 시에는 백업·롤백 파일이 같은 시점에 공존하므로, 백업 디스크 쪽에 현재 데이터 용량의 약 2.5배 디스크 공간이 준비되어야 합니다. 이 둘은 공식 문서 수치가 아니라 인포그랩의 실무 권고입니다. 공식 문서는 16 GB를 기준(baseline)으로 제시하고, 메모리 제약 환경에서는 최소 8 GB로도 동작한다고 명시합니다.

공식 기준 상세

아키텍처 기준점

공식 Reference Architecture "Up to 20 RPS or 1,000 users": API 20 RPS, Web 2 RPS, Git pull 2 RPS, Git push 1 RPS를 견딥니다. 실제 고객 데이터 기반으로, 이 부하가 통상 최대 1,000명(사람 + 자동화 계정 포함)에 해당한다고 명시합니다.
2,000명 이하 환경에는 비HA 단일·소규모 노드 구성과 자동 백업을 공식 권장합니다. HA 아키텍처는 3,000명(60 RPS)부터가 공식 권장 구간입니다.
따라서 200/300/400명은 사용자 수 기준으로는 모두 동일 출발점이며, 실제 차이는 저장소 크기, CI 파이프라인 빈도, 대용량 monorepo 유무에서 발생합니다. monorepo(수 GB 이상)나 CI 부하가 크면 상향 조정이 필요하다고 공식 문서도 명시합니다.

스토리지 세부 (공식)

컴포넌트	최소 용량	비고
애플리케이션 노드 (Rails, Sidekiq, Puma)	40 GB	패키지 약 2.5 GB + OS·로그·임시 파일
저장소 (Gitaly)	전체 저장소 합계 이상	I/O 집약적, SSD 필수에 가까움
DB (PostgreSQL)	5~10 GB (Ultimate는 12 GB)	Ultimate는 취약점 데이터 약 1 GB 포함
오브젝트 스토리지	분산 구성 시 필수, 단일 노드도 권장	LFS, CI 아티팩트, 업로드, 레지스트리, 백업 저장 (S3 호환)

디스크 종류와 파일시스템

SSD 계열(NVMe 포함) 사용을 공식 권장합니다. 특히 Gitaly는 I/O 민감합니다.
NFS, Amazon EFS, Azure Files 같은 네트워크 파일시스템은 성능 저하로 피하라고 명시합니다.
버스터블(burstable) 인스턴스·디스크는 일관되지 못한 성능 때문에 비권장입니다.
스왑은 가능하면 비활성화하고, 불가피하면 GitLab이 스왑을 쓰지 않을 만큼 메모리를 충분히 제공해야 합니다.

주요 미들웨어 버전 (설계 시 참고)

PostgreSQL만 지원됩니다. GitLab 19.x는 PostgreSQL 17.x, 18.x는 16.5~17.x를 사용합니다.
Redis 7.2 권장(최소 7.0) 또는 Valkey 7.2. Redis Cluster와 서버리스 Redis는 미지원입니다.

HA 고려 사항

공식 권장 기준: HA는 "3,000명 이상" 또는 "GitLab 중단이 업무에 치명적일 때" 도입을 권장합니다. 400명 이하에서는 일반적으로 비HA + 자동 백업 + 빠른 복구 절차가 비용·복잡도 대비 합리적입니다.
금융권처럼 가용성 요구가 높다면 전체 HA 대신 부분 이중화부터 검토할 수 있습니다. 외부 PostgreSQL(관리형 또는 이중화), 오브젝트 스토리지 분리, Runner 분리가 대표적입니다. (이는 공식 문서도 단일 노드의 선택 사항으로 인정하는 구성입니다.)
HA를 구성할 때의 공식 제약:

노드 간 지연(latency) 5 ms 미만 (동기 복제 필요)

가용 영역(AZ)은 홀수 개 사용 (쿼럼 투표 때문)
하나의 GitLab 인스턴스를 여러 지리적 리전에 걸치면 안 됨. 다중 리전은 GitLab Geo로 설계
완전 HA는 PostgreSQL 이중화, Gitaly Cluster(Praefect, 전용 PostgreSQL 필요), Redis Sentinel 등 구성 요소별 클러스터가 필요해 복잡도가 크게 올라갑니다.

Kubernetes 기반은 Cloud Native Hybrid 아키텍처가 있으나, 공식 최소 권장이 2,000명(비HA)/3,000명(HA)부터입니다. 400명 이하에서는 VM 단일 노드가 더 단순합니다.

함께 안내할 선택 컴포넌트

필요할 때 별도 리소스가 드는 기능들입니다.

Container Registry: 도메인 + TLS + 스토리지(또는 오브젝트 스토리지)
Advanced Search (Elasticsearch/OpenSearch, Premium 이상): 별도 클러스터
Prometheus 모니터링: Linux 패키지에 기본 내장
GitLab Pages: 별도 데몬 + 와일드카드 DNS
AI Gateway (Duo): 별도 서비스 (Docker/K8s)
Secrets Manager: 별도 K8s 서비스 + 전용 PostgreSQL + 로드밸런서

설계 질문 체크리스트 (사이징 확정 전 고객 확인)

전체 저장소 용량 합계와 향후 2년 증가 예상치
대용량 monorepo(수 GB 이상) 존재 여부
일일 파이프라인 실행 수와 동시 실행 Job 수 → Runner 대수 결정
Container Registry, Pages, Advanced Search 사용 여부
백업 보관 주기와 복구 목표 시간(RTO/RPO) → 비HA 허용 여부 판단
폐쇄망 여부와 외부 오브젝트 스토리지 사용 가능 여부

공식 출처

Reference architectures 개요: https://docs.gitlab.com/administration/reference_architectures/ (RPS 표, HA 권장 기준)
Up to 20 RPS or 1,000 users: https://docs.gitlab.com/administration/reference_architectures/1k_users/ (8 vCPU / 16 GB, 비HA)
설치 요구사항: https://docs.gitlab.com/install/requirements/ (CPU/메모리/스토리지/NFS/HA 네트워크 조건)
사이징 가이드: https://docs.gitlab.com/install/sizing/

GitLab 도입 가이드