[간단한 퀴즈 서비스] 2차 개발 회고

 배포와 기능 추가를 위한 2차 개발을 위해 2024년 9월 초부터 평일 9일간 09:30 ~ 12:30 코어 타임을 가졌었다.

백앤드는 나 혼자이며 프론트는 1차 개발 때와 같이 세 분이서 담당해 주셨다.

 

 이번에 했던 주요 활동들은 아래와 같다.

• AWS EC2, Rout53 등을 이용한 배포
• 퀴즈 데이터 셋 서버 메모리에 JS map자료구조로 저장하던 것에서 DB 이관
• 랭킹 정보 페이지네이션으로 표현
  • 과거에는 1~3등, 나의 랭킹 및 위, 아래 1명 랭킹만 보여줌
• 무한 퀴즈 챌린지
  • 퀴즈에 틀릴 때까지 퀴즈를 계속 풀 수 있음

 

2주간의 코어 타임 동안에는 배포, 랭킹 정보 페이지네이션, 퀴즈 데이터 셋을 DB로 이관하였다.

무한 퀴즈 챌린지 부분은 2주간의 코어 타임 이후에 본격적으로 진행되었다.

 

무한 퀴즈 챌린지는 틀릴 때까지는 문제를 계속 풀 수 있어야 하고 문제마다 15초의 시간제한이 있다.

무한 퀴즈 챌린지에서는 몇 번째 도전의 기록인지, 기록을 갱신 중인지 구분을 할 수 있어야 했기에 이 부분에서 고민할 게 다른 파트에 비해 많았다.

 

유저가 퀴즈를 풀던 도중에 사이트에서 빠져나간다면?

유저의 n번째 도전과 n+1번째 도전을 어떻게 구분할 것인가?

유저한테 챌린지 id를 갖게하면 조작할 수 있지 않을까?

 

이를 방지하기 위해, 무한 퀴즈 챌린지를 시작할 때, 챌린지 id를 만들어서 서버에 저장한다.

시간제한(timeout)은 1분을 주며, 유저가 문제를 1개 맞힐 때마다 15초의 시간 연장 한다.

 

문제에 틀리거나 챌린지 id에 설정한 timeout 시간이 지나버리면 챌린지 id를 서버에서 지워버린다.

바로 유저가 무한퀴즈 챌린지를 다시 하는 경우 서버에는 좀 전에 해당 유저의 챌린지 id를 지워서 유저에 대한 챌린지 id가 없으므로 새로운 챌린지 id를 발급한다.

 

유저가 세 번째 도전 중에 퀴즈를 풀지 않고 바로 무한 퀴즈 챌린지 눌러서 바로 도전한다면,

timeout 지나지 않았고 이전 도전에서 문제에 틀리지 않았기에 서버에 챌린지 id가 남아있기에 세 번째 도전으로 기록된다.

 

사실 화면에서 벗어나면 챌린지 id를 지워버리고 싶었지만 그렇게 되면 클라이언트 단에서 서버에 빠져나갔다는 신호를 주어야 하는데, 브라우저 자체를 끈다거나 컴퓨터를 끈다거나 등등의 경우에서 대응하기 힘들었다.

그랬기에 문제를 틀리지 않았고(아직 연속 정답 중) timeout 시간이 지나지 않았으면 도전이 끝나지 않은 것으로 보기로 하였다.

 

서버에 챌린지 id를 저장하는 부분은 map으로 처리하였다.

DB에 저장하기에는 문제 하나를 풀 때 시간제한이 15초 이기에 15초 이내의 시간마다 DB에서 챌린지 id를 가져오고,

문제가 틀렸을 때는 DB에서 챌린지 id를 지우는 게 성능상에 지장을 줄 것이라 생각하였기에 서버 메모리에 남기었다.

Redis를 쓰면 좀 더 timeout 이나 그 외 관리하기 좋았겠지만 AWS free-tier의 EC2는 1GB이기에 Redis를 띄우기에는 메모리가 적어서 서버에 부담 주고 싶지 않았다. AWS에서 제공하는 Redis를 쓸 수도 있겠지만 그건 비용 때문에 선택하지 않기로 하였다.

트래픽에 따라 서버에 부하가 걸리는 추이를 보면서 Redis를 적용할지 말지를 정하기 하였다.

 

코어 타임(9월 1,2째 주) 이후에 팀원 분들은 다음 프로젝트와 취업, 학업이 있으셨고

무한 퀴즈 챌린지는  코어 타임 이후(9월 3,4째 주)에 개발되었기에 프론트 파트에서는 아직 무한 퀴즈 챌린지가 적용되지 않았다.

서비스도 조금씩 유지보수하면서 보완하고 있다.

 

 

배포와 DB 이관, 무한 퀴즈 챌린지 부분을 구현한 것은 뿌듯 하였으며 아직 남은 개선사항들은 테스트, 로그, 모니터링 툴(센트리, 그라파나, 프로메테우스), CI/CD 부분이 남아있다.