시스템 성능 분석 입문 독서노트: 도구보다 질문과 정량화

브렌든 그레그의 《시스템 성능 분석과 최적화》 초반부를 읽으며 표시해 둔 내용을 다시 정리했다. 원래 글은 페이지별 문장을 옮겨 적는 데 그쳤다. 이번에는 인용 대신, 성능 문제를 만났을 때 실제로 던질 질문의 순서로 바꿨다.

독서 대상: 『시스템 성능 분석과 최적화』

1. 먼저 데이터 경로를 그린다

복잡한 시스템에서 곧바로 CPU나 메모리 명령부터 실행하면 보고 싶은 지표만 보게 되기 쉽다. 먼저 요청이 지나가는 구성 요소와 대기열을 그리면 빠진 영역을 확인할 수 있다.

사용자 요청
  → 로드밸런서
  → 애플리케이션
  → 캐시·데이터베이스
  → 스토리지·네트워크

실제 환경에서는 비동기 큐, 외부 API, 커널과 하드웨어까지 더해진다. 중요한 것은 완벽한 그림보다 관찰 가능한 지점과 아직 보이지 않는 지점을 구분하는 것이다.

2. ‘느리다’를 목표와 비교할 수 있는 값으로 바꾼다

지표만 보고 좋고 나쁨을 판단할 수는 없다. 같은 300ms도 배치 작업에는 충분할 수 있고, 사용자가 반복해서 기다리는 화면에는 길 수 있다.

• 누구의 지연 시간을 재는가?
• 평균이 아니라 p95·p99가 중요한가?
• 처리량, 오류율, 비용 중 무엇을 함께 지켜야 하는가?
• 정상 기준선과 목표 값은 무엇인가?

주관적인 기대를 없애는 것이 아니라, 서비스 수준 목표와 사용자 경험 지표로 비교할 수 있게 만드는 일에 가깝다.

3. 문제의 존재보다 크기를 정량화한다

성능 분석의 결과가 “디스크가 조금 느리다”에서 끝나면 우선순위를 정하기 어렵다. 병목 후보마다 영향 범위를 숫자로 좁혀야 한다.

예를 들면 다음처럼 질문할 수 있다.

1. 전체 요청 중 영향을 받는 비율은 얼마인가?
2. 해당 대기 시간이 전체 지연에서 차지하는 비중은 얼마인가?
3. 병목을 없앴다고 가정했을 때 얻을 수 있는 최대 개선 폭은 얼마인가?
4. 개선에 드는 개발·운영 비용은 얼마인가?

이 과정은 가장 눈에 띄는 지표가 아니라 가장 큰 효과를 낼 수 있는 문제를 고르는 데 필요하다.

4. 통계와 동적 추적의 역할을 구분한다

운영체제 통계는 커널이 미리 정해 둔 관찰 지점을 낮은 비용으로 보여준다. CPU 사용률, 런 큐, 페이지 폴트, I/O 지연 같은 지표가 여기에 해당한다. 반복 측정과 기준선 비교에 적합하다.

동적 추적은 미리 준비되지 않은 질문을 더 구체적으로 조사할 때 유용하다. 대신 수집 비용, 이벤트 양과 관찰 자체가 시스템에 주는 영향을 확인해야 한다. “더 자세한 도구”가 언제나 첫 도구는 아니다.

관련 분석 방법은 RED와 USE 패턴 비교에서 이어서 정리했다.

5. 기준선은 시간이 지나면 달라진다

성능 특성은 고정되어 있지 않다. 사용자 수, 데이터 크기, 하드웨어, 커널, 런타임과 애플리케이션 버전이 바뀌면 정상 범위도 이동한다.

그래서 한 번의 측정보다 같은 조건으로 반복할 수 있는 기록이 중요하다.

• 워크로드와 입력 데이터
• 소프트웨어·커널·펌웨어 버전
• 인스턴스나 하드웨어 사양
• 측정 시간대와 지속 시간
• 평균뿐 아니라 분포와 이상치
• 변경 전후의 동일한 비교 조건

첫 분석을 위한 체크리스트

1. 사용자가 겪는 증상과 시간을 구체적으로 적는다.
2. 요청·데이터 경로와 각 경계의 책임을 그린다.
3. 목표와 정상 기준선을 정한다.
4. 넓은 범위의 저비용 지표로 병목 후보를 좁힌다.
5. 후보별 영향을 정량화한다.
6. 필요한 곳에만 프로파일링이나 동적 추적을 적용한다.
7. 한 번에 한 가지를 바꾸고 같은 조건에서 다시 잰다.

초반부를 다시 읽고 남은 결론은 “도구를 많이 아는 것”보다 “무엇을 왜 재는지 설명할 수 있는가”가 먼저라는 점이다. 다음 독서노트에서는 CPU·메모리·스토리지처럼 자원별 방법론을 이 질문 순서에 연결해 볼 생각이다.

더 읽을 자료

• Brendan Gregg: Systems Performance 2nd Edition