구축형 GitLab을 설치해보셨거나 설치하실 계획이 있으신가요? 구축형 GitLab을 사용하기 위해 고려해야 하는 상황은 다양합니다. 사용하는 유저의 수, 가용성, 클라우드 네이티브 환경 여부 등 이러한 환경에 대해 전부는 아니지만, 구축에 참고할 수 있는 레퍼런스 아키텍처를 오늘 소개해 드리려 합니다.
- 일반적인 환경에서 1,000명의 사용자를 기준으로 작성된 아키텍처
- 클라우드 네이티브 환경에서 사용가능한 2,000명의 사용자를 기준으로 작성된 아키텍처
더 다양한 레퍼런스 아키텍처가 필요하신 경우에는 GitLab 공식 Docs를 참고하시기 바랍니다.
최대 1,000명 레퍼런스 아키텍처 (Omnibus, Single Node)
최대 1,000명 레퍼런스 아키텍처를 기준으로 설명해 드리는 이유는 GitLab에서 권장하는 최소 단위의 아키텍처임과 동시에 일반적인 환경에서 사용하기에 적합하기 때문입니다. 이 아키텍처는 엄격한 가용성 요구 사항이 없는 경우와 백업을 자주 수행하는 단일 노드 솔루션이 있는 대부분의 조직에 적합합니다.
이 아키텍처의 구성 목표를 정리하면 다음과 같습니다.
지원 가능 사용자 수
지원 사용자 수는 1,000명이며 권장 사양 기준 최대 사용자 수 입니다.
고가용성
이 아키텍처에서는 고가용성 사용은 불가능합니다. 고가용성 환경의 경우 최소 3,000명 사용자 레퍼런스 아키텍처를 권장합니다.
예상 비용
예상 비용은 GitLab에서 제공하는 Omnibus 패키지 설치를 기준으로 합니다. 클라우드 공급자 별로 인스턴스의 비용이나 규격화되어 있는 인스턴스 종류가 다르기에 가격에 차이가 있을 수 있습니다.
검증 및 테스트
GitLab의 성능을 측정하고 개선하는 것은 물론 자체 관리 고객이 성능 구성으로 신뢰할 수 있는 레퍼런스 아키텍처를 만들고 검증하는 데 중점을 두고 있습니다. GitLab 품질 엔지니어링 팀은 레퍼런스 아키텍처가 규정을 준수하는지, 적합한지에 대한 것들을 확인하기 위해 정기적으로 성능 테스트를 수행합니다. 테스트는 자동화된 방식을 사용하며 모든 레퍼런스 아키텍처 및 클라우드 제공 업체에 대해 수행합니다. 테스트에는 환경 구축을 위한 GitLab 환경 툴킷, 성능 테스트를 위한 GitLab 성능 도구가 사용 됩니다.
아키텍처에 대한 테스트 결과는 다음과 같습니다.
- 초당 테스트 요청(RPS) 속도: API: 20RPS, 웹: 2RPS, Git(Pull): 2RPS, Git(Push): 1RPS
- RPS : 테스트에서 달성할 수 있는 평균 초당 요청(Requests per second)입니다.
이 테스트 결과는 지속적으로 업데이트 됩니다. 최신 결과에서 변경된 테스트 결과들을 확인할 수 있습니다.
권장 사양
| 사용자 수 | 사양 구성 | GCP | AWS | Azure |
|---|---|---|---|---|
| 최대 500명 | 4 vCPU, 3.6GB memory | n1-highcpu-4(4vCPU / 3.6 GB memory) | c5.xlarge(4vCPU / 8 GB memory) | F4s v2(4vCPU / 8 GB memory) |
| 최대 1,000명 | 8 vCPU, 7.2GB memory | n1-highcpu-8(4vCPU / 7.2 GB memory) | c5.2xlarge(8vCPU / 16 GB memory) | F8s v2(8vCPU / 16 GB memory) |
아키텍처 구조
GitLab은 단일 서버에 설치될 수 있지만 내부적으로는 여러 서비스로 구성되어 있으며 다음과 같은 경우가 발생할 수 있습니다.
- GitLab 인스턴스가 확장되면서 각 서비스는 요구 사항에 따라 세분화되고 독립적으로 확장됩니다. 경우에 따라서는 일부 서비스에 PaaS를 활용할 수 있습니다.
- 중복성을 위해 일부 서비스는 동일한 데이터를 저장하는 노드 클러스터가 됩니다.
- GitLab의 수평 구성에는 클러스터를 조정하거나 리소스를 검색하는 데 필요한 다양한 보조 서비스가 있습니다
(예: PostgreSQL 연결 관리용 PgBouncer, Prometheus EndPoint 검색용 Consul)
최대 2,000명 레퍼런스 아키텍처 (Cloud Native Hybrid, Helm)
클라우드 네이티브 하이브리드를 사용하는 환경에서는 클라우드 공급자가 제공하는 서비스를 선택적으로 활용 할 수 있습니다. 활용 가능 서비스들은 Database, Object Storage, Storage 등이 될 수 있으며, 각 항목별 권장 사양은 다음과 같습니다.
| 서비스 | Nodes | 사양 구성 | GCP | AWS | Azure |
|---|---|---|---|---|---|
| Load balancer | 1 | 2 vCPU, 1.8GB memory | n1-highcpu-2(2vCPU / 1.8 GB memory) | c5.large(2vCPU / 4 GB memory) | F2s v2(2vCPU / 4 GB memory) |
| PostgreSQL | 1 | 2 vCPU, 7.5GB memory | n1-standard-2(2vCPU / 7.5 GB memory) | m5.large(2vCPU / 8 GB memory) | D2s v3(2vCPU / 8 GB memory) |
| Redis | 1 | 1 vCPU, 3.75GB memory | n1-standard-1(1vCPU / 3.75 GB memory) | m5.large(2vCPU / 8 GB memory) | D2s v3(2vCPU / 8 GB memory) |
| Gitaly | 1 | 4 vCPU, 15GB memory | n1-standard-4(4vCPU / 15 GB memory) | m5.xlarge(4vCPU / 16 GB memory) | D4s v3(4vCPU / 16 GB memory) |
| GitLab Rails | 2 | 8 vCPU, 7.2GB memory | n1-highcpu-8(4vCPU / 7.2 GB memory) | c5.2xlarge(8vCPU / 16 GB memory) | F8s v2(8vCPU / 16 GB memory) |
| Monitoring node | 1 | 2 vCPU, 1.8GB memory | n1-highcpu-2(2vCPU / 1.8 GB memory) | c5.large(2vCPU / 4 GB memory) | F2s v2(2vCPU / 4 GB memory) |
| Object Storage | - | - | - | - | - |
| NFS server(non-Gitaly) | 1 | 4 vCPU, 3.6GB memory | n1-highcpu-4(4vCPU / 3.6 GB memory) | c5.xlarge(4vCPU / 8 GB memory) | F4s v2(4vCPU / 8 GB memory) |
이 아키텍처의 구성 목표를 정리하면 다음과 같습니다.
지원 사용자 수
지원 사용자 수는 2,000명 이며 권장 사양 기준 최대 사용자 수 입니다.
고가용성
이 아키텍처에서는 고가용성을 권장하지 않으며 고가용성 환경의 경우 최소 3,000명 사용자 레퍼런스 아키텍처를 권장합니다.
클라우드 네이티브 하이브리드
클라우드 네이티브 하이브리드를 지원합니다. 각 서비스 별로 클라우드 공급자의 서비스들을 사용하여 선택적으로 구성할 수 있으며 Kubernetes환경에 구축되는 GitLab이라면 Helm으로 구성할 수 있습니다.
검증 및 테스트
아키텍처에 대한 테스트 방식은 동일하여 테스트 결과만을 설명합니다.
- 초당 테스트 요청(RPS) 속도: API: 40RPS, 웹: 4RPS, Git(Pull): 4RPS, Git(Push): 1RPS
- RPS : 테스트에서 달성할 수 있는 평균 초당 요청(Requests per second)입니다.
이 테스트 결과는 지속적으로 업데이트 됩니다. 최신 결과에서 변경된 테스트 결과들을 확인할 수 있습니다.
Cloud Native 고려사항
대안적인 접근 방식으로 공식 Helm 차트를 통해 Kubernetes에서 Cloud Native로 GitLab의 일부 구성 요소를 실행할 수도 있습니다. Kubernetes 클러스터에서 각각 Webservice 및 Sidekiq 라는 GitLab Rails 및 Sidekiq 노드와 동등한 실행을 지원합니다. 추가적으로 Supporting service(NGINX, Task Runner, Migrations, Prometheus, Grafana 등)들이 지원됩니다.
하이브리드 설치는 클라우드 네이티브 및 기존 컴퓨팅 배포의 이점을 모두 활용합니다. 이를 통해 상태 비저장 구성 요소는 클라우드 기본 워크로드 관리 이점을 누릴 수 있으며 상태 저장 구성 요소는 Omnibus를 사용하여 컴퓨팅 VM에 배포되어 지속성 향상의 이점을 얻을 수 있습니다.
이 레퍼런스 아키텍처는 2,000명의 사용자를 기준으로 작성되며 고가용성 설정을 지원하지 않습니다. 고가용성을 달성하기 위해서는 수정된 3,000명의 사용자를 기준으로 작성된 레퍼런스 아키텍처를 따릅니다.
참고: Gitaly Cluster는 Kubernetes에서 실행이 지원되지 않습니다.
권장 사항
Omnibus, Cloud Native Hybrid에 대하여 환경별로 사용될 수 있는 권장 사항은 다음과 같습니다.
| 레퍼런스 아키텍처 | GCP | AWS | Azure | Bare Metal |
|---|---|---|---|---|
| Omnibus | ✓ | ✓ | ✓ | ✓ |
| Cloud Native Hybrid | ✓ | ✓ |
클라우드 공급자별 권장 서비스
클라우드 공급자별 제공하는 자체관리형 서비스가 있습니다. 자체관리형 서비스들을 사용하여 GitLab의 아키텍처 일부를 사용할 수 있도록 지원하며 권장 사항은 다음과 같습니다.
| 레퍼런스 아키텍처 | GCP | AWS | Bare metal |
|---|---|---|---|
| Object storage | ✓ Cloud Storage | ✓ S3 | ✓ MiniO |
| DataBase | ✓ Cloud SQL | ✓ RDS | |
| Redis | ✓ ElasticCache |
권장하지 않는 클라우드 공급자 서비스
AWS
Amazon Aurora 는 호환되지 않습니다. 자세한 내용은 14.4.0을 참조하십시오.
Amazon RDS 다중 AZ DB 클러스터 는 테스트되지 않았으므로 권장되지 않습니다. 특히 GitLab Geo에서 작동하지 않을 것으로 예상됩니다.
GCP
Google AlloyDB 및 는 테스트되지 않았으므로 권장되지 않습니다. GitLab Geo에서 작동하지 않을 것으로 예상됩니다.
Azure
Azure Blob Storage 에는 특정 시간에 프로덕션 사용에 영향을 줄 수 있는 성능 제한이 있는 것으로 확인되었습니다. 더 큰 레퍼런스 아키텍처의 경우 서비스가 프로덕션 용도로 충분하지 않을 수 있으며 대신 사용하는 것이 좋습니다.
Azure Database for PostgreSQL Server (단일/유연성)는 성능 문제나 누락된 기능으로 인해 사용하지 않는 것이 좋습니다.
일반적으로 Azure 서비스는 권장하지 않습니다. 필요한 경우 서비스가 적합한지 검증하기 위해 지속적인 기간 동안 의도한 규모에서 철저한 테스트를 수행하는 것이 좋습니다.
구성
다음 표와 다이어그램은 위의 일반 환경과 동일한 형식을 사용하는 하이브리드 환경을 자세히 설명합니다.
먼저 Kubernetes에서 실행되는 구성 요소입니다. 현재 권장 사항은 Google Cloud의 Kubernetes Engine(GKE) 또는 AWS Elastic Kubernetes Service(EKS) 및 관련 머신 유형을 사용하는 것이지만 메모리 및 CPU 요구 사항은 대부분의 다른 제공업체로 변환되어야 합니다. 향후 구체적인 클라우드 제공자 세부 정보로 이를 업데이트할 수 있기를 바랍니다.
| 서비스 명 | Nodes | Configuration | GCP | AWS | 최소 할당 가능한 CPU 및 메모리 |
|---|---|---|---|---|---|
| WebService | 3 | 8 vCPU, 7.2 GB memory | n1-highcpu-8 | c5.2xlarge | 23.7 vCPU, 16.9GB memory |
| Sidekiq. | 2 | 4 vCPU, 15 GB memory | n1-standard-4 | m5.xlarge | 7.8 vCPU, 25.9GB memory |
| Supporting service. | 2 | 2 vCPU, 7.5 GB memory | n1-standard-2 | m5.large | 1.9 vCPU, 5.5GB memory |
이 설정의 경우 Google Kubernetes Engine(GKE) 및 Amazon Elastic Kubernetes Service(EKS) 를 권장 하고 정기적으로 테스트 합니다. 다른 Kubernetes 서비스도 작동할 수 있지만 사용량은 다를 수 있습니다. 노드 구성은 Pod vCPU/Memory 비율을 보장하고 성능 테스트 중에 확장을 피하도록 강제된 것처럼 표시됩니다. 프로덕션 배포에서는 노드에 Pod를 할당할 필요가 없습니다. 탄력적인 클라우드 아키텍처 관행에 맞추기 위해 3개의 서로 다른 가용 영역에 최소 3개의 노드를 사용하는 것이 좋습니다.
다음은 Omnibus(또는 해당되는 경우 외부 PaaS 서비스)를 통해 정적 컴퓨팅 VM에서 실행되는 백엔드 구성 요소입니다.
| 서비스 명 | Nodes | Configuration | GCP | AWS |
|---|---|---|---|---|
| PostgreSQL | 1 | 2 vCPU, 7.5 GB memory | n1-standard-2 | m5.large |
| Redis | 1 | 1 vCPU, 3.75 GB memory | n1-standard-1 | m5.large |
| Gitaly | 1 | 4 vCPU, 15 GB memory | n1-standard-4 | m5.xlarge |
| Object Storage | - | - | - | - |
-
외부 PaaS PostgreSQL 솔루션에서 선택적으로 실행할 수 있습니다.
- Google Cloud SQL 및 Amazon RDS가 작동하는 것으로 알려져 있습니다.
- Google AlloyDB 및 Amazon RDS 다중 AZ DB 클러스터는 테스트되지 않았으므로 권장되지 않습니다. 두 솔루션 모두 GitLab Geo에서 작동하지 않을 것으로 예상됩니다.
- Amazon Aurora는 14.4.0에서 기본적으로 활성화된 로드 밸런싱과 호환되지 않으며 성능 문제로 인해 Azure Database for PostgreSQL은 권장되지 않습니다.
- Consul은 주로 Omnibus PostgreSQL 고가용성을 위해 사용되므로 PostgreSQL PaaS 설정을 사용할 때 무시할 수 있습니다. 그러나 Consul은 Omnibus 자동 호스트 검색을 위해 Prometheus에서도 선택적으로 사용됩니다.
-
외부 PaaS Redis 솔루션에서 선택적으로 실행할 수 있습니다.
- Google Memorystore 및 Amazon ElastiCache가 작동하는 것으로 알려져 있습니다.
리소스 사용량 설정
다음 공식은 리소스 제약 조건 내에서 배포할 수 있는 Pod 수를 계산할 때 도움이 됩니다.
| 서비스 명 | 권장 POD 개수 | Pod당 CPU | Pod당 Memory |
|---|---|---|---|
| Webservice | 4개 | 1 CPU | 1.25 GB |
| Siedekiq | 4개 | 0.9 CPU | 2GB |
웹서비스
사용자가 2,000명인 경우 총 Puma 작업자의 수는 12개를 권장합니다. 제공된 권장 사항을 사용하면 Pod당 작업자 4개 및 노드당 Pod1개가 있는 최대 3개의 Webservice Pod 를 배포할 수 있습니다. 추가 웹서비스 Pod에 대해 각 작업자 프로세스당 1 CPU 및 1.25GB의 메모리에 대한 사용이 가능합니다.
Sidekiq
Sidekiq 포드에는 일반적으로 0.9 CPU와 2GB 메모리가 있어야 합니다. 제공된 시작점을 통해 최대 4개의 Sidekiq 포드를 배포할 수 있습니다. 각 추가 포드에 대해 0.9 CPU 대 2GB 메모리 비율을 사용하여 사용 가능한 리소스를 확장합니다. 리소스 사용에 대한 자세한 내용은 Sidekiq 리소스 를 참조하십시오.
아키텍처 구조
맺음말
지금까지 Omnibus 및 Cloud Native hybrid 구성에 대한 레퍼런스 아키텍처에 대해 알아보았습니다. 지원해야 하는 사용자의 수가 늘어날수록 아키텍처의 규모도 커지고 복잡해집니다. 레퍼런스 아키텍처를 활용하시면 아키텍처를 정의하는데에 많은 도움이 되실거라 생각됩니다.
인포그랩은 GitLab 및 DevOps에 대한 맞춤 기술 지원을 제공합니다. GitLab(Omnibus/Cloud Native Hybrid) 구축 관련한 지원이 필요하시면 문의하기 로 연락 주십시오.