수집 파이프라인을 프로덕션에 배포하기 전에, 전체 볼륨에서도 문제없이 작동할지 묻는 것은 합당한 일이다. 로드 테스트를 실행하려는 본능은 옳지만, 프록시 로드 테스트에는 일반적인 로드 테스트에는 없는 제약이 있다. 트래픽을 쏟아붓는 대상이 보통 다른 누군가의 소유물이라는 점이다.
이 하나의 사실이 작업 전체의 성격을 바꾼다. 여러분은 시스템이 여러분의 부하를 흡수할 수 있는지를 테스트하는 것이 아니라, 제3자를 상대로 예고 없는 스트레스 테스트를 수행하지 않으면서 여러분 자신의 파이프라인 동작을 파악하고 한계치를 찾는 것이다. 이를 제대로 하는 방법을 살펴보자.
실제로 테스트하는 대상
네 가지 질문을 분리해야 한다. 각각 다른 테스트가 필요하며, 그중 하나만 실제 대상을 필요로 한다.
여러분 자신의 파이프라인 용량. 워커, 연결 처리, 파싱, 저장소가 무언가 한계에 도달하기 전까지 얼마나 많은 동시 요청을 견딜 수 있는가. 이는 여러분의 코드와 인프라에 대한 테스트이며 다른 누군가의 사이트를 건드리지 않고 실행할 수 있다.
동시성 하에서의 프록시 경로 동작. 게이트웨이를 통해 진행 중인 요청 수를 늘릴 때 지연 시간과 성공률이 어떻게 변하는가. 이 역시 특정 대상과는 거의 무관하다.
대상의 허용 범위. 특정 사이트가 여러분을 제한하거나 도전 과제를 부과하기 전에 어느 정도의 속도까지 수용하는가. 이것이 로드 생성기가 아니라 신중하고 점진적으로 접근해야 하는 항목이다.
엔드투엔드 처리량. 위 모든 것이 함께 만들어내는 결과물이며, 여러분의 일정이 실제로 의존하는 수치다.
이들을 혼동하면 전형적인 나쁜 결과가 나온다. 특정 대상을 마구 두드리는 “로드 테스트”는 결국 차단당하고, 차단될 수 있다는 사실 외에는 아무것도 알려주지 않는다.
먼저 여러분이 소유한 대상에 테스트하라
현실적인 크기의 응답을 반환하는, 여러분이 통제하는 대상을 세워두고 프록시를 통해 파이프라인을 그곳으로 향하게 하라. 이렇게 하면 제3자를 제외한 모든 요소를 격리할 수 있다.
여기서 놀라울 정도로 많은 것을 배울 수 있다. 워커 풀이 실제로 설정한 동시성에 도달하는지. 연결 처리가 생각한 대로 동작하는지, 풀링된 연결은 게이트웨이를 통할 때 다르게 동작하기 때문이다. IP not rotating를 참고하라. 파싱이나 저장소가 어디서 병목이 되는지. 그리고 대상 자체의 변동성이 섞이지 않은 상태에서 프록시 경로가 추가하는 지연 시간 분포는 어떤지.
현실적인 페이로드 크기를 사용하라. 작은 엔드포인트를 상대로 테스트하면 처리량을 심하게 과대평가하게 되는데, 대역폭과 파싱 모두 응답 크기에 따라 확장되며 레지덴셜 지연 시간은 페이로드 크기에 따라 다르게 우세해지기 때문이다.
올바른 항목을 측정하라
처리량만으로는 부족한 요약이다. 다섯 가지 측정 항목이 로드 테스트를 해석 가능하게 만든다.
HTTP 성공이 아니라 검증된 성공률. 도전 페이지를 반환하면서도 100% 성공을 보고하는 테스트는 잘못된 것을 측정하고 있는 것이다. detecting blocked or fake content를 참고하라.
지연 시간 백분위수, 구체적으로 p50, p95, p99. 레지덴셜 지연 시간은 분포가 넓어서, 평균은 시간 제한이 있는 작업이 완료되는지를 실제로 결정하는 꼬리 부분을 가려버린다.
동시성에 따른 처리량, 한 지점에서 샘플링하는 것이 아니라 그래프로 그려야 한다. 흥미로운 특징은 곡선이 평평해지는 지점인데, 그 지점을 넘어서면 완료 건수를 늘리지 않고도 진행 중인 요청만 늘리게 된다.
오류 유형 분포, 그 비율이 무엇이 여러분을 제한하고 있는지 알려준다. 타임아웃은 한 방향을, 속도 신호는 다른 방향을, 도전 과제는 또 다른 방향을 가리킨다. common residential proxy errors를 참고하라.
요청당 바이트 수, 이는 프로덕션 볼륨에서의 비용을 결정하며 지금 측정하기는 쉽지만 나중에 알게 되면 비용이 크다. estimating monthly bandwidth를 참고하라.
점진적으로 올리고, 급증시키지 마라
동시성을 단계적으로 늘리고, 수치가 안정될 만큼 각 단계를 충분히 유지하고, 각 단계에서 전체 측정값을 기록하라. 스파이크 테스트는 여기서 거의 유용한 정보를 주지 못하는데, 그로 인해 발생하는 실패가 대상이 급격한 트래픽 폭증에 반응하는 것과 구별되지 않기 때문이다.
찾고자 하는 형태는 처리량이 동시성과 함께 더 이상 증가하지 않는 지점, 그리고 p95 지연 시간이 급격히 상승하기 시작하는 지점이다. 이 둘은 보통 일치하며 여러분의 실질적인 한계를 나타낸다. 프로덕션 작업은 그 한계 지점이 아니라 그 아래에서 실행하라. 한계는 대상의 동작, 시간대, 풀 상태에 따라 움직이기 때문이다.
for concurrency in [5, 10, 20, 40, 80]: stats = run_step(concurrency, duration_seconds=180) # hold, then record print(concurrency, stats.validated_success, stats.p50, stats.p95, stats.rps, stats.bytes_per_req, stats.error_mix) if stats.validated_success < 0.9 or stats.p95 > LATENCY_BUDGET: break # found the knee실제 대상을 상대로 신중하게 보정하기
결국 여러분의 실제 소스가 어느 정도까지 허용하는지 알아야 하며, 이는 모의 대상으로는 배울 수 없다. 로드 테스트가 아니라 보정 작업으로 접근하라.
의도한 속도보다 훨씬 낮은 수준에서 시작하여 천천히 늘리면서 상태 코드가 아니라 검증된 성공률을 관찰하라. 성능 저하의 첫 징후가 보이면 증가를 멈춰야 한다. 목표는 지속 가능한 속도를 찾는 것이며 실패 지점까지 밀어붙이는 것이 아니기 때문이다. 보정 작업은 필요하다고 느껴지는 것보다 더 긴 기간에 걸쳐 분산시켜라. 제한은 종종 이동하는 시간 윈도우에 걸쳐 적용되며, 짧은 버스트는 통과하더라도 지속적인 속도는 통과하지 못할 수 있기 때문이다.
대상이 알려주는 신호를 존중하라. 429나 Retry-After는 직접적인 지시이며, 올바른 대응은 속도를 유지하기 위해 주소를 로테이션하는 것이 아니라 속도를 줄이는 것이다. 이는 rate limiting and throttling에서 다루는 구분이다.
그리고 균형을 유지하라. 여러분의 보정 트래픽은 그 사이트의 정상적인 부하에 비해 오차 범위 수준이어야 한다. 제3자의 인프라를 의도적으로 스트레스 테스트하는 것은 무해한 엔지니어링 작업이 아니며, 규모와 의도에 따라 간섭 행위로 넘어갈 수 있다. 파트너의 한계를 정확히 알아야 한다면 직접 물어보라.
결과 해석하기
곡선을 프로덕션 설정에 필요한 두 가지 수치로 변환하라. 대상별 동시성 상한과 대상별 속도, 둘 다 여유를 두고 꼭짓점 아래로 설정한다.
그런 다음 일정과 대조하여 타당성을 점검하라. 동시성은 속도와 지연 시간에서 도출되므로, 측정된 p50 지연 시간이 가정했던 것보다 높다면, 특정 마감 시한에 필요한 동시성도 그에 맞춰 상승한다. 이는 planning request volume and concurrency에서 다루는 계산이다.
마지막으로, 결과를 유효기간이 있는 것으로 취급하라. 대상의 방어 체계는 변하고, 풀 상태는 시간대와 시장에 따라 달라지며, 조용한 주간에 측정한 수치는 성수기에는 유지되지 않을 것이다. 보정을 주기적으로 재실행하고, 더 중요하게는 동일한 측정을 프로덕션에서 지속적으로 실행하여 한계치를 가정하는 대신 관찰하라. monitoring proxy health at scale를 참고하라.
결론
프록시 로드 테스트는 용량 파악이며, 제3자에 대한 공격이 아니다. 네 가지 질문을 분리하고 처음 두 가지는 여러분이 소유한 인프라를 상대로 현실적인 페이로드 크기로 테스트하라. 이렇게 하면 대상의 변동성으로부터 여러분 파이프라인의 실제 병목을 격리할 수 있다. 검증된 성공률, 지연 시간 백분위수, 동시성 대비 처리량, 오류 유형 분포, 요청당 바이트 수를 측정하고, 단계적으로 올리며 처리량이 평평해지고 p95가 상승하는 꼭짓점을 찾아라. 실제 대상을 상대로는 천천히 보정하고 실패 지점까지 밀어붙이는 대신 첫 성능 저하 지점에서 멈추며, 로테이션이 아니라 속도를 줄이는 방식으로 속도 신호를 존중하라. 프로덕션 상한선을 꼭짓점 아래로 설정하고, 측정된 지연 시간으로부터 동시성을 다시 도출하고, 한계가 움직이기 때문에 프로덕션에서 계속 측정하라.
테스트 대상 경로는 레지덴셜 프록시이며, 동시성과 지역은 요금제 설정이 아니라 요청별 매개변수이고, GB당 과금되므로 잘 설계된 로드 테스트는 그 대역폭이 소비하는 만큼의 비용만 든다.