레퍼런스 아키텍처: 최대 20 RPS 또는 1,000명 사용자
GitLab v19.5Offering: 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 |
다음 다이어그램은 GitLab을 단일 서버에 설치할 수 있지만 내부적으로는 여러 서비스로 구성된다는 점을 보여줍니다. 인스턴스를 확장할 때는 이러한 서비스를 분리하여 각 서비스의 수요에 맞게 개별적으로 확장합니다.
일부 서비스에는 PaaS를 활용할 수 있습니다. 예를 들어 일부 파일 시스템에는 Cloud Object Storage를 사용할 수 있습니다. 이중화를 위해 일부 서비스는 동일한 데이터를 저장하는 노드 클러스터로 구성됩니다.
수평 확장한 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 / 1천 명 사용자 레퍼런스 아키텍처는 일반적인 워크플로 대부분을 감당하도록 설계되었습니다. GitLab은 다음 엔드포인트 처리량 목표를 기준으로 스모크 테스트와 성능 테스트를 정기적으로 수행합니다.
| 엔드포인트 유형 | 목표 처리량 |
|---|---|
| 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 설치 후 단계를 참고합니다.
환경과 요구 사항에 따라 추가 기능을 구성할 때 하드웨어 요구 사항이 더 필요하거나 조정이 필요할 수 있습니다. 자세한 내용은 각 페이지를 참고합니다.
Footnotes
-
머신 유형 예시는 이해를 돕기 위한 것입니다. 이 유형들은 검증과 테스트에 사용되지만 반드시 따라야 하는 기본값은 아닙니다. 명시된 요구 사항을 충족하는 다른 머신 유형으로 변경하는 것도 지원하며, 사용할 수 있다면 ARM 변형도 지원합니다. 자세한 내용은 지원되는 머신 유형을 참고합니다. ↩ ↩2 ↩3
-
GCP의 경우 권장 사양인 8 vCPU와 16 GB RAM에 가장 가깝고 동등한 표준 머신 유형을 선정했습니다. 원한다면 사용자 지정 머신 유형을 사용할 수도 있습니다. ↩