1. 어려웠던 부분 : 오늘 아침에 멘토님의 예상 질문을 받고 팀원들과 답변을 준비했다. 어떤 문제는 질문 자체도 잘 이해가 되지 않았다. 그리고 예상치 못한 부분도 있었다. 우리가 너무 생각없이 Redis를 서브 디비로 사용한건가 라는 생각에 뒷통수를 맞은 느낌이었다. 아래는 질문과 우리가 준비한 답변이다. 


- 여러 기수의 프로젝트에 의아한 부분이었는데, Redis 는 메모리 기반의 DB 이지만 휘발성을 가진것은 아니다. 그러면 DB 가 아니라 Cache 정도로 명명하지 않았을까?

  • Redis를 단순히 캐시로 사용하는 것 뿐만 아니라 RDB(SnapShot), AOF 와 같은 방식으로 일정 주기와 명령어를 통해 데이터를 보존할 수 있다는 것을 알고 있다. 그런데 우리 서비스에서는 게임을 하고 있을 때에만 필요한 데이터를 Redis에 저장해서 사용하고 있다. 게임이 끝나면 바로 삭제하는 일시적 데이터라 영속화할 필요가 없어 휘발성이라는 단어에 초점을 맞춰 선택했다고 설명했으나, 생각해보면 우리의 일시적인 데이터도 휘발성에 의존하고 있지 않다. 시간을 정해주고 데이터를 날리는 것이 아니고, 서버가 주기적으로 다운되는 것도 아니며 우리의 로직으로 데이터를 삭제하고 있기 때문이다.
  • 이 부분에 있어서는 우리 로직에 Redis 선택의 이유로 휘발성을 넣은 것은 잘못된 부분이라고 생각한다. 빠르고 접근하기 용이하며 비용 절감이 가능하기에 Redis를 선택했다 라고 설명하는 것이 맞는 것 같다.

- 개발자 입장에서 동시성에 성능문제를 풀려하지말고, 로직으로 고민하는 지혜가 필요하다. 심지어 Mesh 를 사용중이라면 충분히 MySQL 로도 처리 가능하다고 생각하는데, Redis 를 사용하지 않는 어떤 방식으로 풀지?

  • 무슨 소리인지 못 알아들었다.
  • 현재 WebRTC를 P2P 방식으로 사용하기 때문에 서버 부하가 적을 것으로 예상되어 게임 로직에 필요한 데이터를 굳이 Redis를 사용하지 않고 MySQL에 저장해서 사용하는게 낫다는 말씀이실지

- 비관적락/낙관적락 둘 모두 트랜잭션 외의 트랜잭션의 작업을 블록하거나 무시하는것인데, 실시간성이 중요한 로직에서 적합한지 의문, 차라리 MVCC 솔루션이 좋지 않을지. 비관적락의 특성과 그걸 사용하려는 이유에 대해 서술

  • 동시성을 제어하는 대표적인 방법이 낙관적 혹은 비관적 락으로 알고 있어서 해당 방법을 사용하려고 했다.
  • 비관적락의 특성은 미리 충돌이 발생할 것을 예상하고 미리 락을 거는 것인데 충돌이 없으면 오버헤드가 발생한다는 단점이 있다고 알고있다.
  • 실시간성이 중요한 게임이지만 실제 서비스에서 비관적 락을 걸었을 때 딜레이가 얼마나 발생하는지 레퍼런스가 없었기 때문에 우선적으로 시도하고자 했다.

- 무중단 배포 지원에 대해서 구체적으로 어떤 전략을 가지고 있는지

  • 무중단 배포를 이제 막 시작하려는 단계여서 디테일한 전략이 정해지진 않았지만, Nginx를 활용해서 하나의 서버로 Blue-Green 형식의 무중단 배포를 생각하고 있습니다.
  • EC2 프리티어 1대로 구성한 다음 Port를 2개로 나눠 블루-그린 배포 방식으로 진행할 것이다. 비용 측면에서 이 방식이 효율적이라고 생각했다. 새로운 버전 또한 기존 EC2 인스턴스에 그대로 적용하면 되므로 배포를 위해 AWS EC2 인스턴스가 추가로 더 필요하지 않다. 구조는 EC2 혹은 리눅스 서버에 Nginx 1대와 스프링 배포 파일 Jar 2대를 사용하면 되므로 간단하다.
    • Nginx에는 80(http), 443(https) 포트를 할당한다.
    • 스프링 1에는 8081 포트를 할당한다.
    • 스프링 2에는 8082 포트를 할당한다.

- validateToken 의 경우 info 가 아닌 공통으로 정의한 StatusCode 로 CustomException 발생시킨 후 Advise 에서 캐치해도 좋을듯한데, 이에 대한 의견

  • 멘토님 말씀이 맞다. 지금 그 부분만 공통 처리 부분에서 제외가 되어 있는데, 이 부분에 대해서 미처 생각하지 못했다. 추후에 수정하도록 하겠습니다.

2. 느낀 점 : 중간 회고 발표를 통해 우리에게 어떤 부분이 보안되어야 하는지 알 수 있었다. 발표는 리더분이 해주셨는데, 나도 혼자서라도 남들에게 발표하고 설명하는 연습, 말하는 연습을 해야겠다고 느꼈다. 설명을 잘 할 수록 면접을 볼 때에도 도움이 많이 될 것 같다. 말을 차분히 잘 하는 사람들을 보면 참 멋있고 부럽다 ! 

 

3. 새로 알게 된 내용 : 발표를 통해 우리가 왜 이 기술스택을 선택했는지에 대한 부분이 많이 부족하다는 것을 알게되었다. 그리고 Redis를 사용한다고 비용적으로 MySQL에 비해 그렇게 저렴한것도 아니라는 사실도 알게되었다. 중간 회고 발표가 끝난 후 팀원들과의 회의를 통해 오늘 기술스택 선정 이유를 다시한번 정리해 보았다. 그리고 다음주에 Redis에 저장하고 있는 GameSet부분을 MySQL로 돌려보고 동시성제어를 잡아보기로 했다. 

 

4. 셀프칭찬 (오늘 잘한 일) : 오늘은 명절 전이고 다들 지쳐있어서 일찍들 퇴근을 했다. 퇴근하기 전에 다른 팀원분들에게 부탁해서 같이 만든 게임을 해보았다. 생각보다 다들 재밌어해주셔서 뿌듯했다 : ) 

 

5. 내일 할 일 : 이번주 WIL 정리하기


[오늘 공부한 부분] 

 

중간회고 질문

FE.

www.notion.so

https://www.notion.so/cef12775fbfa4eb6941094ce084dfb6c

 

중간회고 피드백

FE.

www.notion.so

 

+ Recent posts