참조 아키텍처

Tier: Free, Premium, Ultimate Offering: Self-Managed

GitLab 참조 아키텍처는 시작점으로 사용할 권장 확장 가능하고 탄력적인 배포를 제공하기 위해 GitLab 테스트 플랫폼 및 지원팀에 의해 설계되고 테스트되었습니다.

사용 가능한 참조 아키텍처

다음은 환경에 대한 권장 시작점으로 사용할 수 있는 참조 아키텍처입니다.

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

note
각 아키텍처는 확장 가능하고 탄력적으로 설계되었습니다. 따라서 특정 작업 부하에 따라 필요에 따라 조정할 수 있습니다. 이것은 대규모 단일 리포지터리 사용 또는 주목할만한 추가 작업 부하와 같은 알려진 과중한 시나리오에서 발생할 수 있습니다.

각 참조 아키텍처가 무엇을 테스트했는지에 대한 자세한 내용은 각 페이지의 “테스팅 방법론” 섹션을 참조하십시오.

GitLab 패키지 (Omnibus)

다음은 Linux 패키지 기반의 참조 아키텍처 디렉터리입니다.

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

다음은 클라우드 네이티브 하이브리드 참조 아키텍처 디렉터리입니다. 여기서 일부 권장 컴포넌트가 Kubernetes에서 실행될 수 있습니다.

시작하기 전에

먼저 고려해야 할 첫 번째 선택은 Self-Managed 방식이 여러분과 여러분의 요구사항에 적합한지 여부입니다.

프로덕션 환경에서 어떠한 응용프로그램이든 실행하는 것은 복잡합니다. GitLab에도 마찬가지입니다. 우리는 이를 가능한한 원활하게 만들려 노력하고 있지만, 여전히 일반적인 복잡성이 존재합니다. 이는 선택한 설계에 따라 다르지만 일반적으로 하드웨어, 운영 체제, 네트워킹, 리포지터리, 보안, GitLab 자체 등과 같은 모든 측면을 관리해야 합니다. 이는 환경의 초기 설정 및 장기적인 유지 보수 모두에 해당합니다.

따라서 이러한 루트를 따를 결정할 때, 실제로 운영환경에서 응용프로그램을 실행하고 유지 관리하는 지식을 가지고 있는 것이 권장됩니다. 이러한 위치에 있지 않은 경우, 저희 프로페셔널 서비스팀에서는 구현 서비스를 제공하지만 장기적으로 관리되는 솔루션을 찾는 분들에게는 GitLab SaaS나 GitLab Dedicated 등의 기타 옵션을 탐색하는 것이 권장됩니다.

Self-Managed 방식을 고려 중이시라면, 이 페이지를 포함하여 시작할 아키텍처 결정, 대규모 단일 리포지터리 및 추가 작업 부하 섹션을 특히 자세히 읽는 것이 강력하게 권장됩니다.

시작할 아키텍처 결정하기

참조 아키텍처는 성능, 내구성 및 비용이라는 세 가지 중요한 요소 사이의 균형을 맞추기 위해 설계되었습니다.

이 아키텍처들은 GitLab을 대규모로 설정하기를 더 쉽게 만들기 위해 설계되었지만, 여러분의 요구 사항을 충족하는 것과 어디서부터 시작해야 하는지 알아내는 것은 여전히 어려울 수 있습니다.

일반적인 가이드로 성능이나 내구성을 원할수록 환경이 더 복잡해진다.

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

예상 부하

가장 먼저 확인해야 할 것은 환경이 처리해야 할 예상 최고 부하입니다.

각 아키텍처는 최고 요청 수(RPS) 또는 사용자 수로 설명됩니다. 각 페이지의 “테스트 방법론” 섹션에 자세히 설명되어 있듯이 각 아키텍처는 각 엔드포인트 유형(API, Web, Git)의 디렉터리된 RPS에 대해 테스트되며, 이는 주어진 사용자 수의 일반적인 최고 부하(매뉴얼 및 자동 포함)입니다.

기존 메트릭(예: Prometheus와 같은)이나 추정을 통해 환경이 처리해야 할 예상 RPS를 확인하고 해당 아키텍처를 선택하는 것이 가장 객관적이므로 강력히 권장합니다.

의심스러울 때 가장 가까운 사용자 수를 선택하고 그에 따라 스케일링

예상 최고 RPS를 알아낼 수 없다면 사용자 수를 기준으로 선택한 후 환경이 RPS, 아키텍처의 성능 및 필요에 따라 스케일링을 확인하기 위해 환경을 밀접히 모니터링하는 것이 권장됩니다.

스탠드얼론(비-HA)

2,000명 이하의 사용자를 대상으로 하는 환경의 경우, 일반적으로 비고가용 단일 또는 다중 노드 환경을 배포하여 독립형 방식을 권장합니다. 이러한 방식으로, 자동 백업을 사용하여 RPO / RTO 수준을 제공하고 HA와 관련된 복잡성을 피할 수 있습니다.

특히 단일 노드 환경의 경우, 설치를 위한 여러 옵션이 제공되며, 이는 복잡성을 더욱 줄여 주는 특정 클라우드 제공업체 마켓플레이스를 통해 직접 배포할 수도 있습니다.

고가용(고가용성) 환경(HA)

고가용성은 GitLab 설정의 각 컴포넌트가 다양한 메커니즘을 통해 장애를 처리할 수 있도록 하는 것입니다. 그러나 이를 달성하는 것은 복잡하며 필요한 환경은 상당할 수 있습니다.

3,000명 이상의 사용자를 대상으로 하는 환경의 경우, 우리는 일반적으로 이 수준의 장애가 더 많은 사용자에게 더 큰 영향을 미치기 때문에 HA 전략이 사용되도록 권장합니다. 이러한 이유로 이 범위의 모든 아키텍처는 HA가 내장되어 있습니다.

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

앞서 언급한 것처럼 HA를 달성하는 데는 비용이 발생합니다. 각 컴포넌트를 복제해야 하기 때문에 환경 요구 사항이 크며, 이로 인해 추가 실제 및 유지 관리 비용이 발생합니다.

3,000명 이하의 사용자를 대상으로 하는 많은 고객들에게는 백업 전략이 충분하며 심지어 선호되는 경우도 있습니다. 이는 복구 시간이 느리지만 그 결과 작은 아키텍처와 결과적으로 적은 유지 관리 비용이 발생한다는 것을 의미합니다.

따라서 우리는 일반적으로 다음 시나리오에서만 HA를 사용할 것을 권장합니다:

  • 사용자가 3,000명 이상인 경우.
  • GitLab 다운로드가 여러분의 작업 흐름에 중대한 영향을 미칠 경우.

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

사용자 수가 적은 경우에도 HA를 필요로 하는 경우, 낮은 사용자 수용 3K 아키텍처를 조정하여 이를 달성할 수 있습니다.

제로 다운타임 업그레이드

제로 다운타임 업그레이드는 HA가 있는 표준 참조 아키텍처 환경에서 사용 가능하며(Cloud Native Hybrid은 지원되지 않음), 환경이 업그레이드 중에 작동 상태를 유지할 수 있도록 합니다. 그러나 결과적으로 이 프로세스는 더 복잡해지며 문서에서 자세히 설명되는 제한 사항이 있습니다.

이 프로세스를 진행할 때 HA 메커니즘이 적용되는 경우 간헐적으로 다운타임이 발생할 수 있음을 유의해야 합니다.

업그레이드를 수행하는 데 필요한 다운타임은 일반적으로 상당할 것으로 생각되지 않으므로 이를 권장하는 경우는 특히 중요한 요구 사항일 때뿐입니다.

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

클라우드 네이티브 하이브리드 참조 아키텍처로 특정 컴포넌트를 Kubernetes에 배포하여 추가 HA 내구성을 확보할 수 있습니다. 안정성을 위해 Gitaly와 같은 상태 유지형 컴포넌트는 Kubernetes에 배포할 수 없습니다.

이는 표준 참조 아키텍처에 비해 고급 구성으로, Kubernetes에서 서비스를 실행하는 것이 복잡함으로 잘 알려져 있습니다. 이 구성은 Kubernetes에 대한 높은 작업 지식과 경험이 있는 경우에만 권장됩니다.

GitLab Geo (지역간 분산/재해 복구)

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

  • 하나의 주요 사이트.
  • 주요 사이트의 복제본 역할을 하는 하나 이상의 보조 사이트.

주요 사이트가 사용 불가능한 경우, 보조 사이트 중 하나로 장애 전환할 수 있습니다.

이 고급 및 복잡한 설정은 여러분의 환경에서 DR이 필수 사항인 경우에만 시도해야 합니다. 또한 각 사이트가 기본 설정되는 방법에 대한 추가적인 결정을 내려야 합니다, 예를 들어 각 보조 사이트가 주요 사이트와 동일한 아키텍처로 구성돼야 하는지, 또는 각 사이트가 HA를 위해 구성돼야 하는지 등에 대해 결정해야 합니다.

대규모 단일 리포지터리/추가 워크로드

대규모 단일 리포지터리나 중요한 추가 워크로드가 있는 경우, 환경의 성능에 뚜렷한 영향을 미치며 상황에 따라 조정이 필요할 수 있습니다.

여러분의 경우, 고객 성공 매니저나 지원 팀에 상담을 요청하는 것이 권장됩니다.

클라우드 제공자 서비스

앞에서 설명한 모든 전략에 대해 PostgreSQL 데이터베이스 또는 Redis와 같은 등가 클라우드 제공자 서비스에서 일부 GitLab 컴포넌트를 실행할 수 있습니다.

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

%%{init: { 'theme': 'base' } }%% graph TD L0A(<b>어떤 참조 아키텍처를 사용해야 할까요?</b>) L1A(<b>예상 로드는 어떻게 되나요?</b>) L2A("기대되는 로드는 <a href=#expected-load-rps>여기</a>를 참고하세요.") L2B("2,000명 이하의 <a href=2k_users.md#testing-methodology>사용자</a>입니다.") L3A("<a href=#do-you-need-high-availability-ha>HA가 필요한가요?</a><br>(또는 제로-다운타임 업그레이드)") L3B[쿠버네티스의 특정 컴포넌트에 대한<br/>추가적인 신뢰성과 경험 여부가 있나요?] L4A><b>추천</b><br><br>60 RPS / 3,000명 이상의 사용자 아키텍처와 HA 및 지원되는 축소] L4B><b>추천</b><br><br>사용자 수에 가장 가까운 아키텍처와 HA] L4C><b>추천</b><br><br>사용자 수에 가장 가까운 Cloud Native Hybrid 아키텍처] L4D>"<b>추천</b><br><br>스탠드얼론 20 RPS / 1,000명 또는 40 RPS / 2,000명의 사용자 아키텍처와 백업"] L0A --> L1A L1A --> L2A L1A --> L2B L2A -->|예| L3B L3B -->|예| L4C L3B -->|아니오| L4B L2B --> L3A L3A -->|예| L4A L3A -->|아니오| L4D L5A("<a href=#gitlab-geo-cross-regional-distribution-disaster--recovery>크로스 리전 분산이나 재해 복구가 필요한가요?</br> 여기</a>") --> |예| L6A><b>추가 권장</b><br><br> GitLab Geo] L4A ~~~ L5A L4B ~~~ L5A L4C ~~~ L5A L4D ~~~ L5A L5B("<a href=#large-monorepos>대규모 단일리포지터리</a>가 있거나</br> <a href=#additional-workloads>추가 작업 부하</a>를 기대하는가요?") --> |예| L6B><b>추가 권장</b><br><br> 고객 성공 매니저 또는 지원팀에 문의] L4A ~~~ L5B L4B ~~~ L5B L4C ~~~ L5B L4D ~~~ L5B classDef default fill:#FCA326 linkStyle default fill:none,stroke:#7759C2

결정 트리

위 내용을 의사 결정 트리 형식으로 제시합니다. 이 전체 가이드를 읽은 후에 참고하는 것이 좋습니다.

요구 사항

참조 아키텍처를 구현하기 전에 다음 요구 사항과 가이드를 참조하세요.

지원되는 CPU

참조 아키텍처는 주로 GCP 및 AWS와 같은 다양한 클라우드 제공업체에서 구축 및 테스트되며 CPU 대상은 가장 일반적인 부분을 나타냅니다:

기타 메모리나 네트워크 대역폭과 클라우드 제공업체의 가용성과 같은 다른 요구 사항에 따라 각 아키텍처 전체에서 다양한 머신 유형을 사용하지만, 상기 대상 CPU가 성능이 잘 나올 것으로 예상됩니다.

원하는 경우 더 최신의 머신 유형 시리즈를 선택하고 성능을 향상시킬 수 있습니다.

또한 ARM CPU는 Linux 패키지 환경 및 해당하는 Cloud Provider 서비스에서 지원됩니다.

note
일괄 처리형 인스턴스 유형은 일관성 없는 성능으로 인해 권장되지 않습니다.

지원되는 디스크 유형

일반적으로 대부분의 표준 디스크 유형이 GitLab에서 작동할 것으로 예상되지만 다음 특정 사항에 유의하세요:

  • Gitaly은 읽기 작업에 대해 최소한 8,000 IOPS(초당 입력/출력 작업) 및 쓰기 작업에 대해 2,000 IOPS를 필요로 합니다.
  • 불일치하는 성능으로 인해 “일괄 처리형” 디스크 유형의 사용은 권장하지 않습니다.

위의 기준을 벗어나 디스크 유형은 GitLab에서 작동할 것으로 예상되며, 내구성이나 비용과 같은 특정 요구 사항에 따라 각각의 선택이 달라집니다.

지원되는 인프라

일반적으로 GitLab은 AWS, GCP, Azure와 같은 잘 알려진 클라우드 제공업체 및 업체의 서비스 또는 Self-Managed(ESXi)와 같은 대부분의 인프라에서 실행될 수 있어야 합니다.

다음 사항을 충족해야합니다. - 각 참조 아키텍처의 세부 사항에 명시된 사양 - 이 섹션의 요구 사항

그러나 이는 모든 잠재적인 조합에 대한 보장으로 간주되지는 않습니다.

자세한 내용은 권장 클라우드 제공자 및 서비스를 참조하십시오.

대규모 단일 리포지터리

참조 아키텍처는 최상의 사례를 따르는 다양한 크기의 리포지터리에서 테스트되었습니다.

그러나, 대규모 단일 리포지터리 (수 기가바이트 이상)는 Git의 성능 및 환경에 상당한 영향을 미칠 수 있습니다. 그러한 리포지터리의 존재와 사용 방법은 Gitaly부터 기반 인프라까지 전체 시스템에 상당한 부담을 줄 수 있습니다.

caution
이에 해당하는 경우, 해당 문서를 참조하거나 고객 성공 매니저 또는 지원팀에 문의하는 것이 강력히 권장됩니다.

따라서 대규모 단일 리포지터리는 상당한 비용을 수반합니다. 이러한 리포지터리가 있는 경우 최상의 성능을 보장하고 비용을 관리하기 위해 다음 가이드를 따르는 것이 강력히 권장됩니다.

  • 대규모 단일 리포지터리 최적화를 수행하십시오. 이러한 기능(예: LFS)을 사용하여 이진 파일을 저장하지 않고 리포지터리 크기를 줄이는 등의 접근 방법을 사용하여 성능을 크게 향상시킬 수 있습니다.
  • 단일 리포지터리에 따라 추가적인 환경 사양이 필요할 수 있습니다. 특히 Gitaly는 확실히 기존 리소스 외에 추가 리소스가 필요할 것으로 예상되며 Praefect, GitLab Rails 및 로드 밸런서에 관해서도 해당합니다. 이는 리포지터리 자체와 그에 따른 사용에 따라 상당히 다릅니다.
  • 단일 리포지터리가 상당히 큰 경우(20기가바이트 이상) 추가 사양이 필요할 수 있으며, 때로는 경우에 따라 단일 리포지터리에 대한 별도의 Gitaly 백엔드 또는 추가적인 사양이 필요할 수 있습니다.
  • 대규모 단일 리포지터리의 경우 네트워크 및 디스크 대역폭도 고려해야 합니다. 매우 많은 병렬 클론(예: CI와 같이)이 있는 경우 대역폭 포화가 발생할 수 있으며 이 경우 이러한 클론을 가능한 한 줄이는 것이 강력히 권장됩니다. 그렇지 않으면 클라우드 제공자에 따라 달라지므로 대역폭을 늘리기 위해 추가 환경 사양이 필요할 수 있으나 이는 경우에 따라 다릅니다. ```

추가 작업량

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

그러나 추가 작업량은 후속 조치를 유발하여 작업 영향을 증폭시킬 수 있습니다. 예를 들어 다음과 같은 경우에는 제안된 사양을 조정해야 할 수 있습니다.

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

일반적으로 추가 작업량의 영향을 메트릭하기 위해 강력한 모니터링이 필요하며 필요한 경우 변경 사항을 정확히 알리기 위해 노력해야 합니다. 또한 추가 지침이 필요한 경우 귀하의 고객 성공 관리자 또는 저희 지원팀에 문의하는 것이 강력히 권장됩니다.

로드 밸런서

참조 아키텍처에서는 클래스에 따라 최대 두 대의 로드 밸런서를 사용합니다.

  • 외부 로드 밸런서 - 기본적으로 Rails와 같은 외부에서 접근 가능한 구성요소로 트래픽을 제공합니다.
  • 내부 로드 밸런서 - Praefect나 PgBouncer와 같이 HA(High Availability)로 배포된 선택한 내부 컴포넌트로 트래픽을 제공합니다.

로드 밸런서의 선택 또는 구성에 대한 구체적인 내용은 GitLab 문서의 범위를 벗어납니다. 가장 일반적인 옵션으로는 머신 노드에 로드 밸런서를 설정하거나 클라우드 제공자에서 제공하는 서비스를 사용하는 것입니다. 클라우드 네이티브 하이브리드 환경을 배포하는 경우, 차트를 통해 Kubernetes Ingress를 통해 외부 로드 밸런서를 구성할 수 있습니다.

각 참조 아키텍처 클래스마다 기본 머신 크기가 제공되어 기본적으로 사용할 수 있지만, 선택한 로드 밸런서 및 작업량에 따라 조정해야 할 수도 있습니다. 또한 머신은 네트워크 대역폭이 다양할 수 있으며 이 점 역시 고려해야 합니다.

로드 밸런서에 대한 추가 지침은 다음 섹션을 참조하십시오.

로드 밸런싱 알고리즘

가능한 경우, 최소 연결 기반 로드 밸런싱 알고리즘 또는 동등한 알고리즘을 사용하여 노드로의 호출을 골고루 분산시켜 성능을 향상시키는 것이 좋습니다.

연결을 골고루 분산시키지 않는다는 점에서 라운드로빈 알고리즘이 권장되지 않습니다.

네트워크 대역폭

머신에 배포된 로드 밸런서의 총 네트워크 대역폭은 클라우드 제공자에 따라 다양할 수 있습니다. 특히 AWS와 같은 특정 클라우드 제공자는 언제든지 대역폭을 결정하는 데 크레딧을 사용하는 폭주 시스템을 운영할 수 있습니다.

로드 밸런서가 필요로 하는 환경의 네트워크 대역폭은 데이터 형태 및 작업량과 같은 다양한 요소에 종속됩니다. 각 참조 아키텍처 클래스에 대한 권장 기본 크기는 실제 데이터를 기반으로 선정되었지만, 대규모 단일리포지터리의 일관된 복제 등의 상황에서는 해당 크기를 조정해야 할 수도 있습니다.

스왑 미사용

스왑은 참조 아키텍처에서 권장되지 않습니다. 이는 성능에 큰 영향을 미치는 보호 장치입니다. 대부분의 경우 참조 아키텍처는 스왑이 필요하지 않도록 대부분 충분한 메모리를 갖추고 있도록 설계되었습니다.

Praefect PostgreSQL

Praefect는 자체 데이터베이스 서버를 필요로 하며 전체 고가용성을 달성하려면 서드 파티 PostgreSQL 데이터베이스 솔루션이 필요합니다.

우리는 앞으로 이러한 제한 사항에 대한 내장형 솔루션을 제공할 예정입니다. 그 동안 사양이 반영된 대로 비고가용성 PostgreSQL 서버는 Linux 패키지를 사용하여 설정할 수 있습니다. 자세한 내용은 다음 이슈들을 참조하십시오.

권장하는 클라우드 제공자 및 서비스

note
다음 디렉터리은 상세하지 않습니다. 일반적으로 여기에 나열되지 않은 다른 클라우드 제공자도 동일한 사양으로 작동할 가능성이 있지만 이에 대한 확인은 되지 않았습니다. 또한 여기 나열되지 않은 다른 클라우드 제공자 서비스에 대해서는 각각의 구현이 현저히 다르며, 실제 사용 전에 철저히 테스트해야 합니다.

테스트와 실제 사용을 통해, 참조 아키텍처는 다음의 클라우드 제공자에서 권장됩니다:

참조 아키텍처 GCP AWS Azure 베어 메탈
리눅스 패키지 🟢 🟢 🟢1 🟢
클라우드 네이티브 하이브리드 🟢 🟢

또한, 참조 아키텍처의 일부로서 다음의 클라우드 제공자 서비스가 권장됩니다:

클라우드 서비스 GCP AWS Azure 베어 메탈
객체 스토리지 🟢   Cloud Storage 🟢   S3 🟢   Azure Blob Storage 🟢   MinIO
데이터베이스 🟢   Cloud SQL1 🟢   RDS 🟢   Azure Database for PostgreSQL Flexible Server
Redis 🟢   Memorystore 🟢   ElastiCache 🟢   Azure Cache for Redis (Premium)
  1. GCP Cloud SQL의 엔터프라이즈 플러스 버전은 일반적으로 최적의 성능을 위해 권장됩니다. 특히 대규모 환경(500 RPS/25,000 사용자 이상)에서는 서비스의 기본 설정보다 높은 최대 연결이 필요할 수 있습니다.
  2. Azure Cache for Redis의 Premium 티어를 배포하여 좋은 성능을 보장하는 것이 강력히 권장됩니다.

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

외부 데이터베이스 서비스를 사용하려고 하는 경우, 표준적이고 성능이 우수하며 지원되는 버전을 실행해야 합니다. 외부 데이터베이스 서비스 선택 시 이 문서를 참고하세요.

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

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

Redis 서비스에 대한 권장 사항

외부 Redis 서비스를 사용하기로 선택한 경우, 표준적이고 성능이 우수하며 지원되는 버전을 실행해야 합니다. GitLab에서는 클러스터 모드로 실행해서는 안 됩니다.

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

객체 리포지터리에 대한 권장 사항

GitLab는 지원되는 여러 오브젝트 스토리지 공급자에 대해 테스트되었으며 작동할 것으로 예상됩니다.

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

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

몇몇 데이터베이스 클라우드 제공 업체 서비스는 위와 같이 지원되지 않거나 다른 문제가 있을 수 있으며 권장되지 않습니다:

권장된 참조 아키텍처에서의 벗어남

일반적인 지침으로는 참조 아키텍처에서 멀어질수록 지원을 받기가 더 어려워집니다. 어떠한 차이가 있더라도 잠재적 문제가 발생할 수 있는 복잡성을 도입하는 것입니다.

참조 아키텍처에서는 공식 Linux 패키지 또는 Helm Charts를 사용하여 각 컴포넌트를 설치하고 구성합니다. 이러한 컴포넌트는 별도의 기계(가상 또는 원본)에 설치되며 “구성” 열에 나열된 기계 하드웨어 요구 사항과 GCP/AWS/Azure 열에 나열된 동등한 VM 표준 크기의 기계에서 설치됩니다. 링크를 참조하십시오 사용 가능한 참조 아키텍처.

도커(도커 컴포즈 포함)에서 컴포넌트를 실행하는 것도 괜찮지만, 여전히 지원 측면에서 추가적인 복잡성을 가질 수 있습니다. 그러나 도커는 컨테이너에서 strace를 쉽게 실행할 수 없는 등의 지원 복잡성을 추가할 수 있음에도 불구하고 상황에 따라 사용이 가능합니다.

지원되지 않는 디자인

GitLab 환경 디자인에 좋은 지원 범위를 갖기 위해 노력하고 있지만, 확실히 작동하지 않는 특정 접근 방식이 있으며, 결과적으로 지원되지 않습니다. 이러한 접근 방식에 대한 자세한 내용은 다음 섹션에서 설명됩니다.

Kubernetes의 Stateful 컴포넌트

Kubernetes에서 Gitaly Cluster와 같은 stateful 컴포넌트를 실행하는 것은 지원되지 않습니다.

Gitaly Cluster는 전통적인 가상 머신에서만 지원됩니다. Kubernetes는 엄격한 메모리 제한을 시행하나 Git 메모리 사용량은 예측할 수 없기 때문에 Gitaly pod의 간헐적인 OOM 종료를 유발할 수 있어 중대한 장애와 잠재적인 데이터 손실로 이어질 수 있습니다. 이러한 이유 등으로 Gitaly는 Kubernetes에서 테스트되거나 지원되지 않습니다. 자세한 내용은 epic 6127를 참조하십시오.

이는 PostgreSQL 및 Redis와 같은 다른 제3자 stateful 컴포넌트에도 해당되지만, 지원되는 경우가 아닌 경우 특정한 명시가 없다면 해당 컴포넌트에 대한 다른 제3자 솔루션을 탐구할 수 있습니다.

Stateful 노드의 자동 확장

일반적인 지침으로는, 상태가 없는 GitLab 컴포넌트만 Autoscaling 그룹에서 실행될 수 있습니다. 즉, GitLab Rails 및 Sidekiq입니다. 상태를 가진 Gitaly와 같은 다른 컴포넌트는 이러한 방식으로 지원되지 않습니다 (이슈 2997 참조).

이는 PostgreSQL 및 Redis와 같은 다른 제3자 stateful 컴포넌트에도 해당되지만, 지원되는 경우가 아닌 경우 특정한 명시가 없다면 해당 컴포넌트에 대한 다른 제3자 솔루션을 탐구할 수 있습니다.

그러나 Cloud Native Hybrid 설정은 일반적으로 ASG보다 우선되며, 데이터베이스 마이그레이션 및 Mailroom과 같은 특정 컴포넌트는 Kubernetes에서만 하나의 노드에서 실행될 수 있는 점이 더 나은 손질을 받습니다.

여러 데이터 센터에 환경 배포

여러 데이터 센터에 걸쳐 하나의 GitLab 환경을 배포하는 것은 지원되지 않습니다. 데이터 센터가 다운되는 경우 잠재적으로 분기 뇌 경계 조건 때문입니다. 예를 들어, GitLab 설정의 여러 컴포넌트인 Consul, Redis Sentinel 및 Praefect은 올바르게 기능하려면 홀수 개수의 쿼럼이 필요하며, 여러 데이터 센터로 분할하면 이를 뚜렷하게 영향을 미칠 수 있습니다.

여러 데이터 센터 또는 지역에 GitLab을 배포하려면 포괄적인 해결책인 GitLab Geo를 제공합니다.

유효성 검사 및 테스트 결과

테스트 플랫폼 팀은 정기적으로 참조 아키텍처에 대한 스모크 및 성능 테스트를 수행하여 그들이 준수되는지를 확인합니다.

테스트를 수행하는 이유

품질 부서는 GitLab의 성능을 메트릭하고 향상시키는 데 중점을 두며, 성능이 우수한 구성으로 Self-Managed 고객이 의존할 수 있는 참조 아키텍처를 생성하고 확인합니다.

자세한 정보는 핸드북 페이지를 참조하세요.

테스트 수행 방법

테스트는 자동화 및 임시 방식으로 모든 참조 아키텍처 및 클라우드 제공업체에 대해 수행됩니다. 이는 두 도구를 사용하여 수행됩니다:

모든 클라우드 제공업체의 테스트 환경에서 컴포넌트간의 네트워크 지연시간은 < 5ms로 메트릭되었습니다. 이는 관찰 결과이며 명시적인 권장 사항이 아닙니다.

우리는 “스마트한 테스트” 접근을 취하고 있으며, 테스트된 아키텍처가 기타 아키텍처에도 적용될 수 있는 좋은 범위를 갖도록 노력합니다. 테스트는 GCP에서 리눅스 패키지 10k 설치로 집중되며, 이 테스트에서 나타난 결과가 다른 아키텍처 및 클라우드 제공업체에도 비슷하게 나타난다는 것을 보여줍니다. 또한 클라우드 네이티브 하이브리드도 포함됩니다.

표준 참조 아키텍처는 플랫폼에 중립적으로 설계되었으며 모든 것을 리눅스 패키지를 통해 VM에서 실행됩니다. 테스트는 주로 GCP에서 수행되지만, 임시 테스트를 수행한 결과, 이러한 참조 아키텍처는 다른 클라우드 제공업체의 동등한 사양을 갖는 하드웨어나 온프레미스(물리적 서버)에서 실행될 경우 유사한 성능을 보여줍니다.

이러한 참조 아키텍처에서의 테스트는 특정 코딩된 작업량으로 GitLab 성능 도구에서 수행되며, 테스트에 사용된 처리량은 샘플 고객 데이터를 기반으로 계산됩니다. 귀하의 규모에 맞는 참조 아키텍처를 선택하세요.

각 엔드포인트 유형은 1,000명의 사용자당 다음과 같은 초당 요청 (RPS) 수로 테스트됩니다:

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

위의 RPS 목표는 CI 및 기타 작업을 포함한 총 환경적 부하에 해당하는 실제 고객 데이터를 기반으로 선택되었습니다.

결과 해석 방법

note
QA 팀이 GitLab 성능 테스트 도구를 활용하는 방법에 대한 블로그 글을 읽어보세요.

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

다음 표는 참조 아키텍처에 대한 테스트 내용, 빈도 및 결과를 자세히 보여줍니다. 추가 테스트는 지속적으로 평가되며 표가 갱신됩니다.

참조
아키텍처 		GCP (* 베어 메탈도 프록시) AWS Azure
리눅스 패키지 클라우드 네이티브 하이브리드 리눅스 패키지 클라우드 네이티브 하이브리드 리눅스 패키지
1k 주간
2k 주간 계획됨
3k 주간 주간
5k 주간
10k 일간 주간 주간 주간
25k 주간
50k 주간

실행 비용

다음 표는 각 클라우드 공급업체의 공식 계산기를 통해 GCP, AWS 및 Azure의 다른 참조 아키텍처의 초기 비용에 대해 설명합니다.

그러나 다음 주의 사항을 유의해 주십시오.

  • 이것들은 Linux 패키지 환경에 대한 대략적인 예산 추정치에 불과합니다.
  • 디스크, 네트워크 또는 객체 리포지터리와 같은 동적 요소를 고려하지 않습니다.
  • Cloud Native Hybrid의 특성상 해당 배포에 대한 정적 비용 계산을 제공하는 것은 불가능합니다.
  • 각 구성에 따라 상당히 다르기 때문에 베어 메탈 비용은 여기에 포함되어 있지 않습니다.

위의 이유로 귀하의 구체적인 설정 및 사용에 최대한 가까운 추정치를 얻기 위해 이러한 계산기를 사용하고 조정하는 것이 강력히 권장됩니다.

참조
아키텍처 		GCP AWS Azure
Linux 패키지 Linux 패키지 Linux 패키지
1k 계산된 비용 계산된 비용 계산된 비용
2k 계산된 비용 계산된 비용 계산된 비용
3k 계산된 비용 계산된 비용 계산된 비용
5k 계산된 비용 계산된 비용 계산된 비용
10k 계산된 비용 계산된 비용 계산된 비용
25k 계산된 비용 계산된 비용 계산된 비용
50k 계산된 비용 계산된 비용 계산된 비용

참조 아키텍처 환경 유지 관리

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

이 섹션에는 관련 영역에 대한 문서 링크와 특정 참조 아키텍처 노트가 포함되어 있습니다.

환경 확장

참조 아키텍처는 시작점으로 설계되었으며 탄력적이고 확장 가능합니다. 배포 후 성능 용량 추가 또는 비용 감소와 같은 이유로 환경을 조정해야 할 수 있습니다. 이는 예상대로이며, 따라서 메트릭이 컴포넌트가 고갈됨을 나타내는 경우 해당 확장 작업을 단계적 또는 도매로 수행할 수 있습니다.

note
컴포넌트가 지속적으로 리소스를 고갈시키고 있다면 확장 작업을 실행하기 전에 지원팀에 문의하는 것이 강력히 권장됩니다. 특히 컴포넌트를 크게 확장할 계획이라면 더욱 그렇습니다.

대부분의 컴포넌트에 대해 수직 및 수평 확장을 보통대로 적용할 수 있습니다. 그러나 이 작업을 수행하기 전에 아래 주의 사항을 인지해야 합니다:

  • Puma나 Sidekiq를 수직으로 확장할 때 워커의 양을 추가 사양을 사용하도록 조정해야 합니다. Puma는 다음 구성 변경 시 자동으로 확장되지만 Sidekiq는 구성 변경을 먼저 수행해야 합니다.
  • Redis와 PgBouncer는 주로 단일 스레드입니다. 이러한 컴포넌트가 CPU를 고갈시키고 있다면 수평으로 확장해야 할 수 있습니다.
  • 특정 컴포넌트를 크게 확장하는 것은 환경의 성능에 영향을 미칠 수 있습니다. 자세한 지침은 아래 전용 섹션을 참조하세요.

반대로, 환경이 과대 구성되었음을 나타내는 강력한 메트릭이 있으면 유사하게 축소할 수 있습니다. 그러나 이 과정은 문제가 없는지를 확인하기 위해 점진적으로 수행하는 것이 좋습니다.

크기 확장 파생 영향

특정 컴포넌트를 크게 확장하는 경우 하위 컴포넌트에 영향을 미칠 수 있습니다. 참조 아키텍처는 서로 의존하는 컴포넌트 사양이 일치하도록 설계되었습니다. 따라서 특정 컴포넌트를 크게 확장하면 해당 증가로 인해 다른 컴포넌트에 전달되는 추가 처리량이 발생할 수 있으며, 결과적으로 그들 또한 확장해야 할 수 있습니다.

note
참조 아키텍처는 상향 컴포넌트의 확장을 수용하도록 설계되었습니다. 그러나 환경에 중대한 변경을 가하려고 할 때에도 지원팀에 문의하는 것이 일반적으로 권장됩니다.

다음 컴포넌트는 크게 확장될 때 다른 컴포넌트에 영향을 미칠 수 있습니다:

  • Puma와 Sidekiq - Puma나 Sidekiq 워커의 크게 스케일업은 내부 로드 밸런서, PostgreSQL (PgBouncer가 있을 경우), Gitaly (Praefect가 있을 경우), 및 Redis로부터 더 높은 동시 연결을 초래할 것으로 예상됩니다.
    • Redis는 주로 단일 스레드 이며, 더 높은 처리량으로 CPU 고갈을 유발할 경우 현재 결합된 클러스터가 사용 중이라면 다른 인스턴스(Cache / Persistent)로 분할해야 할 수 있습니다.
    • PgBouncer 또한 단일 스레드입니다. 기존보다 확장하는 경우 새 풀이 추가되어 Postgres 전체 연결이 증가하게 됩니다. 이 경우 Postgres 연결 관리에 경험이 있는 경우에만 수행해야 하며, 의심스러울 경우 도움을 요청해야 합니다.
  • Gitaly 클러스터 / PostgreSQL - 추가 노드의 상당한 확장은 HA 시스템과 성능에 부정적인 영향을 미칠 수 있으며, 주요 노드로의 증가된 복제 호출 때문입니다.

비-HA 환경에서 HA 아키텍처로 확장

보통 수직 확장은 환경의 리소스를 늘리려 할 때만 필요하지만, 만약 HA 환경으로 전환해야 하는 경우 추가적인 단계가 필요할 것입니다. 다음 컴포넌트가 각각의 HA 형태로 전환하기 위해 필요한 단계는 다음 문서에서 차례대로 따르시기 바랍니다.

업그레이드

참조 아키텍처 환경의 업그레이드는 일반 GitLab 환경과 동일합니다. 주요 GitLab 업그레이드 섹션에 이에 대한 상세한 단계가 포함되어 있습니다.

다운타임 없는 업그레이드도 사용할 수 있습니다.

note
참조 아키텍처를 생성한 순서와 동일한 순서로 업그레이드를 수행해야 합니다.

모니터링

인프라 및 GitLab 자체를 모니터링하는 다양한 옵션이 있으며, 더 많은 정보를 위해 선택한 모니터링 솔루션 문서를 참조하시기 바랍니다.

특히 GitLab 애플리케이션은 Prometheus와 다양한 Prometheus 호환 수출 수단이 번들로 제공되며, 해당 수단들을 솔루션에 통합할 수 있습니다.

변경 이력

아래는 참조 아키텍처의 주요 변경 사항의 역대 디렉터리입니다(2021-01-01 이후, 오름차순). 1분기마다 적어도 한 번은 업데이트 되도록 노력하고 있습니다.

GitLab 프로젝트에서 전체 변경 이력을 찾을 수 있습니다.

2024:

  • 2024-04: Cloud Native Hybrid on GCP의 웹 서비스 노드를 위한 권장 크기를 업데이트했습니다. 또한 NGINX pod 권고를 위해 웹 서비스 노드 풀에서 DaemonSet으로 실행되도록 조정했습니다.
  • 2024-04: 20 RPS / 1,000 사용자 구성 사양이 권장되는 메모리 대상을 16GB의 새로운 기본 대상을 따르도록 업데이트했습니다.
  • 2024-04: 명확성 및 적절한 크기 조정을 돕기 위해 RPS를 포함한 참조 아키텍처 제목을 업데이트했습니다.
  • 2024-02: VM에 배포된 경우 로드 밸랜서 노드의 권장 크기를 업데이트했습니다. 또한 네트워크 대역폭 고려 사항에 대한 참고 사항을 추가했습니다.
  • 2024-02: 사례에서 더는 사용되지 않으므로 Sidekiq Max Concurrency 설정을 제거하고 상세 아키텍처도 업데이트했습니다.
  • 2024-02: 2K에 대한 Sidekiq 권고를 Rails 노드에서 Sidekiq를 비활성화하는 방법에 대한 상세 정보를 포함해 조정했습니다.
  • 2024-01: 모든 참조 아키텍처 크기에 이른 AZURE의 최신 클라우드 서비스와 모든 참조 아키텍처 크기에 대한 AZURE에 대한 권장 설정을 업데이트했습니다.

2023:

  • 2023-12-12: 존경받는 모든 고수준 서비스로부터 일정 수준 작업을 예상했었던 로드 밸런서에 대한 노트를 보다 반영하도록 업데이트했습니다.
  • 2023-11-03: 각 참조 아키텍처의 목적, 사용된 테스팅 방법에 대한 확장된 세부사항 및 환경을 확장하는 방법에 대한 자세한 사항을 추가했습니다.
  • 2023-11-03: 디스크 유형, 객관적 저장 및 모니터링에 대한 확대된 노트를 추가했습니다.
  • 2023-10-25: Linux 패키지 역할을 사용하도록 Sidekiq 구성 예제를 조정했습니다.
  • 2023-10-15: 2k 사용자를 위한 Sidekiq 권고 사항을 포함하고 3k 및 5k의 인스턴스 유형 및 수를 조정했습니다.
  • 2023-10-08: 큰 Monorepo의 사용에 대해 경고하는 데 더 많은 욍촉 사항을 추가했습니다.
  • 2023-10-04: Task Runner pod의 새로운 이름인 Toolbox에 대한 업데이트를 추가했습니다.
  • 2023-10-02: 증가된 처리량으로 인해 Redis를 위해 외부 서비스를 사용하는 가이드를 추가하고, 특히 10k 이상 환경을 위해 분리된 Cache 및 Persistent 서비스를 사용하는 경우에 대해 확장 사항을 더 확장했습니다.
  • 2023-09-21: Kubernetes에서 Gitaly를 실행하는 데 관한 도전을 확대했습니다.
  • 2023-09-20: 폐기 및 삭제 후에 Grafana에 대한 참조를 제거했습니다.
  • 2023-08-30: 결정 트리 하위 섹션에 대한 정보를 확대했습니다.
  • 2023-08-08: Linux 패키지를 사용하도록 설정 예제를 변경했습니다.
  • 2023-08-03: 50k 아키텍처에 대한 AWS Machine Type 오타를 수정했습니다.
  • 2023-06-30: 이제 사용되지 않는 설정을 제거하여 PostgreSQL 구성 예제를 업데이트했습니다.
  • 2023-06-30: Google Memorystore가 권장된 대로 지원되도록 주요 페이지의 명시적인 예제를 추가했습니다.
  • 2023-06-11: 3k 및 5k 아키텍처에 대한 IP 예제를 수정했습니다.
  • 2023-05-25: 외부 클라우드 제공 업체 서비스의 사용 방법에 대한 확대 노트를 추가하고, 10k 이상의 환경에 대해서는 분리된 Redis 서버를 권장하는 추가 지침을 추가했습니다.
  • 2023-05-03: Redis 5 대신에 Redis 6의 정확한 요구 사항으로 문서를 업데이트했습니다.
  • 2023-04-28: Azure PostgreSQL Flexible 서비스와 사용에 관해 지원되지 않는 디자인에 대해서 더 많은 정보를 추가했습니다.
  • 2023-03-23: 지원하지 않는 디자인에 대한 자세한 내용을 추가했습니다.
  • [2023-03-16](https://gitlab.com/gitlab