🚀 부하테스트를 해보자

부하 테스트의 필요성

곧 최종 발표가 남은 시점에서, 실제 사용자를 많이 모아서 하는 것은 분명히 한계가 있기에 테스트를 진행하고,

발생하는 에러들에 대해 최적화를 진행해주어야겠다고 생각했습니다.

여기서, 부하 테스트와 스트레스 테스트의 차이는 무엇일까 라는 궁금증을 가지게 되었습니다.

성능, 부하, 스트레스 테스트의 차이점

성능, 부하, 스트레스 테스트 무엇이 다를까?

성능 테스트

성능 테스트는 특정 상황에서 시스템의 구성 요소가 어떻게 수행되는지 확인하기 위해 수행되는 테스트이다.

성능 테스트를 통해 시스템의 자원의 사용량, 확장성, 신뢰성 등을 검증할 수 있다.

⇒ 특정 시나리오 상황에서의 API 평균 처리 속도를 파악

⇒ 확장성, 신뢰성 및 리소스 사용과 같은 시스템의 다른 품질 속성을 조사, 측정, 검증

부하 테스트

부하 테스트란 임계값 한계에 도달할 때까지 시스템의 부하를 지속적으로 꾸준히 증가시켜 시스템의 성능을 테스트하는 것이다.

부하 테스트는 유저의 수와 초당 API 요청 등을 증가시키며 시스템의 내구성을 테스트하고 결과를 모니터링하며 애플리케이션의 한계를 찾아내는 것을 목표로 한다.

⇒ 버퍼 모버플로우, 메모리 누수 및 잘못된 메모리 관리와 관련된 응용 프로그램의 결함을 노출한다.

⇒ 애플리케이션이 미래에 예상되는 부하를 관리할 수 있도록 데이터베이스, 하드웨어, 네트워크 등의 모든 구성요소의 상한을 결정한다.

스트레스 테스트

스트레스 테스트는 기존 자원에 초과 작업으로 과부하를 주는 다양한 활동을 수행하며 시스템을 무너졌을 때 어떤 동작을 보이는지 확인하는 테스트이다.

시스템이 커버할 수 있는 대역폭 이상으로 과부하를 주며 과부하 상태일 때 모니터링 도구는 정상적으로 복구되는지, 시스템이 장애 조치를 하는지, 보안상의 문제가 발생하는지 등을 확인한다

⇒ 스트레스 테스트를 통해 얻을 수 있는 가장 이상적인 시스템은 부하가 걸려서 시스템이 고장난 이후에도 서비스가 정상 상태로 돌아오는 것

진짜 부하테스트를 해보자

가장 먼저, 익히 알고 있었고, node와 호환성이 좋은 k6 를 사용하기로 결정했다.

k6는 js파일로 작성을 할 수 있고, 툴만 설치하면 쉽게 부하 테스트를 진행할 수 있었다.

다만 고려하지 못한 점이 있었는데 k6는 [socket.io](http://socket.io/) 를 지원하지 않는다.

마침, 부하 테스트 항목이 사용자 별 채팅 방 입장과 채팅 broadcasting이다 보니, 테스트를 진행할 수 없다고 판단했다.

따라서, 다음으로 찾아본 것은 artillery 였다.

artillery의 특징은 yml 파일로 실행을 해야 한다.

코드는 socket.io 공식 문서의 load testing 부분을 참고했다.

https://socket.io/docs/v4/load-testing/

엔진은 socketio가 아닌, socketio-v3을 사용하는 것이 artillery 공식 문서에서 알려주는 방식과는 다른 점이었다.

그리고, 채팅 방 입장을 위해 우리는 roomId를 연결에서는 query로, 채팅에서는 data로 받아오는데, 변수를 따로 설정해줘야 했다.

4시간의 우여곡절 끝에 완성된 코드는 다음과 같다

최종 코드

일단 artillery - socket v3 관해서 설치를 해줘야 한다.

yarn add artillery-engine-socketio-v3 artillery

그리고, socket-test.yml 파일을 작성한다.

config:
  target: 'http://localhost:3000'
  phases:
    - duration: 10
      arrivalRate: 20
  engines:
    socketio-v3:
      transports: ['websocket']
      timeout: 10000
  variables:
    roomId: '7b82b46b-d705-48a5-9bc5-918ee1a124a0'
scenarios:
  - name: 'Chat room flow'
    engine: socketio-v3
    flow:
      - think: 1

      - namespace: '/rooms'
        connect:
          query: 'roomId={{ roomId }}'
          headers:
            x-forwarded-for: '{{ $randomNumber(1000000, 9999999) }}'
        emit:
          channel: 'message'
          data:
            message: 'Test message'
            roomId: '{{ roomId }}'

      - think: 1

      - namespace: '/rooms'
        emit:
          channel: 'vote'
          data:
            trackNumber: "{{ $randomNumber(1,2) }}"

      - think: 30

실행은 다음과 같다.

yarn artillery run -e development socket-test.yml

트러블 슈팅 과정

방 입장

기존 예시 코드들을 보면, 방 입장 관련 서버 코드에서, SubscribeMessage()로 처리해줘서 모두 emit을 적으라고 나와있다.

다만, 우리 코드에서는 handleConnection으로 처리해주고 있기 때문에, emit 방식으로 처리하지 않고, connect 방식으로 처리해야 했다.

다만 여기서, query: {{roomId}} 로만 적었다가, 1시간 정도를 소요한 것 같은데, 풀 네임을 적어줘야했다..

query:roomId={{ roomId }} 이렇게 말이다.

또한, namespace 관련 emit과는 다르게 connect는 실행 전에 선언을 해주어야한다.

입장 로그가 잘 찍히는 것을 확인할 수 있었다.

채팅

기존에는 namespace가 방 입장 로직에서 잘 적혀있으니, 잘 되겠지 라고 생각해서 계속 시도해봤는데,

message 이벤트 로그가 아예 발생하지도 않았다. 따라서, 원인은 namespace 설정 하나밖에 없다고 판단하였다.

- namespace: '/rooms'
        connect:
          query: 'roomId={{ roomId }}'
          headers:
            x-forwarded-for: '{{ $randomNumber(1000000, 9999999) }}'
      - think: 2
      - emit:
          namespace: '/rooms'
          channel: "message"
          data:
	          message: "Test message"
	          roomId: "{{ roomId }}"
      - think: 8

아무리 namespace 설정을 해봐도 적용이 되지 않았다.

뭐가 문제인가 하다가, 발견한 것이, 중간에 think: 2 때문에 emit에 - 가 붙어서, connect와 별개로 설정되어 적용이 되지 않았다.

그래서 think문을 지우고, connect와 emit을 하나의 단계에서 처리하도록 변경하였다.

- namespace: '/rooms'
        connect:
          query: 'roomId={{ roomId }}'
          headers:
            x-forwarded-for: '{{ $randomNumber(1000000, 9999999) }}'
      
        emit:
          channel: 'message'
          data:
            message: 'Test message'
            roomId: '{{ roomId }}'
      - think: 30

이러면 emit의 경우에도 namespace를 잘 찾을 수 있게된다.

투표

그냥 밑에 emit으로 투표 관련 내용 적으면 되겠지 했는데, 아니었다.

새로운 emit에 대해서는 또 namespace를 명시해줘야한다.

		 flow:
      - think: 1

      - namespace: '/rooms'
        connect:
          query: 'roomId={{ roomId }}'
          headers:
            x-forwarded-for: '{{ $randomNumber(1000000, 9999999) }}'
        emit:
          channel: 'message'
          data:
            message: 'Test message'
            roomId: '{{ roomId }}'

      - think: 1

      - namespace: '/rooms'
        emit:
          channel: 'vote'
          data:
            trackNumber: "{{ $randomNumber(1,2) }}"

규격

yml 파일이라 규격이 너무 엄하다. 들여쓰기, 스페이스 바 하나만 잘못 눌러도 무조건 인식조차 하지 못한다.

정말 유의해서 들여쓰기를 해야한다.

소켓 부하 테스트로 얻은 것

• HLS 프로토콜에는 영향을 주지 않는다. ⇒ 소켓에 많은 접속이 이루어지는 것과는 별개로 다음 음악이 잘 실행된다.
• 채팅이 사용자가 많아질수록, 렉이 걸리는데, 유실되는 채팅은 없다.
• 투표는 채팅보다는 덜 느리고, 나름 실시간으로 잘 작동된다.
• 사용자의 랜덤 아이디 부여가 되지 않는다. ⇒ 이전 사용자의 랜덤 아이디가 처리되기 전에 접속하는 것 같다.
  • message Evnet 처리할 때, randomId가 트래픽 몰림으로 인하여 잘 저장이 되어 있지 않은 이유인 줄 알았으나,
    connect 한 이후 바로 message Event가 처리될 때가 있었다.
  • 따라서, 중간에 대기 시간을 넣어주었더니 해결되었다.

=> 나름 잘 작동한다?

리포트도 볼 수 있네?

artillery는 HTML 리포트도 지원한다.

이걸 보기 위해서는, 먼저 결과를 JSON 파일로 변경해야한다.

yarn artillery run -e development socket-test.yml -o report.json

또 이 json 파일을 html로 변환한다.

yarn artillery report report.json

들어가보면,

이런 식으로 눈에 보기 쉽게 정리를 해준다..!!!