03 · USE Method로 느린 서비스의 자원 병목 좁히기

CPU 사용률이 낮다는 이유로 서버의 자원 조사를 끝내기는 어렵습니다. 한 CPU에 작업이 몰렸거나, 짧은 대기가 긴 평균에 가려졌을 수 있습니다. 물리 자원에 여유가 있어도 애플리케이션의 연결 풀이 먼저 한도에 닿는 경우가 있습니다.

Brendan Gregg의 USE Method는 성능 조사 초기에 자원 병목과 오류를 찾는 방법입니다. 먼저 시스템의 자원을 나열하고, 자원마다 사용률·포화·오류를 확인합니다. 질문부터 세우고 그 답을 줄 지표와 도구를 찾는 순서입니다.

요청이 느려진 구간부터

주문 API가 느려졌지만 호스트의 평균 CPU 사용률은 높지 않은 상황을 가정하겠습니다. 실제 측정 결과나 특정 서비스의 장애 사례가 아닌, 조사 순서를 설명하기 위한 가상의 예시입니다.

처음 정할 것은 요청 지연이 늘어난 시간과 영향을 받은 인스턴스입니다. 해당 인스턴스의 CPU·메모리·저장장치·네트워크를 같은 시간 범위에서 비교합니다. 사용자 지연은 짧게 치솟았는데 자원 지표를 몇 분 평균으로만 읽으면 변화가 흐려질 수 있습니다. 증상이 나타난 구간을 좁히고, 수집 해상도가 허용하는 범위에서 관찰 시간을 맞춥니다.

이때 서비스의 증상과 자원의 상태는 서로 다른 정보를 줍니다. USE 지표만으로는 사용자가 요청을 성공적으로 마쳤는지 알 수 없습니다. 요청 수·오류·처리 시간을 보는 RED Method, 사용자 영향과 여유를 살피는 Four Golden Signals를 자원 조사와 함께 활용합니다.

점검표에 들어갈 자원과 질문

자원 목록은 CPU, 메모리, 네트워크 인터페이스, 저장장치부터 작성합니다. 저장장치는 I/O 처리 능력과 용량을 나눕니다. 디스크 공간이 충분해도 I/O가 밀릴 수 있고, I/O가 한가해도 공간 부족으로 쓰기에 실패할 수 있기 때문입니다.

실행 환경에 따라 목록의 범위도 달라집니다. 물리 서버라면 컨트롤러와 자원을 잇는 버스도 조사 대상입니다. 컨테이너에서는 호스트 전체 자원과 해당 워크로드에 허용된 한도를 함께 적습니다.

이 목록에 USE 원문의 질문을 적용합니다. Utilization(사용률)은 자원이 일을 처리하느라 바빴던 시간의 평균입니다. CPU처럼 일을 처리하는 자원에는 이 정의를 적용하고, 메모리나 파일시스템처럼 용량을 보는 자원에서는 전체 중 사용한 비율을 읽습니다.

사용률을 읽었다면 그 자원을 기다리는 일이 있는지 확인할 차례입니다. Saturation(포화)은 자원이 당장 처리하지 못하는 일이 남아 있는 정도를 뜻합니다. 실행 대기 작업, I/O 대기열, 스레드 풀에서 기다리는 요청이 단서입니다. CPU 사용률이 높아도 실행 대기가 없고 응답 시간이 정상일 수 있으므로, 바쁜 정도만으로 병목을 판단하지 않습니다. 전체 사용률이 낮아도 특정 CPU나 짧은 시간대에는 대기가 생길 수 있으므로, 바쁜 정도를 나타내는 사용률과 처리가 밀리는 정도를 나타내는 포화를 함께 봐야 합니다.

Errors(오류)는 오류가 발생한 횟수입니다. 장치 오류나 할당 실패, 네트워크 인터페이스 오류를 살피되 누적값에서 끝내지 않고, 성능이 나빠진 시간에 새 오류가 늘었는지 확인합니다. 복구되거나 재시도로 가려진 오류도 성능을 해칠 수 있습니다.

지표를 구하지 못한 칸은 미확인 상태로 남깁니다. Gregg의 원문은 이런 항목을 물음표로 표시하도록 제안합니다. 네트워크 오류를 수집하지 않았다면 오류가 없는지 아직 모르는 상태입니다. 확인한 항목과 미확인 항목을 구분해 두면 다음 조사자가 같은 범위를 다시 훑는 시간을 줄일 수 있습니다.

소프트웨어의 한도에도 같은 질문을 적용한다

물리 자원이 남아 있는데도 요청이 기다린다면 소프트웨어가 정한 한도도 살펴봅니다. Gregg가 소프트웨어 자원의 예로 든 대상에는 락, 스레드 풀, 파일 디스크립터가 있습니다. 스레드 풀이 모두 사용 중인지, 작업 큐가 길어지는지, 새 작업이 거부됐는지를 함께 계측하면 USE의 질문을 적용할 수 있습니다.

포화 지표가 맞지 않는 자원도 있습니다. 한도에 닿았을 때 대기하지 않고 곧바로 실패하는 경우입니다. 그런 자원에서는 대기 항목을 억지로 만들지 않고, 실패 수와 한도까지 남은 여유를 기록합니다. 자원의 동작 방식에 맞는 지표를 고르는 것이 약어를 채우는 것보다 중요합니다.

Linux 점검표와 숫자의 의미

자원별 질문이 정해졌다면 답을 얻을 도구를 연결합니다. 아래 표는 Gregg의 Linux 체크리스트에서 흔히 접근할 수 있는 도구를 골라 만든 출발점입니다. 명령은 조사 중인 서버의 상태를 읽기 위주로 살피기 위한 예이며, 설치 여부와 출력 필드는 배포판·버전에 따라 다릅니다.

한 명령이 사용률·포화·오류를 모두 보여 주지는 않습니다. CPU 오류처럼 일반적인 사용률 도구에서 얻지 못하는 항목도 있습니다. 접근 가능한 지표부터 조사하되, 출력에 없다는 이유로 정상이라고 판단해서는 안 됩니다.

CPU 전체 평균과 load average를 구분해서 읽기

CPU 전체 평균이 낮을 때도 mpstat -P ALL 1로 CPU별 상태를 확인합니다. 특정 CPU에 작업이 몰렸는지 살피기 위해서입니다. Gregg의 Linux 체크리스트 설명에 따르면 vmstat 1의 r에는 실행을 기다리는 스레드뿐 아니라 CPU에서 실행 중인 스레드도 포함됩니다.

Linux의 load average 역시 CPU 대기열만 나타내는 값이 아닙니다. 실행 가능한 작업에 더해, 일반적으로 I/O 대기와 관련된 중단 불가능한 대기 상태의 작업도 들어갑니다. 값이 CPU 수보다 크다는 이유만으로 CPU를 원인으로 지목하기 어려운 이유입니다. CPU별 사용률과 실행 대기, I/O 지연을 함께 비교하며 원인 후보를 나눕니다. Linux proc_loadavg 매뉴얼

메모리 사용량 옆에 가용량을 놓는다

Linux는 파일 캐시에도 메모리를 사용합니다. MemFree가 작다는 사실만으로 메모리 부족을 판단하기는 어렵습니다. Linux 커널의 meminfo 설명에서 MemAvailable은 회수 가능한 캐시 등을 고려해, 스와핑 없이 새 애플리케이션에 제공할 수 있는 메모리를 추정한 값입니다.

사용량과 가용량을 읽은 뒤에는 회수·스와핑 활동과 실제 지연을 함께 살핍니다. 캐시가 많다는 이유로 비우면 관찰하려던 작업의 특성까지 바뀝니다. 어떤 메모리가 늘었고 그때 어떤 작업이 기다렸는지부터 확인하는 편이 조사에 도움이 됩니다.

%util이 알려 주지 않는 처리 능력

현대 SSD나 RAID의 남은 처리 능력을 iostat의 %util만으로 판단할 수는 없습니다. iostat 매뉴얼도 요청을 병렬로 처리하는 장치에서는 이 값이 성능 한계를 나타내지 않는다고 설명합니다.

await는 큐에서 기다린 시간과 장치가 처리한 시간을 합친 평균이고, aqu-sz는 평균 대기열 길이입니다. 처리량과 이 값들을 함께 읽어야 장치 특성에 맞춰 판단할 수 있습니다.

발견한 이상이 요청 지연의 원인인지

앞서 가정한 주문 API를 조사하다가 어느 한 CPU에 작업이 몰린 것을 발견했다고 해 보겠습니다. CPU는 병목 후보입니다. 이 관찰만으로 주문 API의 지연 원인까지 확정하지는 못합니다. 해당 CPU에서 어떤 스레드가 일했는지, 느린 요청이 그 작업을 기다렸는지를 더 조사합니다.

조사 중 발견한 디스크 대기나 다른 프로세스의 부하도 함께 기록합니다. 처음 발견한 이상이 현재 증상의 주원인이 아닐 수도 있기 때문입니다.

아래 그림은 자원을 확인하며 찾은 이상 징후를 추가 분석과 검증으로 이어 가는 흐름을 재구성한 예시입니다.

이 가상의 조사에서 특정 백그라운드 작업이 같은 CPU를 오래 사용했다는 단서까지 찾았다고 가정하겠습니다. 통제된 환경에서 그 작업의 동시 실행 수를 줄인 뒤, 요청 지연과 CPU 대기가 함께 줄어드는지 비교할 수 있습니다. 변화가 없다면 가설을 수정하고 다른 후보를 조사합니다.

USE가 정해 준 것은 확인할 자원과 병목 후보입니다. 어떤 자원을 증설하거나 설정을 바꿀지는 그 후보를 검증하는 후속 분석으로 결정합니다. 실제 장애 중에는 고객 영향을 줄이는 조치가 우선이며, 원인 검증을 위한 실험은 안전한 범위에서 진행해야 합니다.

운영 중에는 서비스의 증상으로 영향을 확인하고, USE로 자원 후보를 좁힌 뒤, 로그·트레이스·프로파일 등으로 실제 대기와 실행 경로를 조사할 수 있습니다. 이 흐름을 반복하며 점검표의 빈칸을 채우면 다음 장애에서 무엇부터 확인할지 더 명확해집니다.

참고 자료

• The USE Method — Brendan Gregg: 자원별 질문, 지표 해석과 후속 조사 전략
• USE Method: Linux Performance Checklist: Linux 자원과 도구를 연결한 예시. 오래된 도구·필드는 현재 환경의 매뉴얼과 대조
• The /proc Filesystem — Linux Kernel documentation: MemAvailable을 비롯한 메모리 통계의 의미
• proc_loadavg(5), iostat(1): load average와 I/O 지표를 해석하는 기준