참조 아키텍처

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

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

사용 가능한 참조 아키텍처

다음 참조 아키텍처는 환경 설정의 권장 시작점으로 제공됩니다.

아키텍처는 사용자 수에 따라 연관된 총 부하 및 수동 및 자동화된 작업을 기반으로하며 실제 데이터와 대부분의 시나리오에 추가적인 커버리지를 제공하기 위해 상당한 여유 공간이 추가되었습니다.

그러나 알려진 대규모 시나리오인 경우 대형 단일저장소나 주목할만한 추가 작업 부하와 같은 경우 조정이 필요할 수 있음을 감안해야합니다.

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

GitLab 패키지 (Omnibus)

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

Cloud 네이티브 하이브리드

다음은 클라우드 네이티브 하이브리드 참조 아키텍처 목록입니다. 여기서 몇 가지 추천 구성 요소를 Kubernetes에서 실행할 수 있습니다.

시작하기 전에

고려해야 할 첫 번째 선택은 자체 관리 방식이 여러분과 여러분의 요구 사항에 적합한지 여부입니다.

프로덕션 환경에서 어떤 애플리케이션을 실행하는 것은 복잡합니다. GitLab의 경우에도 마찬가지입니다. 우리는 가능한 한 원활하게 만들기 위해 노력하지만, 여전히 일반적인 복잡성이 남아 있습니다. 이는 선택한 설계에 따라 다르지만, 일반적으로 하드웨어, 운영 체제, 네트워킹, 스토리지, 보안, GitLab 자체 및 기타 측면을 모두 관리해야 합니다. 이에는 환경의 초기 설정과 장기간 유지관리가 포함됩니다.

따라서 이러한 경로를 선택할 때 프로덕션 환경에서 애플리케이션을 실행하고 유지하는 지식이 필요합니다. 이러한 위치에 있지 않은 경우 전문 서비스팀에서는 구현 서비스를 제공하지만 장기적으로 보다 관리되는 솔루션을 원하는 경우 GitLab SaaS나 GitLab Dedicated와 같은 다른 옵션을 살펴보는 것이 좋습니다.

자체 관리 방식을 고려 중이라면 이 페이지를 전체적으로 읽는 것이 강력히 권장됩니다. 특히 어떤 아키텍처를 사용할지 결정하는 방법, 대규모 단일저장소 및 추가 워크로드 섹션을 중점적으로 살펴보는 것이 좋습니다.

어떤 아키텍처를 사용할지 결정하는 방법

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

이 아키텍처들은 GitLab을 대규모로 설정하는 것을 더 쉽게 만들기 위해 설계되었지만, 여러분의 요구 사항을 충족하는 아키텍처를 선택하는 것은 여전히 도전일 수 있습니다.

일반적인 지침으로 성능과/또는 신뢰성이 높아질수록 환경이 더 복잡해진다는 사실을 설명하는 섹션이 있습니다.

예상 로드(RPS)

먼저 확인해야 할 것은 환경이 제공할 예상 로드입니다.

참조 아키텍처는 기본적으로 상당한 여유를 가지고 설계되었지만, 왼쪽 엔드포인트 유형(API, 웹, Git)의 RPS(Requests per Second)를 테스트한 것과 비교하여 기존 GitLab 환경에서 기대되는 로드를 확인하여 적절한 참조 아키텍처 크기를 선택하는 데 도움이 되는 “Testing Methodology” 섹션에서 찾을 수 있습니다.

로드는 기존 인프라에서 대부분의 신뢰할 수 있는 모니터링 솔루션이나 로드 밸런서 메트릭과 같은 다른 방법으로 표시될 수 있습니다. 예를 들어, 기존 GitLab 환경에서는 Prometheus 메트릭인 gitlab_transaction_duration_seconds과 같은 메트릭을 사용하여 이 데이터를 확인할 수 있습니다.

단독(HA가 아닌) 환경

환경에서 2,000명 이하의 사용자를 제공하는 경우, 일반적으로 HA가 아닌 단독 방식을 권장합니다. 이러한 방식으로는 HA와 관련된 복잡성을 피하면서도 자동화된 백업을 사용하여 RPO / RTO 수준을 제공할 수 있습니다.

특히 단일 노드 환경에서는 설치를 위한 여러 옵션이나 관리를 위한 다양한 옵션이 있으며 선택적인 클라우드 제공업체 마켓플레이스를 통한 직접 배포가 가능하여 복잡성이 좀 더 감소됩니다.

고가용성(HA)

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

환경에서 3,000명 이상의 사용자를 제공하는 경우, 보다 많은 사용자에게 장애가 더 큰 영향을 미치기 때문에 보통 HA 전략을 사용하는 것을 권장합니다. 이 범위의 아키텍처는 이러한 이유로 기본적으로 HA가 내장되어 있습니다.

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

앞서 말했듯이, HA를 달성하는 것에는 비용이 발생합니다. 각 구성 요소를 곱해야 하므로, 추가적인 실제 및 유지관리 비용이 발생합니다.

3,000명 미만의 많은 고객에 대해 백업 전략이 충분하며 심지어 선호되는 경우도 있습니다. 이것은 더 느린 복구 시간을 가지게 되지만, 그 결과 작은 아키텍처와 그에 따른 유지관리 비용이 훨씬 적다는 것을 의미합니다.

일반적으로 다음과 같은 상황에서만 HA를 사용하는 것이 좋습니다:

  • 사용자가 3,000명 이상인 경우
  • GitLab이 워크플로에 중대한 영향을 미치게 되는 경우

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

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

제로 다운타임 업그레이드

제로 다운타임 업그레이드는 HA(고가용성)이 있는 표준 참조 아키텍처 환경에서 사용할 수 있습니다. (클라우드 네이티브 하이브리드는 지원되지 않음 ). 이는 환경이 업그레이드 중에도 작동 상태를 유지할 수 있게 하지만, 결과적으로 프로세스가 더 복잡해지고 설명서에 상세히 나와 있는 제한 사항이 있습니다.

이 과정을 거치면서 HA 메커니즘이 작동할 때 잠시간 다운 타임이 발생할 수 있다는 점을 주목할 가치가 있습니다.

대부분의 경우에 업그레이드에 필요한 다운 타임은 상당하지 않아야 하므로, 이는 귀하에게 필수적인 요구사항인 경우에만 권장됩니다.

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

HA 내구성의 추가적인 레이어로 클라우드 네이티브 하이브리드 참조 아키텍처에서 일부 구성 요소를 Kubernetes에 배포할 수 있습니다. 안정성을 위해 Gitaly와 같은 상태 유지 구성 요소는 Kubernetes에 배포할 수 없습니다(Kubernetes 내 상태 유지 컴포넌트).

이는 표준 참조 아키텍처에 비해 대안적이고 더 고급된 설정입니다. Kubernetes에서 서비스를 실행하는 것은 복잡하다는 것이 잘 알려져 있습니다. 이 설정은 Kubernetes에 강력한 작동 지식과 경험이 있다면에만 권장됩니다.

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

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

  • 하나의 주 서비스 사이트
  • 복제본으로 작동하는 하나 이상의 보조 사이트

주 서비스 사이트가 사용 불가능해지면 보조 사이트 중 하나로 장애 조치(Failover)를 할 수 있습니다.

이 고급 및 복잡한 설정은 환경의 DR이 중요한 요구 사항인 경우에만 해야 합니다. 또한 각 사이트가 주 사이트와 동일한 아키텍처를 가지도록 하거나 각 사이트가 HA를 위해 설정되었는지 여부와 같은 추가적인 결정을 내려야 합니다.

대규모 단일 저장소 / 추가 작업량

대규모 단일 저장소나 중요한 추가 작업량이 있는 경우, 이러한 요소들은 환경의 성능에 상당한 영향을 미칠 수 있으며 상황에 따라 조정이 필요할 수 있습니다.

해당 사항이 있을 경우 고객 성공 매니저나 지원팀에게 추가적인 지도를 받는 것을 권장합니다.

클라우드 제공업체 서비스

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

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

의사 결정 트리

아래에서 위의 지침을 의사 결정 트리의 형태로 찾아볼 수 있습니다. 그러나 먼저 위의 지침을 완전히 읽어 보는 것이 권장됩니다.

%%{init: { 'theme': 'base' } }%% graph TD L0A(<b>어떤 참조 아키텍처를 사용해야 하나요?</b>) L1A(<b>예상 로드는 어떻게 되나요?<br> [여기](#expected-load-rps)에서 확인하세요</b>) L2A("3,000명 이상의 사용자와 동등한가요?") L2B("2,000명 이하의 사용자와 동등한가요?") L3A("<a href=#do-you-need-high-availability-ha>고가용성(HA)이 필요하신가요?</a><br>(또는 제로 다운타임 업그레이드)") L3B[쿠버네티스에서 일부 구성 요소에 추가적인 내구성이 필요한가요?] L4A><b>추천 사항</b><br><br>3K 아키텍처와 HA,<br>지원되는 축소화] L4B><b>추천 사항</b><br><br>사용자 수에 가까운<br>아키텍처와 HA] L4C><b>추천 사항</b><br><br>사용자 수에 가까운<br>클라우드 네이티브 하이브리드 아키텍처] L4D>"<b>추천 사항</b><br><br>독립형 1K 또는 2K <br/>아키텍처와 백업"] 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>교차 지역 배포나 재해 복구가 필요하신가요?</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

이 참조 아키텍처는 Google Cloud Platform (GCP)에서 Intel Xeon E5 v3 (Haswell) CPU 플랫폼을 가장 낮은 공통 분모 기준으로 사용하여 구축 및 테스트되었습니다 (Sysbench benchmark). 더 최신이면서 동일한 크기의 CPU는 지원되며 성능이 향상될 수 있습니다.

ARM CPU는 Linux 패키지 환경 및 해당되는 경우 Cloud Provider services에 대해서도 지원됩니다.

참고: 어떤 “burstable” 인스턴스 유형도 일관된 성능을 제공하지 않으므로 권장하지 않습니다.

지원되는 디스크 유형

일반적인 지침으로 대부분의 표준 디스크 유형이 GitLab에서 작동할 것으로 예상되지만, 다음과 같은 특정한 사항에 유의하십시오:

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

위의 표준 외에도 디스크 유형은 GitLab에서 작동할 것으로 예상되며, 각각의 선택은 내구성 또는 비용과 같은 특정 요구 사항에 따라 다를 수 있습니다.

지원되는 인프라

일반적으로 GitLab은 AWS, GCP, Azure와 같은 선량한 Cloud Provider(클라우드 제공업체) 및 그들의 서비스 또는 요구 사항을 충족하는 자체 관리형 (ESXi)과 같은 대부분의 인프라에서 실행되어야 합니다.

  • 각 참조 아키텍처의 세부 사항.
  • 이 섹션의 요구 사항.

그러나, 이것은 모든 잠재적인 순열에 대한 보장은 아닙니다.

더 많은 정보를 보려면 권장 클라우드 제공업체 및 서비스를 참조하십시오.

대형 Monorepos

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

그러나, 대형 Monorepos (수 기가바이트 이상)는 Git의 성능 및 결과적으로 환경에 상당한 영향을 줄 수 있습니다. 그러한 저장소의 존재 및 사용 방법은 Gitaly부터 기본 인프라까지 전체 시스템에 상당한 부담을 줄 수 있습니다.

경고: 이러한 경우에 해당된다면, 연결된 설명서를 참조하고 Customer Success Manager나 지원 팀에게 추가 지침을 얻기를 강력히 권장합니다.

따라서 대형 Monorepos는 상당한 비용이 발생합니다. 이와 같은 저장소가 있다면 다음과 같은 지침을 강력히 권장하여 좋은 성능 기회와 비용을 유지할 수 있도록 하십시오:

  • 대형 Monorepo를 최적화. 바이너리를 저장하지 않도록 하는 LFS와 같은 기능 및 저장소 크기를 줄이는 기타 방법은 성능을 크게 향상시키고 비용을 줄일 수 있습니다.
  • Monorepo에 따라, 추가 환경 사양이 보상을 위해 필요할 수 있습니다. 특히 Gitaly는 확실하게 추가 리소스뿐만 아니라 Praefect, GitLab Rails 및 로드 밸런서가 필요할 것으로 예상됩니다. 이는 저장소 자체 및 해당 사용에 근거합니다.
  • 대형 Monorepo인 경우 (20 기가바이트 이상) 더 많은 환경 사양이나 경우에 따라 저장소 전용 Gitaly 백엔드가 필요할 수 있습니다.
  • 대형 Monorepos와 관련하여 네트워크 및 디스크 대역폭 또한 고려해야 할 사항입니다. 매우 무거운 경우에는 동시 복제 (예: CI와 함께)가 높다면 대역폭 포화를 볼 수 있습니다. 이러한 시나리오에서는 가능한 경우 완전한 복제를 줄이는 것이 강력히 권장되며, 그렇지 않으면 대역폭 증가를 위해 추가 환경 사양이 필요하지만, 이는 클라우드 제공자에 따라 다를 수 있습니다.

추가 작업량

이러한 참조 아키텍처는 설계 및 테스트되어 대부분의 시나리오를 커버하는 표준 GitLab 설정을 위한 여유 여백을 고려하여 설계되었습니다.

그러나 추가 작업량은 후속 작업을 트리거링하여 작업의 영향을 배로 늘릴 수 있습니다. 예를 들어 다음과 같은 경우에는 제안된 사양을 조정해야 할 수 있습니다.

일반적인 규칙으로 추가 작업량의 영향을 측정하기 위해 견고한 모니터링이 있어야 할 것으로 예상되며, 어떠한 변경이 필요한지에 대한 정보를 제공하기 위해 또한 Customer Success Manager나 지원 팀에게 직접 도움을 요청하는 것이 강력히 권장됩니다.

로드 밸런서

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

  • 외부 로드 밸런서 - 주로 레일 등 외부를 향한 컴포넌트로 트래픽을 제공합니다.
  • 내부 로드 밸런서 - Praefect나 PgBouncer와 같이 HA 방식으로 배포된 특정 내부 컴포넌트로 트래픽을 제공합니다.

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

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

로드 밸런서에 대한 추가 지침은 다음과 같습니다.

밸런싱 알고리즘

가능한 경우 노드 간 호출을 고르게 분산하고 좋은 성능을 보장하기 위해 최소 연결 기반 로드 밸런싱 알고리즘 또는 동등한 알고리즘을 사용하는 것을 권장합니다.

라운드로빈 알고리즘은 연결을 실제로 고르게 분산하지 않기 때문에 사용을 권장하지 않습니다.

네트워크 대역폭

기계에 배포된 로드 밸런서의 총 네트워크 대역폭은 클라우드 제공업체에 따라 다양하게 변할 수 있습니다. 특히, AWS와 같은 특정 클라우드 제공업체는 언제든 대역폭을 결정하기 위한 크레딧을 사용하는 터스트 시스템을 운영할 수 있습니다.

로드 밸런서가 필요로 하는 네트워크 대역폭은 데이터 형태와 워크로드와 같은 여러 요소에 의존합니다. 각 참조 아키텍처 클래스에 대한 권장 기본 크기는 적절한 여유 분량의 대역폭을 제공할 수 있도록 선택되었지만, 대형 단일 저장소의 지속적인 복제와 같은 특정 시나리오에서는 이를 수정해야 할 수도 있습니다.

스왑 없음

스왑은 추천되지 않습니다. 성능에 큰 영향을 미치는 보조 장치입니다. 참조 아키텍처는 스왑이 필요하지 않도록 메모리 여유분을 확보하는 것을 목표로 하고 있습니다.

Praefect PostgreSQL

Praefect에는 별도의 데이터베이스 서버가 필요합니다 그리고 완전한 고가용성을 달성하려면, 타사 PostgreSQL 데이터베이스 솔루션이 필요합니다.

우리는 미래에 이러한 제한에 대한 내장 솔루션을 제공할 계획입니다. 그 동안, 사양이 반영된 대로 Linux 패키지를 사용하여 비HA(PostgreSQL이 높은 가용성이 아닌) PostgreSQL 서버를 설정할 수 있습니다. 자세한 내용은 다음 이슈를 참조하세요.

권장 클라우드 제공업체 및 서비스

참고: 다음 목록은 모두를 포괄하지는 않습니다. 여기에 나열되지 않은 다른 클라우드 제공업체도 동일한 사양으로 작동할 가능성이 높지만, 이것은 확인되지 않았습니다. 또한, 여기에 나열되지 않은 다른 클라우드 제공업체 서비스의 경우, 각 구현은 뚜렷한 차이가 있을 수 있으므로 본 사용에 앞서 철저하게 테스트하는 것이 좋습니다.

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

참조 아키텍처 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)

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

외부 데이터베이스 서비스 사용을 선택하면, 표준적이고 성능이 우수하며 지원되는 버전을 운영해야 합니다.

제3자 외부 서비스 사용을 선택하는 경우:

  1. HA(Linux) 패키지 PostgreSQL 설정은 PostgreSQL, PgBouncer 및 Consul을 포함합니다. 이러한 구성요소는 제3자 외부 서비스를 사용할 때 더 이상 필요하지 않을 수 있습니다.
  2. HA를 달성하기 위해 필요한 노드 수는 Linux 패키지와 비교하여 서비스에 따라 달라질 수 있으며, 해당 노드 수와 일치하도록 설정할 필요가 없습니다.
  3. 그러나 추가적인 성능 향상을 위해 데이터베이스 로드 밸런싱을 통해 읽기 레플리카를 통한 데이터베이스 로드 밸런싱이 원하는 경우, 참조 아키텍처의 노드 수를 따르는 것이 권장됩니다.
  4. 서비스의 일부로 풀러가 제공되는 경우 전체 부하를 병목 현상 없이 처리할 수 있는지 확인하세요. 예를 들어, Azure Database for PostgreSQL Flexible Server는 데이터베이스 앞에 PgBouncer 풀러를 선택적으로 배포할 수 있지만, PgBouncer는 단일 스레드이므로 결과적으로 병목 현상을 일으킬 수 있습니다. 그러나 데이터베이스 로드 밸런싱을 사용하는 경우에는 분산 방식으로 각 노드에서 이를 활성화할 수 있습니다.
  5. 만약 GitLab Geo를 사용할 경우, 해당 서비스는 Cross Region 복제를 지원해야 합니다.

Redis 서비스에 대한 권장 사항

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

Redis는 주로 단일 스레드입니다. 10,000명 이상의 사용자를 위한 참조 아키텍처에서는 별도로 캐시 및 지속 데이터로 인스턴스를 분리하여 최적의 성능을 달성할 수 있습니다.

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

GitLab는 지원되는 여러 객체 저장소 제공업체에 대해 테스트되었으며 작동할 것으로 예상됩니다.

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

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

일부 데이터베이스 클라우드 제공업체 서비스는 위에서 언급된 사항을 지원하지 않거나 다른 문제가 발견되어 권장되지 않습니다:

추천 참조 아키텍처에서 벗어나기

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

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

동일한 사양으로 Docker(포함하여 Docker Compose)에서 구성 요소를 실행하는 것은 괜찮지만, Docker의 경우 추가적인 계층이며 strace를 쉽게 실행하지 못하는 등 지원 복잡성을 추가할 수 있습니다.

지원되지 않는 디자인

GitLab 환경 디자인을 제대로 지원하기 위해 노력하고 있지만, 확실히 작동하지 않는 특정 방법이 있습니다. 이러한 방법에 대한 자세한 내용은 다음 섹션에서 설명됩니다.

Kubernetes에서 상태 유지 컴포넌트

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

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

이는 Kubernetes에서 Postgres 및 Redis와 같은 기타 써드파티 상태 유지 컴포넌트에도 적용되지만, 지원되지 않는 것이 명시적으로 언급된 경우를 제외하고는 해당 컴포넌트에 대한 지원되는 다른 써드파티 솔루션을 탐색할 수 있습니다.

Stateful 노드의 자동 크기 조정

일반적인 지침으로는 GitLab의 stateless 구성 요소만 자동 크기 조정 그룹에서 실행할 수 있습니다. 구체적으로 GitLab Rails 및 Sidekiq을 의미합니다.

Gitaly와 같이 상태를 가지는 다른 구성 요소는 이러한 방식으로 지원되지 않습니다. 더 많은 정보는 issue 2997를 참조하십시오.

이는 Postgres 및 Redis와 같은 다른 타사의 상태를 가지는 구성 요소에도 적용됩니다. 그러나 특별히 지원되지 않는 한 해당 구성 요소에 대해 원하는 경우 클라우드 제공업체에서 제공되는 지원되는 타사 솔루션을 찾아볼 수 있습니다.

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

하나의 GitLab 환경을 여러 데이터 센터에 배포하는 것은 지원되지 않습니다. 왜냐하면 데이터 센터가 다운되었을 경우 잠재적인 스플릿 브레인 문제가 발생할 수 있기 때문입니다. 예를 들어 GitLab 설정의 여러 구성 요소, 특히 Consul, Redis Sentinel 및 Praefect는 올바르게 작동하기 위해 홀수 개의 쿼럼이 필요하며, 여러 데이터 센터에 걸쳐 분산될 경우 이는 중대한 영향을 미칠 수 있습니다.

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

유효성 검사 및 테스트 결과

Quality Engineering 팀은 참조 아키텍처의 품질 및 성능 테스트를 수행하여 준수 여부를 보장합니다.

테스트를 수행하는 이유

품질 부서는 GitLab의 성능을 측정하고 향상시키는 데 중점을 두며, 자체 관리 고객이 성능이 우수한 구성을 의지할 수 있도록 참조 아키텍처를 작성하고 확인합니다.

자세한 정보는 handbook 페이지를 참조하십시오.

테스트 수행 방법

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

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

우리는 다른 사람에게도 적용될 수 있는 다양한 범위를 가진 똑똑한 테스트 접근을 취하려고 노력합니다. 테스트는 주로 GCP에서 진행되지만, 임시적인 테스트를 통해 다른 클라우드 제공업체의 동등 사양의 하드웨어에서 비슷한 성능을 나타내는 것으로 나타났습니다.

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

각 엔드포인트 유형은 초당 요청(RPS)의 다음 수를 테스트합니다:

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

위의 목표는 CI 및 기타 작업 부하 및 추가적인 여유 공간을 고려한 사용자 수에 대응하는 실제 고객 데이터를 기반으로 선정되었습니다.

결과 해석 방법

참고: 저희 QA 팀이 GitLab 성능 테스트 도구를 어떻게 활용하는지에 대한 자세한 내용은 블로그 글을 참조하십시오.

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

아래 표는 참조 아키텍처에 대한 테스트 세부 정보와 주기 및 결과를 나타내고 있습니다. 추가 테스트는 계속해서 평가되며, 표는 그에 따라 업데이트됩니다.

실행 비용

시작점으로, 다음 표는 GCP, AWS, 그리고 Azure를 통한 Linux 패키지의 다양한 참조 아키텍처의 초기 비용을 설명하고 있습니다.

참고: 클라우드 네이티브 하이브리드의 특성으로 인해 정적 비용 계산을 제공하는 것은 불가능합니다. Bare-metal 비용은 각 구성에 따라 크게 다르므로 여기에 포함되지 않았습니다.

참조
아키텍처 		GCP AWS Azure
Linux 패키지 Linux 패키지 Linux 패키지
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도 단일 스레드이지만 스케일 아웃은 결과적으로 새로운 풀이 추가되어 총 연결 수가 증가합니다. 이를 수행할 때는 반드시 PostgreSQL 연결 관리에 대한 경험이 있는 경우에만 수행하고, 의심이 들면 지원을 받는 것이 강력히 권장됩니다.
  • Gitaly 클러스터/PostgreSQL - 추가 노드를 크게 확장하면 HA 시스템과 성능에 불리한 영향을 줄 수 있으므로 주의가 필요합니다.

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

대부분의 경우에 수직 확장은 환경 자원을 늘리기 위해서만 필요하지만, HA 환경으로 전환하는 경우 다음 구성 요소들에 대해 각각의 HA 형태로 전환하기 위해 추가 단계가 필요합니다.

모니터링

내 려볼 수 있는 몇 가지 옵션이 있으며, 그 외에 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:

  • 2023-12-12: 로드 밸런서에 대한 설명을 보다 반영적으로 업데이트(모든 신뢰할만한 제공).