-
퍼블릭 서브넷만 사용하면 어떤 이슈가 있길래 두개로 나누셨나요?
- WAS로 ddos 공격이 들어오거나 데이터베이스 서버로 접근하여 데이터를 탈취하려는 시도가 있을 수 있고, 보안상 was 및 db 서버의 아이피는 최대한 감추는 것이 좋을 것 같다고 판단했습니다.
-
스테이징 서버구성하셔서 많이 에러를 잡을 수 있었나요? 대표적으로 기억나시는 점이 있나요?
- 웹소켓 연결 전에 이벤트가 호출되어 에러가 나는 것을 staging 환경에서 확인할 수 있었습니다. 해결책으로 메세지 큐를 도입하여 안정화한 후에 실제 서버에 배포하였습니다.
-
git 전략을 main - develop - feature로 짜신 이유가 있나요? develop과 main의 차이가 크지 않은 것 같습니다.
- 저희가 매주 배포를 목표로 잡아서 main은 항상 배포 가능한 상태를 유지하기 위해 main과 feature 사이에 develop 브렌치를 두었습니다. 그리하여 develop 브렌치에서는 아까 말씀드린 staging 환경처럼 실제 배포 환경과 거의 유사한 환경을 구축하여 테스트를 진행한 후에 실제 배포를 진행했습니다.
-
개발 환경에서도 staging 환경을 사용할 수 있나요?
- 환경설정 파일을 잘 만들어놔서 가능합니다.
- 스테이징 환경의 특성상 최종 테스트를 위한 공간으로활용하고 있어서 개발 환경과 분리되어 있습니다.
-
이벤트 기반으로 처리한 퀴즈진행 흐름 하나만 설명해주세요!
- 우선 채팅에 대한 이벤트 처리가 있습니다. 클라이언트가 채팅 이벤트를 서버로 보내면 채팅을 받아야 하는 대상에게만 채팅 이벤트를 브로드 캐스팅하여 채팅 내역을 보내게 됩니다.
PlayService에서 볼 수 있듯이, 퀴즈 제출 이벤트를 예로 들면:
1. 클라이언트가 submit 이벤트 발생
2. 서버는 현재 퀴즈 상태 확인 (PLAY 상태인지)
3. 답안 채점 및 점수 계산
4. 다른 제출한 참가자들에게 제출 현황 브로드캐스트
5. 마지막 제출자면 다음 퀴즈로 진행
-
socketio랑 성능 비교해보셨나요?
- 직접 성능비교는 하지 않았지만 nestjs 공식 문서에서 확인하였습니다.
-
퀴즈에 새로고침이나 재접속할때 어떻게 현재 진행 정보를 받아오나요?
- 새로고침이나 재접속하게 되면 서버로 rest API get요청을 보내고, 이에 대한 응답으로 서버에서 상태와 시간에 따라 실시간으로 변화하는 정보를 가져와 렌더링 해주게 됩니다.
-
300명으로 잡은 기준이 있을까요?
- 부스트캠퍼 대상으로 만들었기 때문에 300명 사용자를 기준으로 잡았습니다.
-
인메모리에 퀴즈존에 대한 정보를 저장하면 추후에 서버가 수평 확장됐을 때는 어떻게 처리하실 생각이신지요?
- 인메모리로 관리하고 있으나, 인터페이스 기반으로 설계되어 있어 Redis나 다른 저장소로 쉽게 교체 가능하도록 구현했습니다.
-
was서버가 갑자기 죽으면 진행중인 메모리에 들고있는 데이터가 전부 사라지는 거 아닌가요?
- 맞습니다. 현재 인메모리에 저장하고 있어서 서버가 죽으면 데이터가 유실되는 문제는 인지하고 있습니다. 추후에 서버를 확장하며 인메모리에서 레디스로 교체할 것이고, 레디스의 RDB나 AOF를 활용해서 데이터의 영구성을 지켜 줄 생각이요.
-
인메모리에 퀴즈존을 저장하셨으면 들고 있는 데이터는 계속 쌓여서 메모리 점유가 커지지 않나요?
- 퀴즈가 종료되면 퀴즈존 객체를 삭제시키고, 그렇게 되면 노드의 가비지 컬렉션이 가비지가 된 퀴즈존 객체를 메모리에서 지우기 때문에 메모리 점유는 리셋될 것입니다.