백엔드 인프라 #2 Artillery 를 이용해서 웹 성능 테스트하기

2021.10.19 - [🌱Backend/CI & CD] - 백엔드 인프라 #1 소개 및 테스트 서버만들기

백엔드 인프라 #1 소개 및 테스트 서버만들기

 

1편에서 구성한 웹 서버를 테스트 해봅시다.

 

물론 크롬 개발자 도구를 띄워놓고 F5를 눌러가며 성능 테스트를 하는 방법도 있겠지만, Atrillery.io 라는 도구를 이용하면 쉽게 성능을 테스트 할 수 있습니다. 그 외 JMeter 등의 도구도 자주 사용하곤 합니다.

Artillery.io | Load & Smoke Testing

 

Arrillery는 Node.JS 의 npm을 이용하여 설치합니다. 없다면 설치해주세요.

$ npm install -g artillery

Node.js

 

 

#1. Artillery 스크립트 작성

공식문서의 예제 코드를 참고하여 아래와 같은 test.yaml 파일을 만들어주세요.

config:
  target: "http://34.64.209.57/"
  phases:
    - duration: 60 # n초 동안
      arrivalRate: 1 # n명의 가상 User를 생성 (유저는 초당 1번 요청)
      name: Warm up


scenarios:
  - name: "just get hash" # 설명
    flow:
      - get: # 해당 url에 get 요청을 합니다.
          url: "/hash/123"

자세한 사용법은 공식 doc에 친절하게 나와있으니 참고해주세요.

 

 

#2. 스크립트 실행

npm으로 아틸러리를 설치했다면, 아래와 같은 명령어로 스크립트를 실행시킬 수 있습니다.

artillery.cmd run --output report.json .\test.yaml

--output 으로 결과 json 파일 이름을 정할 수 있습니다. 그리고 아래의 명령어로 HTML 보고서를 만들어주세요.

report.json을 보기좋게 HTML 문서로 만듭니다.

 

 

# 3. 웹서비스 성능 테스트

유저의 접속량을 바꿔가며 성능 테스트 해봅시다.

60초동안 12명의 유저가 초당 1번씩 요청을 보냅니다.

artillery.cmd run --output report.json .\test.yaml
artillery.cmd report .\report.json

 

보통 웹 서비스의 기대 성능은 Latency(응답속도)를 기준으로 판단합니다.

아래 결과를 보면 Artillery 스크립트를 [60초-초당 1명]으로 했을 때에는 아무런 문제가 없었지만, [60초-초당 8명]으로 했을 떄 서버의 응답속도가 느려짐을 알 수 있습니다. 더 심하게 테스트한다면 서버가 죽어버리기도 하겠죠.

 

 

목표로 하는 응답속도가 200~300ms 라면, 해당 응답속도가 나오지 않았을 때 서버의 성능을 늘리거나(Scale-up) Nginx같은 로드밸런싱을 이용해 서버의 대수를 늘려야(Scale-out) 합니다.

 

또한 예상 트래픽(TPS, HTTP Transcation Per Second)가 1000정도라면, 적어도 2-3000의 트래픽을 감당할 정도의 서버를 구성해야하며 만약 Scale-out을 했는데도 성능이 별 차이가 없다면, 병목을 의심해야 겠죠.

서버에 부하가 커지면 커질수록 Timeout 비율이 늘어나다가, 너무 많이 쌓이게되면 서버가 죽어버립니다.

 

테스트가 짧아서 그래프가 단순하지만, 약간 더 긴시간 동안 테스트해보면 아래와 같은 응답속도 그래프가 나옵니다.

클라우드와 네트워크 특성상, 항상 일정한 레이턴시가 나오기 어렵습니다. 그래서 한번씩 느린 반응속도가 나오게 됩니다. (= 핑이 튄다)

 

그래프에 대해 조금더 자세하게 설명해주자면

좌측 레이턴시 : 클라이언트(브라우저)에서 request를 보내고 response를 받는데 걸린 시간입니다.

max : 가장 오래 걸린 요청->응답시간

p95 : 전체 HTTP 트랜잭션 중 가장 빠른 것부터 95% (거의 대부분의 트래픽)

p50 : 전체 HTTP 트랜잭션중 가장 빠른 것부터 50% (절반이하의 빠른 트래픽)

min : 가장 빠르게 온 요청->응답시간

 

이는 설정에 따라 바꿀 수 있으며, 보통 P99나 P95 그래프를 많이 사용합니다. 네트워크의 특성상 한번씩 핑이 튀어 레이턴시가 높게 나오거나, 가상머신(VM)의 특성상 잠깐동안 제 성능을 못내는 경우가 있기 때문에, max나 min을 참고하는건 바람직하지 않습니다.

 

 

#4. 실제로 적용할 때 팁

• 실제 서비스에서는 가급적 스트레스 테스트를 길게 테스트 하는게 좋습니다.
• 실제 유저들의 패턴과 비슷하게 시나리오를 만들어서 테스트하는게 좋습니다.
• 큰 서비스라 테스트 트래픽이 많이 필요하면 서버 여러 대를 클러스터링하여 Atrillery 같은 툴을 실행시키면 됩니다.

서비스 시나리오는 아래와 같이 작성할 수 있습니다.

[ 메인페이지 진입 ] -> [ 특정 카테고리 진입 ] -> [ 선택 페이지 ] ->
[ 결제 페이지 ] -> [ 결제 요청 ] -> [ 결제 완료 ] -> [ 배송조회 페이지 ] ->
[ 리뷰 목록 ] -> [ 리뷰 작성 ]

물론 위의 과정들이 연속적으로 일어나지는 않겠지만, 사용자별 서비스 이용패턴을 여러개 만드는게 좋습니다.

 

1. 만든 시나리오를 바탕으로 예상 트래픽을 설정해보고, 스트레스 테스트를 진행합니다.

2. 스트레스 테스트를 진행하며 어디가 병목이 생기는지 파악합니다.

이 때 네트워크 병목과 더불어 서버, DB 자원에 대한 모니터링(Cpu, memory, I/O)도 추가로 해주면 좋습니다.

3. 위 테스트를 바탕으로 서비스 코드를 개선하거나, 시스템 장비, 설계를 개선합니다.

4. 서비스를 오픈한 이후에도 서버 리소스에 대한 모니터링을 실시하며 개선점을 파악합니다.

 

 

#5. 네트워크 병목 문제

서버 성능은 짱짱한데 TPS가 느리게 나오는 네트워크의 병목문제는 크게 2가지로 나눌 수 있습니다.

Latency 병목 문제와 대역폭(Bandwidth) 병목 문제.

• Latency는 두 지점사이에 패킷이 오고가는데 얼마나 많은 시간을 걸리는지를 의미합니다. (ping)
• Bandwidth은 두 지점 사이에 초당 얼마나 많은 데이터량이 흐를 수 있는가를 의미합니다.

 

온라인 게임의 경우 레이턴시는 매우 중요하지만, 주고 받는 데이터량은 크지 않습니다.

파일 공유 서비스의 경우 레이턴시는 조금 느려도 되지만, 파일의 크기가 커서 대역폭은 상당히 큽니다.

• 서버 Latency의 병목 문제가 의심된다면 두 지점사이 네트워크 시간을 줄일 방법을 고민해봐야 합니다. 만약 서로 다른 나라에서 접속한다면 각 나라에 캐시 서버를 두는 것도 해결책 중 하나가 될 수 있습니다.
• 서버 Bandwidth의 병목 문제가 의심된다면, 이건 전송되는 데이터를 압축하여 전송하거나 인터넷 서비스 업체를 통해 회선을 바꾸는 수 밖에 없습니다.

 

즉 네트워크 문제를 파악하기 위해서는 위 2가지를 기본적으로 염두해두고, 다각적으로 분석하는 습관이 필요합니다

• 내부 시스템에서 다른 서버, DB 사이에 생기는 네트워크가 지연되는건가?
• 외부로 호출되는 API가 지연되는건가?
• 사용자와 우리 서버사이에 지연되는건가?
• 서버의 성능이 트래픽을 처리하기에 부족한가?