참조 아키텍처: 최대 20 RPS 또는 1,000 사용자
이 참조 아키텍처는 초당 20개 요청(20 RPS)을 처리하는 것을 목표로 합니다. 실제 데이터를 기반으로하면 이런 부하는 일반적으로 수동 및 자동 상호 작용을 포함하여 최대 1,000명의 사용자에 해당합니다.
참조 아키텍처의 전체 목록은 사용 가능한 참조 아키텍처를 참조하세요.
- 목표 부하: API: 20 RPS, Web: 2 RPS, Git (Pull): 2 RPS, Git (Push): 1 RPS
- 고가용성: 없음. 고가용성 환경에서는 변경된 3K 참조 아키텍처를 따르세요.
- 비용 계산기 템플릿: 자세한 정보는 비용 계산기 템플릿을 참조하세요.
- 클라우드 네이티브 하이브리드: 아니요, 클라우드 네이티브 하이브리드 환경의 경우 변경된 하이브리드 참조 아키텍처를 따르실 수 있습니다.
- 어떤 참조 아키텍처를 사용해야 하는지 확신이 드십니까? 자세한 정보는 어떤 아키텍처를 시작해야 하는지 결정을 참조하세요.
사용자수 | 구성 | GCP | AWS | Azure |
---|---|---|---|---|
최대 1,000 또는 20 RPS | 8 vCPU, 16 GB 메모리 |
n1-standard-8 1
| c5.2xlarge
| F8s v2
|
각주:
- GCP의 경우, 8 vCPU 및 16 GB RAM을 권장하는 요구 사항과 일치하는 가장 근접하고 동등한 표준 머신 유형이 선택되었습니다. 원하는 경우 사용자 정의 머신 유형을 사용할 수도 있습니다.
다음 다이어그램은 GitLab이 단일 서버에 설치될 수 있지만 내부적으로 여러 서비스로 구성되어 있음을 보여줍니다. 인스턴스가 확장되면 이러한 서비스는 자체적으로 그들의 특정 요구 사항에 따라 분리되고 독립적으로 확장됩니다.
일부 경우에는 일부 서비스에 대해 PaaS를 활용할 수 있습니다. 예를 들어, 일부 파일 시스템에는 Cloud Object Storage를 사용할 수 있습니다. 신뢰성을 위해 일부 서비스는 동일한 데이터를 보유하는 노드 클러스터로 변합니다.
수평으로 확장된 GitLab 구성에서는 클러스터를 조정하거나 리소스를 찾기 위해 여러 보조 서비스가 필요합니다. 예를 들어, PostgreSQL 연결 관리를 위해 PgBouncer 또는 Prometheus 엔드포인트 검색을 위해 Consul이 있습니다.
요구 사항
시작하기 전에 참조 아키텍처의 요구 사항을 확인하세요.
경고: 노드 사양은 사용 패턴 및 리포지토리 크기의 상위 백분위로 기반을 두고 있습니다. 그러나 대형 단일 리포지토리(수기반 이상) 또는 추가 워크로드가 있는 경우, 환경의 성능에 상당한 영향을 미칠 수 있습니다. 이 경우 추가 조정이 필요할 수 있습니다. 관련 문서를 참조하고 추가 지침이 필요한 경우 고객 성공 매니저 또는 지원팀에 문의하세요.
테스트 방법
1k 아키텍처는 많은 워크플로를 커버하도록 설계되었습니다. 정기적으로 테스트 플랫폼 팀이 다음 엔드포인트 처리량 대상을 대상으로 정기적으로 스모크 및 성능 테스트합니다.
- API: 20 RPS
- Web: 2 RPS
- Git (Pull): 2 RPS
- Git (Push): 1 RPS
이러한 대상은 사용자 수에 해당하는 총 환경 부하의 실제 고객 데이터를 기반으로 선택됩니다. 이에는 CI 및 기타 워크로드가 포함됩니다.
테스트는 GitLab 성능 도구(GPT) 및 해당 데이터셋을 사용하여 정기적으로 수행되며 누구나 사용할 수 있습니다. 이러한 테스트 결과는 GPT 위키에서 공개적으로 사용 가능합니다. 테스트 전략에 대한 자세한 내용은 검증 및 테스트 결과를 참조하세요.
설치 지침
이 기본 참조 아키텍처용 GitLab을 설치하려면 표준 설치 지침을 사용하세요.
또한 GitLab을 외부 PostgreSQL 서비스 또는 외부 객체 저장소 서비스를 사용하도록 구성할 수도 있습니다. 이는 성능과 신뢰성을 향상시키지만 복잡성을 증가시킵니다.
고급 검색 구성
전체 GitLab 인스턴스에서 더 빠르고 고급 코드 검색을 위해 Elasticsearch를 활용하고 고급 검색을 활성화할 수 있습니다.
Elasticsearch 클러스터 설계 및 요구 사항은 귀하의 데이터에 따라 다릅니다. 인스턴스와 함께 Elasticsearch 클러스터를 설정하는 최적의 사례에 대한 권장 사항은 최적의 클러스터 구성 선택을 참조하십시오.
Helm 차트를 활용한 클라우드 네이티브 하이브리드 참고 아키텍처
클라우드 네이티브 하이브리드 참고 아키텍처 설정에서 선택한 무상태 구성 요소는 공식 Helm 차트를 사용하여 Kubernetes에 배포됩니다. 상태유지 구성 요소는 Linux 패키지를 사용하여 컴퓨팅 VM에 배포됩니다.
Kubernetes에서 사용할 수 있는 가장 작은 참고 아키텍처는 2k 또는 40 RPS GitLab 클라우드 네이티브 하이브리드 (비 HA) 및 3k 또는 60 RPS GitLab 클라우드 네이티브 하이브리드 (HA)입니다.
더 적은 사용자나 낮은 RPS를 제공하는 환경의 경우 노드 사양을 낮출 수 있습니다. 사용자 수에 따라 필요에 따라 모든 권장 노드 사양을 원하는대로 낮출 수 있습니다. 그러나 일반적인 요구 사항보다 낮아서는 안 됩니다.
다음 단계
이제 핵심 기능이 구성된 새로운 GitLab 환경을 갖게 되었습니다. 귀하의 요구에 따라 추가 옵션의 GitLab 기능을 설정하고 싶을 수 있습니다. 자세한 정보는 GitLab 설치 후 단계를 참조하십시오.