위코드 프리온보딩 백엔드 과정 - 회고 2주차 1회 (레드브릭)

이번 과제는 레드브릭이라는 게임제작 플랫폼 기업의 과제를 하게 되었다.

개발 요구사항

• 회원가입
• 게임 제작하기
  • 제작 중 단계의 게임을 '프로젝트'
  • 프로젝트는 "실시간"으로 반영
• 게임 출시하기
  • 프로젝트 당 퍼블리싱 할 수 있는 개수는 하나입니다. 퍼블리싱한 게임은 수정할 수 있어야 하며, 수정 후 재출시시 기존에 퍼블리싱된 게임도 수정
  • 출시하는 게임은 다른 사용자들도 볼 수 있으며, 사용자들의 조회수 / 좋아요 등을 기록 가능
  • 게임 혹은 사용자 검색'을 통해서 찾기 가능

개발 과정

행복의 주말이 지나고, 또 노력의 마라톤이 시작되었다. 이번 기업과제는 게임제작 플랫폼 기업의 과제였는데 크게 어려운 부분은 없었다.

 

다만 실시간 저장이라는 기능이 문제였는데, 기존의 RestFul Api의 개념에서는 요청과 응답이기때문에 실시간 저장이란게 성립하기 힘들지않나? 싶다는 것. 물론 복잡하게 구현한다면야 되겠지만...그래서 어쩔 수 없이, 실제 기업이 제공하는 플랫폼처럼 게임제작 파트는 브라우저를 통해 socket 통신을 하기로 결정했다. 

 

socket 부분에 있어서는 경험이 있었기 때문에 별로 어렵지는 않았다. 그보다는 위에서 말한 실시간 저장의 설계가 또 고민이었다.

 

1. 데이터를 저장하는 방식

• 설계상으로는 만드는 게임의 코드와 정보를 단순히 하나의 string으로만 추상화해놨는데, 실제 게임제작데이터는 꽤나 용량이 나갈게 분명했다. 그래서 게임데이터를 매번 통채로 받아서 저장하면 비효율적이지 않나? 라는 고민.
• 해결법으로 GIT의 Commit 시스템처럼, 매번의 변경 내역만 받아서 원본 데이터와 비교하여 적용하는 방법을 생각해봤다. 일종의 히스토리방식.
• 좋은 해결책 같았지만, 1.5일이라는 시간 내에 구현하기엔 너무 복잡하고 버그 잡기에도 어려울 것 같아 어쩔 수 없이 통채로 저장하도록 했다.
• 시간과 경험만 있었으면 이 방식으로 갔을텐데 라는 아쉬움이 남는다 :(

2. 데이터 저장을 트리거 하는 방식

• 클라에서 요청을 언제 보내느냐에 대한 얘기.
• 처음에는 일정 시간 단위로 단순히 데이터를 보내는 것을 생각했지만, 단위가 길어지면 실시간 저장이 힘들고. 짧아지면 너무 빈번한 저장으로 성능에 좋지 않다는 생각이었다.
• 그렇다고 사용자가 데이터를 변경할 때마다 요청한다면 1초에 수십번의 요청 및 쿼리실행이 될 것이라 생각하여 개선방안을 생각해보기로 했다.
  
  
  
  간단한 코드입력에도 수십번의 저장을 시도하는 모습
  
  
• 1차적으로, 서버에 버퍼를 두는 방식을 생각했다. 클라이언트가 저장요청을 보내면 서버는 해당 데이터를 버퍼에 임시보관하고, 일정 시간 뒤 버퍼의 최신 데이터를 DB에 저장하도록 구현했다.
  
  
  
  받아온 정보를 버퍼에 저장하는 부분

     

     일정시간 뒤, 정보를 DB에 저장하는 부분

• 이를 통해 어느정도의 성능개선을 기대할 수 있었지만, 클라이언트에서의 많은 요청은 여전했기에 요청 수를 줄이기로 했다.
• 클라이언트에서도 저장요청에 일종의 CoolTime을 쓰도록 바꿨다.
  
  
• isCoolTime 변수와 setTimeout을 이용해, 정보를 여러번 변경하더라도 1초 뒤에 하나의 요청만 하는 구조이다.
  
  

     

• 그 결과 이전과 똑같은 방법으로 테스트했을 때, 90번에 달하는 저장 요청이 9번의 버퍼저장과 4번의 DB쿼리 실행으로 줄어들었음에도 실시간 저장이 가능해졌다.
• 서버의 저장간격과 클라이언트의 저장요청간격을 서로 다르게 할 수 있다는 점이 장점으로 보인다.
  단점은 서버가 중간에 뻗으면 간격설정에따라 꽤나 긴 내역이 날라간다는 것?
• 사실 네트워크든 게임에서든 쓰이는 테크닉이라 기본중의 기본이긴 하지만, 결정하기 까지 되게 오래걸렸다. 위에서 말한 히스토리 저장방식이나 2중 버퍼 등등 여러 방안을 생각해봤기 때문. 결국은 개발기간 1.5일이라는 제약때문에 대부분 포기했다...

 

 

 

끝내며

회고록의 양식이 어째 매번 바뀌는데, 어떤 식으로 써야할지 여전히 고민이다. 아무래도 강의에서 멘토님이 말씀하신 것처럼 자기의 노력과 실력을 뽐낼 수 있는 부분을 중점으로 적어봐야겠다.