블루믹스에서 Auto-Scaling 사용하기 – Part2(부하 테스트)

블루믹스에서 Auto-Scaling 을 테스트하기 위한 두번 째 시간으로 부하 테스트를 통해 구동중인 자바 런타임 인스턴스의 수가 자동 조정이 되는지 알아보도록 하겠습니다.

부하 테스트는 앞서 Part1의 사전 준비사항에 있던 JMeter를 이용하여 테스트 할 것이므로 다음의 링크를 통해 다운로드 받아서 테스트 하시기 바랍니다.

단계1. JMeter 환경 구성

부하 테스트를 위한 환경 구성에 앞서 JMeter에 대해서 간단히 설명하면 오픈소스로 제작되고 있는 부하테스트 툴로서 간단한 설정으로 우리가 제작한 어플리케이션의 구동환경에 대한 퍼포먼스 테스트를 할 수 있는 도구입니다.
JMeter는 다음과 같은 기능을 가지고 어플리케이션/서버/프로토콜 테스트가 가능합니다.

  • Web – HTTP, HTTPS (Java, NodeJS, PHP, ASP.NET, …)
  • SOAP / REST Webservices
  • FTP
  • Database via JDBC
  • LDAP
  • Message-oriented middleware (MOM) via JMS
  • Mail – SMTP(S), POP3(S) and IMAP(S)
  • Native commands or shell scripts
  • TCP
  • Java Objects

자, 이제 본격적으로 부하테스트를 진행해 보겠습니다. 다만, 본 문서에서는 JMeter의 사용법에 대해서는 따로 설명하지 않기 때문에 미리 설정된 JMeter 스크립트 파일을 공유합니다.
테스트 하시는 환경에 맞춰서 수정하신 후 사용하시면 되겠습니다.

1.1 개별 테스트 환경에 맞춰 JMeter 스크립트 파일 수정

JMeter 프로그램을 다운받아서 압축을 푼 후 실행시키고 스크립트 파일을 불러오기를 하면 아래의 그림과 같이 테스트 시나리오가 로딩됩니다.

  • 왼쪽 트리 구조에서 [Test Plan] > [10User 5s ramp up] > [Login] 클릭 후 오른쪽 상세화면에서 어플리케이션 URL 항목에 각자 구성된 어플리케이션의 URL로 설정하시면 됩니다.
  • JMeter의 상단 툴바에서 부하 시작/중지와 히스토리 삭제를 위한 버튼이 있습니다. 부하 테스트 시 주로 사용하게되는 버튼입니다.
  • 이 스크립트는 10user 5s ramp up 의 Thread Group 이 3개로 이루어져 있습니다. 즉 동시 10명의 사용자가 login 요청을 하는 그룹이 3개이며 모든 Thread Group 을 활성화 하여 부하를 줄 경우 동시에 30명이 요청하는 것과 같습니다.( 부하 테스트에서는 Thread group을 단계별로 증가시키거나 감소시키면서 테스트 합니다.)
  • 아래 두번째 그림에서는 Thread Group의 설정을 보여줍니다. 동시 요청자 수의 변경이 필요할 경우 Number of Threads (users) 의 수를 조정합니다.
  • 각 Thread Group을 활성화 하거나 비활성화 하기 위해서는 아래 세번 째 그럼과 같이 Toggle 시키면 됩니다.



단계2. 부하 테스트 및 모니터링

JMeter 가 준비가 되었으면 실제 부하를 넣으면서 스케일링이 되는지 확인을 해볼 단계입니다.
Part1에서 설정하였던 Auto-Scaling 서비스 화면(Part1의 2.2정책설정 참조)으로 들어가서 아래 그림과 같이 Metric Statistics를 선택합니다.

  • 부하 테스트를 위해 필요한 그래프는 Throughput 그래프 입니다.


2.1 부하 테스트

블루믹스 화면에서 그래프를 모니터링 하면서 JMeter로 Thread Group 1개만 활성화하여 부하를 넣습니다.
(테스트를 위해서 1개 Thread Group이 부하가 들어갈때 Part1 에서 설정한 Throughput 범위인 20 ~ 30 TPS 사이의 값이 나오도록 user 수를 부하를 넣으면서 테스트하여 조정합니다. 현재 문서에서는 10user로 테스트 함.)

  • JMeter의 오른쪽 상단에 10 user의 부하가 들어감을 확인 합니다.
  • 그리고 Summary Report의 Throughput의 값을 확인합니다. (JMeter에서 측정되는 데이터는 2개의 인스턴스가 모두 처리하고 있는 총 처리량을 나타냅니다. 블루믹스의 그래프는 처리량에 대한 평균임으로 JMeter에서 측정되는 Thoughput의 값에서 약 1/2 값이 나옵니다.)

일정 시간이 지난 뒤에 Thread Group을 하나더 활성화 시킵니다.(총 20 user의 부하)

  • 총 20user의 부하시에 JMeter의 Thoughput 이 약 100 TPS 에 근접해 집니다.
  • 이론상으로 평균 20 ~ 30 TPS 정도의 Throughput을 가지기 위해서는 4개의 인스턴스로 처리가 되어야 합니다.
  • 터미널에서 cf app 앱명 명령어를 통해 현재 서비스되고 있는 인스턴스를 확인합니다.
  • 아래 두번째 그림에서 총 4개의 인스턴스가 서비스되고 있음을 확인 할수가 있습니다(최초 2개의 인스턴스로 서비스 되었으나 Scale-out 되었음)

다시 30 user의 부하를 넣어서 동일한 방법으로 확인합니다.

  • 최종적으로 6개의 인스턴스로 서비스 됨을 확인합니다.


이번에는 20user로 부하량을 줄여서 요청합니다.

  • 아래의 그림에서 확인 가능한 것과 같이 Scale-in 되면서 최종적으로 4개의 인스턴스로 줄여서 서비스됨을 확인 할 수 있습니다.

단계3. 테스트 완료

이로서 Auto-Scaling 서비스를 이용하여 부하량에 따라 동적으로 런타임 인스턴스 수가 조정됨을 확인 했습니다.
이번 테스트에서는 Throghput에 한정하여 테스트 하였으나 어플리케이션의 특성에 따라 다양한 Metric 조합으로 설정하여 서비스 가능하며, 다양하게 변화하는 운영환경에 동적으로 적절히 대응하는 런타임 환경을 구성할 수 있습니다.ㄴ