장애 대응 - 부하 테스트 준비(nGrinder → k6)

서비스를 제공하는 입장에서, 사용자에게 신뢰성 있는 서비스를 제공해야 하며 이 신뢰성을 높이기 위해서는 서비스가 안정적으로 제공되어야 한다.

 

장애(outage): 사용자가 직접 경험할 수 있는 시스템의 문제 또는 사용자에게 직접 영향을 주지는 않더라도 내부 시스템이 기대한 대로 동작하지 않는 것

장애는 불규칙적으로, 어쩔 수 없이 발생한다.

피할 수 없다면 적극적으로 예방하고, 장애 발생 시 유연하고 빠르게 대처해야 하며, 같은 장애가 재발되지 않도록 조치해야 한다.

 

현업에서의 장애 대응 프로세스는 보통

1. 장애 탐지 및 전파

2. 장애 분류 및 해결

3. 장애 복구 및 보고

4. 장애 회고

이렇게 진행된다고 보면 된다.

 

이 프로세스가 진행되려면 프로세스 자체도 잘 진행되어야 하지만, 장애 발생 시 빠르게 발견할 수 있는 것이 중요하다.

현업에서 장애를 빠르게 감지하기 위해서는 로깅, 모니터링 등의 방법이 있는데, 장애 상황을 감지하기 위해 다양한 조건을 설정하고 모니터링을 함으로써 장애의 확산을 방지할 수 있다.

이것보다도 우선적으로 신뢰성을 높이는 가장 쉬운 방법이 있는데, 개발 초기부터 신뢰성을 고려하는 것이다.

개발자 본인이 유연하고 테스터블한 코드를 만들며, 동료 간 코드리뷰 문화를 엄격하게 활성화함으로써 1차적으로 신뢰성을 높이고 장애를 줄이는 노력을 할 수 있다.

 

이렇게 어쩔 수 없이 발생하는 장애에 대응하려면, 문화와 프로세스가 뒷받침되고 꾸준히 조직 모두가 노력해야 한다.

 

실제로 우아한 형제들에서 진행한 모의장애훈련 일지가 인상깊었다.

배달의민족 - 모의장애훈련일지

---

 

현재 항해 과제로 구축한 서비스에 대해서 장애를 방지하고, 대응하기 위해 점검하는 시간을 가져보게 되었다.

부하테스트를 이용해 나의 웹서비스가 어떤 장애가 일어날 수 있을지, 성능은 어느 정도인지 파악해보아야 한다.

---

우선, 부하테스트 툴은 jmeter, nGrinder, k6 중에 nGrinder를 이용해보기로 하였다.

이유는 스크립트로 작성되고, 결과값 해석이 편해보였기 때문이다. (k6는 회사에서 한번 학습용으로 그라파나까지 붙여서 시나리오를 돌려봤기 때문에 이번에는 다른 툴을 사용하여 공부해보기로)

 

설치와 실행을 먼저 하였다. https://github.com/naver/ngrinder/releases

 

에러 남

java.io.tmpdir 속성을 설정하지 않아서 발생한 것이라고 한다. ngrinder는 임시 파일을 저장할 디렉터리가 OS의 기본 임시 디렉터리와 다르게 설정되기를 원한다고 한다.. 명시적으로 설정해주자.

얘도 에러남

해당 디렉터리를 만들고, 권한을 설정해주었는데도 에러가 났다.

결국 구글링 중에 유저 패스로 만들어보라 하는 답변을 보고 해결.. 왤까?

+) Gradle도 설치 안되어 있어서 설치해 줌

터미널에서 실행이 되면 브라우저에서 localhost:8300 으로 접속해준다.

초기 id, pw 세팅은 admin, admin

어드민 메뉴바에서 에이전트 다운로드 후 압축풀기

에이전트 폴더에서 에이전트 실행

아까 nGrinder 브라우저로 돌아가서 어드민 메뉴 > 에이전트 관리에 들어가면 내 환경에서 실행중인 것이 보인다.

 

준비작업은 끝났다! (생각보다 오래 걸림)

이제

1. 테스트를 계획하고

2. 시나리오를 수립하고

3. 실제로 테스트를 돌려본 후

4. 결과를 분석하고

5. 장애를 예상하여 개선해나가야 한다.

 

생각보다 길어지는 관계로 2부에서 이어집니다. 이어지려고 했으나,

빌드 오류가 자꾸 생겨 알아봤더니, nGrinder는 JDK17에서 호환이 안되고, 다운그레이드 해서 사용해야 한다고 하였다.

이미 시간을 많이 쓴 상태이기도 하고, 다운그레이드하기 괜시리 싫어서 부하테스트 툴을 변경하기로 하였다.

nGrinder는 다음에 여유있을 때 적용해보기로

---

 

새롭게 적용해 볼 부하테스트 툴로 jmeter, k6 등 고민해봤는데,

k6가 가벼우면서 고성능이기도 하고, 회사에서 한번 연습해본 관계로 적응 시간이 세이브될 것 같아 k6로 선택하였다.

실제로 테스트 툴 성능 비교를 보면,

https://k6.io/blog/comparing-best-open-source-load-testing-tools/#vu

https://k6.io/blog/comparing-best-open-source-load-testing-tools/#vu

위 사진을 보면 k6는 RPS(Request Per Second)도 높고, 메모리 사용량이 낮은 것을 볼 수 있다. 또한 100VU의 가상 사용자 테스트에서 좋은 성능을 보여주고 있다.

---

k6를 간단하고 빠르게 설치해보고, 바로 부하테스트 계획을 세워보려고 한다.

빠른 부하테스트 준비를 위해 효율적으로 부하테스트 + 시각화를 한번에 진행할 수 있는 docker-compose 스크립트를 이용하였다.

 

- docker-compose.yml (공식 이미지 사용)

version: "3.8"

services:
  grafana:
    image: grafana/grafana
    ports:
      - 3000:3000
    // (1) Grafana에서 직접 datasource, dashboard를 설정하지 않고 Provisioning 기능을 활용
    volumes:
      - ./grafana-provisioning:/etc/grafana/provisioning
      - ./grafana-dashboard:/dashboard
    depends_on:
      - prometheus
  prometheus:
    image: prom/prometheus
    ports:
      - 9090:9090
    command:
      - --web.enable-remote-write-receiver	// (2) 결과 전달
      - --enable-feature=native-histograms	// (3) 고해상도 시각화
      - --config.file=/etc/prometheus/prometheus.yml
  k6:
    image: grafana/k6
    volumes:
      - ./k6-scripts:/scripts
    command: run -o experimental-prometheus-rw /scripts/stress.js	// (4) 실행시킬 스크립트
    environment:
      - K6_PROMETHEUS_RW_SERVER_URL=http://prometheus:9090/api/v1/write
      - K6_PROMETHEUS_RW_TREND_AS_NATIVE_HISTOGRAM=true
    extra_hosts:
      - "host.docker.internal:host-gateway"
    depends_on:
      - prometheus

 

- 구성

 

- k6.json

아래 링크에서 Download JSON

https://grafana.com/grafana/dashboards/18030-k6-prometheus-native-histograms/

k6 Prometheus (Native Histograms) | Grafana Labs

- dashboards.yml

apiVersion: 1

providers:
  - name: "k6 Stress Test"
    orgId: 1
    folder: ""
    type: file
    disableDeletion: false
    updateIntervalSeconds: 10
    options:
      path: /dashboard/k6.json
      foldersFromFilesStructure: true

 

- prometheus.yml

apiVersion: 1

datasources:
  - name: Prometheus
    type: prometheus
    access: proxy
    url: http://prometheus:9090

 

- 실행

docker-compose up 명령어로 실행

이를 실행하면 k6가 개별 컨테이너에서 부하테스트를 진행, 결과 데이터들이 Prometheus > Grafana 흐름으로 전달된다.

 

- 확인

localhost:3000 에 접속 > 로그인(admin/admin) > 대시보드 확인

 

---

이제 진짜로

1. 테스트를 계획하고

2. 시나리오를 수립하고

3. 실제로 테스트를 돌려본 후

4. 결과를 분석하고

5. 장애를 예상하여 개선해나가보도록 하자.

레고레고~

다음글 >> https://iwannabarmus.tistory.com/42