시스템 성능 엔지니어링 1장: 관측·실험·USE 방법론으로 읽기

브렌던 그렉의 《Systems Performance》 1장은 성능을 “느린 시스템을 빠르게 만드는 일”보다 넓게 정의한다. 데이터가 지나가는 전체 경로를 이해하고, 관측과 실험을 구분하며, 근거를 따라 병목을 좁혀 가는 일이 시스템 성능 엔지니어링이다.

처음 이 장을 정리할 때는 용어와 도구를 빠짐없이 옮기는 데 집중했다. 다시 읽어 보니 1장의 핵심은 도구 목록이 아니라 어디서부터 어떤 관점으로 볼 것인가에 있었다. 이후 장을 읽을 때 기준으로 삼을 질문만 남기는 쪽으로 노트를 다시 정리했다.

시스템 성능은 전체 데이터 경로의 문제다

성능 문제의 원인은 애플리케이션 코드에만 있지 않다. 요청 하나가 지나가는 경로에는 런타임, 시스템 라이브러리, 커널, CPU, 메모리, 저장 장치와 네트워크가 있다. 분산 시스템이라면 다른 서비스와 데이터베이스까지 이어진다.

그래서 가장 먼저 할 일은 대상 시스템의 데이터 경로를 그리는 것이다.

사용자 요청
  → 애플리케이션
    → 런타임·라이브러리
      → 시스템 콜·커널
        → CPU·메모리·디스크·네트워크
          → 다른 서비스·저장소

이 그림이 없으면 익숙한 계층만 튜닝하기 쉽다. 반대로 흐름을 알고 있으면 “지연이 어느 경계에서 생겼는가”라는 질문으로 바뀐다.

성능 분석의 두 가지 출발점

같은 시스템도 워크로드와 리소스 가운데 어디에서 출발하느냐에 따라 보이는 것이 달라진다.

관점	먼저 묻는 질문	예시
워크로드 관점	누가, 왜, 어떤 요청을 얼마나 보내는가?	요청률, 지연시간, 오류, 호출 경로
리소스 관점	어떤 자원이 바쁘고 기다리며 실패하는가?	CPU 사용률·런큐, 디스크 지연, 네트워크 오류

워크로드 관점은 사용자에게 드러나는 현상에서 아래 계층으로 내려간다. 리소스 관점은 CPU·메모리·디스크·네트워크 상태에서 위로 올라간다. 둘 중 하나만 고집하기보다, 먼저 발견한 단서를 반대편 관점에서 확인해야 한다.

관측과 실험을 구분한다

성능 도구는 크게 관측 도구와 실험 도구로 나눌 수 있다.

• 관측은 현재 시스템을 가능한 한 적게 건드리며 상태를 이해한다. 카운터, 프로파일링, 트레이싱이 여기에 속한다.
• 실험은 의도적으로 부하나 조건을 바꾸고 결과를 측정한다. 마이크로·매크로 벤치마크가 대표적이다.

프로덕션에서 원인을 찾을 때는 대개 관측부터 시작하는 편이 안전하다. 벤치마크는 시스템 상태를 바꾸므로 격리된 환경과 명확한 가설이 필요하다. 그렇다고 실험을 피할 이유는 없다. 관측으로 세운 가설을 재현 가능한 실험으로 검증할 때 분석이 완성된다.

카운터·프로파일링·트레이싱은 무엇이 다른가

방법	잘 답하는 질문	한계
카운터	얼마나 많이, 얼마나 자주 일어났는가?	원인이 된 코드 경로는 부족할 수 있다.
프로파일링	시간이나 자원을 어디에서 쓰는가?	낮은 빈도의 개별 사건을 놓칠 수 있다.
트레이싱	특정 사건이 어떤 순서와 지연으로 이어졌는가?	수집량과 오버헤드를 통제해야 한다.

플레임 그래프는 프로파일링 결과에서 스택별 사용 비중을 읽기 좋게 만든다. eBPF, BCC, bpftrace는 커널과 사용자 공간의 이벤트를 관측하는 강력한 수단이지만, 도구를 먼저 정하기보다 답할 질문을 먼저 적는 편이 낫다.

방법론이 도구보다 먼저다

성능 분석에서 가장 위험한 습관은 근거 없이 설정을 하나씩 바꾸는 것이다. 방법론은 확인할 범위를 빠뜨리지 않게 하고, 관찰 결과가 다음 행동을 결정하게 한다.

대표적인 USE 방법론은 각 리소스에서 세 가지를 확인한다.

1. Utilization: 자원이 일하느라 바쁜 비율
2. Saturation: 처리하지 못한 일이 기다리는 정도
3. Errors: 오류 사건과 실패 횟수

예를 들어 CPU는 사용률만 100%인지 보는 것으로 끝나지 않는다. 런 큐에서 일이 기다리는지, 하드웨어·커널 오류가 있는지를 함께 봐야 한다. USE는 모든 문제를 해결하는 공식이 아니라, 시스템성 병목과 오류를 빠르게 훑는 체크리스트에 가깝다. RED와 USE를 어떤 상황에 적용하는지도 따로 비교해 두었다.

Linux 성능 분석의 첫 60초

브렌던 그렉의 60초 체크리스트는 원인을 확정하는 절차가 아니라 다음 조사 방향을 찾는 초기 탐색이다.

순서	명령	먼저 볼 것
1	uptime	load average의 크기와 추세
2	dmesg -T | tail	OOM, 장치와 커널 오류
3	vmstat 1	실행 큐, 스왑, CPU 상태 변화
4	mpstat -P ALL 1	코어별 CPU 불균형
5	pidstat 1	CPU를 쓰는 프로세스
6	iostat -xz 1	디스크 처리량과 지연
7	free -m	메모리와 캐시 여유
8	sar -n DEV 1	인터페이스별 네트워크 I/O
9	sar -n TCP,ETCP 1	TCP 연결과 재전송
10	top	앞선 단서를 전체 화면에서 재확인

명령을 실행했다는 사실보다 무엇을 발견했고 무엇을 발견하지 못했는지가 중요하다. CPU 쪽 단서가 선명하다면 프로파일링으로, TCP 재전송이 보인다면 네트워크 경로로 내려간다. 메모리 항목은 Linux free와 캐시 메모리 읽는 법에 자세히 정리했다.

1장을 읽고 남긴 기준

• 성능 목표를 지연시간, 처리량, 비용처럼 측정 가능한 말로 바꾼다.
• 데이터 경로를 그린 뒤 워크로드와 리소스 양쪽에서 본다.
• 프로덕션에서는 관측부터 시작하고, 실험은 가설과 격리 조건을 갖춘다.
• 하나의 지표나 도구로 결론을 내리지 않는다.
• 발견한 단서가 다음 측정과 도구 선택을 결정하게 한다.

1장은 정답보다 조사 순서를 준다. 이 기준을 갖고 나니 top, vmstat, eBPF 같은 도구도 명령 모음이 아니라 질문에 답하기 위한 수단으로 보이기 시작했다.

참고 자료

• Brendan Gregg: Systems Performance 2nd Edition 공식 페이지
• Brendan Gregg: Linux Performance Analysis in 60 Seconds
• Brendan Gregg: USE Method