적절한 참조 아키텍처를 선택하려면 참조 아키텍처를 기반으로 GitLab 환경을 평가하고 크기를 정하는 체계적인 접근법을 사용해야 합니다.

적절한 참조 아키텍처와 필요한 구성요소별 조정을 결정하기 위해 다음 정보를 분석하는 데 도움이 됩니다:

• 초당 요청 수(RPS) 패턴.
• 워크로드 특성.
• 리소스 포화.

시작하기 전에#

복잡한 환경이 있는 경우 이 정보를 사용하여 적절한 참조 아키텍처를 선택할 수 있습니다. 이 수준의 세부 정보가 필요하지 않을 수 있으며, 덜 복잡한 환경 정보를 사용하여 환경 크기를 평가할 수 있습니다.

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

Prometheus를 아직 구성하지 않은 경우:

1. Prometheus로 모니터링을 구성합니다. 참조 아키텍처 문서는 각 환경 크기에 대한 Prometheus 구성 세부 정보를 제공합니다. 클라우드 네이티브 GitLab의 경우 메트릭 스크래핑을 구성하기 위해 kube-prometheus-stack Helm 차트를 사용할 수 있습니다.
2. 의미 있는 데이터 패턴을 수집하기 위해 7-14일 동안 데이터를 수집합니다.
3. 이 문서의 나머지 부분을 읽습니다.

Prometheus 모니터링을 구성할 수 없는 경우:

• 크기 추정을 위해 현재 환경 분석 사양을 가장 가까운 참조 아키텍처와 비교합니다.
• GitLabSOS 또는 KubeSOS 로그를 사용하여 참조 아키텍처 크기를 평가하기 위해 GitLab RPS Analyzer를 사용합니다. 그러나 이는 메트릭보다 신뢰성이 낮습니다.

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

1. 예상 워크로드에 따라 가장 가까운 참조 아키텍처를 추정합니다.
2. 예상 추가 워크로드를 식별합니다.
3. 대규모 저장소의 수를 평가합니다.
4. 성장 계획을 포함합니다.
5. 적절한 버퍼가 있는 참조 아키텍처를 선택합니다.

PromQL 쿼리 실행#

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

기준 크기 결정#

초당 요청 수(RPS)는 GitLab 인프라 크기 결정을 위한 주요 메트릭입니다. 다양한 트래픽 유형(API, 웹, Git 작업)은 서로 다른 구성요소에 부하를 주므로, 실제 용량 요구 사항을 찾기 위해 각각 별도로 분석됩니다.

피크 트래픽 메트릭 추출#

최대 부하를 이해하기 위해 다음 쿼리를 실행합니다. 이 쿼리들은 다음을 보여줍니다:

• 절대 최고치, 즉 경험한 가장 높은 급증. 절대 최고치는 최악의 시나리오를 보여줍니다.
• 지속 최고치, 즉 95번째 백분위수로 "바쁜" 일반적인 수준을 나타냅니다. 지속 최고치는 일반적인 높은 부하 기간을 드러냅니다.

절대 최고치가 드문 이상치인 경우, 지속 부하에 맞게 크기를 정하는 것이 적절할 수 있습니다.

보존 기간에 따라 쿼리의 시간 범위를 조정합니다 (더 긴 기록이 사용 가능한 경우 [7d]를 [30d]로 변경).

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 pull 및 clone 피크, 피크 저장소 clone 및 fetch 작업 측정:

     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 push 피크, 피크 코드 push 작업 측정:

     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 pull 및 clone 지속 최고치:

     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 push 지속 최고치:

     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. 결과를 기록합니다.

트래픽을 참조 아키텍처에 매핑#

앞서 기록한 결과를 사용하여 트래픽을 참조 아키텍처에 매핑하려면:

1. 사용 가능한 참조 아키텍처를 참조하여 각 트래픽 유형이 제안하는 참조 아키텍처를 확인합니다.

2. 분석 테이블을 작성합니다. 다음 테이블을 가이드로 사용합니다:

   트래픽 유형	피크 RPS	피크 권장 RA	지속 RPS	지속 권장 RA
   API	________	_____ (최대 ___ RPS)	_____________	_____ (최대 ____ RPS)
   Web	________	_____ (최대 ___ RPS)	_____________	_____ (최대 ____ RPS)
   Git pull/clone	________	_____ (최대 ___ RPS)	_____________	_____ (최대 ____ RPS)
   Git push	________	_____ (최대 ___ RPS)	_____________	_____ (최대 ____ RPS)

3. 피크 권장 RA 열의 모든 참조 아키텍처를 비교하고 가장 큰 크기를 선택합니다. 지속 권장 RA 열에 대해서도 반복합니다.

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

   • 제안된 가장 큰 피크 RA.
   • 제안된 가장 큰 지속 RA.

참조 아키텍처 선택#

이 시점에서 두 가지 후보 참조 아키텍처 크기가 있습니다:

• 절대 최고치 기반.
• 지속 부하 기반.

참조 아키텍처를 선택하려면:

1. 피크와 지속이 동일한 RA를 제안하면 해당 RA를 사용합니다.
2. 피크가 지속보다 더 큰 RA를 제안하는 경우. 차이를 계산합니다. 피크 RPS가 지속 RA의 상한보다 10-15% 이내입니까?

일반 지침:

• 피크 RPS가 지속 RA 한계를 10-15% 미만으로 초과하는 경우, 참조 아키텍처에 내장된 여유분이 있으므로 허용 가능한 리스크로 지속 RA를 고려할 수 있습니다.
• 15%를 초과하는 경우, 피크 기반 RA로 시작한 다음 메트릭이 다운사이징을 지원하면 모니터링하고 조정합니다.
  • 예시 1: 피크가 110 RPS, 대형 RA는 "최대 100 RPS" 처리 → 10% 초과 → 대형으로 충분 (참조 아키텍처에는 내장된 여유분이 있음)
  • 예시 2: 피크가 150 RPS, 대형 RA는 "최대 100 RPS" 처리 → 50% 초과 → 특대형 사용 (최대 200 RPS)
  • 예시 3: 피크가 100 RPS (대형/100 RPS)이지만 지속이 50 RPS (중형/60 RPS). 원시 RPS 그래프는 자동화 급증이 피크를 유발하지만 대부분의 시간에 부하가 <50 RPS임을 보여줍니다. 사용자는 보수적으로 대형으로 시작하여 축소할지, 또는 워크로드별 스케일링으로 중형을 시작할지(더 높은 위험) 평가합니다.

40 RPS 미만의 환경에서 고가용성(HA)이 요구 사항인 경우, 고가용성 섹션을 참조하여 지원되는 감소와 함께 60 RPS / 3,000 사용자 아키텍처로 전환이 필요한지 확인합니다.

진행 전에#

이 섹션을 완료하면 기준 참조 아키텍처 크기가 설정됩니다. 이것이 기반을 형성하지만, 다음 섹션에서 특정 워크로드에 표준 구성 이상의 구성요소 조정이 필요한지 식별합니다.

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

참조 아키텍처 평가 요약:

- 선택된 참조 아키텍처: _____
- _____ RPS [절대/지속]에 기반한 정당화

| 트래픽 유형     | 피크 RPS | 지속 RPS (95번째 백분위수) |
|:--------------|:---------|:------------------------|
| API           | ________ | ____________________ |
| Web           | ________ | ____________________ |
| Git pull/clone | ________ | ____________________ |
| Git push      | ________ | ____________________ |

워크로드 분석을 위한 최고 RPS 피크 타임스탬프: _____

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

총 RPS는 주요 크기 결정 메트릭이지만, 워크로드 구성은 구성요소 리소스 요구 사항에 크게 영향을 미칩니다. 다른 요청 유형은 다양한 강도로 다른 구성요소에 부하를 줍니다.

요청 유형별 RPS 분석#

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

• API 요청 (총 RPS의 ~80%) - 자동화, 통합, 웹훅 및 API 기반 도구
• 웹 요청 (총 RPS의 ~10%) - UI 상호작용, 페이지 탐색 및 사용자 주도 작업
• Git 작업 (총 RPS의 ~10%) - 저장소 clone 및 pull, 낮은 push 비율

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

비정형 워크로드 패턴 식별#

피크 트래픽 메트릭 추출의 RPS 추출 쿼리를 사용하여 워크로드 구성을 이해합니다. 배포를 일반적인 패턴과 비교합니다:

API 집중 워크로드 (API가 총 RPS의 >90%):

• 많은 자동화, 광범위한 통합 또는 API 기반 도구
• 주요 영향: Rails(Webservice), PostgreSQL, Gitaly
• 고려사항: 증가된 Webservice/Rails 용량, 데이터베이스 읽기 복제본

웹 집중 워크로드 (웹이 총 RPS의 >20%):

• 광범위한 UI 상호작용이 있는 대규모 활성 사용자 기반
• 주요 영향: Rails(Webservice), PostgreSQL
• 고려사항: 증가된 Webservice 용량, 데이터베이스 최적화

Git 집약적 워크로드 (Git이 총 RPS의 >15% 또는 크기에 비해 pull 비율이 현저히 높은 경우):

• 빈번한 pull, 모노레포 패턴 또는 저장소 clone을 포함하는 CI/CD 집중 워크플로우를 가진 대규모 팀
• 주요 영향: Gitaly, 네트워크 대역폭
• 고려사항: Gitaly 수직 스케일링, 저장소 최적화, 네트워크 향상된 VM

평가 접근법#

1. 제공된 PromQL 쿼리를 사용하여 RPS 분석 추출
2. 각 요청 유형의 총 비율 계산
3. 어떤 유형이 일반적인 비율을 크게 초과하는지 식별
4. 비정형인 경우 스케일링 지침에 대한 구성요소 조정 식별 참조

구성요소 조정 식별#

워크로드 평가는 기본 참조 아키텍처 이상의 구성요소 조정이 필요한 특정 사용 패턴을 식별합니다. RPS가 전체 크기를 결정하는 반면, 워크로드 패턴은 형태를 결정합니다. 동일한 RPS를 가진 두 환경은 매우 다른 리소스 요구 사항을 가질 수 있습니다.

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

• 중간 RPS를 유지하면서 수천 개의 작업을 처리하는 CI/CD 집중 환경은 Sidekiq 및 Gitaly에 부하를 줍니다.
• 높은 RPS를 보이는 광범위한 API 자동화가 있는 환경은 데이터베이스 및 Rails 레이어에 부하를 집중시킵니다.

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

이전 섹션의 피크 타임스탬프를 사용하여 최대 부하 중에 가장 많은 트래픽을 받은 엔드포인트를 식별합니다.

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. 결과 기록:

   식별된 워크로드 패턴:
   
   - [ ] 데이터베이스 집중
   - [ ] Sidekiq 또는 Gitaly 집중
   - [ ] 감지되지 않음
   

구성요소 조정 결정#

위의 지표는 추가 워크로드의 초기 신호를 제공합니다. 참조 아키텍처의 내장된 여유분으로 인해 이러한 워크로드는 조정 없이 처리될 수 있습니다. 그러나 강력한 지표가 있고 높은 수준의 자동화가 알려진 경우 다음 조정을 고려합니다.

앞서 식별된 워크로드 패턴에 따라 다른 구성요소를 스케일링해야 합니다:

스케일링 지침#

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

1. 현재 리소스의 1.25x-1.5x로 시작합니다.
2. 구현 후 모니터링 데이터를 기반으로 조정합니다.

클라우드 네이티브 GitLab 배포를 계획하는 경우, 이 평가에서 식별된 워크로드 패턴은 Kubernetes 구성에 추가적인 영향을 미칩니다:

• 높은 피크 외 트래픽. 조용한 기간 동안 스케일 투 제로가 아닌 기준 부하에 충분한 최소 파드 수를 확보합니다. 예를 들어, 업무 시간에 100 RPS이고 자동화로 인해 밤에 지속적으로 50 RPS인 경우, 최소 파드 수 구성이 피크 외 기준 부하에 맞춰야 합니다.
• 급격한 트래픽 급증. 기본 HPA 설정이 충분히 빠르게 스케일링되지 않을 수 있습니다. 초기 출시 중 이러한 전환 중 요청 큐잉을 방지하기 위해 파드 스케일링 동작을 모니터링합니다. 예를 들어, 조용한 시간에서 업무 시간으로 전환하거나 특정 자동화 급증으로 인해 50에서 200 RPS로 급격히 증가하는 경우.

데이터베이스 스케일링#

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

1. 즉각적인 용량 제약을 해결하기 위한 수직 스케일링:
   • 복제본이 기본 부하를 줄이지 않으므로 쓰기 집중 워크로드에 필요합니다.
   • 읽기 및 쓰기 작업 모두에 대해 즉각적인 용량 증가를 제공합니다.
2. 읽기 복제본을 사용하는 데이터베이스 로드 밸런싱 (권장):
   • 읽기 집중 워크로드(85-95% 읽기)에 특히 유익합니다.
   • 여러 노드에 읽기 트래픽을 분산시킵니다.
   • 수직 스케일링과 함께 추가할 수 있습니다.
3. 쓰기 성능이 병목 현상으로 남아있는 경우 수직 스케일링 계속 진행.

읽기/쓰기 분포를 식별하기 위해 이 Prometheus 쿼리를 사용합니다:

# 읽기 작업 비율
(
  (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

진행 전에#

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

진행하기 전에 완전한 워크로드 평가를 기록합니다:

식별된 워크로드 패턴:

- [ ] 데이터베이스 집중
- [ ] Sidekiq 또는 Gitaly 집중
- [ ] 감지되지 않음
- 필요한 구성요소 조정: _____

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

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

저장소 특성 및 네트워크 사용 패턴은 RPS 메트릭이 드러내는 것 이상으로 GitLab 성능에 크게 영향을 미칠 수 있습니다.

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

대규모 모노레포#

대규모 모노레포(수 기가바이트 이상)는 Git 작업 성능 방식을 근본적으로 변경합니다. 10 GB 저장소의 단일 clone은 일반적인 저장소의 수백 개 clone보다 더 많은 리소스를 소비합니다.

이러한 저장소는 Gitaly뿐만 아니라 워크로드에 따라 Rails, Sidekiq 및 데이터베이스에도 영향을 줍니다.

프로파일링 프로세스는 일반적인 크기를 크게 초과하는 저장소를 식별하는 데 중점을 둡니다:

• 중간 모노레포: 2 GB - 10 GB. 이는 약간의 조정이 필요합니다.
• 대규모 모노레포: >10 GB. 이는 상당한 인프라 변경이 필요합니다.

저장소 크기를 식별하려면:

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

2. 저장소 스토리지 유형을 검토합니다.

3. 2 GB 이상 및 10 GB 이상의 저장소가 있는 프로젝트 수를 계산합니다.

4. 결과를 기록합니다:

   중간 모노레포 수 (2GB - 10GB): _____
   대규모 모노레포 수 (>10GB): _____
   

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

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

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

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

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

일반적인 네트워크 부하 소스:

• 무거운 컨테이너 레지스트리 사용(대형 이미지, 빈번한 pull).
• LFS 작업(바이너리 파일, 미디어 자산).
• 대규모 CI/CD 아티팩트(빌드 출력, 테스트 결과).
• 모노레포 clone(특히 CI/CD 파이프라인에서).

네트워크 사용량 측정#

잠재적 병목 현상을 식별하기 위해 피크 및 기준 네트워크 소비를 계산합니다. 가끔 급증(버스트 용량으로 처리)과 지속적인 높은 트래픽(네트워크 향상된 VM 필요)을 구별하기 위해 두 가지 모두 평가합니다.

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

   # 아웃바운드 트래픽 (Gbps) - 상위 10개 노드
   topk(10, sum by (instance) (rate(node_network_transmit_bytes_total{device!="lo"}[5m]) * 8 / 1000000000))
   
   # 인바운드 트래픽 (Gbps) - 상위 10개 노드
   topk(10, sum by (instance) (rate(node_network_receive_bytes_total{device!="lo"}[5m]) * 8 / 1000000000))
   
   

2. 모니터링 기간 동안 관찰된 피크 급증과 일반적인 기준 모두를 기록합니다:

   피크 아웃바운드 트래픽: _____ Gbps (기준: _____ Gbps)
   피크 인바운드 트래픽: _____ Gbps (기준: _____ Gbps)
   

네트워크 용량 요구 사항#

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

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

진행 전에#

진행하기 전에 완전한 데이터 프로파일링 평가를 기록합니다:

데이터 프로파일 요약:
- 중간 모노레포 (2GB-10GB): _____
- 대규모 모노레포 (>10GB): _____
- 필요한 Gitaly 조정: _____
- 필요한 Rails 조정: _____
- 피크 아웃바운드 트래픽: _____ Gbps (지속 기준: _____ Gbps)
- 피크 인바운드 트래픽: _____ Gbps (지속 기준: _____ Gbps)
- 네트워크 인프라 변경: _____

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

기존 환경을 이해하는 것은 권장 사항에 중요한 컨텍스트를 제공합니다:

• 현재 환경이 성능 문제 없이 워크로드를 처리하는 경우, 크기 추정에 대한 유효한 검증을 제공합니다.
• 반대로, 성능 문제가 있는 환경은 과소 크기 책정을 반복하지 않기 위해 신중한 분석이 필요합니다.

현재 환경 문서화#

현재 상태를 설정하기 위해 포괄적인 환경 데이터를 수집합니다:

• 아키텍처 세부 정보:
  • 유형: 고가용성(HA) 또는 비고가용성(non-HA).
  • 배포 방법: Linux 패키지 또는 클라우드 네이티브 GitLab.
• 구성요소 사양:
  • 각 구성요소에 대한 노드 수 및 사양.
  • 사용자 정의 구성 또는 편차.

가장 가까운 참조 아키텍처 식별#

1. 현재 환경을 사용 가능한 참조 아키텍처와 비교합니다. 다음을 고려합니다:

   • 구성요소당 총 컴퓨팅 리소스.
   • 노드 배포 및 아키텍처 패턴(HA vs non-HA).
   • 참조 아키텍처 크기에 상대적인 구성요소 사양.

2. 결과를 기록합니다:

   가장 가까운 참조 아키텍처: _____
   사용자 정의 구성 또는 편차:
   - _____
   - _____
   

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

이전 섹션에서 개발한 권장 참조 아키텍처와 현재 환경을 비교합니다. 현재 환경이:

• 성능 문제가 없고 현재 리소스 < 권장 RA인 경우:
  • 권장 사항이 보수적이며 향후 여유분을 제공합니다.
  • 권장 RA로 진행합니다.
  • 잠재적 최적화 기회에 대해 구현 후 모니터링합니다.
• 성능 문제가 없고 현재 리소스 ≈ 권장 RA인 경우:
  • 크기 평가의 강력한 검증입니다.
  • 현재 환경이 권장 크기가 적절하다는 것을 확인합니다.
• 성능 문제가 없고 현재 리소스 > 권장 RA인 경우:

  • 현재 환경이 과잉 프로비저닝되었거나 분석이 필요한 추가 리소스에 대한 유효한 이유가 있을 수 있습니다. Rails, Gitaly, 데이터베이스 및 Sidekiq에서 CPU/메모리 리소스 활용률을 확인합니다.

    낮은 활용률(<40%)은 과잉 프로비저닝을 시사합니다. 높은 활용률은 RPS 분석에서 포착되지 않은 특정 워크로드 요구 사항을 나타낼 수 있습니다.

  • 발견되지 않은 요구 사항에 대해 권장 사항을 조정해야 하는지 검토합니다.

현재 환경에 성능 문제가 있는 경우:

• 현재 사양을 최소 기준으로만 사용합니다. 이전 섹션의 권장 사항은 현재 사양을 초과해야 합니다.
• 권장 사항이 현재보다 크게 낮은 경우 다음을 조사합니다:
  • 평가에서 포착되지 않은 워크로드 패턴.
  • 대상 스케일링이 필요한 구성요소별 병목 현상.

진행 전에#

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

진행하기 전에 완전한 환경 비교를 기록합니다:

현재 환경 분석:
- 현재 RA (가장 가까운): _____
- 권장 RA (RPS 및 워크로드 분석에서): _____
- 리소스 비교: [ ] 현재 < 권장 [ ] 현재 ≈ 권장 [ ] 현재 > 권장
- 성능 상태: [ ] 문제 없음 [ ] 문제 있음
- 필요한 조정: _____
- 참고: _____

다음 섹션에서는 크기 결정이 시간이 지남에 따라 적절하게 유지되도록 성장 예측을 평가합니다.

향후 용량 계획#

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

비즈니스 계획과 결합된 과거 추세가 가장 정확한 성장 예측을 제공합니다.

과거 성장 패턴 분석#

과거 성장 패턴은 비즈니스 예측보다 미래 경로를 더 잘 예측하는 데 도움이 될 수 있습니다:

1. 기준 크기 결정의 정보를 사용하여 현재 RPS와 6-12개월 전을 비교합니다.
2. 성장 가속 또는 감속 추세를 식별합니다.

비즈니스 계획 요인 포함#

인프라 요구 사항에 영향을 미치는 예상 비즈니스 변경:

• 팀 확장 또는 통합.
• 새 프로젝트 개발.
• 기존 프로젝트의 개발 활동 증가.

이러한 요인(또는 다른 조직 변경)이 환경 부하에 영향을 미쳐 인프라 조정이 필요할 수 있는지 평가합니다. 관련 변경 사항과 예상 일정을 문서화합니다.

성장 버퍼 전략 결정#

과거 추세와 비즈니스 예측을 기반으로 적절한 성장 수용 전략을 선택합니다:

• 안정적 또는 최소 성장: 모니터링을 계속합니다. 참조 아키텍처에는 내장된 여유분이 있습니다.
• 중간 성장: 예상 미래 RPS를 처리하기 위해 크기가 조정된 RA를 계획합니다.
• 상당한 성장 예상: 현재 RPS보다 예상 미래 RPS에 맞게 크기를 정하는 것을 고려합니다.

진행 전에#

이 섹션을 완료하면 성장 예측이 크기 결정에 포함됩니다.

완전한 성장 분석을 기록합니다:

성장 평가 요약:
- 과거 RPS 비교: _____
- 비즈니스 성장 요인: _____
- 성장 카테고리: [ ] 안정/최소 [ ] 중간 [ ] 상당
- 전략: [ ] 현재 RA 충분 [ ] 예상 성장에 맞게 크기 조정

다음 섹션에서는 모든 결과를 최종 아키텍처 권장 사항으로 취합합니다.

결과 취합#

최적의 참조 아키텍처와 필요한 조정을 결정하기 위해 이전 모든 섹션의 결과를 취합합니다.

최종 아키텍처 결정#

크기 결정을 구성하기 위해 각 섹션의 주요 출력을 수집합니다:

1. RPS 분석을 기반으로 식별된 참조 아키텍처로 시작합니다.
2. 워크로드 패턴 및 데이터 특성을 기반으로 필요한 구성요소 조정을 적용합니다. 패턴이 식별되지 않거나 표준 구성이 충분한 경우 이 단계를 건너뜁니다.
3. 현재 상태에 대해 검증합니다. 현재 환경이 잘 수행되지만 권장 사항을 초과하는 경우 이유를 문서화합니다. 성능 문제가 있는 경우 권장 사항이 현재 사양을 초과하는지 확인합니다.
4. 향후 용량 계획에서 성장을 수용합니다. 현재 RA가 충분한지 또는 예상 성장에 맞게 크기를 정해야 하는지 결정합니다.

최종 권장 사항 문서화#

포괄적인 평가를 기반으로 완전한 아키텍처 권장 사항을 기록합니다:

최종 아키텍처 권장 사항
==================================

- 선택된 RA: [크기] [값]의 [절대/지속] 피크 RPS를 기반으로
- 필요한 구성요소 조정:
  - [ ] 조정 불필요 - 표준 RA 구성 충분
  - [ ] 조정 필요:
      - Rails: _____
      - Sidekiq: _____
      - Database: _____
      - Gitaly: _____
      - 네트워크 고려 사항: □ 표준 인스턴스 □ 네트워크 최적화 인스턴스
- 선택된 RA가 기존 환경과 일치함: [예/아니요/해당 없음]
- 성장 수용: [현재 RA 충분 / 성장에 맞게 크기 조정]

평가 요약:
├── RPS 분석
│   ├── 절대 피크 RPS: _____ → 기준 RA: _____
│   └── 지속 피크 RPS: _____ → 지속 RA: _____
├── 워크로드 유형
│   └── 유형: [ ] 데이터베이스 집중 [ ] Sidekiq 집중 [ ] 없음
├── 데이터 프로파일
│   ├── 대규모 저장소 (>2GB): _____ | 모노레포 (>10GB): _____
│   └── 네트워크: 피크 _____ Gbps | 기준 _____ Gbps
├── 현재 상태
│   ├── 가장 가까운 RA: _____
|   └── 불일치 및 사용자 정의: _____
└── 성장
    ├── 성장 예측: _____
    └── 성장 버퍼 전략: _____

모든 섹션을 완료했으면 크기 평가가 완료됩니다. 최종 권장 사항에는 다음이 포함됩니다:

• 기본 참조 아키텍처 크기.
• 구성요소별 조정.
• 성장 수용 전략.

워크로드 패턴이 진화함에 따라 가정을 검증하고 인프라를 조정하기 위해 정기적인 모니터링이 필수적입니다.