성능 최적화 면접 퀴즈

성능 측정과 병목 분석

핵심 지표

병목 찾기 순서

1. 모니터링: 어떤 API가 느린지 확인
2. DB 쿼리 분석: slow query log, EXPLAIN
3. 애플리케이션 프로파일링: CPU, 메모리, 스레드
4. 인프라: 네트워크, 디스크 I/O

실무 포인트

• 평균보다 p99가 더 중요 (사용자 경험에 직접 영향)
• 대부분의 병목은 DB 쿼리 → EXPLAIN 먼저 확인
• 추측하지 말고 측정부터 시작

지연 시간과 처리량

백분위의 의미

평균이 위험한 이유

응답시간(ms) 10건
50 50 50 50 50 50 50 50 50 4000

평균 445  <- 아무도 겪지 않은 값
p50   50
p90 4000  <- 실제 불만이 나오는 값

실무 포인트

• 한 화면이 내부 API 10개를 부르면 그중 하나가 꼬리 지연에 걸릴 확률이 커진다. 팬아웃이 클수록 p99가 체감을 지배한다
• 처리량과 지연은 독립이 아니다. 동시성은 대략 처리량 곱하기 평균 지연이므로, 지연이 2배면 같은 처리량에 커넥션과 스레드가 2배 필요하다
• 자원이 포화에 가까워지면 지연은 선형이 아니라 급격히 튄다. 여유를 남긴다
• 백분위는 평균할 수 없다. 서버별 p99를 평균 내지 말고 원본 분포에서 계산한다

관측성 3요소

신호별 역할

조사 순서

메트릭 이상 감지 -> 트레이스로 느린 구간 특정 -> 로그로 원인 확인

골든 시그널

• 지연(Latency), 트래픽(Traffic), 오류(Errors), 포화도(Saturation)
• 넷 중 둘만 본다면 지연과 오류. 사용자가 가장 먼저 느끼는 신호다

실무 포인트

• 로그에 요청 식별자(trace id)를 넣는다. 없으면 트레이스와 로그를 이을 수 없어 조사 시간이 몇 배가 된다
• 성공 로그는 표본만, 실패 로그는 전량. 로그 비용은 트래픽에 비례해 커진다
• 메트릭 라벨에 사용자 ID처럼 값의 종류가 많은 항목을 넣지 않는다. 시계열 수가 폭발한다
• 알림은 원인이 아니라 사용자 영향(증상)에 건다. 원인 기반 알림은 오탐이 많다