• 사용 가능한 참조 아키텍처
  • GitLab 패키지 (Omnibus)
  • 클라우드 네이티브 하이브리드
• 시작하기 전에
• 시작 아키텍처 결정
  • 예상되는 부하(RPS 또는 사용자 수)
    • 초기 크기 조정 가이드
  • 독립형 (비-HA)
  • 고가용성 (HA)
    • 고가능성 (HA)이 필요한가요?
    • 축소된 고가용성 (HA) 접근 방식
    • 다운타임 없는 업그레이드
  • 클라우드 네이티브 하이브리드 (Kubernetes HA)
  • GitLab Geo (교차 지역 배포 / 재해 복구)
  • 대규모 단일 저장소 / 추가 워크로드
  • 클라우드 제공업체 서비스
  • 의사 결정 트리
• 요구 사항
  • 지원되는 CPU
  • 지원되는 디스크 유형
  • 지원되는 인프라
  • 대형 단일 저장소
  • 추가 워크로드
  • 부하 분산기
    • 균형 알고리즘
    • 네트워크 대역폭
  • 스왑 미사용
  • 프라에펙트 PostgreSQL
• 추천 클라우드 제공업체 및 서비스
  • 데이터베이스 서비스에 대한 권장 사항
    • 지원되지 않는 데이터베이스 서비스
  • Redis 서비스에 대한 권장 사항
  • 객체 저장소에 대한 권장 사항
• 제안된 참조 아키텍처와의 일탈
  • 지원되지 않는 디자인
    • Kubernetes에서의 상태 유지 구성 요소
    • 상태가 있는 노드의 자동 확장
    • 여러 데이터 센터에 환경 퍼뜨리기
• 검증 및 테스트 결과
  • 테스트 수행 이유
  • 테스트 수행 방법
  • 결과 해석 방법
• 비용 계산기 템플릿
• 참조 아키텍처 환경 유지
  • 환경 확장
    • 스케일링 연쇄 작용
    • HA 아키텍처에서 비 HA 아키텍처로 스케일링
  • 업그레이드
  • 모니터링
• 업데이트 이력

참조 아키텍처

GitLab 참조 아키텍처는 대상 부하를 위한 출발점으로 권장되는 확장 가능하고 탄력적인 배포를 제공합니다. 이들은 GitLab Test 플랫폼 및 지원팀에 의해 설계 및 테스트되었습니다.

사용 가능한 참조 아키텍처

다음은 여러분의 환경의 권장된 출발점으로 사용할 수 있는 참조 아키텍처입니다.

아키텍처는 사용자 수 또는 초당 요청 (RPS)에 따라 최대 부하를 기준으로 명명되었습니다. RPS는 평균 실제 데이터를 기반으로 계산됩니다.

각 참조 아키텍처가 무엇에 대해 테스트되었는지 자세한 내용은 각 페이지의 Testing Methodology 섹션을 참조하십시오.

GitLab 패키지 (Omnibus)

다음은 Linux 패키지 기반 참조 아키텍처 목록입니다.

• 최대 20 RPS 또는 1,000 사용자 API: 20 RPS, Web: 2 RPS, Git (Pull): 2 RPS, Git (Push): 1 RPS
• 최대 40 RPS 또는 2,000 사용자 API: 40 RPS, Web: 4 RPS, Git (Pull): 4 RPS, Git (Push): 1 RPS
• 최대 60 RPS 또는 3,000 사용자 API: 60 RPS, Web: 6 RPS, Git (Pull): 6 RPS, Git (Push): 1 RPS
• 최대 100 RPS 또는 5,000 사용자 API: 100 RPS, Web: 10 RPS, Git (Pull): 10 RPS, Git (Push): 2 RPS
• 최대 200 RPS 또는 10,000 사용자 API: 200 RPS, Web: 20 RPS, Git (Pull): 20 RPS, Git (Push): 4 RPS
• 최대 500 RPS 또는 25,000 사용자 API: 500 RPS, Web: 50 RPS, Git (Pull): 50 RPS, Git (Push): 10 RPS
• 최대 1000 RPS 또는 50,000 사용자 API: 1000 RPS, Web: 100 RPS, Git (Pull): 100 RPS, Git (Push): 20 RPS

클라우드 네이티브 하이브리드

다음은 Kubernetes에서 선택된 권장 구성 요소를 실행할 수 있는 클라우드 네이티브 하이브리드 참조 아키텍처 목록입니다.

• 최대 40 RPS 또는 2,000 사용자 API: 40 RPS, Web: 4 RPS, Git (Pull): 4 RPS, Git (Push): 1 RPS
• 최대 60 RPS 또는 3,000 사용자 API: 60 RPS, Web: 6 RPS, Git (Pull): 6 RPS, Git (Push): 1 RPS
• 최대 100 RPS 또는 5,000 사용자 API: 100 RPS, Web: 10 RPS, Git (Pull): 10 RPS, Git (Push): 2 RPS
• 최대 200 RPS 또는 10,000 사용자 API: 200 RPS, Web: 20 RPS, Git (Pull): 20 RPS, Git (Push): 4 RPS
• 최대 500 RPS 또는 25,000 사용자 API: 500 RPS, Web: 50 RPS, Git (Pull): 50 RPS, Git (Push): 10 RPS
• 최대 1000 RPS 또는 50,000 사용자 API: 1000 RPS, Web: 100 RPS, Git (Pull): 100 RPS, Git (Push): 20 RPS

시작하기 전에

먼저, Self-managed 접근 방식이 여러분과 여러분의 요구 사항에 적절한 선택인지를 고려하십시오.

프로덕션 환경에서 어떤 애플리케이션을 실행하는 것은 복잡하며, GitLab에 대해서도 마찬가지입니다. 이를 최대한 원활하게 만들려고 노력하지만 여전히 여러분의 설계에 따라 일반적인 복잡성이 있습니다. 보통 하드웨어, 운영 체제, 네트워킹, 스토리지, 보안, GitLab 자체 등 모든 측면을 관리해야 합니다. 이는 환경의 초기 설정과 장기적인 유지보수를 포함합니다.

이 경로를 따를 결정을 한다면 운영환경에서 애플리케이션을 실행하고 유지하는 지식이 있어야 합니다. 이러한 위치에 있지 않은 경우 전문 서비스팀에서 구현 서비스를 제공합니다. 장기적으로 더 관리되는 솔루션을 원하는 경우 GitLab SaaS이나 GitLab Dedicated과 같은 다른 옵션을 살펴볼 수 있습니다.

Self Managed 접근 방식을 고려 중이라면, 다음 섹션을 중점적으로 읽을 것을 권장합니다.

• 사용할 아키텍처를 결정하는 방법
• 대규모 단일 저장소
• 추가 작업 부하

시작 아키텍처 결정

참조 아키텍처는 성능, 탄력성 및 비용이라는 세 가지 중요한 요소 사이의 균형을 맞추도록 설계되었습니다. 이러한 아키텍처는 GitLab을 대규모로 설정하는 것을 더 쉽게 만들기 위해 설계되었지만, 여전히 귀하의 요구 사항을 충족하는 것과 어디서부터 시작해야 하는지를 알기는 여전히 어려울 수 있습니다.

일반적인 지침으로 환경이 더 성능이 좋고/또는 탄력적이면 그만큼 더 복잡해진다.

본 섹션에서는 참조 아키텍처를 선택할 때 고려해야 할 사항에 대해 설명합니다.

예상되는 부하(RPS 또는 사용자 수)

올바른 아키텍처 크기는 주로 환경의 예상 최대 부하에 따라 달라집니다. 이 부하의 가장 객관적인 측정 방법은 환경으로 들어오는 최대 초당 요청 (RPS)을 통해합니다.

각 아키텍처는 다른 유형의 요청(API, 웹, Git)에 대한 특정 RPS 대상을 처리하도록 설계되었습니다. 이러한 세부 정보는 각 페이지의 테스트 방법론 섹션에 설명되어 있습니다.

RPS를 확인하는 것은 특정 환경 설정 및 모니터링 스택에 상당히 의존할 수 있습니다. 일부 잠재적인 옵션에는 다음이 포함될 수 있습니다:

• GitLab Prometheus 및 sum(irate(gitlab_transaction_duration_seconds_count{controller!~'HealthController|MetricsController|'}[1m])) by (controller, action)와 같은 쿼리 사용.
• 기타 모니터링 솔루션.
• 부하 분산 장치 통계.

만약 귀하의 RPS를 결정할 수 없다면, 수동 및 자동 사용을 모두 고려하여 일반적인 RPS 값으로 매핑된 사용자 수에 기반한 대안적인 크기 조정 방법을 제공합니다.

초기 크기 조정 가이드

예상 부하에 대해 어떤 아키텍처를 선택해야 하는지를 결정하기 위해 다음 초기 크기 조정 가이드 테이블을 참조하세요:

참고: 초기 아키텍처를 선택하기 전에이 섹션을 신중히 검토하십시오. 고가용성(HA) 또는 대규모 단일 저장소 사용과 같은 다른 요소를 고려하십시오. 이러한 요소는 RPS 또는 사용자 수 이상으로 영향을 미칠 수 있습니다.

참고: 초기 참조 아키텍처를 선택한 후, 지원되는 메트릭에 따라 귀하의 요구 사항에 따라 상하 조정할 수 있습니다.

독립형 (비-HA)

2,000명 이하의 사용자를 서비스하는 환경의 경우, 비-HA, 단일 노드 또는 다중 노드 환경을 배포하여 독립형 접근 방식을 권장합니다. 이러한 방식으로 자동 백업과 같은 복구를 위한 전략을 활용할 수 있습니다. 이러한 전략은 HA와 관련된 복잡성을 피하면서 복구 시간 목표(RPO) 또는 복구 지점 목표(RTO)를 잘 제공합니다.

독립형 설정에서 특히 단일 노드 환경의 경우, 설치 및 관리를 위한 다양한 옵션이 제공됩니다. 해당 옵션에는 특정 클라우드 제공업체 마켓플레이스에서 직접 배포할 수 있는 기능이 포함되어 복잡성을 조금 더 줄일 수 있습니다.

고가용성 (HA)

고가용성은 GitLab 설정의 모든 구성 요소가 다양한 매커니즘을 통해 장애를 처리할 수 있음을 보장합니다. 그러나 이를 달성하는 것은 복잡하며, 필요한 환경은 상당히 큽니다.

3,000명 이상의 사용자를 서비스하는 환경의 경우, 일반적으로 HA 전략을 사용하는 것이 좋습니다. 이 수준에서는 중단 시 사용자에게 더 큰 영향을 미칩니다. 이러한 이유로 이 범위 내의 모든 아키텍처에는 HA가 이미 내장되어 있습니다.

고가능성 (HA)이 필요한가요?

이전에 언급했듯이, HA를 달성하는 것에는 비용이 듭니다. 각 구성 요소를 곱해야 하므로 환경 요구 사항이 크며, 이는 추가적인 실제 및 유지 관리 비용이 발생합니다.

3,000명 미만의 많은 고객들에게 백업 전략이 충분하며 오히려 선호되는 경우가 많았습니다. 이는 복구 시간이 더 느리지만 결과적으로 훨씬 작은 아키텍처와 이로 인한 유지 관리 비용이 적다는 의미입니다.

일반적인 지침으로는 다음과 같은 경우에만 HA를 사용하세요:

• 3,000명 이상의 사용자가 있는 경우.
• GitLab의 장애가 업무 흐름에 심각한 영향을 미칠 경우.

축소된 고가용성 (HA) 접근 방식

사용자 수가 적더라도 HA가 필요한 경우, 3,000 사용자 아키텍처를 조정하여 달성할 수 있습니다.

다운타임 없는 업그레이드

다운타임 없는 업그레이드는 HA가 있는 표준 환경에서 사용할 수 있습니다(Cloud Native Hybrid은 지원되지 않습니다). 이를 통해 환경을 업그레이드하는 동안 시스템을 유지할 수 있습니다. 그러나 이 과정은 결과적으로 더 복잡하며 문서에 자세히 기술된 제한 사항이 있습니다.

이 과정을 수행하는 동안 HA 메커니즘이 작용하기 때문에 여전히 짧은 다운타임이 발생할 수 있음에 주의해야 합니다.

대부분의 경우, 업그레이드를 실행하는 데 필요한 다운타임은 상당하지 않아야 합니다. 이 접근 방식은 핵심 요구 사항인 경우에만 사용하세요.

클라우드 네이티브 하이브리드 (Kubernetes HA)

추가 HA 내구성의 한 가지 방안으로써, 클라우드 네이티브 하이브리드 참조 아키텍처에서 일부 구성 요소를 Kubernetes에 배치할 수 있습니다. 안정성을 위해 Gitaly와 같은 상태를 유지하는 구성 요소는 Kubernetes에 배포할 수 없습니다((#stateful-components-in-kubernetes)).

클라우드 네이티브 하이브리드는 표준 참조 아키텍처에 비해 대체로 고급된 설정입니다. Kubernetes에서 서비스를 운영하는 것은 복잡합니다. 강력한 Kubernetes 지식과 경험이 있는 경우에만 이 설정을 사용하세요.

GitLab Geo (교차 지역 배포 / 재해 복구)

GitLab Geo를 사용하면 서로 다른 지역의 분산 환경 및 완전한 재해 복구(DR) 설정을 구현할 수 있습니다. GitLab Geo는 적어도 두 개의 별도 환경이 필요합니다:

• 기본 사이트 하나.
• 복제본으로 작동하는 하나 이상의 보조 사이트.

기본 사이트를 사용할 수 없는 경우, 보조 사이트 중 하나로 장애 조치(Failover)할 수 있습니다.

이 고급 및 복잡한 설정은 환경에서 DR이 필수적인 경우에만 사용하세요. 또한 각 사이트가 어떻게 구성되어야 하는지에 대한 추가적인 결정을 내려야 합니다. 예를 들어, 각 보조 사이트가 주 사이트와 동일한 아키텍처로 구성되어야 하는지 또는 각 사이트가 HA로 구성되어 있는지 등에 대해 결정해야 합니다.

대규모 단일 저장소 / 추가 워크로드

대규모 단일 저장소 또는 중요한 추가 워크로드는 환경의 성능에 상당한 영향을 미칠 수 있습니다. 상황에 따라서 일부 조정이 필요할 수 있습니다.

이런 상황이 해당되는 경우, 추가 지침을 위해 고객 성공 관리자 또는 지원 팀에 문의하세요.

클라우드 제공업체 서비스

이전에 설명한 모든 전략에 대해 전용 클라우드 제공업체 서비스(CDN)에서 PostgreSQL 데이터베이스 또는 Redis와 같은 GitLab 구성 요소를 실행할 수 있습니다.

자세한 내용은 권장 클라우드 제공업체 및 서비스를 참조하세요.

의사 결정 트리

다음 의사 결정 트리를 참고하기 전에 상기된 안내를 제일 먼저 읽으세요.

요구 사항

참조 아키텍처를 구현하기 전에 다음 요구 사항과 안내를 참조하십시오.

지원되는 CPU

아키텍처는 주로 GCP 및 AWS와 같은 다양한 클라우드 공급 업체에서 구축 및 테스트됩니다. 다양성을 보장하기 위해 CPU 대상은 주로 다음과 같은 플랫폼을 기준으로 의도적으로 설정됩니다.

• GCP의 n1 시리즈.
• AWS의 m5 시리즈.

다른 요구 사항(메모리 또는 네트워크 대역폭 등)에 따라 아키텍처 전체에 걸쳐 서로 다른 머신 유형이 사용됩니다. 위의 대상 CPU가 잘 작동할 것으로 기대합니다.

원한다면 더 최신의 머신 유형 시리즈를 선택하고 이로 인해 성능을 향상시킬 수 있습니다.

또한 Linux 패키지 환경 및 클라우드 공급 업체 서비스에서 ARM CPU를 지원합니다.

참고: 임의의 “burstable” 인스턴스 유형은 일관되지 않은 성능으로 인해 권장되지 않습니다.

지원되는 디스크 유형

GitLab에서는 대부분의 표준 디스크 유형이 작동할 것으로 기대됩니다. 그러나 다음 구체적인 부분을 인지하십시오.

• Gitaly는 읽기 작업에 대해 최소 8,000 IOPS(입력/출력 작업) 및 쓰기 작업에 대해 2,000 IOPS를 요구합니다.
• 일관되지 않은 성능 때문에 “burstable” 디스크 유형의 사용을 권장하지 않습니다.

다른 디스크 유형은 GitLab과 작동할 것으로 기대됩니다. 내구성 또는 비용 등과 같은 요구 사항에 따라 선택하십시오.

지원되는 인프라

GitLab은 대부분의 인프라(예: AWS, GCP, Azure와 같은 신뢰할 수 있는 클라우드 공급 업체 및 서비스 또는 자체 관리형(ESXi))에서 실행될 수 있으며 다음을 충족해야 합니다.

• 각 아키텍처에서 자세히 설명된 사양.
• 이러한 섹션의 어떠한 요구 사항.

그러나 이는 모든 잠재적인 조합과 호환성을 보장하지는 않습니다.

자세한 정보는 권장 클라우드 공급 업체 및 서비스를 참조하십시오.

대형 단일 저장소

아키텍처는 모범 사례를 따르는 다양한 크기의 저장소로 테스트되었습니다.

그러나, 대형 단일 저장소 (수 기가바이트 이상)는 Git의 성능에 상당한 영향을 미칠 수 있으며, 따라서 환경 자체에도 영향을 줄 수 있습니다. 그러한 존재와 사용 방법은 Gitaly에서 기본 인프라까지 중대한 압력을 가할 수 있습니다.

이러한 성능 영향은 주로 소프트웨어적인 면에서 발생합니다. 추가 하드웨어 리소스는 고객에게 점점 감소하는 수익을 제공합니다.

경고: 만약 여러분의 경우에 해당된다면, 관련 문서를 따르고 고객 성공 매니저 또는 지원 팀에게 추가 지침을 요청하는 것을 강력히 권장합니다.

대형 단일 저장소는 주목할 만한 비용이 발생합니다. 만약 해당 저장소가 있다면, 다음 지침을 따르어 성능을 보장하고 비용을 관리하십시오.

• 대형 단일 저장소 최적화. 이러한 기능을 사용하여 바이너리를 저장하지 않을 수 있는 LFS 등과 같은 저장소 크기를 줄이는 방법을 사용하면 성능이 크게 향상되고 비용이 절감될 수 있습니다.
• 단일 저장소에 따라 환경 사양을 보상하기 위해 추가 요구 사항이 필요할 수 있습니다. 이는 단일 저장소 자체 및 해당 사용 방법에 따라 다릅니다.
• 단일 저장소가 상당히 큰 경우(20 기가바이트 이상), 추가 리소스 또는 경우에 따라 단일 Gitaly 백엔드가 필요할 수 있습니다.
• 대형 단일 저장소의 경우 네트워크 및 디스크 대역폭도 고려해야 합니다. 매우 무거운 경우에는 대역폭 포화가 가능하며, 동시에 많은 클론(예: CI에서)이 발생하는 경우입니다. 이 상황에서는 가능한 경우 전체 클론을 줄이십시오. 그렇지 않으면 대역폭을 늘리기 위해 추가 환경 사양이 필요합니다. 이는 클라우드 공급 업체에 따라 다릅니다.

추가 워크로드

이 아키텍처는 실제 데이터를 기반으로 한 표준 GitLab 설정에 대해 설계 및 테스트되었습니다.

그러나 추가 워크로드는 후속 작업을 발생시켜 작업의 영향을 증폭시킬 수 있습니다. 단순히 특정한 사양을 조정해야 할 수 있습니다.

• 노드에 보안 소프트웨어.
• 대규모 저장소에 대한 수백 개의 동시 CI 작업.
• 높은 빈도로 실행되는 사용자 지정 스크립트.
• 많은 대규모 프로젝트에서의 통합.
• 서버 후크.
• 시스템 훅.

일반적으로 모든 추가 워크로드의 영향을 측정하기 위해 견고한 모니터링이 있어야 합니다. 추가적으로 변경될 사항에 대한 정보를 제공하기 위해 고객 성공 매니저 또는 지원팀에 문의하십시오.

부하 분산기

아키텍처는 클래스에 따라 최대 두 개의 부하 분산기를 사용합니다.

• 외부 부하 분산기 - 주로 레일스와 같은 외부에 노출된 구성 요소에 트래픽을 제공합니다.
• 내부 부하 분산기 - Praefect 또는 PgBouncer와 같이 HA 환경에 배포된 일부 내부 구성 요소에 트래픽을 제공합니다.

어떤 부하 분산기를 사용할지 또는 정확한 구성은 GitLab 문서의 범위를 벗어납니다. 가장 일반적인 옵션은 머신 노드에 부하 분산기를 설정하거나 클라우드 공급 업체에서 제공하는 서비스를 사용하는 것입니다. Cloud Native Hybrid 환경을 배포한다면 차트를 사용하여 외부 부하 분산기를 설정할 수 있습니다.

각 아키텍처 클래스에는 기계에 직접 배포하기 위한 권장 기본 기계 크기가 포함되어 있습니다. 그러나 선택한 부하 분산기 및 예상 작업량과 같은 요소에 따라 조정이 필요할 수 있습니다. 주의할 점은 여러 네트워크 대역폭을 가진 기계가 고려해야 할 수도 있습니다.

다음 섹션에서 부하 분산기에 대한 추가 지침을 제공합니다.

균형 알고리즘

노드로의 호출을 고르게 분산시키고 성능을 향상시키기 위해 가능한 경우 최소 연결 기반 로드 밸런싱 알고리즘 또는 해당하는 알고리즘을 사용하세요.

실제로 연결을 고르게 분산하지 못하는 것으로 알려진 Round-Robin 알고리즘의 사용을 권하지 않습니다.

네트워크 대역폭

머신에 배포된 로드 밸런서의 총 네트워크 대역폭은 클라우드 제공업체에 따라 상당히 다를 수 있습니다. AWS와 같은 일부 클라우드 제공업체는 언제든지 대역폭을 결정하는데 크레딧을 사용하는 터스트 시스템에서 작동할 수 있습니다.

로드 밸런서에 필요한 네트워크 대역폭은 데이터 형태와 작업량과 같은 요소에 따라 다를 수 있습니다. 각 아키텍처 클래스의 권장 기본 크기는 실제 데이터를 기반으로 선택되었습니다. 그러나 대형 단일 저장소의 일괄 복제와 같은 특정 시나리오에서는 크기를 그에 맞게 조정해야할 수 있습니다.

스왑 미사용

레퍼런스 아키텍처에서 스왑을 권장하지 않습니다. 성능에 큰 영향을 미치는 보안 장치입니다. 대부분의 경우에 충분한 메모리가 있는 디자인이므로 스왑이 필요하지 않습니다.

프라에펙트 PostgreSQL

Praefect는 자체 데이터베이스 서버와 완전한 HA를 달성하기 위한 타사 PostgreSQL 데이터베이스 솔루션을 필요로 합니다.

우리는 미래에는 이러한 제약에 대한 내장된 솔루션을 제공할 계획입니다. 한편, 규격은 리눅스 패키지를 사용하여 HA가 아닌 PostgreSQL 서버를 설정할 수 있도록 요구됩니다. 더 많은 정보는 다음 이슈를 참조하세요.

• omnibus-gitlab#7292.
• gitaly#3398.

추천 클라우드 제공업체 및 서비스

주의: 아래 목록은 모두를 포함하는 것은 아닙니다. 일반적으로 여기에 없는 다른 클라우드 제공업체들 또한 동일한 사양으로 작동하지만, 이는 확인되지 않았습니다. 또한 여기에 명시되지 않은 다른 클라우드 제공업체 서비스들에 있어서는 각 구현이 상당히 다를 수 있으므로 제품화 전 철저한 테스트가 권장됩니다.

테스트와 실제 사용을 통해 레퍼런스 아키텍처는 다음 클라우드 제공업체에서 추천됩니다:

또한, 다음 클라우드 제공업체 서비스들을 레퍼런스 아키텍처의 일부로 사용하는 것을 권장합니다:

1. GCP Cloud SQL의 엔터프라이즈 플러스 에디션은 더 큰 환경(500 RPS / 25,000 사용자 이상)을 위해 최적의 성능을 제공하는 것이 일반적입니다. 작업량에 따라 서비스의 기본 연결 수치보다 높은 연결 수치로 조정해야할 필요가 있을 수 있습니다.
2. Azure Cache for Redis의 프리미엄 티어를 배포하는 것이 좋은 성능을 보장하는 것이 강력히 권장됩니다.

데이터베이스 서비스에 대한 권장 사항

외부 데이터베이스 서비스를 사용하기로 결정했을 때, 표준적이고 성능이 우수하며 지원되는 버전을 실행해야 합니다.

외부 제삼자 서비스를 사용하는 경우:

1. HA Linux 패키지 PostgreSQL 설정은 PostgreSQL, PgBouncer 및 Consul을 포함하고 있습니다. 이러한 구성 요소는 제삼자 외부 서비스를 사용할 때 더 이상 필요하지 않을 수 있습니다.
2. HA를 달성하기 위해 필요한 노드 수는 Linux 패키지와 비교하여 서비스에 따라 달라질 수 있으며 마찬가지로 맞추어야 할 필요가 없습니다.
3. 가능한 경우 데이터베이스 부하 분산을 위해 일반적으로 읽기 전용 복제본을 활성화하는 것이 좋습니다. 특히 대규모 환경(200 RPS/10,000 사용자 이상)의 경우에는 표준 Linux 패키지 배포와 노드 수를 맞추는 것이 좋습니다.
4. 서비스의 일부로 풀러가 제공되는 경우 전체 부하를 병목 현상 없이 처리할 수 있는지 확인하십시오. 예를 들어, Azure Database for PostgreSQL 유연한 서버는 선택 사항으로 데이터베이스 앞에 PgBouncer 풀러를 배포할 수 있지만, PgBouncer는 단일 스레드이므로 이는 병목 현상을 유발할 수 있습니다. 그러나 데이터베이스 부하 분산을 사용하는 경우 이를 보상하기 위해 각 노드에 분산 방식으로 활성화할 수 있습니다.
5. GitLab Geo를 사용할 경우 서비스는 Cross Region 복제를 지원해야 합니다.

지원되지 않는 데이터베이스 서비스

몇몇 데이터베이스 클라우드 제공업체 서비스는 위의 사항을 지원하지 않거나 다른 문제가 있는 것으로 알려져 있으며 권장되지 않습니다:

• Amazon Aurora는 호환되지 않으며 지원되지 않습니다. 자세한 내용은 14.4.0을 참조하세요.
• Azure Database for PostgreSQL Single Server는 지원되지 않습니다. 해당 서비스는 현재 지원되지 않는 버전의 PostgreSQL에서 작동하며 안정성 및 성능 문제가 있었음이 확인되었습니다.
• Google AlloyDB 및 Amazon RDS Multi-AZ DB 클러스터는 테스트되지 않았으며 권장되지 않습니다. 두 솔루션 모두 특히 GitLab Geo와 호환되지 않을 것으로 예상됩니다.
  • Amazon RDS Multi-AZ DB 인스턴스는 별도의 제품으로 지원됩니다.

Redis 서비스에 대한 권장 사항

외부 Redis 서비스를 사용하기로 결정했을 때, 표준적이고 성능이 우수하며 지원되는 버전을 실행해야 합니다. 특히 이는 GitLab에서 지원되지 않는 클러스터 모드에서 동작해서는 안됩니다.

Redis는 주로 단일 스레드입니다. 2,000 RPS/10,000 사용자 이상을 대상으로 하는 환경에서는 Cache 및 Persistent 데이터로 인스턴스를 분리하여 이 규모에서 최적의 성능을 달성할 수 있습니다.

객체 저장소에 대한 권장 사항

GitLab은 기대치에 맞는 다양한 객체 저장소 제공업체를 테스트했습니다.

일반적인 지침으로 전체 S3 호환성을 갖춘 신뢰할 수 있는 솔루션을 사용하는 것이 좋습니다.

제안된 참조 아키텍처와의 일탈

일반적인 지침으로 참조 아키텍처에서 멀어질수록 해당 지원을 받기가 어려워집니다. 어떤 일탈이든, 잠재적인 문제점을 찾는 것에 어려움을 추가하는 복잡성을 도입하게 됩니다.

참조 아키텍처는 공식 Linux 패키지 또는 Helm Charts를 사용하여 다양한 구성 요소를 설치하고 구성합니다. 이러한 구성 요소는 별도의 기기(가상화 또는 베어 메탈)에 설치되며 “구성” 열에 기기 하드웨어 요구 사항 및 GCP/AWS/Azure 열의 동등한 VM 표준 크기로 나열되어 있습니다.

동일한 사양의 Docker(포함하여 Docker Compose)에 구성 요소를 실행하는 것은 괜찮지만, 여전히 지원 관련 복잡성을 추가할 수 있는 추가적인 계층입니다. 그러나 컨테이너에서 strace를 쉽게 실행할 수 없는 등의 지원 복잡성을 추가할 수 있습니다.

지원되지 않는 디자인

우리는 GitLab 환경 디자인을 다양하게 지원하려 노력하지만, 확실히 작동하지 않는 특정 접근 방식이 있음을 알고 있으며 결과적으로 지원되지 않습니다. 이러한 접근 방식에 대한 자세한 내용은 다음 섹션에서 설명되어 있습니다.

Kubernetes에서의 상태 유지 구성 요소

Kubernetes에서 Gitaly Cluster와 같은 상태 유지 구성 요소를 실행하는 것은 지원되지 않습니다.

Gitaly Cluster는 전통적인 가상 머신에서만 지원됩니다. Kubernetes는 엄격한 메모리 제한을 강제하는데, Git의 메모리 사용은 예측할 수 없기 때문에 Gitaly 팟이 가끔씩 OOM 종료를 유발하여 중대한 장애와 잠재적 데이터 손실로 이어질 수 있습니다. 이와 같은 이유로 Kubernetes에서의 Gitaly는 테스트되지 않고 지원되지 않습니다. 자세한 내용은 epic 6127을 참조하세요.

이는 PostgreSQL 및 Redis와 같은 다른 타사 상태 유지 구성 요소에도 적용됩니다. 그러나 특별히 지원되지 않는 것으로 명시하지 않는 한 이러한 구성 요소에 대해 다른 타사 솔루션을 탐색할 수 있습니다.

상태가 있는 노드의 자동 확장

일반적으로, 상태가 없는 GitLab 구성 요소만이 자동 확장 그룹에서 실행될 수 있습니다. 즉, GitLab Rails 및 Sidekiq입니다. Gitaly와 같은 상태가 있는 다른 구성 요소는 이러한 방식으로 지원되지 않습니다. (자세한 내용은 이슈 2997을 참조하세요).

이는 PostgreSQL 및 Redis와 같은 다른 타사 상태 유지 구성 요소에도 적용됩니다. 그러나 특별히 지원되지 않는 것으로 명시하지 않는 한 여기서 설명된 것과 같이 이러한 구성 요소에 대해 다른 타사 솔루션을 탐색할 수 있습니다.

그러나 Cloud Native Hybrid 설정은 일반적으로 ASG보다 선호되며, 데이터베이스 마이그레이션 및 Mailroom과 같은 특정 구성 요소는 Kubernetes에서만 단일 노드에서 실행할 수 있으므로 이를 Kubernetes에서 더 잘 처리합니다.

여러 데이터 센터에 환경 퍼뜨리기

하나의 GitLab 환경을 여러 데이터 센터에 퍼뜨리는 것은 잠재적인 스플릿 브레인(분할된 두 개 이상의 컴퓨터가 각각 독립적으로 처리하는 뇌와 같은 현상) 예외 사례로 인해 지원되지 않습니다. 예를 들어, GitLab 설정의 몇 가지 구성 요소, 즉 Consul, Redis Sentinel 및 Praefect는 올바르게 기능하려면 홀수 개의 쿼럼이 필요하며, 여러 데이터 센터로 분할하는 것은 이를 뚜렷하게 영향을 줄 수 있습니다.

여러 데이터 센터 또는 지역에 GitLab을 배포하기 위해 종합적인 솔루션으로 GitLab Geo를 제공합니다.

검증 및 테스트 결과

테스트 플랫폼 팀은 참조 아키텍처의 교착 상태를 보장하기 위해 정기적으로 스모크 및 성능 테스트를 수행합니다.

테스트 수행 이유

품질 부서는 GitLab의 성능을 측정하고 개선하는 데 중점을 두며, 구성 가능한 성능 구성으로 자체 관리 고객이 신뢰할 수 있는 참조 아키텍처를 생성하고 검증합니다.

자세한 내용은 handbook 페이지를 참조하십시오.

테스트 수행 방법

테스트는 모든 참조 아키텍처 및 클라우드 제공 업체에 대해 자동 및 입양식으로 수행됩니다. 이들은 두 도구에 의해 수행됩니다:

• GitLab 환경 툴킷은 환경을 구축하기 위한 Terraform 및 Ansible 스크립트입니다.
• GitLab 성능 도구는 성능 테스트를 위한 도구입니다.

클라우드 제공 업체의 테스트 환경에서 구성 요소 사이의 네트워크 지연은 <5ms로 측정되었습니다. 이는 관측 사항으로 공유되며 명시적인 권장 사항이 아닙니다.

우리는 아키텍처에 대해 ‘스마트한 테스트’ 접근을 가지려고 노력하고 있으며, 이러한 테스트는 1만 명의 Linux 패키지 설치에 초점을 맞추고 있습니다. 이는 다른 아키텍처 및 클라우드 제공 업체 및 클라우드 네이티브 하이브리드에도 적용할 수 있는 좋은 지표인 것으로 입증되었기 때문입니다.

표준 참조 아키텍처는 플랫폼에 독립적으로 설계되어 있으며, Linux 패키지를 통해 모든 것이 VMs 상에서 실행됩니다. 테스트는 주로 GCP에서 수행되지만, 상당한 하드웨어 사양으로 다른 클라우드 제공 업체에서 실행되거나 온프레미스(베어 메탈)에서 실행되는 경우 유사하게 수행된다는 것을 입증하였습니다.

이러한 참조 아키텍처에서의 테스트는 특정 코드화된 워크로드를 기반으로 수행되며, 테스트에 사용되는 처리량은 샘플 고객 데이터를 기반으로 계산됩니다. 귀하의 규모에 해당하는 참조 아키텍처를 선택해 주십시오.

각 엔드포인트 유형은 초당 요청(RPS) 당 다음과 같은 수의 요청으로 테스트됩니다:

• API: 20 RPS
• Web: 2 RPS
• Git (Pull): 2 RPS
• Git (Push): 0.4 RPS (가장 가까운 정수로 반올림)

위의 RPS 대상은 CI 및 기타 워크로드를 포함한 전체 환경 부하에 해당하는 실제 고객 데이터 기반으로 선정되었습니다.

결과 해석 방법

참고: QA 팀이 GitLab 성능 테스트 도구를 어떻게 활용하는지에 대한 블로그 글을 읽어보세요.

테스트는 공개적으로 수행되며, 모든 결과가 공유됩니다.

다음 테이블은 참조 아키텍처에 대한 테스트 세부 정보 및 빈도 및 결과를 보여줍니다. 추가 테스트는 지속적으로 평가되며, 해당 테이블이 그에 따라 업데이트됩니다.

비용 계산기 템플릿

시작점으로, 다음 표는 각 클라우드 제공업체의 공식 계산기를 사용하여 GCP, AWS 및 Azure의 다른 참조 아키텍처에 대한 초기 컴퓨팅 계산기 비용 템플릿을 나열합니다.

그러나 다음 주의 사항을 주의하십시오:

• 이러한 것들은 리눅스 패키지 아키텍처에 대한 대략적인 추정 컴퓨팅 템플릿에 불과합니다.
• 디스크, 네트워크 또는 객체 저장소와 같은 동적 요소를 고려하지 않습니다. 이는 비용에 상당한 영향을 미칠 수 있습니다.
• 클라우드 네이티브 하이브리드의 성격으로 인해 해당 배포의 정적 비용 계산을 제공할 수 없습니다.
• 클라우드 제공업체 계산기의 기본 사용 할인이 적용됩니다.
• 각 구성에 따라 많이 달라지므로 베어메탈 비용은 여기에 포함되지 않습니다.

특정 환경에 대한 비용을 정확하게 예상하려면 가장 가까운 템플릿을 선택하고 사양 및 예상 사용 사항과 일치하도록 조정해야 합니다.

참조 아키텍처 환경 유지

참조 아키텍처 환경을 유지하는 것은 일반적으로 다른 GitLab 환경과 크게 다르지 않으며, 보통 이 문서의 다른 섹션에서 다루고 있습니다.

이 섹션에서 관련 영역에 대한 문서에 대한 링크와 특정 참조 아키텍처에 대한 참고 사항을 찾을 수 있습니다.

환경 확장

참조 아키텍처는 시작점으로 설계되었으며 탄력적이며 확장 가능합니다. 배포 이후에 성능 용량을 추가하거나 비용을 줄이기 위해 구체적인 요구에 맞게 환경을 조정하고 싶을 가능성이 높습니다. 이것은 예상대로, 척도 조정은 구성 요소가 고갈될 가능성이 있을 때에 대비하여 순차적으로 또는 실질적으로 다음 크기의 아키텍처로 전체적으로 수행할 수 있습니다.

참고: 만약 구성 요소가 계속해서 리소스를 고갈시키는 것을 보게 된다면, 규모 변경을 수행하기 전에 반드시 지원팀에 문의하는 것이 강력히 권장됩니다. 특히 구성 요소를 크게 확장할 계획이 있다면 그렇게 할 경우에는 특히 그런 경우에는 그렇게 할 경우에는 그렇게 할 경우에는 그렇게 할 경우에는 대단히 그렇게 할 경우에는 그렇게 할 경우에는 그렇게 할 경우에는 그렇게 할 경우에는 그렇게 할 경우에는 그렇게 할 경우에는 그렇게 할 경우에는 그렇게 할 경우에는 그렇게 할 경우에는 그렇게 할 경우에는 그렇게 할 경우에는 그렇습니다.

대부분의 구성 요소는 일반적으로 수직 및 수평 스케일링이 적용될 수 있습니다. 그러나 그 전에 다음의 주의 사항을 주의깊게 살펴보십시오.

반대로, 환경이 과다 구성되었다는 것을 나타내는 견고한 지표가 있다면 비슷하게 축소할 수 있습니다. 그러나 이 경우에도 문제가 없도록 하기 위해 순진한 방법으로 축소할 것을 권장합니다.

스케일링 연쇄 작용

어떤 경우에는 구성 요소를 크게 확장하면 하류 구성 요소에 연쇄 작용을 일으켜 성능에 영향을 미칠 수 있습니다. 참조 아키텍처는 구성 요소 간의 균형을 고려하여 설계되었으며, 그 결과로 특정 구성 요소를 크게 확장하면 이로 인해 종속되어 있는 다른 구성요소에 추가 처리량이 전달되어 그 구성요소의 규모도 조정해야 할 수 있음을 확인할 수 있을 것입니다.

참고: 참조 아키텍처는 상류 구성 요소가 확장되도록 탄력적으로 설계되었지만, 여전히 안전하게 환경에 중대한 변경을 수행하기 전에 지원 팀에 문의하는 것이 일반적으로 권장됩니다.

다음 구성 요소는 상당한 규모로 확장될 때 다른 구성 요소에 영향을 미칠 수 있습니다.

• Puma 및 Sidekiq - Puma나 Sidekiq 작업자의 상당한 확장은 내부 로드 밸런서로의 높은 동시 연결 또는 PostgreSQL(및 PgBouncer, 경우에 따라서), Gitaly(및 Praefect, 경우에 따라서) 및 Redis로의 커넥션을 증가시킬 수 있습니다.
  • Redis는 주로 단일 스레드입니다. 경우에 따라서, 결합된 클러스터에서 CPU 고갈을 유발할 경우 캐시 및 지속적인 데이터를 분리된 인스턴스로 분할할 필요가 있을 수 있습니다.
  • PgBouncer 역시 단일 스레드이지만 확장 시 새로운 풀이 추가될 수 있으며, 이는 결과적으로 Postgres로의 총 연결을 증가시킬 수 있습니다. 의심스러울 경우에만 이를 수행하도록 강력히 권장하며, Postgres 연결을 관리하는 데에 경험이 있거나 의견이 필요할 경우에는 지원을 요청하십시오.
• Gitaly 클러스터 / PostgreSQL - 추가 노드의 상당한 확장은 HA 시스템 및 성능에 부정적인 영향을 미치므로 주 의해야 합니다.

HA 아키텍처에서 비 HA 아키텍처로 스케일링

대부분의 경우에서 성능 리소스를 증가시키기 위해서는 환경의 리소스를 늘리기만 하면 되지만, 만약 HA 환경으로 전환해야 하는 경우에는 다음에 해당하는 구성 요소에 대한 변경 작업을 수행해야 합니다. 주어진 문서를 따라서 각각의 HA 형태로 전환하는 데 필요한 추가 단계를 취해야 합니다.

• 멀티 노드 Redis w/ Redis Sentinel로의 전환을 위해 기존 단일 머신 설치에서 전환하는 방법
• Consul + PgBouncer로의 멀티 노드 Postgres로의 전환을 위한 가이드
• Praefect와 함께 Gitaly Cluster로의 전환을 위한 방법

업그레이드

참조 아키텍처 환경의 업그레이드는 다른 GitLab 환경에서의 것과 동일합니다. GitLab 업그레이드 주요 섹션에는 이에 대한 세부적인 절차가 담겨 있습니다.

제로 다운타임 업그레이드도 가능합니다.

참고: 참조 아키텍처를 만든 순서와 같은 순서로 참조 아키텍처를 업그레이드해야 합니다.

모니터링

인프라 및 GitLab 그 자체를 모니터링하기 위한 다양한 옵션이 있으며, 그에 대한 자세한 정보는 선택한 모니터링 솔루션의 문서를 참고하십시오.

이외에도, GitLab 애플리케이션에는 Prometheus 및 다양한 Prometheus 호환성 수출자가 번들로 제공되어 해당 솔루션에 연동할 수 있습니다.

업데이트 이력

다음은 참조 아키텍처에 대한 주목할만한 업데이트 이력입니다(2021-01-01부터, 오름차순으로 정렬), 최소한 1분기마다 이를 업데이트하고자 합니다.

GitLab 프로젝트에서 전체 변경 기록을 확인할 수 있습니다.

2024:

• 2024-08: 예상 로드 섹션을 업데이트하여 RPS를 계산하는 예제를 더 추가했습니다.
• 2024-08: 40 RPS / 2k User 페이지에서 Redis 구성을 올바르게 업데이트했습니다.
• 2024-08: 모니터링 노드에서 Prometheus를 위한 Sidekiq 구성을 업데이트했습니다.
• 2024-08: 페이지에 대한 추가 기능을 발견할 수 있도록 다음 단계 앵커 섹션을 추가했습니다.
• 2024-05: 60 RPS / 3k User 및 100 RPS / 5k User 페이지를 업데이트하여 Redis 지침을 최신으로 하고 Redis Sentinel을 Redis 본문에 적절하게 배치한 것을 갱신했습니다.
• 2024-05: 비용 계산 섹션을 보다 정확한 비용 추정치를 제공하기 위한 계산기만이 출발점으로 사용되며 특정 사용량과 함께 조정되어야 하므로 오직 비용 계산 템플릿 섹션으로 이름을 변경했습니다.
• 2024-04: 클라우드 네이티브 하이브리드의 Webservice 노드를 위한 권장 사이즈를 GCP용으로 업데이트했습니다. 또한 NGINX pod 권장 사항을 DaemonSet으로 구동하도록 함
• 2024-04: 20 RPS / 1,000 User 아키텍처 스펙을 16 GB의 메모리 타깃을 따르도록 업데이트했습니다.
• 2024-04: 참조 아키텍처 제목을 더욱 명확하게 하고 적절한 크기 결정을 돕기 위해 RPS가 포함된 것으로 업데이트했습니다.
• 2024-02: VMs에 배포된 경우, 로드 밸런서 노드를 위한 권장 사이즈를 업데이트했고 네트워크 대역폭 고려 사항에 대한 주석도 추가했습니다.
• 2024-02: 예제에서 Sidekiq Max Concurrency 설정을 삭제처리한 것으로 업데이트했으며 이제 이전처럼 명확하게 설정할 필요가 없게 되었습니다.
• 2024-02: 2k의 Sidekiq에 대한 추가 지침을 추가하고 레일 노드에서 Sidekiq를 비활성화하는 방법을 업데이트하고 아키텍처 다이어그램을 업데이트했습니다.
• 2024-01: Azure에 대한 모든 참조 아키텍처 크기에 대한 권장 사항을 업데이트하고 최신 클라우드 서비스로 조정했습니다.

2023:

…(이하 생략)