시험의 목표 수치는 어디서 나오는가

목표

4주치 시간별 트래픽 자료에서 일 총량 · 피크 시간대 · 안전 계수 · 장애 여유 · 성장률을 차례로 적용해 부하 시험의 목표 RPS 를 유도하고, 그 목표를 실제로 걸어 이 환경에서 만들어지는지까지 확인합니다.

왜 중요한가

부하 시험 계획서에서 가장 자주 비어 있는 칸은 목표 RPS 의 출처다. '초당 1,000건' 이 어디서 나왔는지 물으면 대개 답이 없고, 그러면 시험을 통과해도 무엇을 보장한 것인지 말할 수 없다. 목표는 운영 자료에서 끌어내야 한다. 하루 총량을 86400 으로 나눈 평균은 거의 언제나 실제 피크보다 몇 배 작고, 그 평균으로 용량을 잡으면 정확히 그 배수만큼 모자란다. 거기에 피크에도 용량을 다 쓰지 않기 위한 헤드룸, 구역 하나가 빠져도 견디기 위한 여유, 다음 계획 주기까지의 성장률이 차례로 곱해진다. 마지막으로 그렇게 정한 목표가 실제로 걸리는지를 한 번 확인해야 한다 — 걸지 못한 부하로 얻은 통과는 통과가 아니다.

단계

1. /opt/lab/lt/lt-capacity-target/traffic.tsv 는 4주치 시간별 요청 수입니다(머리글 한 줄 뒤 날짜 시각 요청수). 날짜별 합계를 /root/lt-capacity-target/daily.tsv 에 탭으로 나눈 두 칸 <날짜> <하루 총 요청 수> 로 28줄 적고, /root/lt-capacity-target/01-peak-day.txt 에 두 줄 peak_date= 과 peak_total= 을 적으세요. 가장 바빴던 하루입니다.
2. 가장 바빴던 날의 24시간 중 가장 바쁜 한 시간을 찾아 /root/lt-capacity-target/02-peak-hour.txt 에 세 줄 peak_hour= (0..23 정수) · peak_hour_requests= (그 한 시간의 요청 수) · peak_share= (그 한 시간이 그날 총량에서 차지하는 비율, 소수 넷째 자리까지)를 적으세요.
3. /root/lt-capacity-target/03-rps.txt 에 세 줄을 적으세요. avg_rps= 는 가장 바빴던 날의 총량을 86400 으로 나눈 값, peak_rps= 는 가장 바쁜 한 시간의 요청 수를 3600 으로 나눈 값(둘 다 소수 둘째 자리까지), peak_over_avg= 는 둘의 비(소수 둘째 자리까지)입니다.
4. 운영 여유(헤드룸)를 30% 로 잡습니다 — 피크에도 용량의 70% 만 쓰겠다는 뜻입니다. /root/lt-capacity-target/04-headroom.txt 에 두 줄 headroom=0.30 과 rps_after_headroom= 을 적으세요. 뒤 값은 peak_rps ÷ (1 − headroom) 을 소수 둘째 자리까지 적습니다.
5. 서비스는 4개 구역에 고르게 놓여 있고, 한 구역이 통째로 빠져도 피크를 받아야 합니다. /root/lt-capacity-target/05-nplus1.txt 에 세 줄 nodes=4 · surviving=3 · rps_after_nplus1= 을 적으세요. 뒤 값은 rps_after_headroom × nodes ÷ surviving 을 소수 둘째 자리까지 적습니다.
6. 트래픽이 월 8% 씩 늘고 있고 이 용량으로 6개월을 버텨야 합니다. /root/lt-capacity-target/06-growth.txt 에 네 줄 monthly_growth=0.08 · months=6 · growth_factor= (1.08 의 6제곱, 소수 넷째 자리까지) · rps_after_growth= (rps_after_nplus1 × growth_factor, 소수 둘째 자리까지)를 적으세요.
7. /root/lt-capacity-target/target.tsv 를 만드세요. 머리글 없이 다섯 줄이고 각 줄은 탭으로 나눈 두 칸 <단계> <RPS> 입니다. 단계 이름은 순서대로 peak · headroom · nplus1 · growth · target 이고 앞 네 줄은 앞 단계에서 적은 값을, 마지막 target 줄은 rps_after_growth 를 올림한 정수를 적습니다. 그리고 /root/lt-capacity-target/07-note.txt 에 두 줄 test_target_rps= (그 정수)과 reason= (이 목표가 어디서 나왔는지 60자 이상)을 적으세요.
8. /opt/lab/lt/lt-capacity-target/echo.py 를 포트 8095 에 띄우고, 7단계에서 정한 목표를 실제로 걸어 보세요. 워커는 20개, 워커당 비율 상한은 올림(목표 ÷ 20), 요청 수는 목표 × 5 로 하고 원본 CSV 를 /root/lt-capacity-target/run.csv 에 남깁니다. 그다음 /root/lt-capacity-target/08-run.txt 에 다섯 줄 target_rps= · workers=20 · q_per_worker= · measured_rps= (run.csv 에서 다시 계산한 값, 소수 둘째 자리) · reached= (measured 가 목표의 90% 이상이면 yes, 아니면 no)와 50자 이상의 note= 를 적으세요.

참고

• 작업 디렉터리는 /root/lt-capacity-target 입니다. 없으면 먼저 만드세요.
• 자료와 부하 대상은 /opt/lab/lt/lt-capacity-target/ 에 있습니다 — traffic.tsv(4주 × 24시간), 그 자료를 만든 gen_traffic.py(시드 고정), 그리고 8단계에서 쓸 echo.py 입니다.
• 반올림 약속: 비율은 소수 넷째 자리, RPS 는 소수 둘째 자리, 마지막 목표만 올림한 정수입니다. 채점기는 자료에서 같은 계산을 다시 해서 맞춰 봅니다.
• 흔한 실수: 헤드룸을 곱하기로 적용하는 것. 30% 여유는 × 0.7 이 아니라 ÷ 0.7 입니다.
• 흔한 실수: 성장률을 단리로 계산하는 것. 월 8% 로 6개월이면 1.48 이 아니라 1.08 의 6제곱입니다.
• [Google SRE Workbook — Managing Load](https://sre.google/workbook/managing-load/) · [SRE Book — Software Engineering in SRE (수요 예측)](https://sre.google/sre-book/software-engineering-in-sre/) · [hey — 옵션 -n · -c · -q 의 정의](https://github.com/rakyll/hey) · [k6 — scenarios 와 도착률](https://grafana.com/docs/k6/latest/using-k6/scenarios/) · [USE Method](https://www.brendangregg.com/usemethod.html)

단계 8개

1. 먼저 하루 총량을 센다
2. 그 하루 안에서 언제가 가장 바빴나
3. 평균으로 나눈 값은 몇 배나 모자라나
4. 여유를 남기고 목표를 올린다
5. 한 구역이 빠져도 견디게 한다
6. 반년 뒤에도 쓸 수 있는 목표인가
7. 목표가 어디서 나왔는지 한 파일에 남긴다
8. 그 목표가 이 환경에서 걸리기는 하는가