P: UI/UX 관련 피드백은 아니지만 퀴즈와 퀴즈 사이 간격이 좀 긴거같아요, 앗 30초 말씀드리는게 아니라, 다음 퀴즈 준비중입니다. 뜨면서 5초 기다리는게 좀 길다고 느꼈던 거였어요!
A: 그거는 기본 문제라서 일단 30초 정도로 지ㅌ정 되어져 있습니다. 차후에 문제 생성 단계 까지 가면 짧게 해드리겠습니다. 아 그것도 조절을 해보겠습니다 ㅎㅎ
이후에 문제를 사용자가 출제할 수 있도록 하는 것을 계획하고 있는데 그때 출제자가 제한시간 등을 지정할 수 있도록 적용해볼 예정이에요
서버와 클라이언트의 동기화에 대한 처리를 서버에서 응답 지연이 발생핬을 때 충분히 고려하기 위해서 5초를 기다리도록 설정했는데요! 5초 기다리는 것은 저희도 해보니 조금 길더라구요..ㅎㅎ 단축을 고려하고 있습니다,(백엔드 마스터클래스에서 호눅스님이 이야기해주셨던 크래시오브클랜의 로딩 시간을 응용해봤어요)
퀴즈 중간 텀은 일단 5초로 처리했고 이 부분은 조절할 수 있습니다. 300명이 목표이기 때문에 모든 사용자가 동시에 렌더링 될 수 있는 최소한의 시간으로 텀을 만들어볼 생각입니다.
신이 화나면 뭐지요?(ㅅㅂㄲ) 신발끈!
??
발표를 듣고 궁금한 점에 대한 질문이나 피드백
Q: 퍼널 패턴의 단점이 있다면 어떤 게 있을 수 있을까요?
A: 아직 구현 초기여서 확실한 단점이 구체적이지는 않지만, 바로 생각해볼 수 있는 단점은 퍼널 커스텀 훅에서 상태 업데이트 시에 불필요한 리렌더링 가능성이 있다는 것입니다. 실제로 커스텀 훅에서 제공하는 함수들이 다수 있는데요. 해당 함수들이 타이머 상태가 변경 될 때 마다 생성 되는 문제 등이 실제로 개발 과정에 보였습니다. 이런 부분에 대해서는 useCallback, useMemo, 등을 활용하여 최적화 하는 경험을 할 수 있을 거라 기대하고 있습니다.
Q: 현재 아키텍처는 어떻게 되어있나요?
A: 프론트엔드 정적 파일을 제공할 웹서버(nginx) API, WebSocket 서버(Nest)가 다른 서버에 각각 배포되어있습니다. (RDB 등 요소는 현재 버전에서 활용되지않아 없지만 이후 기능 추가시에 새로 배포될 것 같아요)
A: 백엔드는 퀴즈존 API, 퀴즈 진행을 위한 play(WebSocket) 정도로 도메인이 나뉘어있어요
Q: 퀴즈 시작 종료는 이벤트로 해결하시나요? redis같이 사용하시는 기술이있나요?
A: 넵, 모든 퀴즈를 제출하고 나면 서버에서 WebSocket을 이용해 퀴즈 종료 메시지를 발신해주는 방식으로 구현되어있어요
A: 레디스는 추후에 세션 데이터가 커지면 도입할 예정입니다. 현재는 서버의 메모리만을 이용하여 한 세션에 한 사용자에 대한 정보만 저장하고 있어요
Q: socket io를 사용하지 않고 Websocket 자체를 사용하신 이유가 있을까요?
A: 저희 서비스가 서버에서 퀴즈 진행을 처리하기 때문에 어느정도 시간이 지연될 경우 퀴즈 전반적인 진행에 딜레이가 발생할 수 있어 사용자 경험이 많이 떨어질 수 있습니다. 그래서 조금이라도 좋은 성능을 보여주는 ws를 활용하여 최대한 변수를 줄이려고 했습니다.
A: socket.io가 많은 편의 기능들을 제공하지만 일단 퀴즈프로그램에서 필요한 기능마다 하나씩 직접 구현해볼 예정입니다. 그리고 ws가 성능이 빨라 선택했습니다,
Q: was를 퍼블릭 서브넷이 아닌 프라이빗 서브넷에 두신 이유가 있을까요?
A: 현재 배포되어있는 nginx가 리버스 프록싱을 통해 웹서버로 요청을 전달하고있어요. 그러한 구조라면 굳이 퍼블릭으로 둬야 할 이유가 없다고 판단했습니다.
Q: 성능에는 큰 차이가 없을까요? 요청에 대한 응답 속도?
A: nginx 자체 성능이 매우 좋은 편 이기도 하고, 현재 저희가 고려하고있는 트래픽 정도에서는 영향이 거의 없다고 보셔도 좋을 것 같습니다.
A: 또 두 서브넷에 대해 vpc설정도 해둬서 두 서브넷 사이의 통신은 원활할 거라 예상합니다!
답변 감사합니다!
Q: 네이버클라우드는 private subnet에 NAT 없어도 인터넷 되는걸로 압니다
A: 오 그런가요?! NAT가 비용이 계속 청구되어서 아깝다고 생각했는데 제거하는 것을 고려해봐야겠네요! 감사합니다 :)
비공인 IP로 접근하면 되실 겁니다
Q: 정답제출과정에서 사용자가 종료 직전에 정답을 제출한 경우, 서버에서 이 요청이 씹힐수있는 문제는 어떻게 해결하셨나요?(또는 예정이신가요)
A: 서버 내부에서 제출 시간과 응답이 도착한 시간을 고려하여 채점하는 로직을 수행하고있어요!
서버 내부에서도 타이머를 통해 답변 제출 시간이 지났을 경우 오답으로 처리하는 안전장치도 있습니다.
GIthbuc action에서j 네이버 클라우드에서 SSH와 SCP로 docker 파일을 전송하시는 거 같은데 혹시 acg, acl 0.0.0.0에 열려있나요?저희는 전체에 대해서 열었다가 이후에 메일이 와서요. 비공인 ip에서 접속 시도로 경고 메일이 왔습니다... action에서 naver cloud platform acg 를 추가하고 배포 후 acg를 제거하는 로직을 추가해 놨었던 것 같아 이야기 드려봅니다.
서비스 시연이나 데모에 앞서 해결한 문제가 있다보니 어떤 맥락으로 고민을 한건지 알기 어려운 것 같아요. 기능이나 서비스 소개가 조금 더 디테일했다면 왜 이런 고민을 하셨는지 청중이 이해하기 수월할 것 같습니다.✅
피드백 감사합니다 :) 이후 발표에는 고려해볼 수 있는 내용같네요
socket.io가 아닌 웹소켓 자체를 선택하시게 된 사유가 궁금합니다!✅
구현 전 기술 선택 과정에서 nest의 기본 websocket 기능 구현이 socket.io로 지정되어있는 것을 확인했지만, ws를 활용하는 것이 성능상 유리하다는 정보들을 많이 확인할 수 있었습니다. 참여하고 있는 모든 사용자들이 동시에 퀴즈 진행하는 문제가 저희 비즈니스로직에 가장 중요한 만큼 지연 시간을 최대한 줄이기 위해 선택했습니다.
socket.io는 많은 기능들을 편하게 제공하고 있는데, 저희가 필요한 기능들을 직접 구현해보는 경험을 해보고 싶었습니다.