레퍼런스 아키텍처: 최대 20 RPS 또는 1,000명 사용자
Offering: GitLab Self-Managed
이 레퍼런스 아키텍처는 초당 20개 요청(RPS)의 최대 부하를 대상으로 합니다. 레퍼런스 아키텍처의 전체 목록은 사용 가능한 레퍼런스 아키텍처를 참조하세요. 다음 다이어그램은 GitLab을 단일 서버에 설치할 수 있지만 내부적으로 여러 서비스로 구성되어 있음을 보여줍니다.
이 레퍼런스 아키텍처는 초당 20개 요청(RPS)의 최대 부하를 대상으로 합니다. 실제 데이터를 기반으로 이 부하는 일반적으로 수동 및 자동화된 상호 작용을 포함하여 최대 1,000명의 사용자에 해당합니다.
레퍼런스 아키텍처의 전체 목록은 사용 가능한 레퍼런스 아키텍처를 참조하세요.
- 목표 부하: API: 20 RPS, Web: 2 RPS, Git (Pull): 2 RPS, Git (Push): 1 RPS
- 고가용성: 없음. 고가용성 환경은 수정된 3K 레퍼런스 아키텍처를 따릅니다.
- 클라우드 네이티브 하이브리드: 없음. 클라우드 네이티브 하이브리드 환경의 경우 수정된 하이브리드 레퍼런스 아키텍처를 따를 수 있습니다.
- 어떤 레퍼런스 아키텍처를 사용할지 확실하지 않으신가요? 자세한 내용은 어떤 아키텍처로 시작할지 결정하기를 참조하세요.
| 사용자 | 구성 | GCP 예시1 | AWS 예시1 | Azure 예시1 |
|---|---|---|---|---|
| 최대 1,000명 또는 20 RPS | 8 vCPU, 16 GB 메모리 | n1-standard-82 |
c5.2xlarge |
F8s v2 |
각주:
- 머신 유형 예시는 설명 목적으로 제공됩니다. 이러한 유형은 검증 및 테스트에 사용되지만 규정적인 기본값으로 의도된 것은 아닙니다. 사용 가능한 경우 ARM 변형을 포함하여 나열된 요구 사항을 충족하는 다른 머신 유형으로 전환하는 것이 지원됩니다. 자세한 내용은 지원되는 머신 유형을 참조하세요.
- GCP의 경우 8 vCPU 및 16 GB RAM의 권장 요구 사항과 일치하는 가장 가까운 동등한 표준 머신 유형이 선택되었습니다. 원하는 경우 사용자 정의 머신 유형을 사용할 수도 있습니다.
다음 다이어그램은 GitLab을 단일 서버에 설치할 수 있지만 내부적으로 여러 서비스로 구성되어 있음을 보여줍니다. 인스턴스가 확장되면 이러한 서비스는 분리되어 특정 수요에 따라 독립적으로 확장됩니다.
경우에 따라 일부 서비스에 PaaS를 활용할 수 있습니다. 예를 들어 일부 파일 시스템에 클라우드 오브젝트 스토리지를 사용할 수 있습니다. 이중화를 위해 일부 서비스는 노드 클러스터가 되어 동일한 데이터를 저장합니다.
수평으로 확장된 GitLab 구성에서는 클러스터를 조정하거나 리소스를 검색하기 위한 다양한 보조 서비스가 필요합니다. 예를 들어 PostgreSQL 연결 관리를 위한 PgBouncer 또는 Prometheus 엔드포인트 검색을 위한 Consul이 있습니다.
소스 코드 보기
@startuml 1k
card "**Prometheus**" as monitor #7FFFD4
package "GitLab Single Server" as gitlab-single-server {
together {
card "**GitLab Rails**" as gitlab #32CD32
card "**Gitaly**" as gitaly #FF8C00
card "**PostgreSQL**" as postgres #4EA7FF
card "**Redis**" as redis #FF6347
card "**Sidekiq**" as sidekiq #ff8dd1
}
card "Local Storage" as local_storage #white
}
gitlab -[#32CD32]--> gitaly
gitlab -[#32CD32]--> postgres
gitlab -[#32CD32]--> redis
gitlab -[#32CD32]--> sidekiq
gitaly -[#32CD32]--> local_storage
postgres -[#32CD32]--> local_storage
sidekiq -[#32CD32]--> local_storage
gitlab -[#32CD32]--> local_storage
monitor .[#7FFFD4]u-> gitlab
monitor .[#7FFFD4]u-> sidekiq
monitor .[#7FFFD4]-> postgres
monitor .[#7FFFD4]-> gitaly
monitor .[#7FFFD4,norank]--> redis
@enduml
요구 사항#
진행하기 전에 레퍼런스 아키텍처에 대한 요구 사항을 검토하세요.
노드의 사양은 양호한 상태의 사용 패턴과 리포지터리 크기의 높은 백분위수를 기반으로 합니다. 그러나 대형 모노리포(여러 기가바이트보다 큰) 또는 추가 워크로드가 있는 경우 환경 성능에 상당한 영향을 미칠 수 있습니다. 이것이 해당된다면 추가 조정이 필요할 수 있습니다. 연결된 문서를 참조하고 추가 지침이 필요한 경우 문의하세요.
테스트 방법론#
20 RPS / 1k 사용자 레퍼런스 아키텍처는 대부분의 일반적인 워크플로우를 수용하도록 설계되었습니다. GitLab은 다음 엔드포인트 처리량 목표에 대해 정기적으로 smoke 및 성능 테스트를 수행합니다:
| 엔드포인트 유형 | 목표 처리량 |
|---|---|
| API | 20 RPS |
| Web | 2 RPS |
| Git (Pull) | 2 RPS |
| Git (Push) | 1 RPS |
이러한 목표는 CI 파이프라인 및 기타 워크로드를 포함하여 지정된 사용자 수에 대한 총 환경 부하를 반영하는 실제 고객 데이터를 기반으로 합니다. 이는 일반적인 워크로드 구성을 나타냅니다. 비정형 워크로드 패턴에 대한 지침은 RPS 구성 이해를 참조하세요.
테스트 방법론에 대한 자세한 내용은 검증 및 테스트 결과 섹션을 참조하세요.
성능 고려 사항#
환경에 다음이 있는 경우 추가 조정이 필요할 수 있습니다:
이 경우 자세한 내용은 환경 확장을 참조하세요. 이러한 고려 사항이 해당될 수 있다고 생각되면 필요한 추가 지침을 위해 문의하세요.
설치 지침#
이 기본 레퍼런스 아키텍처에 대해 GitLab을 설치하려면 표준 설치 지침을 사용합니다.
선택적으로 성능과 신뢰성을 향상시키지만 복잡성 비용이 증가하는 외부 PostgreSQL 서비스 또는 외부 오브젝트 스토리지 서비스를 사용하도록 GitLab을 구성할 수도 있습니다.
고급 검색 구성#
Elasticsearch를 활용하고 고급 검색을 활성화하여 전체 GitLab 인스턴스에서 더 빠르고 고급적인 코드 검색을 수행할 수 있습니다.
Elasticsearch 클러스터 설계 및 요구 사항은 데이터에 따라 다릅니다. 인스턴스와 함께 Elasticsearch 클러스터를 설정하는 방법에 대한 권장 모범 사례는 최적 클러스터 구성 선택을 참조하세요.
Helm 차트를 사용한 클라우드 네이티브 하이브리드 레퍼런스 아키텍처#
클라우드 네이티브 하이브리드 레퍼런스 아키텍처 설정에서는 선택된 상태 비저장 컴포넌트가 공식 Helm 차트를 사용하여 Kubernetes에 배포됩니다. 상태 저장 컴포넌트는 Linux 패키지가 있는 컴퓨팅 VM에 배포됩니다.
Kubernetes에서 사용할 수 있는 가장 작은 레퍼런스 아키텍처는 2k 또는 40 RPS GitLab 클라우드 네이티브 하이브리드(비HA) 및 3k 또는 60 RPS GitLab 클라우드 네이티브 하이브리드(HA)입니다.
더 적은 사용자 또는 더 낮은 RPS를 제공하는 환경의 경우 노드 사양을 낮출 수 있습니다. 사용자 수에 따라 원하는 대로 모든 제안된 노드 사양을 낮출 수 있습니다. 그러나 일반 요구 사항보다 낮추어서는 안 됩니다.
다음 단계#
이제 핵심 기능이 구성된 새로운 GitLab 환경이 생겼습니다. 요구 사항에 따라 추가적인 선택적 GitLab 기능을 구성할 수 있습니다. 자세한 내용은 GitLab 설치 후 단계를 참조하세요.
환경 및 요구 사항에 따라 추가 기능을 설정하기 위해 추가 하드웨어 요구 사항이나 조정이 필요할 수 있습니다. 자세한 내용은 개별 페이지를 참조하세요.