해당 아키텍처를 도입하게 된 배경

🚨 API 설계규칙

Rest API URI 설계규칙을 따른다.
  1. 후행 /는 URI에 포함하지 않는다.
  2. 계층관계를 나타낼 때 슬래시 구분자를 사용한다. ex) /rooms/{roomId}/quizzes/{quizType}
  3. 긴 path를 표현하는 경우에는 가독성을 높이기 위해 하이픈(-)을 사용한다.
  4. 언더바(_)는 URI에 사용하지 않는다.
  5. URI는 모두 소문자로 작성한다.
  6. 파일확장자는 URI에 포함하지 않는다.
  7. 모든 resource는 복수형을 사용한다.

메인페이지에서 변경된 방 정보를 업데이트하기 위해 1초 간격으로 Room 리스트 조회하기 api를 요청(Polling)

메인페이지에 접속자가 집중되면 서버 부하 증가 → 배포 이후 메인페이지 40명 정도 접속하면서 CPU 90%로 급증

📍 서버를 t3.micro으로 변경(CPU 1 → 2)하여 우선 조치(메모리는 Swap으로 늘려놓은 3G로 충분하다고 판단)

메인페이지 접속자 수에 따른 서버 부하를 확인하기 위해 테스트 진행

Client의 메인페이지 접속자 수를 10 단위로 증가시키면서 CPU 사용량을 실시간 관찰

① CPU 사용량이 급증 ② 전체 200 중 180%까지 올라가는 지점을 한계로 봄

- api 요청 간격 1초(현재 상태) : 70명
- api 요청 간격 1.5초 : 80명
- api 요청 간격 2초 : 100명

현재 서비스 수준에서 70명 이상이 메인페이지에 접속할 가능성은 낮고,

업데이트 간격을 2초로 늘리면 오히려 유저 경험이 안좋아 질거라고 판단

서비스가 성장한다면, Polling이 아니라 다른 방법으로 문제 해결을 시도하는 것이 더 나을 것!

NodeJS의 undefined 에러로 인해 서버가 재시작되면서 각 브라우저의 roomID 초기화

socket.io의 방 구분 기능이 정상적으로 작동하지 않음

📍 NodeJS의 에러를 해결하여 서버가 재시작되지 않도록 조치

브라우저의 마이크 사용 권한을 제한하면 게임 플레이 불가

브라우저에 따라 권한 허용 방법을 설명하는 창을 띄워 다시 서비스 이용할 수 있도록 안내