부하 도구가 응답을 기다린 뒤 다음 요청을 보내니 장애 중 지연이 낮게 나옵니다. coordinated omission은 무엇인가요?

서버가 느려질 때 부하 생성기 자체가 새 요청을 줄이면 실제로 도착했을 요청의 대기를 측정하지 못할 수 있습니다. 이를 coordinated omission 문제로 설명하며 도착 모델과 측정 시작점을 확인해야 합니다.

동작 원리와 전제

폐쇄 루프의 고정 동시 사용자 모델은 응답이 늦으면 처리율이 줄어드는 것이 자연스럽습니다. 하지만 실제 외부 도착률이 유지되는 서비스 용량을 평가하려면 개방 루프나 예정 도착 시각을 고려한 측정이 필요합니다.

선택과 실패 처리

생성기가 목표 요청률을 못 내는 경우와 서버가 포화된 경우를 분리합니다. 보정 histogram이 있어도 운영 패턴을 임의로 만들지는 못하므로 어떤 가정을 썼는지 기록합니다. think time·연결·retry도 실제 모델에 맞춥니다.

구체적인 사례와 검증

동시 사용자 한 명이 요청 완료를 기다리는 도구에서 서버가 10초 멈추면 그동안 새 요청이 생성되지 않습니다. 실제 서비스에 초당 100건이 계속 들어오는 상황이라면 그 천 건의 대기가 빠진 셈이 될 수 있습니다. 어느 모델이 운영을 대표하는지 먼저 정합니다. open-loop에서도 생성기 CPU·네트워크가 목표율을 못 내면 발행 지연이 생겨 서버 지연과 구분해야 합니다. 예정 발행과 실제 발행 시각을 기록하면 이 차이를 볼 수 있습니다. 부하 테스트의 좋은 숫자보다 어떤 요청을 언제부터 언제까지 측정했는지 명확한 실험이 중요합니다.

일시 정지·지속 과부하·부하 종료 회복에서 예정·실제 발행·완료 시각을 비교합니다. 성공 응답만의 지연과 timeout·거절도 함께 봅니다. 낮은 p99가 정말 사용자 지연 개선인지 부하가 사라진 결과인지 검증하겠습니다.