업그레이드하기 전에 시스템 용량 확인

GitHub Enterprise Server의 최신 버전으로 업그레이드하면 일반적으로 리소스 사용량이 증가합니다. 각 기능 릴리스에는 새로운 기능이 추가되며, 일부는 기본적으로 활성화되고, 다른 일부는 선택적으로 활성화되며, 이로 인해 더 많은 처리 능력이 필요합니다. 고객의 사용 패턴 또한 수요에 영향을 미칩니다. 예를 들어, 수만 개의 조직이 있는 엔터프라이즈에서는 리소스 사용량이 더 높아지게 됩니다.

리소스 증가는 주로 CPU 사용률 상승, IOPS(초당 I/O 작업) 증가, 메모리 사용량 증가, Aqueduct 큐 백로그 증가로 나타나는 경우가 많습니다. 이러한 변화에 대비하기 위해 업그레이드하기 전에 시스템의 사용 가능한 용량을 확인하고 수정 권장 사항을 적용합니다. 가장 정확한 결과를 얻으려면 하루/주 중 가장 사용량이 많은 시간에 이러한 검사를 실행합니다.

특정 리소스 요구 사항

인스턴스를 업그레이드하기 전에 시스템이 다음과 같은 필수 리소스 요구 사항을 충족하는지 확인하는 것이 중요합니다.

CPU 사용량 70% 미만
메모리 사용량 70% 미만
디스크 비포화 상태
Unicorn 큐 200-300건 미만
Aqueduct 백로그 1~2시간 미만

CPU 사용량 70% 미만

CPU 사용률을 확인합니다. 관리 콘솔에서 모니터 페이지(https://HOSTNAME.com:8443/setup/monitor)로 이동하여 CPU 그래프를 확인합니다.
- 사용률이 정기적으로 70% 미만이면, 메모리 사용량 섹션으로 이동해 계속 진행하세요.
- 사용률이 정기적으로 70%를 초과하면, 시스템은 업그레이드 기준을 충족하지 않습니다.
CPU 부하 평균과 사용률을 비교합니다. 이 비교는 가능한 디스크 포화를 식별하는 데 도움이 됩니다.
- Operational Health view로 이동하여 Load 그래프를 확인합니다.
- 행렬에서 shortterm 행과 avg 열이 교차하는 값을 찾습니다.
- 부하 평균 비율 계산:
```
(short-term avg ÷ number of vCPUs) × 100
```
- 같은 보기에서 CPU 그래프를 확인합니다. 행렬에서 idle 행과 avg 열이 교차하는 값을 찾습니다. 이 값을 100에서 빼서 최종 사용률을 구합니다.
결과 해석

CPU 부하 평균 비율이 사용률보다 50% 이상 높은 경우, 리소스 경합이 발생할 가능성이 높습니다. 가능한 디스크 포화 상태를 조사할 때까지는 업그레이드를 진행하지 마세요(디스크 비포화 상태 참조).

메모리 사용량 70% 미만

메모리 사용량을 확인합니다. 관리 콘솔에서 모니터 페이지(https://HOSTNAME.com:8443/setup/monitor)로 이동하여 Memory 그래프를 확인합니다.
결과 해석
- 메모리 사용량이 정기적으로 70% 미만이면, 디스크 비포화 상태 섹션으로 이동해 계속 진행하세요.
- 메모리 사용량이 정기적으로 70%를 초과하면, 시스템은 업그레이드 기준을 충족하지 않습니다.

디스크 비포화 상태

공급자 사양을 확인합니다. 클라우드 또는 하드웨어 공급자가 디스크 사용률 메트릭을 제공하는 경우, 이를 사용하여 디스크가 포화 상태에 있는지 확인합니다.
- 메트릭을 사용할 수 없는 경우, 공급자에게 최대 처리량 및 최대 IOPS를 포함하여 디스크 사양을 요청합니다.
- 이러한 제한을 관찰된 디스크 사용량과 비교해 보세요. 사용량이 최댓값에 근접하면 디스크가 포화 상태가 됩니다.
관리 콘솔에서 디스크 그래프를 확인하세요. 모니터 페이지(https://HOSTNAME.com:8443/setup/monitor)로 이동합니다.
- Disk Operations 및 Disk Traffic 그래프를 봅니다.
- Y축 값을 공급자의 사양(그래프에 표시된 최대 스케일링 아님)과 비교해 보세요.
- 데이터와 루트 디스크를 모두 검토합니다.

이러한 그래프는 "System & Application Insights" 뷰에서 확인할 수 있습니다.

결과 해석 디스크 사용량이 공급자가 정의한 최대치에 근접하면, 디스크는 포화 상태로 간주됩니다. 이 경우 시스템은 업그레이드 기준을 충족하지 않습니다.

Unicorn 큐 200-300건 미만

대기 요청 그래프를 확인합니다. 관리 콘솔에서 모니터 페이지(https://HOSTNAME.com:8443/setup/monitor)로 이동하여 Queued Requests 그래프를 확인합니다.

이 그래프는 "System & Application Insights" 뷰에서 확인할 수 있습니다.

결과 해석
- 대기 요청이 지속적으로 200개 미만이면, Aqueduct 백로그 1~2시간 미만 섹션으로 이동해 계속 진행하세요.
- 대기 요청이 정기적으로 200-300건을 초과하면, 시스템은 업그레이드 기준을 충족하지 않습니다.
선택 사항: Unicorn 작업자 사용률을 확인합니다. 관리 셸에서 다음을 실행합니다.
```
ps -ef | grep unicorn | grep -v gitauth | grep -v ".rb" | grep -v init | grep git
```
출력의 마지막 열을 살펴보세요. 모든 프로세스가 > 90% utilization으로 표시되면, 더 많은 Unicorn 작업자가 필요합니다.

Aqueduct 백로그 1~2시간 미만

Aqueduct 큐 깊이를 확인합니다. 관리 콘솔에서 모니터 페이지(https://HOSTNAME.com:8443/setup/monitor)로 이동하여 Aqueduct queue depth 그래프를 확인합니다.

이 그래프는 "System & Application Insights" 뷰에서 확인할 수 있습니다.

결과 해석
- 백로그가 1~2시간 미만으로 지속된다면, 이 요구 사항을 충족합니다.
- 백로그가 정기적으로 1~2시간 이상 지속된다면, 시스템은 업그레이드 기준을 충족하지 못합니다.
index_high 큐를 모니터링합니다. 대규모 배포에서는 index_high 큐 깊이가 크게 증가할 수 있으며, 이로 인해 백로그가 악화될 수 있습니다. 모니터링할 때, 이 큐에 특별히 주의하세요.

모든 기준(CPU, 메모리, 디스크, Unicorn 큐, Aqueduct 백로그)이 충족되면, 대상 기능 버전으로 업그레이드를 진행할 수 있습니다. 업그레이드한 후에는 리소스 사용량이 더 증가할 것으로 예상합니다.

조건을 충족하지 못한 경우, 업그레이드를 시도하기 전에 근본적인 문제를 먼저 해결하세요.

하드웨어 업그레이드 및 작업자 미세 조정

시스템이 하나 이상의 리소스 요구 사항을 충족하지 못하는 경우, 업그레이드하기 전에 용량을 늘려야 합니다. 다음 섹션에서는 일반적인 병목 상태를 해결하기 위해 하드웨어 리소스를 추가하고 작업자 구성을 조정하는 방법을 설명합니다.

CPU 70% 초과
메모리 70% 초과
디스크 포화 상태
Unicorn 큐 200~300건 초과
Aqueduct 백로그 1~2시간 초과

CPU 70% 초과

CPU 사용률이 정기적으로 70%를 초과하는 경우:

CPU 리소스를 늘립니다. vCPU를 최소 20% 이상 추가합니다.
새 작업자를 고려합니다. 작업자당 1 vCPU를 할당하세요. 예를 들어, Unicorn 작업자 5개와 Resque 작업자 10개를 추가하는 경우, 최소 15개의 vCPU를 늘려야 합니다.

메모리 70% 초과

메모리 사용량이 정기적으로 70%를 초과하는 경우:

메모리를 늘립니다. RAM을 추가하여 평균 사용량을 70% 미만으로 줄입니다.
새 작업자를 고려합니다. 작업자당 1GB의 메모리를 할당합니다. 예를 들어, Unicorn 작업자 5개와 Resque 작업자 10개를 추가하는 경우, 최소 15GB 이상의 메모리를 늘려야 합니다.

디스크 포화 상태

디스크 포화 상태 검사에서 포화 상태로 나타나면, 더 높은 처리량과 최대 IOPS를 제공하는 디스크로 업그레이드하세요.

Unicorn 큐 200~300건 초과

Unicorn 요청이 지속적으로 200~300건을 초과하여 대기 중인 경우에는 Unicorn 작업자를 더 추가해야 할 수도 있습니다. 다음 단계에 따라 필요한 총 대상 작업자 수를 확인하고 구성을 업데이트하세요.

1. 추가 작업자 추정

사용량이 가장 많은 시간대에 다음 명령을 실행하여 작업자당 사용률을 확인합니다.

ps -ef | grep unicorn | grep -v gitauth | grep -v ".rb" | grep -v init | grep git

예시 출력:

git      3048972 3045762  0 Aug01 ?        00:07:47 unicorn 3-16-nightly.ghe-test.com[6e6ad46] worker[00]: 20491 reqs,  10.8 req/s,   13ms avg,   85.2% util
git      3048979 3045762  0 Aug01 ?        00:07:53 unicorn 3-16-nightly.ghe-test.com[6e6ad46] worker[01]: 20951 reqs,  12.5 req/s,   13ms avg,   80.3% util
git      3048985 3045762  0 Aug01 ?        00:08:04 unicorn 3-16-nightly.ghe-test.com[6e6ad46] worker[02]: 21502 reqs,  10.5 req/s,   15ms avg,   76.5% util
git      3048992 3045762  0 Aug01 ?        00:07:45 unicorn 3-16-nightly.ghe-test.com[6e6ad46] worker[03]: 20249 reqs,  14.2 req/s,   15ms avg,   86.9% util

평균 요청/초는 초당 12건의 요청입니다.

이 출력에서 초당 평균 요청(req/s)을 계산합니다.

위 예시의 경우: 12req/s
대상은 대기 요청을 ≤100으로 줄이는 것입니다.
공식:
```
(Queued requests – 100) ÷ avg req/s
```
예: (280 – 100) ÷ 12 =15, 15개의 추가 작업자가 필요합니다.

팁

결과를 확인하려면 GitHub Enterprise 지원를 방문하여 번들을 업로드하고 Unicorn 작업자의 총 대상 수를 요청하여 문의해 주세요.

2. 현재 구성 확인

총 작업자 수(Unicorn + Resque)가 vCPU를 초과하지 않도록 하세요. 작업자당 최소 1개 이상의 vCPU를 할당해야 합니다.

현재 수 확인:

Unicorn 작업자
```
ps -ef | grep unicorn | grep -v gitauth | grep -v ".rb" | grep -v init | grep git | wc -l
```
계산된 새 작업자 수를 이 값에 더해 총 대상 작업자 수를 구하세요.

Resque 작업자

ps -ef | grep aqueduct-1.1.0 | grep -v "grep aqueduct-1.1.0" | wc -l

3. 구성 조정

Unicorn + Resque 작업자 수의 합계가 vCPU를 초과하는 경우, 계속하기 전에 vCPU를 더 추가합니다.

Unicorn 작업자 수를 업데이트합니다.

ghe-config app.github.github-workers <NUM-WORKERS>
ghe-config-apply

를 Unicorn 작업자의 총 대상 수로 바꾸세요.

Aqueduct 백로그 1~2시간 초과

Aqueduct 작업이 정기적으로 1~2시간 이상 백로그되는 상태라면, Resqued-low 작업자를 추가하여 큐 백업 위험을 줄이세요. 이 문제는 업그레이드 이후 더 심각해지는 경우가 많습니다.

1. Resqued-low 작업자 추가

작업자 수를 5~10개 정도 늘리세요. CPU 용량을 고려하세요. 각 작업자에게는 최소 1 vCPU가 필요합니다.

ghe-config app.github.resqued-low-workers <NUM-WORKERS>
ghe-config-apply

를 새로운 총 resqued-low 작업자의 수로 바꿉니다.

2. 총 작업자 수 검증

결합된 Unicorn + Resque 작업자의 총 수가 총 vCPU 수를 초과하지 않도록 합니다. 현재 작업자 구성을 확인하는 방법에 대한 지침은 Unicorn 큐 200~300건 초과를 참조하세요.

이 문서의 내용