[SW 정글 119일차] 나만의 무기 27일차 (소켓서버 구조 변경)

오늘은 Artillery를 이용하여 스트레스 테스트를 이어서 하는 것으로 하루를 시작했다.

config:
  target: "http://localhost:5001"
  phases:
    - duration: 60
      arrivalRate: 5
      # maxVusers: 7
      name: Ramp up load
  payload:
    path: "test_file1.csv"
    fields:
      - "email"
      - "password"
      - "nickname"
​
scenarios:
  - name: "Test_case_2"
    engine: "socketio"
    flow:
      - log: "{{email}} socket connection 시도"
      - think: 1
      - log: "{{email}}  login 시도"
      - post:
          url: "http://localhost:5000/api/user/login"
          json:
            email: "{{email}}"
            pwd: "{{password}}"
      - get:
          url: "http://localhost:5000/api/user/challenges/ids"
      - log: "{{email}} Challenge-42 페이지 접근"
      - get:
          url: "http://localhost:5000/api/challenge/42"
      - get:
          url: "http://localhost:5000/api/chat/42"
      - log: "test"
      - emit:
          channel: "join"
          data:
            "roomId": "challenge-42"
            "userId": "user-1"
      - log: "Challenge room 입장"
      - loop:
          - emit:
              channel: "send_message"
              data:
                "room": "challenge-42"
                "user_nickname": "{{nickname}}"
                "message": "소켓 채팅테스트 중입니다."
                "time": "11월 29일 Test"
                "challenge_id": "42"
          - think: 1

같이 Artillery와 친해지고 있는 팀원이 짠 yaml파일이다.

간단하게 로그인하고 페이지에 접속하는 시나리오 이외에 여러 유저가 접속하여 채팅을 입력하는 시나리오를 짠 것이다.

일단은 테스트는 돌아갔고 남은 일은 결과 report를 분석하는 것이다.

지금의 서버 성능은 어느정도이고 어떻게 얼마만큼 개선시킬지...

일단은 생각한 방법은 로드밸런서를 이용하여 부하를 자동으로 분산시켜주는 방법을 생각하고 있고 선택해야하는 것은 현재의 우리 서비스에 도입이 반드시 필요한가이다.

도입 이유와 로드밸런서를 도입했으면 어떠한 로드밸런서를 도입하는지도 알아봐야한다.

웹 서버인 NginX가 제공하는 로드밸런싱을 사용할지 아니면 AWS에서 제공하는 Auto scaling과 ELB를 사용할지 아니면 더 괜찮은 것이 있는지...

 

 

그리고 우리의 서비스에서 소켓 서버의 통신구조가 바뀌었다.

기존에는 유저가 자신이 참여하고 있는 챌린지 어항에 접속했을 때 소켓통신이 핸드세이킹되고 해당 챌린지 어항에서 나가면 커넥션이 끊어지는 구조이다.

처음에 이 구조를 선택한 이유는 챌린지 어항 내에만 있는 유저들끼리만 인터렉션, 채팅 혹은 아직 도입되지 못했지만 감정표현같은 것이다.

 

하지만 우리에게 반드시 필요한 기능인 알림기능을 도입해야됨에 따라 구조가 바뀌었다.

바뀐 이유는 소켓통신 시점이 유저가 챌린지에 입장함에 따라 핸드세이킹이 이루어지고 한 유저가 다른 챌린지에서 일어난 인층요청, 인증수락 등과 같은 알림을 받아야하는데 받지 못한다.

그래서 로그인 시에 유저가 가입하고 있는 챌린지 ID를 이용하여 소켓통신 커넥션을 생성해주었다.

이렇게 되면 특정 챌린지방에 들어가지 않아도 다른 챌린지에서 일어난 일들에 대한 메시지를 받을 수 있게 된다.

좋은 방법인지에 대한 생각이 있었지만 오늘 멘토링을 통해 우리의 방법을 설명하고 페이스북이나 기타 서비스에서는 어떠한 구조로 설계되었는지에 대해 물어봤을 때 우리가 선택한 방법이 틀리지 않고 비슷한 구조일 것이라는 말을 들었다.

 

 

 

<해야할 일>

팀의 목표에 빠르게 도달하기 위해 내가 프론트개발에서 도움을 줄 수 있는 것 찾아서 기여하기

로드밸런서 알아보기

소켓서버가 분리되면 소켓서버끼리 통신할 수 있는 방법 모색하기

DB 준학사 되기