참조 아키텍처

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

GitLab 참조 아키텍처는 권장되는 배포를 제공하기 위해 GitLab 품질 엔지니어링 및 지원 팀에 의해 설계되고 테스트되었습니다.

사용 가능한 참조 아키텍처

다음 참조 아키텍처는 환경의 권장된 시작점으로 사용할 수 있습니다.

아키텍처는 총 로드에 대한 이름을 가지며, 매뉴얼 및 자동으로 연관되며 사용자 수에 따라 실제 데이터를 기반으로 하며 대부분의 시나리오에 대한 추가적인 보증을 제공하기 위해 상당한 여유 공간이 추가되었습니다.

그러나 알려진 대형 시나리오인 대형 단일 리포지터리나 주목할 만한 추가 워크로드와 같은 경우, 조정이 필요할 수 있음에 유의해야 합니다.

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

GitLab 패키지 (Omnibus)

다음은 리눅스 패키지 기반의 아키텍처 디렉터리입니다.

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

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

시작하기 전에

먼저 고려해야 할 첫 번째 선택은 Self Managed 방법이 귀하와 귀하의 요구 사항에 적합한지 여부입니다.

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

따라서 이 경로를 선택할 때 운영 및 유지 관리 애플리케이션에 대한 작동 지식이 있는 것이 좋습니다. 이러한 포지션에 없는 경우, 저희 전문 서비스 팀은 구현 서비스를 제공하지만 장기적으로 보다 관리되는 솔루션을 원하는 경우 GitLab SaaS나 GitLab Dedicated과 같은 다른 오퍼링을 탐색하는 것이 좋습니다.

Self Managed가 여러분이 고려 중인 방법이라면, 이 페이지를 전체적으로 읽는 것이 강력히 권장됩니다. 특히 어떤 아키텍처를 사용할지 결정, 대형 단일 리포지터리 및 추가 워크로드 섹션을 읽는 것이 좋습니다.

어떤 아키텍처를 사용할지 결정하기

참조 아키텍처는 성능과 내구성이라는 두 가지 중요한 요소 사이의 균형을 이루도록 설계되었습니다.

이들은 대규모로 GitLab을 설정하는 것을 더 쉽게 만들기 위해 설계되었지만, 여전히 어떤 것이 귀하의 요구 사항을 충족하는 지 알아내는 것은 도전일 수 있습니다.

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

본 섹션에서는 선택할 수 있는 디자인에 대해 설명합니다. 복잡성이 가장 적은 것에서 가장 많은 것으로 시작하여 의사 결정 트리로 끝납니다.

예상 부하 (RPS)

가장 먼저 확인해야 하는 것은 환경이 예상되는 부하입니다.

참조 아키텍처는 기본적으로 상당한 여유를 가지고 설계되었지만, 올바른 참조 아키텍처 크기를 선택하기 위해 기존 GitLab 환경에 대한 기대되는 부하와 각 아키텍처가 테스트된 부하를 비교하여 “테스트 방법론” 섹션에서 찾을 수 있는 값을 확인하는 것이 좋습니다.

부하는 각 엔드포인트 유형(API, 웹, Git)별 초당 요청(RPS)으로 제공됩니다. 기존 인프라에서 이 정보는 대부분의 신뢰할 수 있는 모니터링 솔루션에서 또는 로드 밸런서 메트릭과 같은 다른 방식으로 제공될 수 있습니다. 예를 들어, 기존 GitLab 환경에서는 Prometheus 메트릭인 gitlab_transaction_duration_seconds과 같은 것을 사용하여이 데이터를 볼 수 있습니다.

스탠드얼론 (비-HA)

2,000명 이하 사용자를 대상으로 하는 환경의 경우, 일반적으로 비고가용 단일 노드 또는 다중 노드 환경을 배포하여 스탠드얼론 접근을 권장합니다. 이 접근 방식으로는 자동 백업과 같은 전략을 활용하여 HA와 관련된 복잡성을 피하면서도 좋은 수준의 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)

추가적인 HA 내구성의 추가적인 계층으로서, Kubernetes에서 특정 컴포넌트를 배포하여 클라우드 네이티브 하이브리드 참조 아키텍처라고 알려진 것을 사용할 수 있습니다. 안정성을 위해, Gitaly와 같은 상태 유지 구성요소는 Kubernetes에 배포할 수 없습니다.

이것은 표준 참조 아키텍처에 비해 더 고급된 설정이며, Kubernetes에서 서비스를 실행하는 것으로 잘 알려져 있습니다. 이 설정은 단지 귀하의 Kubernetes에 대한 강력한 작동 지식과 경험이 있을 때만 권장합니다.

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

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

  • 하나의 주 사이트.
  • 복제본으로서 기능하는 하나 이상의 보조 사이트.

주 사이트가 사용 불가능한 경우, 보조 사이트 중 하나로 장애 조치(failover)를 수행할 수 있습니다.

이러한 고급 및 복잡한 설정은 귀하의 환경에서 DR이 핵심 요구 사항인 경우에만 진행해야 합니다. 또한 각 사이트가 기본적으로 기본 사이트와 같은 아키텍처로 구성되어야 하는지 또는 각 사이트가 HA를 위해 구성되어야 하는지와 같은 추가적 결정을 내려야 합니다.

대형 단일 리포지터리 / 추가 작업 부하

대형 단일 리포지터리 또는 중요한 추가 작업 부하가 있는 경우, 환경의 성능에 뚜렷한 영향을 줄 수 있으며 상황에 따라 조정이 필요할 수 있습니다.

둘 중 하나라도 해당된다면 고객 지원 담당자 또는 지원팀에 문의할 것을 권장합니다.

클라우드 제공자 서비스

이전에 설명한 전략에 대하여 클라우드 제공자의 PostgreSQL 데이터베이스 또는 Redis와 같은 해당 클라우드 제공자 서비스를 사용할 수 있습니다.

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

%%{init: { 'theme': 'base' } }%% graph TD L0A(<b>어떤 참조 아키텍처를 사용해야 하나요?</b>) L1A(<b>예상 로드는 어떻게 되나요?<a href=#expected-load-rps></a>?</b>) L2A("대략 <a href=3k_users.md#testing-methodology>3,000명의 사용자</a> 이상과 동일한가요?") L2B("대략 <a href=2k_users.md#testing-methodology>2,000명의 사용자</a> 이하와 동일한가요?") L3A("<a href=#do-you-need-high-availability-ha>HA가 필요하신가요?</a><br>(또는 제로 다운타임 업그레이드)") L3B[쿠버네티스에서 선택 컴포넌트에 대한<br/>추가적인 신뢰성을 원하고 경험이 있나요?] L4A><b>권장사항</b><br><br>HA 및 지원되는 감축이 적용된 3K 아키텍처] L4B><b>권장사항</b><br><br>사용자 수에 가장 가까운 HA가 적용된 아키텍처] L4C><b>권장사항</b><br><br>사용자 수에 가장 가까운 클라우드 네이티브 하이브리드 아키텍처] L4D>"<b>권장사항</b><br><br>백업이 적용된 독립형 1K 또는 2K 아키텍처"] 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("큰 단일 리포지터리</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

이 참조 아키텍처는 Google Cloud Platform (GCP)에서 Intel Xeon E5 v3 (Haswell) CPU 플랫폼을 기준선으로하여 구축되고 테스트되었습니다 (Sysbench benchmark). 더 최신이고 동일한 크기의 CPU는 지원되며 결과적으로 성능이 향상될 수 있습니다.

ARM CPU는 리눅스 패키지 환경에서 지원되며 해당되는 경우 클라우드 제공 업체 서비스에도 지원됩니다.

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와 같이 많은 동시 복제가 있는 경우 대역폭 포화가 발생할 수 있습니다. 이러한 시나리오에서는 가능한 경우 전체 복제를 줄이는 것이 강력히 권장됩니다. 그렇지 않을 경우, 클라우드 제공 업체에 따라 대역폭을 늘리기 위해 추가 환경 사양이 필요하지만 이는 다양하게 다를 수 있습니다. ```

추가 작업량

이 참조 아키텍처는 대부분의 시나리오를 커버하기 위해 충분한 여유 공간을 고려하여 설계 및 테스트되었습니다. 그러나 추가 작업량은 후속 조치를 유발하여 작업의 영향을 곱할 수 있습니다. 예를 들어 다음과 같은 경우 바람직한 사양을 조정해야 할 수 있습니다.

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

일반적인 원칙으로는 추가 작업량의 영향을 메트릭하기 위해 견고한 모니터링이 필요합니다. 또한 추가 지침이 필요한 경우 고객 성공 관리자나 지원팀에 문의하는 것이 강력히 권장됩니다.

로드 밸런서

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

  • 외부 로드 밸런서 - 기본적으로 Rails와 같은 외부 노출 구성요소로의 트래픽 제공.
  • 내부 로드 밸런서 - Praefect나 PgBouncer와 같이 HA(High Availability) 방식으로 배포된 일부 내부 구성요소로의 트래픽 제공.

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

참조 아키텍처 클래스마다 로드 밸런서를 직접 머신에 배포하는 것을 선택하는 경우 시작할 수 있는 기본 머신 크기가 제공됩니다. 그러나 이는 사용하는 로드 밸런서 및 작업량에 따라 조정해야 할 수 있습니다. 또한 머신에 따라 네트워크 대역폭이 다를 수 있으므로 이를 고려해야 합니다.

로드 밸런서에 대한 추가 지침을 위한 다음 섹션을 참고하세요.

균형있는 알고리즘

가능하다면 노드로의 호출을 고르게 분산하고 성능을 향상시키기 위해 최소 연결 기반의 로드 밸런싱 알고리즘 또는 동등한 알고리즘을 권장합니다.

연결을 고르게 분산하지 않는다고 알려진 라운드 로빈 알고리즘의 사용을 권장하지 않습니다.

네트워크 대역폭

머신에 배포되는 로드 밸런서의 총 네트워크 대역폭은 클라우드 제공업체마다 다르게 변할 수 있습니다. 특히 AWS와 같은 일부 클라우드 제공업체는 언제든지 대역폭을 결정하는데 크레딧을 사용하는 버스트 시스템을 사용할 수 있습니다.

로드 밸런서가 필요로 하는 네트워크 대역폭은 데이터 형태와 작업량과 같은 여러 요소에 따라 달라집니다. 각 참조 아키텍처 클래스에 대한 추천 기본 크기는 적절한 여유 공간을 제공하기 위해 선택되었지만 대형 단일 리포지터리의 일관적인 복제와 같은 특정 시나리오에서는 해당 크기를 조정해야 할 수 있습니다.

스왑하지 않음

스왑은 참조 아키텍처에서 권장되지 않습니다. 성능에 큰 영향을 미치는 보조 기능이며, 참조 아키텍처는 스왑이 필요하지 않도록 메모리 여유 공간을 확보하도록 설계되었습니다.

Praefect PostgreSQL

Praefect는 자체 데이터베이스 서버가 필요하며, 완전한 고가용성을 달성하기 위해 제3자 PostgreSQL 데이터베이스 솔루션이 필요합니다.

우리는 이러한 제한 사항에 대한 내장 솔루션을 향후 제공할 계획입니다. 한편, 사양은 리눅스 패키지를 통해 비-HA PostgreSQL 서버를 설정할 수 있도록 반영하고 있습니다. 자세한 내용은 다음 이슈를 참조하세요:

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

note
아래 디렉터리은 전체적이지 않을 수 있습니다. 여기에 나열되지 않은 다른 클라우드 제공업체들도 해당 사양을 준수할 가능성이 높지만, 이는 검증되지 않은 사실입니다. 또한 여기에 나열되지 않은 다른 클라우드 제공업체 서비스의 경우 각 구현이 두드러짐에 따라 매우 다를 수 있으므로 제품 사용 전에 철저하게 테스트하는 것이 좋습니다.

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

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

또한, 다음 클라우드 제공업체 서비스가 참조 아키텍처의 일부로 사용하기에 권장됩니다:

클라우드 서비스 GCP AWS Azure 베어 메탈
객체 스토리지 🟢   Cloud Storage 🟢   S3 🟢   Azure Blob Storage 🟢   MinIO
데이터베이스 🟢   Cloud SQL 🟢   RDS 🟢   Azure Database for PostgreSQL Flexible Server
Redis 🟢   Memorystore 🟢   ElastiCache 🟢   Azure Cache for Redis (Premium)

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

외부 데이터베이스 서비스를 사용하려는 경우, 표준 및 성능이 좋은 지원되는 버전을 실행해야 합니다.

서드 파티 외부 서비스를 사용하는 경우:

  1. HA Linux 패키지 PostgreSQL 설치는 PostgreSQL, PgBouncer 및 Consul을 포함하고 있습니다. 이러한 컴포넌트는 서드 파티 외부 서비스를 사용할 때 더 이상 필요하지 않습니다.
  2. HA를 달성하기 위해 필요한 노드 수는 Linux 패키지와 비교하여 서비스에 따라 달라질 수 있으며, 해당 수와 일치할 필요는 없습니다.
  3. 그러나 추가적인 개선된 성능을 위해 데이터베이스 로드 밸런싱을 통한 읽기 복제본을 원한다면, 참조 아키텍처의 노드 수를 따르는 것이 좋습니다.
  4. 서비스의 일부로 풀러가 제공된다면 병목 현상 없이 총 부하를 처리할 수 있는지 확인하세요. 예를 들어, Azure Database for PostgreSQL Flexible Server는 데이터베이스 앞에 PgBouncer 풀러를 선택적으로 배포할 수 있지만, PgBouncer는 단일 스레드이므로 이로 인해 병목 현상이 발생할 수 있습니다. 그러나 데이터베이스 로드 밸런싱을 사용하는 경우, 이를 각 노드에 분산하여 활성화할 수 있습니다.
  5. GitLab Geo를 사용할 경우 서비스는 Cross Region 복제를 지원해아 합니다.

Redis 서비스에 대한 권장 사항

외부 Redis 서비스를 사용하려는 경우, 표준 및 성능이 좋은 지원되는 버전을 실행해아 합니다. GitLab에서는 클러스터 모드에서 실행하면 지원되지 않으니 주의하세요.

Redis는 주로 단일 스레드입니다. 10,000명 이상의 사용자 및 이상을 위한 참조 아키텍처에서는 최적의 성능을 위해 Cache 및 Persistent 데이터로 구분하여 인스턴스를 사용하세요.

Object Storage에 대한 권장 사항

GitLab은 예상대로 작동하는 여러 Object Storage 제공 업체를 테스트했습니다.

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

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

일부 데이터베이스 클라우드 제공 업체 서비스는 위에서 설명한 방법을 지원하지 않거나 기타 문제가 발견되어 권장되지 않습니다:

제안된 참조 아키텍처에서 벗어남

일반적인 지침으로, 참조 아키텍처에서 멀어질수록 지원받기가 더 어려워집니다. 어떠한 책임의 거부가 추가되면 잠재적인 문제점을 찾는 데 도전을 겪게 됩니다.

참조 아키텍처는 각 컴포넌트를 설치하고 구성하기 위해 공식 Linux 패키지 또는 Helm Charts를 사용합니다. 이러한 컴포넌트는 별도의 기계(가상화 또는 bare metal)에 설치되며 “Configuration” 열에 기계 하드웨어 요구 사항이 나열되어 있고 GCP/AWS/Azure 열에 해당하는 VM 표준 크기가 나열되어 있습니다. 도커(도커 컴포즈 포함)에서 컴포넌트를 실행해도 마찬가지로 좋습니다. 그러나 여전히 추가적인 층으로 복잡성이 추가되어 strace를 컨테이너에서 쉽게 실행할 수 없는 등의 지원 복합성이 추가될 수 있습니다.

지원되지 않는 디자인

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

Kubernetes에서의 상태 유지 컴포넌트

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

Gitaly Cluster는 전통적인 가상 머신에서만 지원됩니다. Kubernetes는 엄격한 메모리 제한을 강제하는데, Git 메모리 사용량은 예측하기 어려워 Gitaly pod의 간헐적인 OOM 종료를 유발하여 중대한 중단 및 잠재적인 데이터 손실로 이어질 수 있습니다. 이러한 이유 등으로 Gitaly는 Kubernetes에서 테스트되지 않았으며 지원되지 않습니다. 자세한 내용은 epic 6127를 참조하세요.

Postgres 및 Redis와 같은 다른 써드파티 상태 유지 컴포넌트에도 동일한 적용이 되지만, 이와는 별도로 지원되지 않는 것이 명시적으로 명시된 경우에 한해 해당 컴포넌트의 다른 써드파티 솔루션을 살펴볼 수 있습니다.

상태 있는 노드의 자동 확장

일반적인 지침으로, 상태를 유지하는 컴포넌트인 Gitaly와 같은 다른 컴포넌트는 Autoscaling 그룹에서 실행되지 않습니다(GitLab Rails 및 Sidekiq는 예외).

Postgres 및 Redis와 같은 다른 써드파티 상태 유지 컴포넌트에도 동일한 적용이 되지만, 이와는 별도로 지원되지 않는 것이 명시적으로 명시된 경우에 한해 해당 컴포넌트의 다른 써드파티 솔루션을 살펴볼 수 있습니다.

여러 데이터 센터에 하나의 환경 분산

하나의 GitLab 환경을 여러 데이터 센터에 나누어 배포하는 것은 지원되지 않습니다. 데이터 센터가 다운되면 잠재적인 분산된 상황으로 인해 문제가 발생할 수 있습니다. 예를 들어, Consul, Redis Sentinel 및 Praefect와 같은 GitLab 설정 컴포넌트 중 일부는 올바르게 작동하려면 홀수 개의 쿼럼이 필요하며, 여러 데이터 센터로 분할되면 이에 영향을 줄 수 있습니다.

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

유효성 검사 및 테스트 결과

Quality Engineering team은 정기적으로 참조 아키텍처에 대한 스모크 및 성능 테스트를 수행하여 준수를 유지하는지 확인합니다.

테스트를 수행하는 이유

품질 부서는 GitLab의 성능을 메트릭하고 향상시키는 데 초점을 두며, Self-managed 고객이 성능을 신뢰할 수 있는 참조 아키텍처를 작성하고 확인합니다.

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

테스트 수행 방법

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

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

우리는 아키텍처가 다른 환경에도 적용될 수 있는 범위를 가지고 있는 “스마트한 테스트” 접근을 가지고 있습니다. 테스트는 가장 먼저 GCP에서 1만 개의 Linux 패키지 설치에 중점을 두고 있으며, 이는 다른 아키텍처 및 클라우드 제공업체에 대해 좋은 예측 지표로 나타났습니다. 또한 클라우드 네이티브 하이브리드에 대해서도 동일하게 적용됩니다.

표준 참조 아키텍처는 플랫폼에 중립적으로 만들어졌으며, 모든 것이 Linux 패키지를 통해 VM에서 실행됩니다. 테스트는 주로 GCP에서 수행되지만, 하드웨어의 등가 사양에서 다른 클라우드 제공업체에서 실행되거나 온프레미스(bare-metal)에서 실행될 경우 유사하게 수행됨을 임의로 확인하였습니다.

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

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

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

위의 목표는 CI 및 기타 워크로드와 추가적인 상당한 여유 공간을 포함한 사용자 수에 해당하는 실제 고객 데이터를 기반으로 선택되었습니다.

결과 해석 방법

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

아래 표는 참조 아키텍처에 대한 테스트 내용, 빈도 및 결과를 상세히 보여줍니다. 추가 테스트는 계속해서 평가되며, 표는 그에 따라 업데이트됩니다.

참조
아키텍처 		GCP (* Bare-Metal을 대신함) AWS Azure
Linux 패키지 클라우드 네이티브 하이브리드 Linux 패키지 클라우드 네이티브 하이브리드 Linux 패키지
1천개 주간
2천개 주간 계획됨
3천개 주간 주간
5천개 주간
1만개 매일 주간 주간 주간
2만 5천개 주간
5만개 주간

실행 비용

시작점으로, 다음 표는 리눅스 패키지를 통한 GCP, AWS 및 Azure의 다른 참조 아키텍처의 초기 비용을 상세히 설명합니다.

caution
클라우드 네이티브 하이브리드의 특성으로 인해 정적 비용 계산이 불가능합니다. 각 구성에 따라 상당히 다르기 때문에 베어 메탈 비용은 여기에 포함되지 않았습니다.
참조 아키텍처 GCP AWS Azure
리눅스 패키지 리눅스 패키지 리눅스 패키지
1k 계산된 비용 계산된 비용 계산된 비용
2k 계산된 비용 계산된 비용 계산된 비용
3k 계산된 비용 계산된 비용 계산된 비용
5k 계산된 비용 계산된 비용 계산된 비용
10k 계산된 비용 계산된 비용 계산된 비용
25k 계산된 비용 계산된 비용 계산된 비용
50k 계산된 비용 계산된 비용 계산된 비용

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

참조 아키텍처 환경을 유지하는 것은 일반적으로 다른 GitLab 환경과 크게 다르지 않으며, 이에 대한 내용은 이 설명서의 다른 부분에서 다루고 있습니다.

이 섹션에서는 관련 영역에 대한 설명서 링크와 특정 참조 아키텍처 노트를 찾을 수 있습니다.

업그레이드

참조 아키텍처 환경의 업그레이드는 다른 GitLab 환경과 동일합니다. 기본 GitLab 업그레이드 섹션에서 이를 접근하는 방법에 대한 자세한 단계가 나와 있습니다.

다운타임 없는 업그레이드도 가능합니다.

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

환경 확장

참조 아키텍처는 사용 사례 및 상황에 따라 다양한 방식으로 확장할 수 있도록 설계되었습니다. 이는 지표가 특정 컴포넌트가 고갈되고 있는 것을 나타내는 경우에 반복적으로 하거나 대규모로 다음 크기의 아키텍처로 전체적으로 수행될 수 있습니다.

note
특정 컴포넌트가 계속해서 자원을 고갈시키는 경우, 환경을 확장하기 전에 반드시 지원 팀에 문의해야 합니다. 특히 컴포넌트를 중대하게 확장할 계획이있는 경우에는 특히 그렇습니다. 대부분의 컴포넌트에 대해 수직 및 수평 확장을 적용할 수 있습니다. 그러나 이전에 다음과 같은 유의 사항을 인식해야 합니다.
  • Puma 또는 Sidekiq를 수직으로 확장할 때는 워커의 수를 조정하여 추가 사양을 사용하도록 조정해야 합니다. Puma는 다음 재구성 시 자동으로 확장되지만, Sidekiq는 사전에 설정을 변경해야 합니다.
  • Redis와 PgBouncer는 주로 단일 스레드로 동작합니다. 이러한 컴포넌트가 CPU를 고갈시키는 경우 수평적으로 확장해야 할 수도 있습니다.
  • 특정 컴포넌트를 크게 확장하는 것은 환경의 성능에 영향을 줄 수 있는 주목할만한 연쇄 효과를 초래할 수 있습니다. 더 많은 지침을 위해 아래 전용 섹션을 참조.

반면에, 환경이 과다 구성되어 있다는 굳은 지표가 있는 경우, 비슷하게 축소할 수 있습니다. 그러나 축소할 때는 이슈가 없는지 확인하기 위해 반복적으로 접근해야 합니다.

확장의 연쇄 효과

특정 컴포넌트를 크게 확장하는 경우, 종속적인 컴포넌트에 대한 연쇄 효과가 발생할 수 있습니다. 참조 아키텍처는 서로에게 영향을 미치는 컴포넌트가 동일한 사양을 갖도록 설계되어 실효하게 균형을 이루도록 하겠습니다. 따라서 특정 컴포넌트를 크게 확장할 때 해당 증가로 인해 다른 컴포넌트에 전달되는 추가 처리량으로 인해 그들을 더 크게 확장해야 할 수 있습니다.

note
일반적인 규칙으로 대부분의 컴포넌트는 상류 컴포넌트의 확장을 수용하기 위한 여유 여지를 가지고 있으므로 이는 일반적으로 특정한 경우와 변경된 사항에 따라 달라집니다. 환경을 변화시키기 전에 지원 팀에 문의하는 것이 좋습니다.

다음 컴포넌트를 크게 확장할 경우 다른 컴포넌트에 영향을 미칠 수 있습니다:

  • Puma 및 Sidekiq - Puma 또는 Sidekiq 워커의 주목할만한 확장은 내부 로드 밸런서, PostgreSQL (PgBouncer가 있는 경우), Gitaly (Praefect가 있는 경우) 및 Redis에 대한 더 높은 동시 연결로 이어집니다.
    • Redis는 주로 단일 스레드이며, 증가된 처리량으로 CPU 고갈이 발생할 경우 현재 결합된 클러스터를 사용 중이라면 다른 인스턴스(캐시 / 영속적)로 분할해야 할 수 있습니다.
    • PgBouncer도 또한 단일 스레드입니다. 그러나 확장은 새로운 풀이 추가되어 총 연결이 증가함으로써 전체 연결수가 Postgres에 증가되므로 이 경우 Postgres 연결을 관리하는 데 경험이 있는 경우에만 이를 수행하도록 강력히 권장합니다.
  • Gitaly 클러스터 / PostgreSQL - 추가 노드의 주목할만한 확장이 HA 시스템 및 성능에 부정적인 영향을 미칠 수 있습니다.
    • 특히 Kubernetes에서 Gitaly의 실행에 대한 문제점에 대한 세부 내용을 확장했습니다.
  • [고가용성(High Availability) 아키텍처로의 확장] section 위치를 참조하여 환경을 선택할 때 참고 사항을 선택합니다.

대부분의 컴포넌트가 상게 조정될 필요가 있는 환경의 자원을 증가시키기 위해서는 경우에는, HA(High Availability) 환경으로 이동하기 위해서 추가적인 단계가 필요합니다.

아래의 컴포넌트에 대한 추가 조치가 필요합니다.

모니터링

인프라 및 GitLab 자체를 모니터링하기 위한 다양한 옵션이 있으며, 자세한 내용은 선택한 모니터링 솔루션의 문서를 참조해야 합니다.

특히 GitLab 애플리케이션에는 Prometheus 및 다양한 Prometheus 호환 판매자가 번들로 제공되어 솔루션에 연결될 수 있습니다.

업데이트 기록

아래는 참조 아키텍처(2021-01-01 이후, 오름차순)의 주목할만한 업데이트 기록입니다.

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

2024:

  • 2024-02: VM에 배포된 로드 밸런서 노드에 대한 권장 사양 및 네트워크 대역폭 고려 사항을 추가했습니다.
  • 2024-02: Sidekiq Max Concurrency 설정에 대한 설명이 폐기되었으며 더 이상 명시적으로 설정할 필요가 없습니다.
  • 2024-02: 2k에서 Sidekiq 비활성화에 대한 설명과 아키텍처 다이어그램을 업데이트했습니다.
  • 2024-01: 모든 참조 아키텍처 크기에 대한 Azure에 대한 권장 사항 및 최신 클라우드 서비스를 업데이트했습니다.

2023: … (계속됨)