폴의 최근 블로그 글 "사전 생산 테스트가 효과적인가?"에 대해 좀 더 자세히 설명하고자 합니다. 폴은 CPU 사용률과 코드 경로에 대해 다루었지만, 많은 애플리케이션에서 또 다른 매우 중요한 측면이 있습니다. 바로 네트워크 사용률입니다. 많은 애플리케이션은 지연 시간이 1밀리초 미만이고 대역폭이 최소 100Mbps인 LAN 환경에서 테스트됩니다. 그런 다음 대역폭이 더 작고 지연 시간이 훨씬 더 긴 WAN을 통해 사용되도록 배포됩니다. 그 결과는 재앙이 될 수 있습니다.
LAN 환경에서 테스트하면 대부분의 네트워크 관련 버그를 발견할 수 있지만, 패킷 손실이나 예상치 못한 세그멘테이션(TCP는 메시지 경계를 유지하지 않음)과 관련된 버그는 LAN 환경에서는 발견하기 어려울 수 있습니다. 또한 고속 LAN 환경에서는 느린 WAN 환경에 비해 비효율적인 설계 문제를 발견하기가 훨씬 어렵습니다. 따라서 네트워크 기반 애플리케이션은 예상되는 최악의 네트워크 환경(저대역폭, 높은 지연 시간, 패킷 손실률 포함)에서 반드시 테스트해야 합니다.
이를 수행하는 방법은 두 가지가 있습니다.
첫 번째는 실제 환경을 활용하는 것입니다. 서버(또는 클라이언트)를 네트워크 내 호스트에 배치하여 작동 방식을 확인합니다. 이는 실제 인프라를 활용할 수 있다는 장점이 있습니다. 단점은 환경을 통제할 수 없다는 점으로, 문제를 재현하거나 버그 수정을 테스트할 때 매우 중요한 요소입니다.
두 번째 방법은 WAN 시뮬레이터를 사용하는 것입니다. 하드웨어 기반과 소프트웨어 전용, 상용 및 오픈소스(무료) 시뮬레이터가 존재합니다. 여기서 장점은 지연 시간, 패킷 손실률 및 기타 네트워크 매개변수를 완전히 제어할 수 있으며, 다른 그룹의 협조(즉, 타인의 시스템에 소프트웨어를 설치하는 것)가 필요 없다는 점입니다. 단점은 비용과 학습 곡선입니다. 무료 소프트웨어를 사용하더라도 이를 실행할 시스템(일반적으로 유닉스 계열)을 제공하고 사용법을 익혀야 합니다. 몇 년 전 저는 Dummynet에 대한 튜토리얼을 작성한 적이 있습니다. 당시에는 사용 가능한 무료 시뮬레이터가 거의 없었습니다. 지금은 훨씬 더 많으니, "WAN 시뮬레이터"로 검색해 보세요.
성능 및 애플리케이션 장애 문제를 분석해온 경험을 바탕으로 볼 때, 이러한 테스트는 버그로 인한 생산 중단 시간 감소와 애플리케이션 및 사용자 성능 향상으로 인해 투자 대비 효과를 충분히 발휘할 것이라고 믿습니다.