부하 테스트의 TPS와 지연 결과가 운영 성능을 예측하려면 요청·데이터·캐시·부하 생성 조건을 무엇까지 맞춰야 하나요?

운영을 예측하는 부하 테스트는 TPS만 맞추는 시험이 아닙니다. 요청 종류와 읽기·쓰기 비율, payload 크기, 사용자·키 인기 분포, 도착 패턴, 데이터베이스 크기와 인덱스 상태, 캐시 적중률이 달라지면 같은 TPS에서도 CPU·메모리·저장 장치와 꼬리 지연이 크게 달라집니다. 같은 인기 키만 반복하면 캐시가 과도하게 적중해 원본 저장소 부하를 숨길 수 있습니다. 따라서 테스트가 운영의 어떤 조건을 재현하고 어떤 조건을 의도적으로 제외했는지 명시해야 합니다. 이 방법이 운영을 닮은 부하 모델링입니다.

도착 모델과 캐시 상태를 맞춥니다

steady state, 단계적 증가, burst, 배포·재시작 직후의 cold cache, 캐시 장애와 회복을 분리합니다. closed-loop는 응답을 받은 뒤 다음 요청을 보내므로 서버가 느려지면 생성률도 낮아져 적체를 숨길 수 있습니다. open-loop는 목표 도착률을 유지해 큐가 어떻게 쌓이는지 볼 수 있지만 생성기가 감당할 수 있는지 확인해야 합니다. 부하 생성기 CPU·네트워크가 먼저 포화되면 발송률이 목표보다 낮아지므로 generator metrics와 서버 수신률을 함께 기록합니다.

실제 데이터 크기와 분포, 인덱스·통계·파티션 상태, 연결 풀·캐시·외부 API 한도를 운영과 맞추고, 개인정보는 제거합니다. 결제·쓰기·알림 같은 부수 효과는 가짜 저장소나 격리된 계정으로 대체해야 재실행할 수 있습니다. p50 하나가 아니라 p95·p99, 오류율, 큐·풀 대기, oldest request age, 회복 시간과 비용을 봅니다. 최고 순간 TPS보다 SLO를 지키면서 지속할 수 있는 처리율이 용량 기준입니다.

회복과 재현성을 포함합니다

장시간 일정 부하를 유지하는 soak test로 누적 누수와 성능 저하를 확인하고, 별도의 부하 종료 후 회복 구간에서 연결·고루틴·메모리·큐·파일 디스크립터가 정상 범위로 돌아오는지 봅니다. 데이터 시드, 캐시 예열 순서, 부하 생성기 수, 서버 설정, 외부 stub와 버전을 함께 저장해 같은 실험을 재현합니다. 개선 후에는 요청 분포·캐시 상태·도착 모델이 바뀌지 않은 대조군과 비교하고, 결과가 좋아도 생성기 병목이나 데이터 규모 축소 때문인지 확인하겠습니다.

운영 의존성을 즉시 성공하는 stub으로 바꾸면 timeout·재시도·connection pool 대기를 검증할 수 없습니다. 외부 API의 응답 크기·지연 tail·rate limit·실패율을 안전한 stub에 반영하되, 결제·알림 같은 부수 효과는 가상 계정과 격리 저장소로 치환하겠습니다. CPU 세대, 디스크, TLS·keep-alive, 네트워크 지연, 관측 에이전트도 결과와 함께 기록해야 테스트 환경의 차이를 설명할 수 있습니다.

closed-loop는 응답이 느려지면 발송률도 떨어져 적체를 숨길 수 있고, open-loop는 목표 도착률을 유지하지만 generator가 그 속도를 지속할 수 있는지 확인해야 합니다. 동시 연결·think time·키 인기 분포·cold cache와 warm cache를 나누고, p95·p99·오류율·큐 대기·회복 시간과 비용을 SLO 기준으로 비교하겠습니다.

테스트가 운영을 닮았는지는 서버가 받은 실제 도착률로 확인합니다. 생성기가 목표 TPS를 보내지 못했거나 closed-loop가 서버 지연 때문에 스스로 느려졌다면 결과는 대상의 용량이 아닙니다. 생성기 CPU·네트워크, 서버 수신률, 의존성 지연과 캐시 상태를 함께 기록해 해석 범위를 명시하겠습니다.

동시 연결 수, keep-alive, TLS·압축, 사용자 think time도 운영의 비용을 바꿉니다. 운영보다 빠른 DB·즉시 성공하는 외부 stub을 쓰면 timeout과 재시도 병목이 사라지고, 반대로 단일 느린 장비를 쓰면 다른 병목을 만들 수 있습니다. 환경 차이와 보정 범위를 기록한 뒤 SLO를 지키는 지속 처리율을 용량으로 삼겠습니다.