설치 전에, 또는 기존 환경의 규모가 올바르게 산정되었는지 평가할 때 GitLab 환경의 워크로드를 평가하고 적절한 배포 요구 사항을 결정하세요.

워크로드 특성화#

GitLab 환경은 사용자 수나 요청량이 비슷하더라도 인프라 요구 사항이 크게 다릅니다. Git 작업, CI/CD 활동, API 사용량, 자동화의 조합이 어떤 구성 요소에 부하가 걸리고 어떻게 스케일링해야 하는지를 결정합니다.

워크로드 특성화는 환경을 고정된 규모 등급에 매핑하는 대신 환경의 프로파일을 설명합니다. 환경을 측정한 후 도출한 특성화는 어떤 구성 요소 수준의 요구 사항과 스케일링 고려 사항이 적용되는지 안내합니다.

이러한 특성화는 서술적인 것이지 규범적인 것이 아닙니다. 미리 선택하는 범주가 아니라 환경을 측정하여 도출하는 결론입니다. 많은 환경은 하나의 특성화에 깔끔하게 들어맞지 않습니다. 웹과 API 활동은 가볍지만 Git 작업이 많은 환경은 그 반대 프로파일을 가진 환경과 다른 위치에 놓입니다.

Small 및 Medium 환경에서는 이 페이지의 안내만으로 충분하도록 설계되었습니다. Large 및 Extra Large 환경에서는 운영 복잡성 때문에 Professional Services와의 협업이 필요한 경우가 많으며, 운영 부담을 완전히 없애는 대안으로 GitLab Dedicated나 GitLab.com을 고려할 수 있습니다.

워크로드 고려 사항#

일부 워크로드 패턴은 이 가이드가 다루는 표준 RPS 기반 방법론 이상을 필요로 합니다. 그중 두 가지는 RPS 메트릭을 추출한 뒤에 다룹니다. 대규모 모노레포 및 기타 인프라 특유의 요인과, 과도한 자동화, CI/CD 사용, 보안 스캔 같은 비전형적인 워크로드 패턴입니다.

GitLab Duo Agent Platform은 표준 워크로드 사이징을 넘어서는 고유한 인프라 고려 사항을 도입합니다. 이를 사용할 환경의 규모를 산정하기 전에 GitLab Duo Agent Platform 스케일링을 참조하세요.

오토스케일링#

Rails(Puma)와 Sidekiq은 무상태이며 오토스케일링 그룹을 지원합니다. 이러한 구성 요소는 평균 지속 부하에 맞춰 규모를 산정하고 피크는 오토스케일링이 처리하도록 하세요.

Gitaly는 상태를 가지며 오토스케일링을 지원하지 않습니다. Gitaly 노드는 아래 안내에 따라 피크 부하에 맞춰 규모를 산정하세요.

오토스케일링이 요구 사항이라면 일반적으로 VM 기반 오토스케일링 그룹보다 클라우드 네이티브 배포가 선호됩니다. 데이터베이스 마이그레이션이나 Mailroom처럼 단일 노드에서 실행해야 하는 구성 요소는 VM 오토스케일링 그룹보다 쿠버네티스가 더 안정적으로 처리하므로, VM 기반 오토스케일링을 선택하기 전에 이 제약을 고려하세요.

시작하기 전에#

이 지침은 Prometheus 메트릭을 사용하여 환경을 정확하게 평가합니다. 환경이 단순하다면 이 수준의 분석 없이도 레퍼런스 아키텍처만으로 충분한 안내를 얻을 수 있습니다.

전문가의 안내가 필요하신가요? 아키텍처 규모를 올바르게 산정하는 것은 최적의 성능을 위해 매우 중요합니다. GitLab Professional Services 팀은 특정 아키텍처를 평가하고 성능, 안정성, 가용성 최적화를 위한 맞춤형 권장 사항을 제공할 수 있습니다.

이 문서를 따르려면 GitLab 인스턴스와 함께 Prometheus 모니터링이 배포되어 있어야 합니다. Prometheus는 적절한 규모 산정 평가에 필요한 정확한 메트릭을 제공합니다.

아직 Prometheus를 구성하지 않았다면:

• Prometheus로 모니터링을 구성합니다. 레퍼런스 아키텍처 문서는 각 환경 규모별 Prometheus 구성에 대한 세부 정보를 제공합니다. 클라우드 네이티브 GitLab에서는 kube-prometheus-stack Helm 차트를 사용하여 메트릭 스크래핑을 구성할 수 있습니다.

• 의미 있는 데이터 패턴을 모으려면 7~14일 동안 데이터를 수집합니다.

• 이 문서의 나머지 내용을 읽습니다.

Prometheus 모니터링을 구성할 수 없다면:

• 규모를 추정하려면 현재 환경의 사양을 가장 가까운 레퍼런스 아키텍처와 비교합니다.

• GitLab RPS Analyzer를 사용하여 GitLabSOS 또는 KubeSOS 로그로 레퍼런스 아키텍처 규모를 평가합니다. 다만 이 방법은 메트릭보다 신뢰도가 낮습니다.

다른 플랫폼에서 마이그레이션하는 경우, 기존 GitLab 메트릭이 없으면 다음 PromQL 쿼리를 적용할 수 없습니다. 그러나 일반적인 평가 방법론은 여전히 유효합니다:

• 예상 워크로드를 기반으로 가장 가까운 레퍼런스 아키텍처를 추정합니다.

• 예상되는 추가 워크로드를 식별합니다.

• 대규모 리포지터리의 수를 평가합니다

• 성장 예측을 반영합니다.

• 적절한 버퍼를 갖춘 레퍼런스 아키텍처를 선택합니다.

PromQL 쿼리 실행#

PromQL 쿼리를 실행하는 방법은 사용하는 모니터링 솔루션에 따라 다릅니다. Prometheus 모니터링 문서에 설명된 대로, 모니터링 데이터는 Prometheus에 직접 연결하거나 Grafana 같은 대시보드 도구를 사용하여 액세스할 수 있습니다.

기준 규모 결정#

초당 요청 수(RPS)는 GitLab 인프라 규모 산정의 주요 메트릭입니다. 트래픽 유형(API, 웹, Git 작업)마다 부하를 주는 구성 요소가 다르므로, 실제 용량 요구 사항을 파악하기 위해 각각을 별도로 분석합니다.

피크 트래픽 메트릭 추출#

최대 부하를 파악하려면 다음 쿼리를 실행하세요. 이 쿼리는 다음을 보여줍니다:

• 절대 피크는 관측된 가장 높은 스파이크입니다. 절대 피크는 최악의 시나리오를 보여줍니다.

• 지속 피크는 95번째 백분위수로, 일반적인 "바쁜" 수준으로 간주됩니다. 지속 피크는 전형적인 고부하 기간을 드러냅니다.

절대 피크가 드문 이상값이라면 지속 부하에 맞춰 규모를 산정하는 것이 적절할 수 있습니다.

보존 기간에 따라 쿼리의 시간 범위를 조정하세요(더 긴 이력이 있으면 [7d]를 [30d]로 변경).

활동량이 많은 환경에서는 max_over_time 또는 quantile_over_time 쿼리가 타임아웃될 수 있습니다. 이런 경우 바깥쪽 집계 함수를 제거하고 안쪽 쿼리를 그래프로 시각화하세요. 예를 들어 API 트래픽 피크의 경우 다음을 사용합니다:

sum(rate(gitlab_transaction_duration_seconds_count{controller=~"Grape", action!~".*/internal/.*"}[1m]))

그런 다음 모니터링 기간 동안 그래프로 표시된 결과에서 피크 값을 시각적으로 식별합니다.

절대 피크 쿼리#

지정한 기간 동안 관측된 최대 RPS를 식별하려면:

1. 다음 쿼리를 실행합니다:

   • API 트래픽 피크. 자동화, 외부 도구, 웹훅에서 발생하는 최대 API 요청을 측정합니다:

     max_over_time(
       sum(rate(gitlab_transaction_duration_seconds_count{controller=~"Grape", action!~".*/internal/.*", action!="POST /api/jobs/request"}[1m]))[7d:1m]
     )
     

   • 웹 트래픽 피크. 브라우저에서 발생하는 사용자의 최대 UI 상호작용을 측정합니다:

     max_over_time(
       sum(rate(gitlab_transaction_duration_seconds_count{controller!~"Grape|HealthController|MetricsController|Repositories::GitHttpController|GraphqlController"}[1m]))[7d:1m]
     )
     

   • Git 풀 및 클론 피크. 최대 리포지터리 클론 및 페치 작업을 측정합니다:

     max_over_time(
       (sum(rate(gitlab_transaction_duration_seconds_count{action="git_upload_pack"}[1m])) or vector(0) +
       sum(rate(gitaly_service_client_requests_total{grpc_method="SSHUploadPack"}[1m])) or vector(0))[7d:1m]
     )
     

   • Git 푸시 피크. 최대 코드 푸시 작업을 측정합니다:

     max_over_time(
       (sum(rate(gitlab_transaction_duration_seconds_count{action="git_receive_pack"}[1m])) or vector(0) +
       sum(rate(gitaly_service_client_requests_total{grpc_method="SSHReceivePack"}[1m])) or vector(0))[7d:1m]
     )
     

2. 결과를 기록합니다.

지속 피크 쿼리#

드문 스파이크를 걸러내고 전형적인 고부하 수준을 식별하려면:

1. 다음 쿼리를 실행합니다:

   • API 지속 피크:

     quantile_over_time(0.95,
       sum(rate(gitlab_transaction_duration_seconds_count{controller=~"Grape", action!~".*/internal/.*", action!="POST /api/jobs/request"}[1m]))[7d:1m]
     )
     

   • 웹 지속 피크:

     quantile_over_time(0.95,
       sum(rate(gitlab_transaction_duration_seconds_count{controller!~"Grape|HealthController|MetricsController|Repositories::GitHttpController|GraphqlController"}[1m]))[7d:1m]
     )
     

   • Git 풀 및 클론 지속 피크:

     quantile_over_time(0.95,
       (sum(rate(gitlab_transaction_duration_seconds_count{action="git_upload_pack"}[1m])) or vector(0) +
       sum(rate(gitaly_service_client_requests_total{grpc_method="SSHUploadPack"}[1m])) or vector(0))[7d:1m]
     )
     

   • Git 푸시 지속 피크:

     quantile_over_time(0.95,
      (sum(rate(gitlab_transaction_duration_seconds_count{action="git_receive_pack"}[1m])) or vector(0) +
      sum(rate(gitaly_service_client_requests_total{grpc_method="SSHReceivePack"}[1m])) or vector(0))[7d:1m]
     )
     

2. 결과를 기록합니다.

트래픽을 레퍼런스 아키텍처에 매핑#

트래픽을 레퍼런스 아키텍처에 매핑하는 방법은 배포 경로에 따라 다릅니다.

Linux 패키지(Omnibus) 또는 Cloud Native Hybrid:

1. 각 트래픽 유형이 어떤 레퍼런스 아키텍처를 시사하는지 확인하려면 사용 가능한 레퍼런스 아키텍처를 참조합니다.

2. 분석 표를 작성합니다. 다음 표를 가이드로 사용하세요:

   트래픽 유형	피크 RPS	피크 시사 RA	지속 RPS	지속 시사 RA
   API	________	_____ (최대 ___ RPS)	_____________	_____ (최대 ____ RPS)
   웹	________	_____ (최대 ___ RPS)	_____________	_____ (최대 ____ RPS)
   Git 풀 및 클론	________	_____ (최대 ___ RPS)	_____________	_____ (최대 ____ RPS)
   Git 푸시	________	_____ (최대 ___ RPS)	_____________	_____ (최대 ____ RPS)

3. 피크 시사 RA 열의 모든 레퍼런스 아키텍처를 비교하여 가장 큰 규모를 선택합니다. 지속 시사 RA 열에 대해서도 반복합니다.

4. 기준을 문서화합니다:

   • 시사된 가장 큰 피크 RA.
   • 시사된 가장 큰 지속 RA.

Cloud Native:

Cloud Native 아키텍처는 트래픽 유형별 목표가 아니라 전체 RPS 대역 하나로 규모를 산정합니다. API 트래픽이 일반적으로 부하의 대부분을 차지하기 때문입니다(요청 유형별 RPS 분포 참조).

1. 피크 및 지속 전체 RPS를 사용 가능한 규모와 비교합니다:

   특성화	Cloud Native 규모	목표 RPS
   Small	Small (S)	≤100 RPS
   Medium	Medium (M)	≤200 RPS
   Large	Large (L)	≤500 RPS
   Extra Large	Extra Large (XL)	≤1000 RPS

2. 기준을 문서화합니다:

   • 시사된 피크 규모.
   • 시사된 지속 규모.

레퍼런스 아키텍처 선택#

이 시점에서 후보 규모는 두 가지입니다. 하나는 절대 피크를 기반으로 한 것이고, 다른 하나는 지속 부하를 기반으로 한 것입니다.

규모를 선택할 때:

• 피크와 지속이 같은 규모를 시사하면 그 규모를 사용합니다.

• 피크가 지속보다 큰 규모를 시사하면 그 격차를 계산합니다. 피크 RPS가 지속 규모 상한의 10~15% 이내인가요?

일반 지침:

• 피크 RPS가 지속 규모의 한계를 10~15% 미만으로 초과한다면, 레퍼런스 아키텍처에는 여유 용량이 내장되어 있으므로 허용 가능한 위험 수준에서 지속 규모를 고려할 수 있습니다.

• 15%를 초과하면 피크 기반 규모로 시작한 다음, 모니터링하면서 메트릭이 규모 축소를 뒷받침하면 조정합니다.

Linux 패키지 / Cloud Native Hybrid 예시:

• 5,000 사용자 아키텍처(최대 100 RPS) 대비 피크가 110 RPS → 10% 초과 → 5,000 사용자 아키텍처로 충분합니다.

• 5,000 사용자 아키텍처(최대 100 RPS) 대비 피크가 150 RPS → 50% 초과 → 10,000 사용자 아키텍처(최대 200 RPS)를 사용합니다.

• 피크는 100 RPS(5,000 사용자 아키텍처)이지만 지속은 50 RPS(3,000 사용자 아키텍처, 최대 60 RPS)입니다. 원시 RPS 그래프를 보면 대부분의 시간 동안 부하가 50 RPS 미만인 상태에서 자동화 스파이크가 피크를 유발합니다. 5,000 사용자 아키텍처로 보수적으로 시작한 다음 규모를 축소할지, 아니면 워크로드별 스케일링을 적용한 3,000 사용자 아키텍처로 시작할지(위험이 더 큼) 평가하세요.

Cloud Native 예시:

• 피크는 120 RPS(medium)이지만 지속은 80 RPS(small)입니다. medium으로 보수적으로 시작한 다음 규모를 축소할지, 아니면 워크로드별 스케일링을 적용한 small로 시작할지(위험이 더 큼) 평가하세요.

40 RPS 미만이면서 고가용성(HA)이 요구 사항인 환경에서는 고가용성 섹션을 참조하여 지원되는 축소를 적용한 60 RPS / 3,000 사용자 아키텍처로 전환해야 하는지 확인하세요.

다음으로 진행하기 전에#

이 섹션을 완료하면 기준 레퍼런스 아키텍처 규모가 정해집니다. 이것이 토대가 되지만, 이어지는 섹션에서는 특정 워크로드가 표준 구성을 넘어서는 구성 요소 조정을 필요로 하는지 확인합니다.

진행하기 전에 이 섹션에서 수집한 세부 정보를 문서화했는지 확인하세요. 다음을 가이드로 사용할 수 있습니다:

Reference architecture assessment summary:

- Selected reference architecture: _____
- Justification based on _____ RPS [absolute/sustained]

| Traffic Type       | Peak RPS | Sustained RPS (95th) |
|:-------------------|:---------|:---------------------|
| API                | ________ | ____________________ |
| Web                | ________ | ____________________ |
| Git pull and clone | ________ | ____________________ |
| Git push           | ________ | ____________________ |

Highest RPS Peak timestamp for workload analysis: _____

RPS 구성 및 워크로드 패턴 이해#

전체 RPS는 주요 사이징 메트릭이지만, 워크로드 구성은 구성 요소의 리소스 요구 사항에 큰 영향을 미칩니다. 요청 유형마다 서로 다른 구성 요소에 서로 다른 강도로 부하를 줍니다.

요청 유형별 RPS 분포#

레퍼런스 아키텍처의 RPS 목표는 프로덕션 데이터를 기반으로 한 일반적인 워크로드 구성을 가정합니다:

• API 요청(전체 RPS의 약 80%) - 자동화, 통합, 웹훅, API 기반 도구

• 웹 요청(전체 RPS의 약 10%) - UI 상호작용, 페이지 탐색, 사용자 주도 작업

• Git 작업(전체 RPS의 약 10%) - 리포지터리 클론 및 풀, 그리고 그보다 낮은 푸시 비율

비전형적 구성 - 한 가지 요청 유형이 일반적인 비율을 크게 초과하는 환경(목표 RPS 범위 내에서도 구성 요소별 조정이 필요할 수 있음)

비전형적 워크로드 패턴 식별#

워크로드 구성을 파악하려면 피크 트래픽 메트릭 추출의 RPS 추출 쿼리를 사용하세요. 분포를 일반적인 패턴과 비교하세요:

API 집약적 워크로드(API가 전체 RPS의 90% 초과):

• 과도한 자동화, 광범위한 통합, 또는 API 기반 도구

• 주요 영향: Rails(Webservice), PostgreSQL, Gitaly

• 고려 사항: Webservice/Rails 용량 증대, 데이터베이스 읽기 복제본

웹 집약적 워크로드(웹이 전체 RPS의 20% 초과):

• 광범위한 UI 상호작용을 하는 대규모 활성 사용자 기반

• 주요 영향: Rails(Webservice), PostgreSQL

• 고려 사항: Webservice 용량 증대, 데이터베이스 최적화

Git 집약적 워크로드(Git이 전체 RPS의 15% 초과 또는 풀 비율이 해당 규모의 일반적인 수준을 뚜렷하게 상회):

• 잦은 풀을 수행하는 대규모 팀, 모노레포 패턴, 또는 리포지터리 클론을 동반한 CI/CD 집약적 워크플로

• 주요 영향: Gitaly, 네트워크 대역폭

• 고려 사항: Gitaly 수직 스케일링, 리포지터리 최적화, 네트워크 강화 VM

평가 방법#

• 제공된 PromQL 쿼리를 사용하여 RPS 분포를 추출합니다

• 각 요청 유형이 전체에서 차지하는 비율을 계산합니다

• 어떤 유형이 일반적인 비율을 크게 초과하는지 식별합니다

• 비전형적이라면 스케일링 안내는 구성 요소 조정 식별을 참조합니다

작은 변동(어떤 범주에서든 5~10 RPS 차이)은 아키텍처 변경을 필요로 하지 않습니다. RPS 비교만으로 결정을 내리기보다 프로덕션에서 실제 구성 요소 포화 메트릭(CPU, 메모리, 큐 길이)을 모니터링하세요. 지속 사용률이 70% 미만인 구성 요소는 사소한 RPS 변동과 무관하게 일반적으로 충분한 용량을 갖추고 있습니다.

구성 요소 조정 식별#

워크로드 평가는 기본 레퍼런스 아키텍처를 넘어서는 구성 요소 조정이 필요한 특정 사용 패턴을 식별합니다. RPS가 전체 규모를 결정한다면, 워크로드 패턴은 그 형태를 결정합니다. RPS가 동일한 두 환경이라도 리소스 요구 사항은 크게 다를 수 있습니다.

워크로드마다 GitLab 아키텍처의 서로 다른 부분에 부하를 줍니다:

• 보통 수준의 RPS를 유지하면서 수천 개의 작업을 처리하는 CI/CD 집약적 환경은 Sidekiq과 Gitaly에 부하를 줍니다.

• 광범위한 API 자동화를 사용하는 환경은 높은 RPS를 보이지만 부하가 데이터베이스와 Rails 계층에 집중됩니다.

피크 부하 시 상위 엔드포인트 분석#

앞 섹션의 피크 타임스탬프를 사용하여 최대 부하 동안 어떤 엔드포인트가 가장 많은 트래픽을 받았는지 식별합니다.

RPS 메트릭이 업무 외 시간에도 지속적으로 높은 트래픽(피크의 50% 초과)을 보인다면, 이는 일반적인 패턴을 넘어서는 과도한 자동화를 시사합니다. 예를 들어 업무 시간에는 피크 트래픽이 100 RPS에 도달하지만 야간과 주말에도 50 RPS 이상을 유지한다면 상당한 자동화 워크로드가 있음을 나타냅니다. 구성 요소 조정을 평가할 때 이를 고려하세요.

1. 시각화를 활성화한 상태로 다음 쿼리를 실행합니다(시간에 따른 분포는 막대 차트, 전반적인 분포는 원형 차트):

   topk(20,
     sum by (controller, action) (
       rate(gitlab_transaction_duration_seconds_count{controller!~"HealthController|MetricsController", action!~".*/internal/.*"}[1m])
     )
   )
   

2. 절대 RPS 피크 동안의 상위 엔드포인트 분포에 대해 결과를 검토합니다. 결과는 다음과 같을 수 있습니다:

   • 뚜렷한 엔드포인트 패턴이 없음. 이 경우 앞에서 선택한 레퍼런스 아키텍처를 그대로 사용합니다. 워크로드 변경의 영향을 측정할 수 있도록 견고한 모니터링을 갖추세요.

   • Git이 아닌 트래픽에 대한 과도한 API 사용이 대부분을 차지함. 이 경우 웹훅과 이슈, 그룹, 프로젝트 API 호출은 데이터베이스 집약적 패턴을 나타냅니다.

   • Git 또는 Sidekiq 관련 엔드포인트가 대부분을 차지함. 이 경우 머지 리퀘스트 diff, 파이프라인 작업, 브랜치, 커밋, 파일 작업, CI/CD 작업, 보안 스캔, 가져오기 작업은 Sidekiq/Gitaly 집약적 패턴을 나타냅니다.

3. 결과를 기록합니다:

   Workload pattern identified:
   
   - [ ] Database-intensive
   - [ ] Sidekiq- or Gitaly-intensive
   - [ ] None detected
   

구성 요소 조정 결정#

위의 지표는 추가 워크로드에 대한 초기 신호를 제공합니다. 레퍼런스 아키텍처에는 여유 용량이 내장되어 있으므로 이러한 워크로드는 조정 없이 처리될 수도 있습니다. 그러나 강한 지표가 존재하고 높은 수준의 자동화가 알려져 있다면 다음 조정을 고려하세요.

앞에서 식별한 워크로드 패턴에 따라 스케일링이 필요한 구성 요소가 달라집니다:

스케일링 안내#

리소스 조정은 워크로드 강도와 포화 메트릭에 따라 달라집니다:

• 현재 리소스의 1.25~1.5배로 시작합니다.

• 구현 후 모니터링 데이터를 기반으로 세부 조정합니다.

클라우드 네이티브 GitLab 배포를 계획 중이라면, 이 평가에서 식별한 워크로드 패턴은 쿠버네티스 구성에 추가적인 함의를 가집니다:

• 업무 외 시간 트래픽이 높은 경우. 한산한 기간에 0으로 축소되도록 허용하는 대신 최소 파드 수가 기준 부하에 충분한지 확인하세요. 예를 들어 업무 시간에 100 RPS이고 자동화로 인해 야간에도 50 RPS가 지속된다면, 최소 파드 수 구성이 업무 외 시간의 기준 부하에 맞아야 합니다.

• 급격한 트래픽 스파이크. 기본 HPA 설정은 충분히 빠르게 스케일링하지 못할 수 있습니다. 이러한 전환 구간에서 요청이 대기열에 쌓이지 않도록 초기 롤아웃 동안 파드 스케일링 동작을 모니터링하세요. 예를 들어 한산한 시간대에서 업무 시간대로 넘어가면서, 또는 특정 자동화 스파이크로 인해 50에서 200 RPS로 급증하는 경우입니다.

데이터베이스 스케일링#

데이터베이스 스케일링 전략은 워크로드 특성에 따라 달라지며 여러 접근 방식이 필요할 수 있습니다:

• 즉각적인 용량 제약을 해소하기 위한 수직 스케일링:

  • 복제본이 프라이머리 부하를 줄이지 못하므로 쓰기 집약적 워크로드에 필요합니다.
  • 읽기 및 쓰기 작업 모두에 즉각적인 용량 증가를 제공합니다.

• 읽기 복제본을 사용하는 데이터베이스 로드 밸런싱(권장):

  • 읽기 집약적 워크로드(읽기 85~95%)에 특히 유익합니다.
  • 읽기 트래픽을 여러 노드에 분산합니다.
  • 수직 스케일링과 함께 추가할 수 있습니다.
  • 쓰기 성능이 계속 병목이라면 수직 스케일링을 이어갑니다.

읽기/쓰기 분포를 식별하려면 다음 Prometheus 쿼리를 사용하세요:

# Percentage of READ operations
(
  (sum(rate(gitlab_transaction_db_count_total[5m])) - sum(rate(gitlab_transaction_db_write_count_total[5m]))) /
  sum(rate(gitlab_transaction_db_count_total[5m]))
) * 100

다음으로 진행하기 전에#

이 섹션을 완료하면 워크로드 패턴을 식별하고 필요한 구성 요소 조정을 결정하게 됩니다.

진행하기 전에 전체 워크로드 평가를 기록하세요:

Workload pattern identified:

- [ ] Database-intensive
- [ ] Sidekiq- or Gitaly-intensive
- [ ] None detected
- Component adjustments needed: _____

다음 섹션에서는 추가적인 인프라 고려 사항이 필요할 수 있는 특수한 데이터 특성을 평가합니다.

특수 인프라 요구 사항 평가#

리포지터리 특성과 네트워크 사용 패턴은 RPS 메트릭이 드러내는 범위를 넘어 GitLab 성능에 큰 영향을 미칠 수 있습니다.

대규모 모노레포, 방대한 바이너리 파일, 네트워크 집약적 작업은 표준 규모 산정이 고려하지 않는 인프라 조정을 필요로 합니다.

대규모 모노레포#

대규모 모노레포(수 기가바이트 이상)는 Git 작업의 수행 방식을 근본적으로 바꿉니다. 10GB 리포지터리를 한 번 클론하는 것이 일반적인 리포지터리를 수백 번 클론하는 것보다 더 많은 리소스를 소비합니다.

이러한 리포지터리는 Gitaly뿐만 아니라 워크로드에 따라 Rails, Sidekiq, 데이터베이스에도 영향을 미칩니다.

프로파일링 과정은 일반적인 크기를 크게 초과하는 리포지터리를 식별하는 데 중점을 둡니다:

• 중간 규모 모노레포: 2GB~10GB. 소폭의 조정이 필요합니다.

• 대규모 모노레포: 10GB 초과. 상당한 인프라 변경이 필요합니다.

리포지터리 크기를 확인하려면:

1. 프로젝트의 사용량 할당량으로 이동합니다.

2. Repository 스토리지 유형을 검토합니다.

3. 리포지터리 크기가 2GB를 초과하는 프로젝트와 10GB를 초과하는 프로젝트의 수를 계산합니다.

4. 결과를 기록합니다:

   Number of medium monorepos (2GB - 10GB): _____
   Number of large monorepos (>10GB): _____
   

모노레포를 위한 인프라 조정#

대규모 리포지터리는 수직 스케일링과 운영상의 조정이 모두 필요합니다. 이러한 리포지터리는 Git 작업과 CPU 사용량부터 메모리 소비와 네트워크 대역폭에 이르기까지 스택 전반의 성능에 영향을 미칩니다.

모노레포 환경을 위한 추가 최적화 전략은 바이너리 파일용 Git LFS와 shallow 클론을 포함하여 모노레포 성능 개선에 문서화되어 있습니다.

네트워크 집약적 워크로드#

네트워크 포화는 진단하기 어려운 고유한 문제를 일으킵니다. 특정 작업에 영향을 미치는 CPU나 메모리 병목과 달리, 네트워크 포화는 모든 GitLab 기능에서 무작위처럼 보이는 타임아웃을 유발할 수 있습니다.

일반적인 네트워크 부하 원인:

• 과도한 컨테이너 레지스트리 사용(대용량 이미지, 잦은 풀).

• LFS 작업(바이너리 파일, 미디어 에셋).

• 대용량 CI/CD 아티팩트(빌드 결과물, 테스트 결과).

• 모노레포 클론(특히 CI/CD 파이프라인에서).

네트워크 사용량 측정#

잠재적 병목을 식별하려면 피크 및 기준 네트워크 소비량을 계산하세요. 간헐적인 스파이크(버스트 용량으로 처리)와 지속적인 높은 트래픽(네트워크 강화 VM 필요)을 구분하려면 둘 다 평가하세요.

1. 다음 쿼리를 실행합니다:

   # Outbound traffic (Gbps) - top 10 nodes
   topk(10, sum by (instance) (rate(node_network_transmit_bytes_total{device!="lo"}[5m]) * 8 / 1000000000))
   
   # Inbound traffic (Gbps) - top 10 nodes
   topk(10, sum by (instance) (rate(node_network_receive_bytes_total{device!="lo"}[5m]) * 8 / 1000000000))
   

2. 모니터링 기간 동안 관측된 피크 스파이크와 일반적인 기준치를 모두 기록합니다:

   Peak outbound traffic: _____ Gbps (baseline: _____ Gbps)
   Peak inbound traffic: _____ Gbps (baseline: _____ Gbps)
   

네트워크 용량 요구 사항#

아래 임계값은 대략적인 지침일 뿐입니다. 실제 네트워크 대역폭 보장치는 클라우드 공급자와 VM 유형에 따라 크게 달라집니다. 사용 중인 특정 인스턴스 유형의 네트워크 사양(기준 및 버스트 한도)이 워크로드 패턴에 부합하는지 항상 확인하세요.

아웃바운드 및 인바운드 트래픽 측정값을 기준으로:

다음으로 진행하기 전에#

진행하기 전에 전체 데이터 프로파일링 평가를 기록하세요:

Data Profile Summary:
- Medium monorepos (2GB-10GB): _____
- Large monorepos (>10GB): _____
- Gitaly adjustments needed: _____
- Rails adjustments needed: _____
- Peak outbound traffic: _____ Gbps (sustained baseline: _____ Gbps)
- Peak inbound traffic: _____ Gbps (sustained baseline: _____ Gbps)
- Network infrastructure changes: _____

현재 환경 분석 및 권장 사항 검증#

기존 환경을 이해하면 권장 사항에 대한 중요한 맥락을 얻을 수 있습니다:

• 현재 환경이 성능 문제 없이 워크로드를 처리하고 있다면, 이는 규모 추정치에 대한 유용한 검증이 됩니다.

• 반대로 성능 문제가 있는 환경은 과소 산정이 반복되지 않도록 신중한 분석이 필요합니다.

현재 환경 문서화#

현재 상태를 파악하려면 포괄적인 환경 데이터를 수집하세요:

• 아키텍처 세부 정보:

  • 유형: 고가용성(HA) 또는 비고가용성(non-HA).
  • 배포 방식: Linux 패키지 또는 클라우드 네이티브 GitLab.

• 구성 요소 사양:

  • 각 구성 요소의 노드 수와 사양.
  • 사용자 지정 구성 또는 편차.

가장 가까운 레퍼런스 아키텍처 식별#

1. 현재 환경을 사용 가능한 레퍼런스 아키텍처와 비교합니다. 다음을 고려하세요:

   • 구성 요소별 총 컴퓨팅 리소스.
   • 노드 분포와 아키텍처 패턴(HA 대 non-HA).
   • 레퍼런스 아키텍처 규모 대비 구성 요소 사양.

2. 결과를 기록합니다:

   Nearest Reference Architecture: _____
   Custom configurations or deviations:
   - _____
   - _____
   

현재 환경과 권장 아키텍처 비교#

앞선 섹션에서 도출한 권장 레퍼런스 아키텍처와 현재 환경을 비교하세요. 현재 환경이 다음과 같다면:

• 성능 문제가 없고 현재 리소스 < 권장 RA인 경우:

  • 권장 사항이 보수적이며 향후 여유 용량을 제공합니다.
  • 권장 RA로 진행합니다.
  • 잠재적인 최적화 기회를 위해 구현 후 모니터링합니다.

• 성능 문제가 없고 현재 리소스 ≈ 권장 RA인 경우:

  • 규모 산정 평가에 대한 강력한 검증입니다.
  • 현재 환경이 권장 규모가 적절함을 확인해 줍니다.

• 성능 문제가 없고 현재 리소스 > 권장 RA인 경우:

  • 현재 환경이 과다 프로비저닝되었거나, 분석이 필요한 추가 리소스에 대한 타당한 이유가 있을 수 있습니다. Rails, Gitaly, 데이터베이스, Sidekiq의 CPU/메모리 리소스 사용률을 확인하세요.
  • 낮은 사용률(40% 미만)은 과다 프로비저닝을 시사합니다. 높은 사용률은 RPS 분석에 포착되지 않은 특정 워크로드 요구 사항을 나타낼 수 있습니다.
  • 발견되지 않은 요구 사항에 맞춰 권장 사항을 조정해야 하는지 검토합니다.

현재 환경에 성능 문제가 있다면:

• 현재 사양은 최소 기준선으로만 사용합니다. 앞선 섹션의 권장 사항이 현재 사양을 초과해야 합니다.

• 권장 사항이 현재보다 현저히 낮다면 다음을 조사합니다:

  • 평가에 포착되지 않은 워크로드 패턴.
  • 표적 스케일링이 필요한 구성 요소별 병목.

다음으로 진행하기 전에#

이 섹션을 완료하면 현재 환경을 분석하고 권장 사항과 비교하게 됩니다.

진행하기 전에 전체 환경 비교 결과를 기록하세요:

Current Environment Analysis:
- Current RA (nearest): _____
- Recommended RA (from RPS and workload analysis): _____
- Resource comparison: [ ] Current < Recommended [ ] Current ≈ Recommended [ ] Current > Recommended
- Performance status: [ ] No issues [ ] Has issues
- Adjustments needed: _____
- Notes: _____

다음 섹션에서는 시간이 지나도 규모가 적절하게 유지되도록 성장 예측을 평가합니다.

향후 용량 계획#

인프라 변경은 조달, 마이그레이션, 테스트에 상당한 리드 타임이 필요합니다. 성장 추정은 권장 아키텍처가 구현 기간과 그 이후에도 유효하게 유지되도록 보장합니다.

과거 추세와 사업 계획을 결합하면 가장 정확한 성장 예측을 얻을 수 있습니다.

과거 성장 패턴 분석#

과거 성장 패턴은 사업 예측보다 향후 궤적을 더 잘 예측하는 데 도움이 될 수 있습니다:

• 기준 규모의 정보를 사용하여 현재 RPS를 6~12개월 전과 비교합니다.

• 성장 가속 또는 감속 추세를 식별합니다.

사업 계획 요인 반영#

인프라 요구 사항에 영향을 미치는 예상 사업 변화:

• 팀 확장 또는 통합.

• 신규 프로젝트 개발.

• 기존 프로젝트의 개발 활동 증가.

이러한 요인(또는 기타 조직 변화)이 환경의 부하에 영향을 미쳐 인프라 조정을 필요로 할 수 있는지 평가하세요. 관련 변화와 예상 일정을 문서화하세요.

성장 버퍼 전략 결정#

과거 추세와 사업 예측을 기반으로 적절한 성장 수용 전략을 선택하세요:

• 안정적이거나 최소한의 성장: 모니터링을 계속합니다. 레퍼런스 아키텍처에는 여유 용량이 내장되어 있습니다.

• 보통 수준의 성장: 예상되는 향후 RPS를 처리할 수 있는 규모의 RA를 계획합니다.

• 상당한 성장이 예상됨: 현재 RPS가 아니라 예상되는 향후 RPS에 맞춰 규모를 산정하는 것을 고려합니다.

다음으로 진행하기 전에#

이 섹션을 완료하면 성장 예측이 규모 산정 결정에 반영됩니다.

전체 성장 분석을 기록하세요:

Growth Assessment Summary:
- Historical RPS comparison: _____
- Business growth factors: _____
- Growth category: [ ] Stable/Minimal [ ] Moderate [ ] Significant
- Strategy: [ ] Current RA sufficient [ ] Size for projected growth

다음 섹션에서는 모든 결과를 종합하여 최종 아키텍처 권장 사항을 도출합니다.

결과 종합#

최적의 레퍼런스 아키텍처와 필요한 조정을 결정하려면 앞선 모든 섹션의 결과를 종합하세요.

최종 아키텍처 결정#

규모 산정 결정을 내리기 위해 각 섹션의 핵심 산출물을 모으세요:

• RPS 분석을 기반으로 식별한 레퍼런스 아키텍처에서 시작합니다.

• 워크로드 패턴과 데이터 특성을 기반으로 필요한 구성 요소 조정을 적용합니다. 식별된 패턴이 없거나 표준 구성으로 충분하다면 이 단계를 건너뜁니다.

• 현재 상태와 대조하여 검증합니다. 현재 환경이 잘 작동하지만 권장 사항을 초과한다면 그 이유를 문서화합니다. 성능 문제가 있다면 권장 사항이 현재 사양을 초과하도록 하세요.

• 향후 용량 계획에서 성장을 수용합니다. 현재 RA로 충분한지, 아니면 예상 성장에 맞춘 규모 산정이 필요한지 판단합니다.

최종 권장 사항 문서화#

종합 평가를 기반으로 전체 아키텍처 권장 사항을 기록하세요:

Final Architecture Recommendation
==================================

- Selected RA: [Size] based on [Absolute/Sustained] Peak RPS of [value]
- Component adjustments required:
  - [ ] No adjustments needed - standard RA configuration sufficient
  - [ ] Adjustments required:
      - Rails: _____
      - Sidekiq: _____
      - Database: _____
      - Gitaly: _____
      - Network considerations: □ Standard instances □ Network-optimized instances
- Selected RA is aligned with existing environment: [Yes/No/Not applicable]
- Growth accommodation: [Current RA sufficient / Sized up for growth]

Assessment Summary:
├── RPS Analysis
│   ├── Absolute Peak RPS: _____ → Baseline RA: _____
│   └── Sustained Peak RPS: _____ → Sustained RA: _____
├── Workload Type
│   └── Type: [ ] Database-Intensive [ ] Sidekiq-Intensive [ ] None
├── Data Profile
│   ├── Large repos (>2GB): _____ | Monorepos (>10GB): _____
│   └── Network: Peak _____ Gbps | Baseline _____ Gbps
├── Current State
│   ├── Nearest RA: _____
|   └── Discrepancies and customizations: _____
└── Growth
    ├── Growth projection: _____
    └── Growth buffer strategy: _____

모든 섹션을 완료하면 규모 산정 평가가 끝납니다. 최종 권장 사항에는 다음이 포함됩니다:

• 기본 레퍼런스 아키텍처 규모.

• 구성 요소별 조정

• 성장 수용 전략.