• 사용 가능한 참조 아키텍처
  • GitLab 패키지 (Omnibus)
  • 클라우드 네이티브 하이브리드
• 시작하기 전에
• 어떤 아키텍처로 시작할지 결정하기
  • 예상 부하 (RPS 또는 사용자 수)
    • 초기 크기 가이드
  • 독립형 (비 HA)
  • 고가용성 (HA)
    • 고가용성 (HA)가 필요합니까?
    • 축소된 고가용성 (HA) 접근 방식
    • 무중단 업그레이드
  • 클라우드 네이티브 하이브리드 (쿠버네티스 HA)
  • GitLab Geo (지역 간 분산 / 재해 복구)
  • 대규모 모노레포 / 추가 워크로드
  • 클라우드 제공업체 서비스
  • 결정 트리
• 요구사항
  • 지원되는 CPU
  • 지원되는 디스크 유형
  • 지원되는 인프라
  • 대형 모노레포
  • 추가 워크로드
  • 로드 밸런서
    • 균형 알고리즘
    • 네트워크 대역폭
  • 스왑 없음
  • Praefect PostgreSQL
• 권장 클라우드 제공업체 및 서비스
  • 데이터베이스 서비스에 대한 추천 내용
    • 지원되지 않는 데이터베이스 서비스
  • Redis 서비스에 대한 추천 내용
  • 오브젝트 스토리지에 대한 추천 내용
• 제안된 참조 아키텍처에서 벗어나기
  • 지원되지 않는 설계
    • Kubernetes의 상태 저장 구성 요소
    • 상태 저장 노드의 자동 확장
    • 여러 데이터 센터에 하나의 환경 배포하기
• 검증 및 테스트 결과
  • 테스트를 수행하는 이유
  • 테스트 수행 방법
  • 결과 해석 방법
• 비용 계산기 템플릿
• 참조 아키텍처 환경 유지관리
  • 환경 확장
    • 하향 조정의 여파
    • 비HA 아키텍처에서 HA 아키텍처로의 확장
  • 업그레이드
  • 모니터링
• 업데이트 이력

참조 아키텍처

Offering: Self-managed

GitLab 참조 아키텍처는 목표 하중을 위한 출발점으로 권장되는 확장 가능하고 유연한 배포를 제공합니다. 이들은 GitLab Test Platform 및 Support 팀에 의해 설계되고 테스트되었습니다.

사용 가능한 참조 아키텍처

다음 참조 아키텍처는 귀하의 환경에 대한 권장 출발점으로 사용 가능합니다.

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

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

GitLab 패키지 (Omnibus)

다음은 리눅스 패키지 기반 참조 아키텍처의 목록입니다:

• 최대 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

시작하기 전에

우선, 자체 관리 방식이 귀하의 요구 사항에 적합한 선택인지 고려하십시오.

생산 환경에서 애플리케이션을 실행하는 것은 복잡하며, GitLab도 마찬가지입니다. 최대한 원활하게 만들려고 하지만, 설계에 기초한 일반적인 복잡성은 여전히 존재합니다. 일반적으로 하드웨어, 운영 체제, 네트워킹, 저장소, 보안, GitLab 자체 등과 같은 모든 측면을 관리해야 합니다. 여기에는 환경의 초기 설정과 장기적인 유지 관리가 포함됩니다.

이 경로를 선택하기로 결정했다면, 생산 환경에서 애플리케이션을 실행하고 유지 관리하는 데 대한 실무 지식이 있어야 합니다. 이러한 지식이 없다면, 우리 전문 서비스 팀에서 구현 서비스를 제공합니다. 장기적으로 보다 관리되는 솔루션을 원하는 고객은 GitLab SaaS 또는 GitLab Dedicated와 같은 다른 제안을 탐색할 수 있습니다.

자체 관리 방식을 고려하고 있다면, 다음 섹션을 특히 전체적으로 읽어보시기 바랍니다:

• 어떤 아키텍처를 사용할지 결정하기
• 대형 모노레포
• 추가 워크로드

어떤 아키텍처로 시작할지 결정하기

참고 아키텍처는 성능, 복원력 및 비용의 세 가지 중요한 요소 간의 균형을 맞추도록 설계되었습니다. 이들은 GitLab을 대규모로 설정하는 것을 쉽게 만들기 위해 설계되었습니다. 그러나 어떤 것이 귀하의 요구 사항을 충족하는지, 그리고 어디에서 시작해야 하는지는 여전히 어려울 수 있습니다.

일반적인 가이드로, 환경이 더 성능적이고/혹은 복원력이 높을수록 더 복잡해집니다.

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

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

적절한 아키텍처 크기는 주로 귀하의 환경에서 예상되는 최대 부하에 따라 다릅니다. 이 부하의 가장 객관적인 측정 기준은 환경에 들어오는 최대 초당 요청(Requests per Second, RPS)입니다.

각 아키텍처는 다양한 유형의 요청(API, Web, 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가 여전히 필요한 경우, 조정된 3K 아키텍처를 통해 이를 달성할 수 있습니다.

무중단 업그레이드

무중단 업그레이드는 HA가 있는 표준 환경에서 가능합니다(클라우드 네이티브 하이브리드는 지원되지 않음). 이를 통해 업그레이드 중에도 환경이 지속될 수 있습니다. 그러나 이 과정은 그로 인해 더 복잡하며, 문서에 자세히 설명된 몇 가지 제한 사항이 있습니다.

이 과정을 진행하는 동안 HA 메커니즘이 적용되는 동안 여전히 짧은 중단 시간이 있을 수 있음을 유의할 가치가 있습니다.

대부분의 경우, 업그레이드를 수행하는 데 필요한 중단 시간은 크지 않아야 합니다. 이는 귀하에게 중요한 요구 사항인 경우에만 이 접근 방식을 사용하세요.

클라우드 네이티브 하이브리드 (쿠버네티스 HA)

HA의 복원력을 추가적으로 지원하기 위해, 특정 구성 요소를 쿠버네티스에서 배포할 수 있으며, 이를 클라우드 네이티브 하이브리드 참조 아키텍처라고 합니다. 안정성 문제로 인해 상태 저장 구성 요소인 Gitaly는 쿠버네티스에 배포할 수 없습니다.

클라우드 네이티브 하이브리드는 표준 참조 아키텍처에 비해 대안적이고 더 고급 설정입니다. 쿠버네티스에서 서비스를 실행하는 것은 복잡합니다. 이 설정을 사용하세요 단, 쿠버네티스에 대한 강력한 작업 지식과 경험이 있는 경우에만 사용하십시오.

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

GitLab Geo를 사용하면 서로 다른 지역에 분산된 환경을 구축하고 완전한 재해 복구(DR) 설정을 갖출 수 있습니다. GitLab Geo는 최소한 두 개의 별도 환경을 필요로 합니다:

• 하나의 기본 사이트.
• 하나 이상의 보조 사이트(복제본 역할).

기본 사이트가 사용할 수 없게 되면, 보조 사이트 중 하나로 전환할 수 있습니다.

이 고급 및 복잡한 설정은 DR이 귀하의 환경에서 중요한 요구 사항인 경우에만 사용하세요. 각 사이트가 어떻게 구성될지에 대한 추가 결정을 내려야 합니다. 예를 들어, 각 보조 사이트가 기본과 동일한 아키텍처일지 또는 각 사이트가 HA에 맞게 구성될지를 결정해야 합니다.

대규모 모노레포 / 추가 워크로드

대규모 모노레포 또는 중요한 추가 워크로드는 환경의 성능에显著한 영향을 미칠 수 있습니다. 상황에 따라 일부 조정이 필요할 수 있습니다.

이 상황이 귀하에게 해당된다면, 고객 성공 관리자 또는 지원 팀에 연락하여 추가 안내를 받으시기 바랍니다.

클라우드 제공업체 서비스

앞서 설명한 모든 전략의 경우, PostgreSQL 데이터베이스 또는 Redis와 같은 동등한 클라우드 제공업체 서비스에서 특정 GitLab 구성 요소를 실행할 수 있습니다.

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

결정 트리

다음 결정 트리를 참조하기 전에 위의 안내를 먼저 전체적으로 읽어보세요.

요구사항

참조 아키텍처를 구현하기 전에 다음 요구사항과 지침을 참조하세요.

지원되는 CPU

아키텍처는 다양한 클라우드 공급자에서 구축되고 테스트되며, 주로 GCP 및 AWS를 사용합니다.

가장 넓은 호환성을 보장하기 위해 CPU 타겟은 이들 플랫폼 전반에서 낮은 공통 분모로 설정됩니다:

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

메모리 또는 네트워크 대역폭 및 클라우드 공급자 가용성과 같은 다른 요구 사항에 따라 각 아키텍처에서 다른 머신 유형이 사용됩니다. 위의 타겟 CPU가 좋은 성능을 발휘할 것으로 예상합니다.

원하신다면, 더 최신 머신 유형을 선택하여 성능을 향상시킬 수 있습니다.

추가적으로, ARM CPU는 리눅스 패키지 환경 및 모든 클라우드 공급자 서비스에 대해 지원됩니다.

참고: 일관성이 없는 성능 때문에 “버스트 가능(burstable)” 인스턴스 유형의 사용은 권장하지 않습니다.

지원되는 디스크 유형

대부분의 표준 디스크 유형은 GitLab과 함께 작동할 것으로 예상됩니다. 그러나 다음과 같은 특정 사항에 유의하세요:

• Gitaly에는 읽기 작업을 위한 최소 8,000 IOPS와 쓰기 작업을 위한 2,000 IOPS가 필요합니다.
• 성능이 일관되지 않기 때문에 “버스트 가능(burstable)” 디스크 유형의 사용은 권장하지 않습니다.

기타 디스크 유형은 GitLab과 함께 작동할 것으로 예상됩니다. 내구성 또는 비용과 같은 요구 사항에 따라 선택하세요.

지원되는 인프라

GitLab은 대부분의 인프라에서 실행되어야 하며, 신뢰할 수 있는 클라우드 공급자(AWS, GCP, Azure)와 그 서비스 또는 자가 관리(ESXi)가 다음 두 가지를 충족해야 합니다:

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

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

자세한 정보는 추천 클라우드 공급자 및 서비스를 참조하세요.

대형 모노레포

아키텍처는 모범 사례를 따르는 다양한 크기의 리포지토리로 테스트되었습니다.

그러나 대형 모노레포 (수 기가바이트 이상)는 Git의 성능 및 시스템 전체에 큰 영향을 미칠 수 있습니다.

대형 모노레포의 존재와 사용 방식은 Gitaly부터 기본 인프라까지 전체 시스템에 상당한 부담을 줄 수 있습니다.

성능 문제는 주로 소프트웨어에 기인합니다. 추가 하드웨어 리소스는 점차적인 수익 감소로 이어집니다.

경고: 해당 사항이 적용된다면, 링크된 문서를 따르고 고객 성공 관리자 또는 지원 팀에 추가 지침을 요청하는 것이 좋습니다.

대형 모노레포는 상당한 비용이 발생합니다. 이러한 리포지토리를 보유하고 있다면,

좋은 성능을 보장하고 비용을 관리하기 위해 다음 지침을 따르세요:

• 대형 모노레포 최적화. 바이너리를 저장하지 않기 위해 LFS와 같은 기능을 사용하고, 리포지토리 크기를 줄이기 위한 다른 접근 방식을 사용하는 것은 성능을 극적으로 개선하고 비용을 줄일 수 있습니다.
• 모노레포에 따라, 이를 보상하기 위해 필요한 환경 사양이 증가할 수 있습니다. Gitaly와 Praefect, GitLab Rails, 부하 분산기에 추가 리소스가 필요할 수 있습니다. 이는 모노레포 자체 및 그 사용에 따라 다릅니다.
• 모노레포의 크기가 상당히 클 경우(20 기가바이트 이상), 추가 사양 증가 또는 경우에 따라 모노레포 전용의 별도 Gitaly 백엔드와 같은 추가 전략이 필요할 수 있습니다.
• 대형 모노레포와 관련하여 네트워크 및 디스크 대역폭도 고려해야 할 수 있습니다. CI와 같은 많은 동시 복제 요청이 있을 경우 대역폭 포화가 발생할 수 있습니다. 이 경우 전체 복제를 줄이세요. 그렇지 않으면 대역폭을 늘리기 위해 추가 환경 사양이 필요할 수 있습니다. 이는 클라우드 공급자에 따라 다릅니다.

추가 워크로드

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

하지만 추가 워크로드는 후속 작업을 유발함으로써 작업의 영향을 곱할 수 있습니다.

다음의 경우 제안된 사양을 조정해야 할 수 있습니다:

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

일반적으로 추가 워크로드의 영향을 측정하기 위해 강력한 모니터링을 갖추어야 하며, 필요한 변경 사항을 알리는 데 도움이 됩니다.

추가 안내가 필요할 경우 고객 성공 관리자 또는 지원 팀에 문의하세요.

로드 밸런서

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

• 외부 로드 밸런서 - 주로 Rails와 같은 외부 노출 구성 요소에 트래픽을 제공합니다.
• 내부 로드 밸런서 - Praefect나 PgBouncer와 같은 HA 방식으로 배포된 선택된 내부 구성 요소에 트래픽을 제공합니다.

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

각 아키텍처 클래스에는 기계에 직접 배포하기 위한 추천 기본 기계 크기가 포함되어 있습니다. 그러나 선택한 로드 밸런서 및 예상 워크로드와 같은 요인에 따라 조정이 필요할 수 있습니다. 주목할 점은 기계가 고려해야 할 네트워크 대역폭을 가질 수 있다는 것입니다.

다음 섹션에서는 로드 밸런서에 대한 추가 안내를 제공합니다.

균형 알고리즘

노드에 대한 호출의 균등한 분산과 우수한 성능을 보장하기 위해 가능한 한 적은 연결 기반 로드 밸런싱 알고리즘 또는 동등한 알고리즘을 사용하세요.

우리는 실제로 연결을 균등하게 분산하지 않는 것으로 알려져 있는 라운드 로빈 알고리즘의 사용을 권장하지 않습니다.

네트워크 대역폭

기계에 배포된 로드 밸런서가 사용할 수 있는 총 네트워크 대역폭은 클라우드 제공업체마다 크게 다를 수 있습니다. 일부 클라우드 제공업체는 AWS와 같이 크레딧을 사용하여 언제든지 대역폭을 결정하는 버스트 시스템으로 운영될 수 있습니다.

로드 밸런서의 필요한 네트워크 대역폭은 데이터 형상 및 워크로드와 같은 요인에 따라 다릅니다. 각 아키텍처 클래스의 권장 기본 크기는 실제 데이터를 기반으로 선택되었습니다. 그러나 대규모 모노레포의 일관된 복제와 같은 일부 시나리오에서는 크기를 조정해야 할 수 있습니다.

스왑 없음

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

Praefect PostgreSQL

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

앞으로 이러한 제약에 대한 내장 솔루션을 제공하기를 희망합니다. 그동안 사양이 반영된 Linux 패키지를 사용하여 비HA PostgreSQL 서버를 설정할 수 있습니다. 추가 정보는 다음 문제를 참조하세요:

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

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

참고:

다음 목록은 포괄적이지 않습니다. 일반적으로 여기 나열되지 않은 다른 클라우드 제공업체도 동일한 사양으로 작동할 가능성이 있지만, 이는 검증되지 않았습니다.

또한, 여기 나열되지 않은 다른 클라우드 제공업체 서비스에 대해서는 각 구현이 상당히 다를 수 있으므로 신중하게 접근해야 하며, 실제 사용 전에 철저히 테스트해야 합니다.

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

또한, 다음 클라우드 제공업체 서비스는 참조 아키텍처의 일환으로 사용을 권장합니다:

1. GCP Cloud SQL에 대해 Enterprise Plus 에디션의 사용이 일반적으로 권장됩니다. 이 추천은 특히 대규모 환경(500 RPS / 25k 사용자 이상)에 적합합니다. 작업 부하에 따라 최대 연결 수는 서비스의 기본값보다 높게 조정해야 할 수 있습니다.

2. 좋은 성능을 보장하기 위해 Azure Cache for Redis의 Premium tier의 배포가 강력히 권장됩니다.

데이터베이스 서비스에 대한 추천 내용

외부 데이터베이스 서비스를 사용하기로 선택할 때, 표준, 성능이 우수하며 지원되는 버전에서 실행되어야 합니다.

타사 외부 서비스를 사용하기로 결정했다면:

1. HA Linux 패키지 PostgreSQL 설정에는 PostgreSQL, PgBouncer 및 Consul이 포함됩니다. 이들 구성 요소는 타사 외부 서비스를 사용할 때 더 이상 필요하지 않습니다.

2. HA를 달성하는 데 필요한 노드 수는 서비스에 따라 Linux 패키지와 다를 수 있으며 이를 일치시킬 필요는 없습니다.

3. 가능하다면 데이터베이스 로드 밸런싱을 위해 읽기 복제본을 활성화하는 것이 일반적으로 권장됩니다. 이는 표준 Linux 패키지 배포에 대한 노드 수와 일치해야 합니다. 이 추천은 특히 대규모 환경(200 RPS 초과 / 10,000 사용자 이상)에서 더욱 중요합니다.

4. 서비스의 일환으로 풀러가 제공되는 경우 해당 서비스가 전체 로드를 처리할 수 있는지 확인해야 합니다.

   예를 들어, Azure Database for PostgreSQL Flexible Server는 데이터베이스 앞에 PgBouncer 풀러를 선택적으로 배포할 수 있지만, PgBouncer는 단일 스레드로 작동하므로 이로 인해 병목 현상을 일으킬 수 있습니다. 그러나 데이터베이스 로드 밸런싱을 사용하는 경우 이를 각 노드에서 분산 방식으로 활성화하여 보완할 수 있습니다.

5. GitLab Geo를 사용할 경우 서비스가 크로스 리전 복제를 지원해야 합니다.

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

여러 데이터베이스 클라우드 제공업체 서비스는 위 내용을 지원하지 않거나 다른 문제가 발견되어 추천되지 않습니다:

• Amazon Aurora는 호환되지 않으며 지원되지 않습니다. 자세한 내용은 14.4.0을 참조하십시오.

• Azure Database for PostgreSQL Single Server는 이제 더 이상 지원되지 않는 서비스로, 지원되지 않는 PostgreSQL 버전에서 실행되고 있습니다. 또한 성능과 안정성 문제도 notable하게 발견되었습니다.

• Google AlloyDB 및 Amazon RDS Multi-AZ DB 클러스터는 테스트되지 않았으며 추천되지 않습니다. 두 솔루션 모두 GitLab Geo와의 호환이 기대되지 않습니다.

  • Amazon RDS Multi-AZ DB 인스턴스는 별도의 제품이며 지원됩니다.

Redis 서비스에 대한 추천 내용

외부 Redis 서비스를 사용하기로 선택할 때, 표준, 성능이 우수하며 지원되는 버전에서 실행되어야 합니다. 이 서비스는 클러스터 모드에서 실행되지 않아야 합니다, 이는 GitLab에서 지원하지 않기 때문입니다.

Redis는 주로 단일 스레드로 작동합니다. 200 RPS / 10,000 사용자 이상의 환경을 목표로 할 경우, 최적의 성능을 달성하기 위해 인스턴스를 캐시와 영구 데이터로 분리해야 합니다.

오브젝트 스토리지에 대한 추천 내용

GitLab은 다양한 오브젝트 스토리지 제공업체에 대해 테스트를 수행하여 작동할 것으로 예상됩니다.

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

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

일반 지침으로, 참조 아키텍처에서 멀어질수록 지원을 받기 어려워집니다. 어떤 편차를 주게 되면 잠재적인 문제가 발생할 수 있는 위치를 파악하는 데 복잡성이 추가됩니다.

참조 아키텍처는 공식 Linux 패키지 또는 Helm Charts를 사용하여 다양한 구성 요소를 설치하고 구성합니다. 구성 요소는 별도의 머신(가상화 또는 물리적)에서 설치되며, 머신 하드웨어 요구 사항은 “구성(Configuration)” 열에 나열되고 각 사용 가능한 참조 아키텍처의 GCP/AWS/Azure 열에 동등한 VM 표준 크기가 나열됩니다.

동일한 사양을 가진 Docker(및 Docker Compose)에서 구성 요소를 실행하는 것은 괜찮습니다. Docker는 지원 측면에서 잘 알려져 있습니다. 그러나 여전히 추가적인 레이어로서, 컨테이너 내에서 strace를 쉽게 실행할 수 없는 등의 지원 복잡성을 추가할 수 있습니다.

지원되지 않는 설계

우리는 GitLab 환경 설계에 대한 좋은 지원 범위를 가지려고 노력하지만, 알고 있는 특정 접근 방식 중 확실히 작동하지 않는 것들이 있으며 결과적으로 지원되지 않습니다. 이러한 접근 방식에 대한 세부 정보는 다음 섹션에 나와 있습니다.

Kubernetes의 상태 저장 구성 요소

Kubernetes에서 Gitaly 클러스터와 같은 상태 저장 구성 요소 실행은 지원되지 않습니다.

Gitaly 클러스터는 기존의 가상 머신에서만 지원됩니다. Kubernetes는 엄격한 메모리 제한을 적용하지만, Git 메모리 사용량은 예측할 수 없으므로 Gitaly 포드의 간헐적인 OOM 종료를 초래할 수 있으며, 이는 상당한 중단 및 잠재적 데이터 손실로 이어질 수 있습니다. 이러한 이유로, Gitaly는 Kubernetes에서 테스트되거나 지원되지 않습니다. 더 많은 정보는 epic 6127를 참조하세요.

이것은 Postgres 및 Redis와 같은 다른 서드파티 상태 저장 구성 요소에도 적용되지만, 특별히 지원되지 않는다고 언급하지 않는 한 그러한 구성 요소에 대해 지원되는 클라우드 제공업체 서비스를 사용할 경우 다른 서드파티 솔루션을 탐색할 수 있습니다.

상태 저장 노드의 자동 확장

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

이것은 Postgres 및 Redis와 같은 다른 서드파티 상태 저장 구성 요소에도 적용되지만, 특별히 지원되지 않는다고 언급하지 않는 한 그러한 구성 요소에 대해 지원되는 클라우드 제공업체 서비스를 사용할 경우 다른 서드파티 솔루션을 탐색할 수 있습니다.

그러나 클라우드 네이티브 하이브리드 설정은 ASG보다 일반적으로 선호되며, 데이터베이스 마이그레이션 및 Mailroom와 같은 특정 구성 요소는 한 노드에서만 실행할 수 있어 Kubernetes에서 더 잘 처리됩니다.

여러 데이터 센터에 하나의 환경 배포하기

여러 데이터 센터에 하나의 GitLab 환경을 배포하는 것은 데이터 센터가 다운될 경우 잠재적인 분할 뇌(split brain) 에지 케이스로 인해 지원되지 않습니다. 예를 들어, GitLab 구성의 여러 구성 요소, 즉 Consul, Redis Sentinel 및 Praefect는 올바르게 기능하기 위해 홀수 투표수를 필요로 하며 여러 데이터 센터에 분할될 경우 이 점에 중대한 영향을 미칠 수 있습니다.

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

검증 및 테스트 결과

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

테스트를 수행하는 이유

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

자세한 내용은 우리의 핸드북 페이지를 참조하세요.

테스트 수행 방법

테스트는 모든 참조 아키텍처와 클라우드 공급자에 대해 자동화된 방식과 수동 방식으로 이루어집니다. 이는 두 가지 도구에 의해 수행됩니다:

• GitLab 환경 툴킷 Terraform 및 Ansible 스크립트를 사용하여 환경을 구축합니다.
• GitLab 성능 도구를 사용하여 성능 테스트를 진행합니다.

모든 클라우드 공급자의 테스트 환경에서 구성 요소 간의 네트워크 지연 시간은 <5 ms로 측정되었습니다. 이는 관찰 사항으로 공유되며 암묵적인 권장 사항으로 간주되지 않습니다.

우리는 테스트된 아키텍처가 다른 아키텍처에도 적용될 수 있는 좋은 범위를 갖도록 “스마트 테스트” 접근 방식을 취하고자 합니다. 테스트는 GCP에서 10k Linux 패키지 설치에 중점을 두며, 이는 다른 아키텍처와 클라우드 공급자 및 클라우드 네이티브 하이브리드에 대한 좋은 지표인 것으로 나타났습니다.

표준 참조 아키텍처는 플랫폼에 구애받지 않도록 설계되었으며, 모든 것은 리눅스 패키지를 통해 VM에서 실행됩니다. 테스트는 주로 GCP에서 이루어지지만, 수동 테스트에서는 다른 클라우드 공급자 또는 온프레미스(베어 메탈)에서 동일한 스펙을 가진 하드웨어에서도 유사한 성능을 보이는 것으로 나타났습니다.

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

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

• API: 20 RPS
• 웹: 2 RPS
• Git (풀): 2 RPS
• Git (푸시): 0.4 RPS (가장 가까운 정수로 반올림)

위 RPS 목표는 CI 및 기타 워크로드를 포함하여 사용자 수에 해당하는 총 환경 부하에 대한 실 고객 데이터를 기반으로 선택되었습니다.

결과 해석 방법

참고: 우리가 QA 팀이 GitLab 성능 테스트 도구를 활용하는 방법에 대한 블로그 게시물을 읽어보세요.

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

다음 표는 참조 아키텍처에 대한 테스트와 그 빈도 및 결과를 상세히 설명합니다. 추가 테스트는 지속적으로 평가되며, 표는 그에 따라 업데이트됩니다.

비용 계산기 템플릿

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

그러나 다음과 같은 주의사항이 있습니다:

• 이는 Linux 패키지 아키텍처에 대한 대략적인 컴퓨트 템플릿일 뿐입니다.
• 디스크, 네트워크 또는 객체 스토리지와 같은 동적 요소는 고려하지 않습니다 - 이러한 요소들이 비용에 상당한 영향을 미칠 수 있습니다.
• Cloud Native Hybrid의 특성으로 인해 해당 배포에 대한 정적 비용 계산은 불가능합니다.
• 클라우드 제공업체 계산기에서 기본값으로 설정된 경우 커밋 사용 할인은 적용됩니다.
• 베어 메탈 비용은 각 구성에 따라 크게 달라지므로 여기에 포함되지 않습니다.

특정 환경에 대한 정확한 비용 추정을 얻으려면 가장 근접한 템플릿을 선택하고 규격 및 예상 사용량에 맞게 조정해야 합니다.

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

참조 아키텍처 환경 유지보수는 일반적으로 이 문서의 다른 섹션에서 다루는 다른 GitLab 환경과 동일합니다.

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

환경 확장

참조 아키텍처는 출발점으로 설계되었으며, 전체적으로 탄력적이고 확장 가능합니다. 배포 후 성능 용량 추가나 비용 절감 등의 이유로 특정 요구사항에 맞게 환경을 조정하고 싶어질 가능성이 높습니다. 이는 예상되는 사항으로, 메트릭스가 구성 요소가 소진되고 있음을 나타내는 경우,Scale를 반복적으로 적용하거나 다음 아키텍처 크기로 전환할 수 있습니다.

참조: 구성 요소가 지속적으로 주어진 자원을 소진하고 있다면, Scaling을 수행하기 전에 지원 팀에 문의하는 것이 강력히 권장됩니다. 이는 특정 구성 요소를 대폭 확장할 계획인 경우 특히 그렇습니다.

대부분의 구성 요소는 수직 및 수평 Scaling을 일반적으로 적용할 수 있습니다. 그러나 이를 수행하기 전에 아래의 주의 사항을 인지해야 합니다:

• Puma 또는 Sidekiq를 수직으로 확장할 경우, 추가 사양을 사용하려면 작업자 수를 조정해야 합니다. Puma는 다음 구성 변경 시 자동으로 확장되지만 Sidekiq는 구성을 사전에 변경해야 합니다.
• Redis와 PgBouncer는 주로 단일 스레드입니다. 이러한 구성 요소에서 CPU 소진이 발생하는 경우 수평으로 확장이 필요할 수 있습니다.
• HA 형태로 배포할 때 투표 쿼럼을 위한 홀수 개의 노드가 필요한 구성 요소는 다음과 같습니다: Consul, Redis Sentinel, Praefect.
• 특정 구성 요소를 대폭 확장할 경우, 환경 성능에 부정적인 여파를 줄 수 있습니다. 아래의 전용 섹션을 참조하여 추가 안내를 받으세요.

반대로, 환경이 과도하게 구성된 것을 보여주는 강력한 메트릭스가 있는 경우, 유사하게 하향 조정할 수 있습니다.

그러나 하향 조정 시에는 문제가 발생하지 않도록 반복적인 접근 방식을 취해야 합니다.

하향 조정의 여파

경우에 따라 구성 요소를 대폭 확장하면 후속 구성 요소에 대한 여파가 발생하여 성능에 영향을 줄 수 있습니다. 참조 아키텍처는 상호 의존하는 구성 요소들이 사양 측면에서 일치하도록 균형을 고려하여 설계되었습니다. 따라서, 구성 요소를 현저히 확장할 경우 그 증가가 다른 종속 구성 요소로 전달되어 이들 또한 확장이 필요할 수 있습니다.

참조: 참조 아키텍처는 상위 구성 요소가 확장될 수 있도록 탄력성을 갖추도록 설계되었습니다. 그러나 환경에 심각한 변화를 주기 전에 지원 팀에 문의하는 것이 일반적으로 권장됩니다.

다음 구성 요소들은 대폭 확장되었을 때 다른 구성 요소에 영향을 줄 수 있습니다:

• Puma 및 Sidekiq - Puma 또는 Sidekiq 작업자를 현저하게 확장하면 내부 로드 밸런서, PostgreSQL(존재하는 경우 PgBouncer 경유), Gitaly(존재하는 경우 Praefect 경유) 및 Redis에 대한 더 많은 동시 연결이 발생합니다.

  • Redis는 주로 단일 스레드입니다. 경우에 따라 증가한 처리량으로 인해 결합된 클러스터에서 CPU가 소진되면 Redis를 별도의 인스턴스(예: 캐시 및 영구 저장소)로 분할해야 할 수도 있습니다.

  • PgBouncer 역시 단일 스레드지만 확장이 이루어질 경우 새로운 풀 추가가 발생하여 PostgreSQL에 대한 총 연결 수가 증가할 수 있습니다. PostgreSQL 연결 관리 경험이 없다면, 반드시 주의하고 도움을 요청하는 것이 강력히 권장됩니다.

• Gitaly 클러스터 / PostgreSQL - 추가 노드를 현저하게 확장할 경우, 기본 노드에 대한 복제 호출이 증가하여 HA 시스템과 성능에 부정적인 영향을 줄 수 있습니다.

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

대부분의 경우 수직 확장은 환경의 리소스를 증가시키기 위해 필요하지만, HA 환경으로 전환하는 경우 다음 구성 요소들이 각각의 HA 형태로 전환될 수 있도록 추가 조치가 필요합니다. 각 구성 요소에 대한 문서를 따르세요.

• Redis에서 다중 노드 Redis 및 Redis Sentinel로 전환
• Postgres에서 다중 노드 Postgres 및 Consul + PgBouncer로 이동
• Gitaly에서 Gitaly 클러스터 및 Praefect로 전환

업그레이드

참조 아키텍처 환경의 업그레이드는 다른 GitLab 환경과 동일합니다.

주요 GitLab 업그레이드 섹션에서 이에 대한 자세한 접근 방법을 안내합니다.

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

참고: 참조 아키텍처를 생성한 순서대로 업그레이드해야 합니다.

모니터링

인프라스트럭처 및 GitLab 자체를 모니터링할 수 있는 여러 가지 옵션이 있으며, 선택한 모니터링 솔루션의 문서를 참조하여 추가 정보를 얻어야 합니다.

특히 GitLab 애플리케이션은 Prometheus 및 다양한 Prometheus 호환 엑스포터와 번들로 제공되며, 솔루션에 통합할 수 있습니다.

업데이트 이력

아래는 참조 아키텍처에 대한 주목할 만한 업데이트 이력입니다(2021-01-01 이후, 오름차순). 매 분기 최소 한 번 업데이트를 유지할 계획입니다.

변경 사항의 전체 이력을 GitLab 프로젝트에서 확인할 수 있습니다.

2024:

• 2024-08: RPS 계산 방법에 대한 더 많은 예제가 포함된 예상 로드 섹션 업데이트.
• 2024-08: 40 RPS / 2k 사용자 페이지의 Redis 구성을 올바른 Redis 구성으로 업데이트.
• 2024-08: 2k 모니터링 노드에서 Prometheus에 대한 Sidekiq 구성 업데이트.
• 2024-08: 추가 기능 발견을 돕기 위해 페이지에 다음 단계 탐색 섹션 추가.
• 2024-05: 최신 Redis 안내를 반영하여 60 RPS / 3k 사용자 및 100 RPS / 5k 사용자 페이지 업데이트.
• 2024-05: Cost to run 섹션의 이름을 Cost calculator templates로 변경하여 계산기가 시작점에 불과하며 특정 사용에 맞게 조정해야 한다는 것을 더 잘 반영하도록 업데이트.
• 2024-04: GCP에서 Cloud Native Hybrids를 위한 웹 서비스 노드에 대한 권장 크기 업데이트. 또한 웹 서비스 노드 풀에서 DaemonSet으로 실행할 NGINX 포드 권장 사항 조정.
• 2024-04: 20 RPS / 1,000 사용자 아키텍처 사양을 16 GB의 권장 메모리 목표를 따르도록 업데이트.
• 2024-04: 참조 아키텍처 제목을 RPS를 포함하도록 업데이트하여 추가 명확성을 제공하고 적정 크기를 지원.
• 2024-02: VM에 배포될 경우 로드 밸런서 노드의 권장 크기 업데이트. 또한 네트워크 대역폭 고려 사항에 대한 주석 추가.
• 2024-02: 이제 더 이상 설정할 필요가 없는 Max Concurrency 설정을 예제에서 제거.
• 2024-02: Rails 노드에서 Sidekiq을 비활성화하도록 2k에 대한 Sidekiq 권장 사항 조정 및 아키텍처 다이어그램 업데이트.
• 2024-01: 모든 참조 아키텍처 크기에 대한 Azure에 대한 권장 사항 및 최신 클라우드 서비스 업데이트.

2023:

• 2023-12-12: 로드 밸런서에 관한 주석을 업데이트하여 평판이 좋은 제공업체가 작동할 것으로 예상된다는 점을 더 잘 반영하도록 함.
• 2023-11-03: 각 참조 아키텍처의 설계 목적, 사용된 테스트 방법론에 대한 세부 정보 확장 및 환경 확장 방법에 관한 세부 추가.
• 2023-11-03: 디스크 유형, 개체 저장소 및 모니터링에 대한 추가 주석 추가.
• 2023-10-25: Sidekiq 구성 예를 Linux 패키지 역할로 조정.
• 2023-10-15: 2k에 대한 Sidekiq 권장 사항을 조정하여 별도의 노드를 포함하고 3k 및 5k에 대한 인스턴스 유형 및 수량 조정.
• 2023-10-08: 대용량 모노레포의 사용과 그 영향을 경고하기 위해 여러 부분에 걸쳐 더 많은 주석 추가.
• 2023-10-04: Task Runner 포드의 이름을 새로운 이름인 Toolbox로 업데이트.
• 2023-10-02: 10k 이상의 별도 캐시 및 지속적인 서비스에 대한 Redis 외부 서비스 사용에 대한 지침을 확장.
• 2023-09-21: Kubernetes에서 Gitaly 실행의 문제점에 대한 세부사항 확장.
• 2023-09-20: 폐기 및 제거 이후에 Grafana에 대한 언급 삭제.
• 2023-08-30: 결정 나무 아래에서 Geo에 대한 섹션 확장.
• 2023-08-08: Linux 패키지에서 Sidekiq 역할을 사용하기 위한 구성 예시로 전환.
• 2023-08-03: 50k 아키텍처에 대한 AWS 머신 타입의 오타 수정.
• 2023-06-30: PostgreSQL 구성 예를 업데이트하여 이제 필요하지 않은 설정을 제거하고 Linux 패키지 기본값을 사용하도록 변경.
• 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 서비스에 사용할 수 없는 Azure Active Directory 인증 방법에 대한 주석 추가.
• 2023-03-23: 알려진 지원되지 않는 디자인에 대한 추가 세부정보 추가.
• 2023-03-16: 모든 구성 요소가 연결할 수 있도록 다중 노드에 대한 Redis 구성 예를 업데이트.
• 2023-03-15: Gitaly 구성 예를 새로운 형식으로 업데이트.
• 2023-03-14: 비용 추정치를 더 이상 NFS VM를 포함하지 않도록 업데이트.
• 2023-02-17: Praefect 구성 예를 새로운 형식으로 업데이트.
• 2023-02-14: 추가 작업으로 고려될 수 있는 자동화의 예 추가.
• 2023-02-13: 자가 관리 소프트웨어를 실행하는 데 필요한 사항을 더 잘 설명하는 ‘시작하기 전에’ 섹션 추가. 또한 결정 나무 섹션에서 독립형 설정 및 클라우드 공급자 서비스에 대한 추가 세부정보 추가.
• 2023-02-01: 덜 알려진 “involved” 대신에 더 일반적인 “complex” 용어 사용으로 전환.
• 2023-01-31: 메인 페이지의 요구 사항 섹션 확장 및 중앙 집중화.
• 2023-01-26: NFS에서 Git 데이터를 마이그레이션할 때의 주의 사항 및 다수의 Rails 노드에서 SSH 키를 올바르게 처리하는 방법에 대한 주석 추가.

2022:

• 2022-12-14: Git 데이터에 NFS를 사용하는 것에 대한 안내 제거, 지원이 15.6 이후로 종료됨.
• 2022-12-12: Amazon RDS Multi-AZ DB _cluster_와 _instance_의 차이를 명확히 하기 위한 주석 추가, 후자는 지원됨. 또한 PostgreSQL 최대 연결 수 설정을 새로운 기본값인 500으로 증가.
• 2022-12-12: Sidekiq 최대 동시 처리 구성 업데이트하여 새로운 기본값인 20에 맞춤.
• 2022-11-16: 저희 3k 아키텍처 섹션의 Praefect 및 Gitaly에 대한 조언 수정하여 홀수 수의 쿼럼이 필요하다는 것을 명확히함.
• 2022-11-15: Cloud Native Hybrids에서 GitLab 비밀을 처리하는 방법 및 GitLab Charts 문서에 대한 추가 링크에 대한 안내 추가.
• 2022-11-14: 10k 아키텍처의 Sidekiq 구성에서 오타 수정.
• 2022-11-09: 대규모 모노레포 및 추가 작업이 성능에 미치는 영향을 다루는 안내 추가. 또한 SSL 및 최소 연결 기반 라우팅 방법에 대한 로드 밸런서 관련 안내를 확장.
• 2022-10-18: NFS보다 권장된다는 것을 명확하게 하도록 객체 저장소 안내 조정.
• 2022-10-11: 성능 문제로 인해 Azure에 대한 권장 사항을 최대 2k로 수정.
• 2022-09-27: 사용자가 어떤 아키텍처를 사용해야 할지를 결정하는 데 도움이 되는 결정 트리 섹션 추가.
• 2022-09-22: 객체 저장소가 사용될 때만 증분 로깅을 활성화하기 위한 명시적 단계 추가.
• 2022-09-22: 추천 클라우드 공급자 및 서비스에 대한 안내를 확장.
• 2022-09-09: 객체 저장소 안내를 확장하고 Git 데이터에 대한 NFS 지원이 15.6에서 종료됨을 업데이트.
• 2022-08-24: Gitaly 클러스터가 Kubernetes에서 지원되지 않음을 명확히 보여주는 주석 추가.
• 2022-08-24: 지원되는 CPU 및 유형에 대한 섹션 추가.
• 2022-08-18: 객체 저장소 지원을 더 명확하게 하기 위해 아키텍처 테이블 업데이트.
• 2022-08-17: 2k 아키텍처를 위해 클라우드 네이티브 하이브리드 풀 사양을 늘려서 포드에 충분한 리소스가 있도록 함. 또한 Sidekiq 워커 수를 늘림.
• 2022-08-02: GitLab 15 및 이후 버전의 Gitaly 체크 명령의 사용을 권장하도록 주석 추가.
• 2022-07-25: 문제 해결 섹션을 더 일반적인 위치로 이동.
• 2022-07-14: GitLab 14.4.0 이후 버전에서 Amazon Aurora가 더 이상 호환되지 않으며 지원되지 않는다는 안내 추가.
• 2022-07-07: Gitaly 저장소 구성에서 default 섹션을 제거하지 말라는 댓글 추가, 이는 필요합니다.
• 2022-06-08: 증분 로깅 관련 안내를 별도 섹션으로 이동.
• 2022-04-29: 테스트 결과 섹션에 대한 새로운 정기 파이프라인과 함께 확장.
• 2022-04-26: Praefect 구성을 설정 이름 변경을 반영하도록 업데이트.
• 2022-04-15: 객체 저장소를 올바르게 활성화하기 위한 누락된 설정 추가.
• 2022-04-14: AWS 머신 유형에 대한 클라우드 네이티브 하이브리드 안내를 확장.
• 2022-04-08: AWS 및 Azure에 대한 비용 추정치를 추가.
• 2022-04-06: 대부분의 구성 요소에 대한 구성 예를 업데이트하여 Prometheus 모니터링 자동 발견을 올바르게 포함시킴.
• 2022-03-30: 검증 및 테스트 결과 섹션의 언어를 더 명확하고 구체적으로 확장.
• 2022-03-21: 특정 시나리오에서 Gitaly 추가 사양이 필요할 수 있다는 주의 사항 추가.
• 2022-03-04: 필요하지 않은 노드에서 GitLab KAS 서비스가 실행되는 것을 방지하기 위한 안내 추가.
• 2022-03-01: 구성 예제에서 Praefect TLS 포트에 대한 오타 수정.
• 2022-02-22: Gitaly Pack-objects 캐시를 활성화하는 데 대한 안내 추가.
• 2022-02-22: 추천 클라우드 공급자 및 서비스에 대한 일반 섹션 추가.
• 2022-02-14: GPT 테스트에 대한 블로그 포스트 링크 추가.
• 2022-01-26: 테스트 프로세스 및 비용 추정치를 한 섹션으로 병합하여 세부정보를 확장.
• 2022-01-13: 추천 Kubernetes 플랫폼에 대한 안내 확장.

2021:

• 2021-12-31: 25k Redis AWS 머신 크기에 대한 오타 수정.
• 2021-12-28: 테스트 프로세스 및 결과 섹션에 클라우드 공급자 분해 추가.
• 2021-12-17: 테스트 프로세스 및 결과 섹션에 세부사항 추가.
• 2021-12-17: 수정된 3k 아키텍처를 사용할 때 데이터베이스 로드 밸런싱 요구사항에 대한 주의 사항 추가.
• 2021-12-17: 1k 아키텍처(단일 노드)에 대한 다이어그램 추가.
• 2021-12-15: 예상 비용(GCP), 테스트 프로세스 및 결과 및 추가 클라우드 공급자 서비스 세부정보에 대한 섹션 추가.
• 2021-12-14: 구성 요소에 대한 외부 데이터베이스 서비스 안내를 확장하고 추천하는 클라우드 공급자 서비스를 다루도록 업데이트.
• 2021-11-24: 데이터베이스 로드 밸런싱에 대한 권장 사항 추가.
• 2021-11-04: 아키텍처에 사용되는 테스트 대상에 대한 세부 사항을 추가.
• 2021-10-13: Incremental Logging을 Redis를 통해 선택적으로 활성화하는 방법에 대한 안내 추가.
• 2021-10-07: Sidekiq 구성을 업데이트하여 필수 external_url 설정을 포함하도록 함.
• 2021-10-02: Gitaly Cluster 및 Gitaly Sharded에 대한 안내 확장.
• 2021-09-29: 소규모 사용자 수와 함께 사용할 클라우드 네이티브 하이브리드 아키텍처에 대한 주의사항 추가.
• 2021-09-27: Redis Sentinel을 Redis와 같은 노드에 공동 배치하도록 지침 변경.
• 2021-08-18: 2k Cloud Native Hybrid 아키텍처 추가.
• 2021-08-04: 각 아키텍처의 성능 테스트 결과 링크 추가.
• 2021-07-30: PostgreSQL 구성 예의 복제 설정을 올바른 값으로 수정.
• 2021-07-22: 3k Cloud Native Hybrid 아키텍처 추가.
• 2021-07-16: 아키텍처 다이어그램을 업데이트하여 Rails와 Sidekiq 간의 직접 연결이 없음을 올바르게 반영.
• 2021-07-15: Patroni 구성을 업데이트하여 Rest API 인증 설정 포함.
• 2021-07-15: 5k Cloud Native Hybrid 아키텍처 추가.
• 2021-07-08: 25k Cloud Native Hybrid 아키텍처 추가.
• 2021-06-29: 50k Cloud Native Hybrid 아키텍처 추가.
• 2021-06-23: 클라우드 네이티브 하이브리드에 대한 주요 페이지의 추가 사항과 3k 아키텍처를 축소.
• 2021-06-16: PostgreSQL 단계를 업데이트하고 최신 역할을 사용하여 Geo 복제 준비.
• 2021-06-14: 모니터링 노드에 대한 구성 예를 최신 정보에 맞게 업데이트.
• 2021-06-11: 외부 서비스에 대한 주석을 더 상세하게 확장.
• 2021-06-09: GitLab 비밀 및 데이터베이스 마이그레이션을 올바르게 관리하는 방법에 대한 추가 안내 및 확장.
• 2021-06-09: 새로운 스토리지 형식을 따르도록 Praefect 구성 예를 업데이트.
• 2021-06-03: 이제 Puma로 교체된 Unicorn 웹 서버에 대한 언급 제거.
• 2021-04-23: 각 노드에서 여러 작업자를 올바르게 구성하는 방법을 보여 주기 위해 Sidekiq 구성 예를 업데이트.
• 2021-04-23: 사용자 수가 적은 3k 참조 아키텍처를 수정하는 방법에 대한 초기 안내 추가.
• 2021-04-13: 외부 서비스(PostgreSQL, Redis) 사용에 대한 추가 설명.
• 2021-04-12: 로드 밸런서 및 라우팅 방법 사용에 대한 추가 안내.
• 2021-04-08: Praefect의 데이터베이스 마이그레이션을 수행하기 위해 하나의 노드만 올바르게 구성하는 방법에 대한 추가 안내.
• 2021-04-06: 10k Cloud Native Hybrid 문서를 더 자세히 확장하고 명확한 명명법을 적용.
• 2021-03-04: Gitaly 클러스터 문서를 모든 적용 가능한 참조 아키텍처 크기로 확장.
• 2021-02-19: 권장 사항에 따라 데이터 유형별로 구분된 버킷을 사용하는 것에 대한 추가 객체 저장소 지침 추가.
• 2021-02-12: Rails 및 Sidekiq와 함께 객체 저장소 설정에 대한 문서 추가.
• 2021-02-12: 10k 참조 아키텍처를 위한 Gitaly 클러스터 설정 문서 추가.
• 2021-02-09: 10k 클라우드 네이티브 하이브리드 참조 아키텍처의 첫 번째 버전 추가.
• 2021-01-07: PostgreSQL 복제 관리자로서 Patroni 사용에 대한 문서 추가.