느린 이유를 숫자로 설명하는 성능 엔지니어링

부하 모델·p95·용량·비용을 출시 기준으로 연결하기

workload와 latency budget을 세우고 k6, OpenTelemetry, DB plan, 용량·비용으로 병목을 판정한다.

상태: 출간 후보 웹교정쇄 · 자동 QA 통과 · 성능·SRE·DBA 현장 감수 대기 · 36개 장

성능은 “빠르게 최적화”하는 감각이 아니다. 사용자 여정을 측정 가능한 목표로 만들고, 실제와 닮은 부하에서 병목을 증거로 좁히며, 용량·비용·신뢰성의 균형을 결정하는 일이다. FieldPass의 예약 피크를 k6·OpenTelemetry·DB plan·profile로 추적한다. 예제 숫자는 fixture이며 실제 SLA를 보장하지 않는다.

목차

1. 1장. 빠르다는 말을 사용자 SLI로 바꾼다
2. 2장. 종단 지연 예산을 분해한다
3. 3장. Workload model이 load tool보다 먼저다
4. 4장. 기초선은 재현 가능한 환경 설명이다
5. 5장. k6 threshold로 통과·실패를 코드화한다
6. 6장. Smoke·load·stress·spike·soak를 구분한다
7. 7장. RED·USE와 업무 지표를 함께 본다
8. 8장. OpenTelemetry trace로 critical path를 찾는다
9. 9장. Profile은 어느 코드가 자원을 쓰는지 답한다
10. 10장. Queueing이 tail latency를 만드는 순간
11. 11장. Connection pool을 동시성 제한으로 본다
12. 12장. Query plan을 대표 데이터로 읽는다
13. 13장. Cache hit ratio 하나로 성공을 선언하지 않는다
14. 14장. Runtime과 GC를 증거로 조정한다
15. 15장. 비동기화가 latency를 없애지는 않는다
16. 16장. 성능과 비용을 한 단위로 비교한다
17. 17장. 용량 계획을 예측 범위로 만든다
18. 18장. Overload 때 graceful degradation을 설계한다
19. 19장. 성능 회귀를 릴리스 gate로 만든다
20. 20장. 8주 성능·용량 캡스톤
21. 21장. Workload 발견 워크숍
22. 22장. k6 시나리오 리뷰
23. 23장. Trace에서 병목을 좁히는 실습
24. 24장. Database 병목 실험표
25. 25장. Soak test에서 누수를 찾는다
26. 26장. Overload 게임데이
27. 27장. 분기 용량 리뷰 문서
28. 28장. 최종 성능 판정 회의
29. 29장. 성능 Incident 15분 분류
30. 30장. Browser 성능 예산
31. 31장. Telemetry 비용과 Sampling
32. 32장. 90분 성능 설계 시험
33. 33장. AI 성능 분석의 검증
34. 34장. 성능 개선 보고서
35. 35장. 안전한 부하 실습 환경
36. 36장. 실제 API Baseline을 고정한다