성능 최적화 면접 퀴즈

성능 측정과 병목 분석

핵심 지표

병목 찾기 순서

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

재기 전에 고치면 대개 틀린다

성능 문제는 짐작이 잘 안 맞습니다. 코드를 읽고 느릴 것 같은 곳을 고치면, 그 구간이 전체의 몇 퍼센트였는지 모르고 고친 것이 됩니다.

기다리는 시간과 일하는 시간을 나눠 재는 것이 첫 걸음입니다. CPU 사용률이 낮은데 느리면 어딘가를 기다리는 것이고, 그것은 서버를 늘려도 줄지 않습니다.

무엇을 재나

호출 횟수가 특히 값싼 발견을 줍니다. 한 번에 20ms 인 질의가 화면 하나에서 50번 돌면 1초입니다. 그 질의를 빠르게 하는 것보다 횟수를 줄이는 것이 훨씬 크게 듣습니다.

실무 포인트

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

지연 시간과 처리량

백분위의 의미

평균이 위험한 이유

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

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

둘은 같이 좋아지지 않는다

처리량을 올리려고 한 번에 많이 묶으면 각 요청의 지연이 늘어납니다. 지연을 줄이려고 바로바로 보내면 묶는 이득이 사라집니다.

셋째만 둘을 함께 좋게 합니다. 그런데 한계까지만 그렇습니다. 그 뒤로는 일꾼을 늘려도 처리량이 안 오르고 대기만 늘어납니다.

목표를 어떻게 적나

"빠르게" 는 목표가 아닙니다. 세 가지가 함께 있어야 확인할 수 있는 목표가 됩니다.

어느 지점에서 재나: 사용자 화면인가 서버 안인가
어느 백분위인가: 상위 1퍼센트인가 절반인가
어느 부하에서인가: 초당 100인가 1만인가

부하가 빠진 목표가 가장 흔합니다. 한가할 때 50ms 인 것은 아무 약속이 아닙니다.

실무 포인트

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

관측성 3요소

신호별 역할

조사 순서

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

골든 시그널

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

무엇을 남기지 않을지도 정한다

셋을 다 남기면 비용이 서비스 비용을 넘길 수 있습니다. 그래서 무엇을 버릴지를 함께 정합니다.

첫째가 가장 잘 터집니다. 이름표에 값의 종류가 많은 것을 넣으면 조합이 곱해져 지표 수가 폭발합니다. 사용자 번호나 주소를 이름표로 쓰면 그렇게 됩니다.

사고 때 실제로 보는 순서

평소에 만들어 두지 않으면 사고 때 쓸 수 없습니다.

지금 나쁜지: 요청 수, 실패율, 지연 상위 백분위
어디가 나쁜지: 구간별 시간
그 자리에서 무슨 일인지: 그 요청 번호의 로그

셋을 잇는 것이 요청 번호입니다. 그것이 로그에 없으면 로그를 뒤지며 짐작하게 됩니다.

실무 포인트

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