Kubernetes는 클라우드 워크로드를 실행하기 위한 좋은 선택이 될 수 있으며 애플리케이션을 오케스트레이션하기 위한 강력한 도구가 될 수 있습니다. 하지만 Kubernetes로 구성된 소프트웨어 또는 서비스를 안정적으로 운영하기 위해서는 부하 테스트 단계를 반드시 거쳐야 합니다.
부하 테스트는 적절한 부하를 발생시켜 통계적으로 의미 있는 수치를 측정할 수 있고, 장시간 서비스를 진행할 수 있는지 그리고 실제 처리 능력은 어느 정도인지 가늠해볼 수 있습니다.
가장 먼저 부하 테스트를 진행하려는 이유를 명확히 해야 합니다. 상황에 따라 다르겠지만, 대부분 폭증하는 트래픽을 처리할 수 있는지를 확인하고 싶을 것입니다. 또, 응용 프로그램이 중단되는 시점을 확인하고 싶을 수 있습니다.
부하 테스트를 진행하려는 이유를 파악했다면 테스트를 진행하기 위해 많은 양의 트래픽을 시뮬레이션 할 수 있는 도구가 필요합니다. Kubernetes 부하 테스트는 일반적으로 부하 테스트를 위해 만들어진 도구들을 모두 사용할 수 있지만 Kubernetes 부하 테스트를 전문으로 수행하는 툴을 사용하면 훨씬 더 많은 정보를 얻을 수 있습니다. 이런 툴은 Kubernetes에서 애플리케이션이 실행될 때 훨씬 더 전문화될 수 있으며, 올바른 도구를 사용했을 때 부하 테스트를 CI/CD 파이프라인에 통합하는 것이 더욱 쉬워집니다.
부하테스트 도구는 필요한 작업을 수행할 뿐만 아니라 사용하기 쉽고 디버그하기 쉬운 것을 선택하는 것이 중요합니다. 아래의 비교자료는 부하테스트를 담당하는 개발자의 시각으로 여러가지 툴을 비교해 본 것입니다.
실용적인 측면에서 K8s 부하 테스트 도구는 시작하기 얼마나 쉬운가, CI/CD 시스템과 얼마나 잘 통합되는가 등에 따라 비교, 평가됩니다.
Speedscale UI를 확인하는 순간, 높은 편의성을 경험하게 됩니다. 또한 Speedscale 은 Kubernetes와 함께 사용하기 위해 개발된 도구입니다.
Speedscale은 Kubernetes 클러스터를 구성하는 데 사용할 수 있는 자체 `speedctl` CLI 도구를 개발했습니다. 설명서가 잘 작성되어 있고 도구가 상당히 간단하기 때문에 도구를 실행하기 위해 많은 Kubernetes 지식이 요구되지 않습니다.
Speedscale의 특히 편리한 기능 중 하나는 트래픽을 캡처한 다음 그로부터 모의를 자동 생성하는 것입니다. 실제로 이 기능은 서비스가 재생 자체의 일부가 되는 모의 서버 컨테이너를 빌드할 수 있음을 의미합니다. 또한, 기존 부하 테스트에 비해 상당한 장점이 있습니다. 부하 테스트를 실행하기 위해 거대한 클러스터를 설정할 필요가 없다는 것, 재생을 실행하는데 프로덕션 등급 포드가 필요하지 않으므로 리소스와 관련하여 높은 인바운드/백엔드 트래픽 시뮬레이션을 훨씬 저렴하게 만들 수 있다는 것 등이 있습니다. 또, Mocking 컨테이너는 다양한 레이턴시 테스트, 404 및 무응답과 같은 카오스 엔지니어링 기법의 혼란을 일으킬 수 있습니다. 이렇게 하면 최적의 조건에서 서비스를 테스트할 뿐만 아니라 불안정한 종속성에 어떻게 응답하는지도 확인할 수도 있습니다. 테스트를 실행한 후 모든 테스트 보고서를 자세히 살펴볼 수 있습니다.
Speedscale은 특정 CI/CD 시스템과 통합하는 방법에 대한 문서를 제공하지 않지만, 파이프라인에 수동으로 포함할 수 있는 bash 스크립트 설정에 대한 포괄적인 가이드를 제공합니다. 특별한 점은 Kubernetes와 얼마나 잘 통합되는지입니다. 올바른 주석으로 배포를 만들고 `speedctl`을 통해 설치한 운영자가 나머지를 처리합니다. 설정하는 작업은 거의 없으며 'kubectl apply' 외에는 테스트 사이에 작업이 거의 없습니다. [Helm](https://helm.sh/)과 같은 것으로도 쉽게 자동화할 수 있습니다.
Speedscale의 또 다른 특징 중 하나는 Kubernetes와 잘 통합된다는 것입니다. 올바른 주석으로 배포를 만들고 `speedctl`을 통해 설치한 운영자가 나머지를 처리합니다. 별도의 설정 작업은 거의 없으며 'kubectl apply' 외에는 테스트 사이의 작업도 거의 없습니다. [Helm](https://helm.sh/)과 같은 것으로도 쉽게 자동화할 수 있습니다
JavaScript 작성에 익숙하다면 K6가 좋은 도구가 될 것 입니다. 테스트는 가져올 수 있는 라이브러리를 사용하여 일반 JavaScript로 작성됩니다. JavaScript를 몰라도 구문은 상당히 간단합니다. 테스트가 작성되면 `k6` CLI 도구를 사용하여 테스트를 실행하고 결과를 터미널에 출력합니다.
이 접근 방식은 터미널을 보기만 해도 믿을 수 없을 정도로 빠르게 결과를 얻을 수 있음을 의미합니다. 그러나 이것은 터미널에서 그래프를 표시할 수 없기 때문에 가시성에 약간의 제약이 있습니다. 이에 대한 해결 방법으로 K6는 결과를 터미널에 표시할 뿐만 아니라 K6의 서버에 업로드하여 웹 UI에서 결과를 볼 수 있는 클라우드 솔루션을 제공합니다. 이를 통해 그래프와 함께 깔끔하게 정리된 데이터를 볼 수 있습니다.
많은 설정을 좋아하지 않는 담당자라면 K6가 적합할 수 있습니다. 사용하기 쉬운 CLI이며 환경에 많은 것을 설치할 필요가 없습니다. 실제로 K6에는 Docker 이미지가 있으므로 별도의 도구를 설치할 필요 없이 테스트 파일을 작성하고 실행하기만 하면 됩니다. CI/CD 파이프라인에 통합하려는 경우 K6에 이를 설정하는 문서가 있습니다.
JMeter 는 소개하는 도구 중, 가장 오래된 것일 수 있습니다. JMeter는 로컬에서만 실행되는 Java 애플리케이션이기 때문에 처음 실행할 때 몇 가지 문제가 발생할 수 있습니다. 그 외에도 설명서는 매우 포괄적이지만 살펴보기에 혼란스러울 수 있으므로 도구를 설정하는 데 어려움을 겪을 수 있습니다. 도구를 로컬에서 실행하면 빠르게 결과를 얻을 수 있습니다. JMeter는 모든 과부하 테스트가 CLI 버전을 사용하여 실행되어야 한다고 권장합니다.
CI/CD 파이프라인에 부하 테스트를 통합하려는 경우 다른 도구를 선택하는 것이 더 나을 수 있습니다. 자동화된 시스템에서 JMeter를 사용하는 것이 가능하지만 도구가 부하 테스트를 목적으로 하여 구축된 것이 아니며 이를 설정하는 방법에 대한 공식 문서를 찾을 수 없습니다. 하지만, JMeter는 완전 무료라는 장점이 있습니다.
Gatling은 부하 테스트를 설정에 대한 명확한 경로가 없습니다. 그렇기 때문에 Gatling을 시작하는 것 자체가 꽤 어려운 일이 될 수 있습니다. 설정이 완료되면 자체 DSL(Domain Specific Language)로 부하 테스트 스크립트를 생성해야 합니다. 물론 이는 더 큰 기능 집합을 의미할 수도 있지만 Gatling을 설정하는 것은 더 포괄적인 작업이기도 합니다.
CI/CD 시스템에 대한 직접적인 통합은 없으며 수동 설정에 대한 지침도 없는 것으로 보입니다. 따라서 자동화된 솔루션의 경우 다른 도구가 더 나은 선택일 수 있습니다.
ReadyAPI는 훌륭한 응용 프로그램이지만 현대적이지는 않습니다. 데스크탑 애플리케이션을 다운로드하고 UI 디렉토리 구조로 탐색하는 전통적인 UI를 좋아한다면 ReadyAPI가 좋을 수 있지만, 현대적인 디자인, 심지어 CLI 도구를 좋아한다면 ReadyAPI는 적합하지 않습니다. 이 도구는 부하 테스트 작업을 수행함에 있어 나쁜 도구는 아니지만, "현대" 개발자에게는 다소 어려울 수 있습니다.
Kubernetes의 부하 테스트가 목표라는 염두에 두고 보았을 때 훌륭한 도구는 Speedscale과 K6 입니다. 각각의 장점이 있습니다. 빠르고 간단한 부하 테스트 설정을 원한다면 K6을 시작하기가 매우 쉽습니다. Speedscale이 설정하기 어렵다는 말은 아니지만 Kubernetes 클러스터에 Operator를 설치해야 합니다. 덕분에 클러스터와의 긴밀한 통합을 원하는 사람들에게는 Speedscale 이 더 좋은 도구일 수 있습니다.
쉽고 빠른 테스트의 경우 K6를 사용하는 것이 좋고, Kubernetes 워크플로에서 직접 부하 테스트를 통합하고 추가 이점을 얻고자 한다면 Speedscale을 사용하는 것이 좋습니다.
.png)
