OpenResty FAQ | 테스트를 위한 네트워크 구조, SSL 관련 기능, DSL, `ab` 도구
API7.ai
December 1, 2022
OpenResty 시리즈가 지금까지 업데이트되었으며, 테스트 부분에 대한 학습을 마쳤습니다. 뒤처지지 않고 적극적으로 학습하고 실습하며 열정적으로 생각을 남겨주신 것을 축하드립니다.
댓글에서 제기된 많은 질문들이 가치 있으며, 그 중 더 전형적이고 흥미로운 질문들을 오늘의 Q&A로 특별히 추렸습니다.
오늘은 이 다섯 가지 질문을 살펴보겠습니다.
질문 1: 테스트를 위한 네트워크 구조를 어떻게 구축할까요?
Q: wrk를 실행하는 클라이언트를 외부 네트워크의 머신에 배치해야 할까요, 아니면 서버와 같은 LAN에 있는 머신에 배치해야 할까요? 이 두 가지 중 어떤 것이 성능 테스트에 더 의미가 있을까요?
A: 웹 관련 서비스를 테스트할 때 적절한 테스트 도구를 선택하는 것은 좋은 시작일 뿐이며, 테스트를 위한 네트워크 구조를 어떻게 구축할지도 후속 작업에서 필수적인 부분입니다.
일반적으로 우리는 네트워크 간섭을 모두 배제하고 서비스 자체의 성능 한계를 테스트하고자 합니다. 이를 위해 두 가지 방법으로 네트워크를 구축하여 부하 테스트를 할 수 있습니다.
첫 번째 방법은 wrk와 서버 애플리케이션을 성능이 좋은 동일한 머신에 배포하는 것입니다. 예를 들어, NGINX에서 8개의 워커를 열고 남은 CPU 리소스를 wrk에 할당하면 로컬 네트워크 통신만 발생하므로 네트워크의 영향을 최소화할 수 있습니다.
두 번째 방법은 전용 라우터로 LAN을 구축하고 wrk가 있는 머신을 서버가 있는 머신에 연결하는 것입니다.
기존 네트워크에서 직접 테스트하는 것은 권장하지 않습니다. 대부분의 네트워크에는 스위치와 방화벽이 있어 대량 트래픽의 부하 테스트를 제한할 수 있고 테스트 결과가 부정확할 수 있기 때문입니다.
추가로, 성능 테스트 도구에 대해 몇 가지 더 언급하고 싶습니다. 먼저, 성능 테스트 도구는 Coordinated Omission 문제를 가질 수 있으며, 이는 도구의 지연 데이터를 분석할 때 특히 주의해야 합니다.
Coordinated Omission이란 성능 테스트를 할 때 요청을 보내고 응답을 받는 시간만을 측정하는 것으로는 충분하지 않다는 것을 의미합니다. 이는 단지 서비스 시간일 뿐이므로 통계에 잠재적인 문제가 많이 누락될 수 있습니다. 따라서 테스트 요청의 대기 시간도 포함해야 하며, 이는 전체적으로 사용자가 관심을 갖는 응답 시간입니다. 물론, 서버 측 프로그램이 블로킹될 가능성이 있다면 이 문제를 고려해야 합니다. 그렇지 않으면 무시해도 됩니다.
질문 2: test::nginx로 SSL 관련 기능을 테스트할 수 있나요?
Q: test::nginx로 SSL 관련 기능을 테스트할 수 없나요?
A: 그렇지 않습니다. test::nginx는 SSL 관련 기능을 테스트할 수 있습니다. ssl.t를 참조할 수 있습니다. 이 테스트 케이스 파일은 SSL 인증서의 전체 프로세스를 테스트합니다. 먼저, 테스트 케이스가 Lua 코드를 사용하여 로컬 인증서의 공개 키와 개인 키를 읽는 것을 볼 수 있습니다. 그런 다음, HTTP API를 통해 인증서를 설정하고, 마지막으로 cosocket을 사용하여 SSL 핸드셰이크 및 접근을 통해 인증서가 유효한지 확인합니다.
사실, SSL뿐만 아니라 OpenResty에 포함된 기능들도 test::nginx를 사용하여 재정의할 수 있습니다.
특정 기능이 test::nginx로 구현 가능한지 확실하지 않다면, lua-nginx-module 및 기타 OpenResty 오픈소스 프로젝트의 테스트 케이스를 먼저 검색해보면 일반적으로 해당 예제를 찾을 수 있습니다. 결국 test::nginx는 매우 유연하고 다양한 조합과 트릭이 발견되기를 기다리고 있습니다.
질문 3: DSL이 정확히 무엇인가요?
Q: DSL과 test::nginx는 정확히 무엇인가요?
A: DSL은 Domain Specific Language의 약자입니다. DSL의 목적은 일반적인 개발 언어와 다릅니다. 일반적인 도메인의 요구를 해결하기 위한 것이 아니라 특정 도메인의 요구를 해결하기 위한 것입니다. 가장 유명한 DSL은 데이터베이스 도메인에서 사용되는 Structured Query Language인 SQL입니다.
test::nginx는 NGINX와 OpenResty의 테스트 요구를 해결하기 위해 만들어진 DSL입니다. 사실, OpenResty 저자는 많은 DSL 아이디어를 발명했고 OpenResty 커뮤니티에 많은 새로운 시도와 해결책을 가져왔습니다. 그러나 이전 글에서 언급했듯이, DSL은 양날의 검이며, DSL의 가치를 측정하는 주요 기준은 최종 사용자에게 생산성 향상을 가져올 수 있는지 여부입니다.
질문 4: test::nginx 설치 문제
Q: git clone을 실행한 후, test::nginx를 설치하기 위해 다음 명령어를 실행해야 하나요?
cd test-nginx
perl Makefile.PL
make
sudo make install
A: 사실 그렇지 않습니다. 여기서 몇 가지 오픈소스 프로젝트를 참조할 수 있습니다.
1단계: 패키지 관리자를 통해 설치
sudo cpanm --notest Test::Nginx >build.log 2>&1 || (cat build.log && exit 1)
2단계: 최신 test::nginx를 git clone
git clone https://github.com/openresty/test-nginx.git test-nginx
3단계: prove 명령어를 사용할 때 test-nginx 디렉토리를 포함
prove -Itest-nginx/lib -r t
앞서 언급했듯이, OpenResty 및 주변 프로젝트를 설치하는 가장 좋은 가이드는 문서가 아니라 CI에 있습니다. 이는 다른 프로젝트와 다를 수 있으며, 주로 OpenResty가 일부 주변 프로젝트의 포크 또는 특정 버전을 유지하고 있고, OpenResty가 CI에 강하게 의존하기 때문입니다. 따라서 OpenResty를 CI에서 빌드하는 방식과 동일하게 사용하고 테스트해야 공식 버전과 일관성을 유지할 수 있습니다.
질문 5: ab 테스트 도구는 좋은가요?
Q: Yichun Zhang이 Google Groups에서 ab를 최고의 테스트 도구로 자주 언급한 것을 어떻게 기억하나요?
A: 글에서 언급했듯이, 도구 기능만으로 보면 ab는 좋은 성능 테스트 도구가 아닙니다. 왜냐하면 충분한 요청 압력을 생성할 수 없기 때문입니다. 그러나 서버 측 프로그램의 성능이 이제는 강력합니다. test::nginx에서 wrk 대신 ab를 사용하는 이유는 TEST_NGINX_BENCHMARK 모드에서 test::nginx가 HTTP 프로토콜 버전에 따라 ab 또는 weighttp를 성능 테스트 도구로 사용하기 때문입니다.
또한, 인터넷 기술은 매우 빠르게 변화하고 있으며, 우리 각자는 지식과 기술을 적시에 업데이트해야 합니다. 예를 들어, 제 생각에 test::nginx의 이 선택은 이제 업데이트가 필요하며, Yichun Zhang은 당시 wrk의 존재를 알지 못했을 수도 있습니다. 물론, 시간이 지나면 wrk보다 더 나은 성능 테스트 도구가 나타날 수도 있으며, 우리는 자연스럽게 긍정적이고 열린 마음으로 배우고 선택해야 합니다.
오늘은 주로 위에서 언급한 질문들에 답변했습니다. 소통과 Q&A를 통해 여러분이 배운 것을 얻을 수 있도록 도움이 되길 바랍니다. 이 글을 공유하여 함께 소통하고 발전할 수 있기를 바랍니다.