기술 스택을 정리하다 데이터 베이스 종류와 구조에대해 정리를 하고 가면 좋겠다고 생각했다. 현재 우리는 gameStartSet 정보를 인메모리 디비인 Redis를 사용하고 있는데, 멘토님은 RDB인 MySQL사용을 추천해 주셨다. 그 차이가 뭔지 정리해 보자.

1. RDB(Relational Database)

• RDB는 관계형 데이터 모델을 기초로 두고 모든 데이터를 2차원 테이블 형태로 표현하는 관계형 데이터베이스
• 대표적으로 Mysql, Oracle, PostgreSql 등이 가장 많이 알려진 RDB. 아래의 그림과 같은 구조를 나타낸다.

- 특징

• 테이블(Table) 마다 스키마(Schema)를 정의해야 된다
  •  스키마
    데이터베이스에 저장되는 데이터 구조와 제약조건을 정의한 것
    스키마 : 데이터베이스 : 테이블 = 평면도 : 집 : 방
• 데이터 타입과 제약(Constraint)를 통해서 데이터의 정확성을 보장함
• SQL 질의문을 통해 요청을 처리
• 성능을 높이려며 하드웨어(H/W)를 고성능으로 교체해야 된다. (Scale Up)
•  고성능 하드웨어는 가격이 비싸기 때문에, RDB의 성능을 높이거나 확장하기 어렵기 때문에 확장성에 좋지 않다.
• 구성된 테이블이 다른 테이블들과 관계를 맺고 모여있는 집합체
• 이러한 관계를 나타내기 위해 외래 키(foreign key)라는 것을 사용
• 이러한 테이블간의 관계에서 외래 키를 이용한 테이블 간 Join이 가능하다는 게 가장 큰 특징입니다.

DBMS database management system

사용자와 데이터베이스 사이에서 사용자의 요구에 따라 정보를 생성해 주고 데이터베이스를 관리해 주는 소프트웨어

RDBMS Relational Database Management System

사용자의 요구에 따라 정보를 생성해 관계형 데이터베이스를 생성하고 수정하고 관리할 수 있는 소프트웨어

2. NoSQL(Not only SQL)

• 대표적으로 mongoDB, hBase, redies(key-value) 등이 있으며, mongoDB의 경우 문서(document)형 데이터베이스이다.
• hBase 같은 경우는 빅데이터 처리를 한다고 하면 누구나 한번쯤은 들어봤을 법한 DB. 아래의 그림과 같은 구조를 나타낸다.

- 특징

• RDB의 확장성 이슈를 해결하기 위해 나온 데이터베이스 모델
• 분산 컴퓨팅 활용이 목적이고, 이것을 통해 비교적 저렴한 가격으로 DB 성능을 높일 수 있다. (Scale Out)
• 여러 개의 테이블이 아닌, 큰 테이블 하나만을 사용
• 가장 많이 쓰이는 NoSQL의 방식은 key-value방식으로 데이터를 관리한다
• SQL 질의문을 사용하지 않는다.
• Schema-less (구조 변경이 용이하고, 데이터 형식이 다양하며, 바꾸기 쉬우며, 정확성 보다는 데이터 양이 중요한 빅데이터(Big Data)에 사용
• NoSQL에서는 RDBMS와는 달리 테이블 간 관계를 정의하지 않음
• 데이터 테이블은 그냥 하나의 테이블이며 테이블 간의 관계를 정의하지 않아 일반적으로 테이블 간 Join도 불가능

3. In-Memory DB

• In-Memory DB의 경우에는 NoSQL 방식에 속하는 데이터베이스 이며, key-value방식을 사용하고 있다. 아래와 같은 구조를 갖는다.

- 특징

• Memory의 가격이 용량 대비, 충분히 낮아지면서 빠른 데이터베이스 성능을 위해서 등장했다.
• 디스트(Disk) 대신 메모리(Memory)를 사용함으로써, I/O(input/output)의 성능을 높여준다.
• 대표적으로 Redis 및 LMDB 등이 있다

RDB(관계형 데이터베이스)를 RDBMS(데이터베이스를 관리)로 생성하고 수정하고 관리한다.
SQL은 RDBMS를 관리하기 위해 설계된 특수 목적의 프로그래밍 언어이고,

NOSQL(비관계형 데이터베이스)는 RDB 형태의 관계형 데이터베이스가 아닌 다른 형태의 데이터 저장방식.

[ 참고 자료 ]

https://im-designloper.tistory.com/67

https://toma0912.tistory.com/83

발표 관련

• 멘토님이 우리가 배포한 사이트에 접속했을 때 카카오 로그인이 안되고 회원가입이 잘 안되는 상황이었다. 
  • 배포당시 프론트엔드에서 카카오로그인 리다이렉트 주소를 로컬 서버로 해놓았기 때문 ( 수정 완료 )
  • 회원가입 비밀번호 유효성검사 토스트가 띄워지지 않았던 상황이라 아마 비밀번호입력에 문제가 있었을 듯. ( 수정 완료 )
• 발표는 찍어놓은 영상으로 하지말고 직접 페이지 들어가서 시연하는게 좋음. 영상을 활용하면 신빙성이 떨어진다.
• 아키텍쳐 기술은 다 설명할 필요 없이 대략적 개요를 설명하고 디테일한 부분을 슬라이드 따로 빼서 좀 더 상세히 설명하는 식으로 하는게 좋다.
• 발표는 스크립트 읽는것이 아니라 자연스럽게 하기

기술관련 질문 

• 프론트엔드 서빙을 위한 서버를 따로 두었는지 ?
• 프론트엔드와 백엔드 배포는 어떻게 하고 있는지 ? 
• EC2 Nginx 를 사용해서 경량화를 하는게 어떤지 제안해 주심

백엔드 질문

• 레디스를 휘발성을 가졌다고 표현하는 이유는 ?
• 레디스의 특성을 설명해 보세요.
• 코드상으로 Redis가 아니라 MySQL을 사용해도 충분한데 왜 굳이 Redis를 사용했는지 ?
• 동시성 제어에 비관적 락을 사용하는 이유?
• 무중단배포 어떻게 할 계획인지 ? 
• 기술 선택 부분의 설명이 아쉽다. 이 부분을 잘 준비해야 면접 질문에 대비할 수 있다.  

피드백 받고 작성해본 기술 선택 부분 정리

https://www.notion.so/cef12775fbfa4eb6941094ce084dfb6c

Refresh Token 을 사용하는 이유

• Access Token 만을 통한 인증 방식의 문제는 만일 제 3자에게 탈취당할 경우 보안에 취약하다는 점이다. Access Token은 발급된 이후, 서버에 저장되지 않고 토큰 자체로 검증을 하며 사용자 권한을 인증하기 때문에, Access Token이 탈취되면 토큰이 만료되기 전 까지, 토큰을 획득한 사람은 누구나 권한 접근이 가능해 지기 때문이다.
• JWT는 발급한 후 삭제가 불가능하기 때문에, 접근에 관여하는 토큰에 유효시간을 부여하는 식으로 탈취 문제에 대해 대응을 하여야 한다.
• 이처럼 토큰 유효기간을 짧게하면 토큰 남용을 방지하는 것이 해결책이 될 수 있지만, 유효기간이 짧은 Token의 경우 그만큼 사용자는 로그인을 자주 해서 새롭게 Token을 발급받아야 하므로 불편하다는 단점이 있다. 그렇다고 무턱대고 유효기간을 늘리자면, 토큰을 탈취당했을 때 보안에 더 취약해지게 된다.
• 이때 “그러면 유효기간을 짧게 하면서  좋은 방법이 있지는 않을까?”라는 질문의 답이 바로 Refresh Token이다. 이름이 다르지만 형태 자체는 Refresh Token은 Access Token과 똑같은 JWT다.
• 단지 Access Token은 접근에 관여하는 토큰이고, Refresh Token은 재발급에 관여하는 토큰 이므로 행하는 역할이 다르다고 보면 된다.

Access Token과 Refresh Token의 사용방법과 흐름

• 처음에 로그인을 했을 때, 서버는 로그인을 성공시키면서 클라이언트에게 Access Token과 Refresh Token을 동시에 발급한다.
• 서버는 데이터베이스에 Refresh Token을 저장하고, 클라이언트는 Access Token과 Refresh Token을 쿠키, 세션 혹은 웹스토리지에 저장하고 요청이 있을때마다 이 둘을 헤더에 담아서 보낸다.
• 이 Refresh Token은 긴 유효기간을 가지면서, Access Token이 만료됐을 때 새로 재발급해주는 열쇠가 된다.
• 따라서 만일 만료된 Access Token을 서버에 보내면, 서버는 같이 보내진 Refresh Token을  DB에 있는 것과 비교해서 일치하면 다시 Access Token을 재발급하는 원리이다.
• 그리고 사용자가 로그아웃을 하면 저장소에서 Refresh Token을 삭제하여 사용이 불가능하도록 하고 새로 로그인하면 서버에서 다시 재발급해서 DB에 저장한다.

Access / Refresh Token 재발급 원리

1. 기본적으로 로그인 같은 과정을 하면 Access Token과 Refresh Token을 모두 발급한다.

이때, Refresh Token만 서버측의 DB에 저장하며, Refresh Token과 Access Token을 쿠키 혹은 웹스토리지에 저장한다.

2. 사용자가 인증이 필요한 API에 접근하고자 하면, 가장 먼저 토큰을 검사한다.

이때, 토큰을 검사함과 동시에 각 경우에 대해서 토큰의 유효기간을 확인하여 재발급 여부를 결정한다.

• case1 : access token과 refresh token 모두가 만료된 경우 → 에러 발생 (재 로그인하여 둘다 새로 발급)
• case2 : access token은 만료됐지만, refresh token은 유효한 경우 → refresh token을 검증하여 access token 재발급
• case3 : access token은 유효하지만, refresh token은 만료된 경우 → access token을 검증하여 refresh token 재발급
• case4 : access token과 refresh token 모두가 유효한 경우 → 정상 처리

3. 로그아웃을 하면 Access Token과 Refresh Token을 모두 만료시킨다.

Refresh Token 을 Redis 에서 사용하고 있는데 시간이 만료되었을 때 바로바로 제거가 되게끔 처리가 되려면 ?

• @RedisHash(value = "refreshToken", timeToLive = 초단위시간)
• 위와 같이 일정 기간을 정해서 시간이 다했을때 자동으로 삭제되도록 할 예정이고, 또한 로그아웃 API가 완성되면 로그아웃시에도 토큰이 삭제되도록 할 예정입니다.

Access Token과 Refresh Token을 어떻게 관리할지

1. 서버단에서는 리프레시 토큰을 Redis에 저장한다.

• Redis에 저장하는 이유는 아래와 같다
  • 빠른 액세스 속도로 사용자 로그인시 (리프레시 토큰 발급시) 병목이 되지 않는다.
  • 또한 리프레시 토큰은 발급된 후 일정 시간 이후 만료되어야 한다. 리프레시 토큰을 RDB등에 저장하면, 스케줄러등을 사용하여 주기적으로 만료된 토큰을 만료 처리하거나 제거해야한다. 하지만, 레디스는 기본적으로 데이터의 유효기간(time to live)을 지정할 수 있다. 이런 특징들은 리프레시 토큰을 저장하기에 적합하다.
  • @RedisHash(value = "refreshToken", timeToLive = 초단위시간)
• 물론 JWT와 같은 클레임 기반 토큰을 사용하면 리프레시 토큰을 서버에 저장할 필요가 없다. 하지만, 사용자 강제 로그아웃 기능, 유저 차단, 토큰 탈취시 대응을 해야한다는 가정으로 서버에서 리프레시 토큰을 저장하도록 구현하였다.

2. 프론트 단에서는 두가지의 경우가 있다. 어떤게 좋은지는 잘 모르겠다.

• 쿠키에 보관
• localStorage 보관

localStorage에 저장하는 경우

• cookie의 httpOnly 옵션도 XSS 공격을 완벽히 막을 수 없다. 어차피 XSS 방어는 필수적이므로 cookie의 장점이 매력적이게 보이지 않는다.
• cookie를 사용한다면 백엔드 api에 내가 사용하는 cookie를 위한 설정을 요구해야한다. 백엔드와 조율이 잘 되는 상태면 cookie를 사용해도 문제 없지만 서드파티 api의 경우 거의 불가능하므로 localStorage가 더 좋을 것 같다.
• mdn은 저장소로 쿠키를 추천하지 않는다. 대신 ModernStorage(localStorage와 sessionStorage)를 추천한다.
  
  

cookie를 지지하는 경우

• CSRF 공격은 다루기 쉬운 반면 프론트엔드 크기가 크면 클수록 XSS 공격을 막기위한 작업은 많아지므로 쿠키 사용을 추천
• 쿠키는 별도로 헤더에 담지 않아도 요청을 보낼때 자동으로 담아서 보내지기 때문에 매번 서버로의 요청에 담아야하는 토큰이라는 성격과 잘 맞고, 코드도 더 간결하게 작성할 수 있다

Refresh Token의 한계점

리프레시토큰을 도입해서 액세스토큰의 공격범위를 줄인다고해도, 리프레시토큰마저 탈취당하면 도로묵이고.

그래서 JWT로그인을 도입할 때는 이 한계점이 명확하다는것을 유의해서 작업해야 할 것 같다.

또다른 큰 단점은, 임의적으로 생성된 JWT를 서버에서 임의적으로 삭제할 수 없다는 점이다. 

사실 이 점이 더 큰 단점이라고한다.

만약 리프레시토큰이 탈취당한다면 어떤 액션을 취해야할지? 

아니면 클라이언트측이 갖고있는 토큰을 아예 탈취도 못하도록 보안에 더 신경쓰거나.

아니면 탈취당했더라도 금새 리프레시토큰을 재발급할 수 있게 한다거나?

아무리 생각해봐도 뭐라도 하나 털린순간 피해를 당하긴 하는데,얼마나 줄이냐의 문제같다.

[ 참고 자료 ]

1. 어려웠던 부분 :

• 지난주 멘토님의 피드백을 반영해서 CI/CD, 웹소켓 세션 객체 Redis 저장을 시도했지만, 아쉽게도 둘다 해결하지 못했다.
• https 서버 배포후 알 수 없는 에러를 프론트엔드 서버를 EC2로 다시 배포함으로써 임시방편으로 해결했지만 그 전 에러의 원인을 여전히 알 수 없다.
• 이번주 중간 발표를 위해 모든 팀원이 MVP구현을 위해 노력했다. 특히 정신없이 뷰작업을 해주신 프론트엔드분들 진짜 고생 많으셨다.
• 아직 동시성제어, 그리고 무중단배포, 리프레시토큰 적용 등 해결해야 할 과제들이 남아있다. 

2. 느낀 점 : 

• 다시한번 모두가 열심히 하는 팀을 만난 것에 감사함을 느낀다.
• 지칠법도 한데, 열심히 새로운 기술을 공부하고 해결하고 솔선수범하는 팀원들을 보며 반성하고 많이 배웠다.
• 사실 처음엔 이게 될까?라는 생각이 있었는데, 되는걸 보니 신기하고 뿌듯하다.
• 우리팀에서 나만 잘하면 된다.

3. 새로 알게 된 내용 :

• 서버가 다운될 수도 있다. 그럴땐 AWS 접속해서 차분하게 다시 재부팅 하자.
• 동시성제어 - 비관적락만이 정답이 아닐 수 있다. MVCC에 대해 알아보자
• 발표와 면접에 가장 중요한부분은 기술스택 선정 이유와 이해도 이다. 열심히 공부하고 파고들어 보자.

4. 셀프칭찬 : 

• 사실 의욕이 많이 떨어진 주차였다. 개인적인 일도 있고, 그렇지만 그럼에도 불구하고 최대한 티 안내고 집중하려고 노력했다. 
• 자꾸 남들과 비교하면 밑도 끝도 없이 자존감이 떨어진다. 객관적으로 나를 보려고 노력했다. 아직 코딩을 시작한지 3개월 차인 코린이일 뿐이다. 충분히 잘 하고 있다. 

5. 다음주 할 일 : 

• 게임스타트셋 DB MySQL로 변경 (1순위)
• 동시적으로 게임 시작했을 때 발생하는 오류 원인 파악 (1순위)
• 원인 파악 후 로직 수정 (1순위)
• CI/CD 엔진엑스 사용해서 마무리 (2순위)
• Refresh Token 작업 (2순위)
• JWT 예외 처리 수정 (2순위)
• 레파지토리 서비스 관심사 분리 (3순위)
• 테스트 코드 진행 (3순위)

[ 이번주 공부한 부분]

[11] Docker (1) 

[12] 게임 로직 - 랜덤으로 카테고리 / 키워드 뿌려주기

[13] 트러블 슈팅 : HTTPS 배포 유의사항

[52] Spring boot Logging(@Slf4j)

[15] Spring CI/CD

[16] Docker 실행 / 명령어 정리

+ 노션에 정리한 부분

https://www.notion.so/cd4bad2d032343c8bafcb640b597f6bc

https://www.notion.so/cef12775fbfa4eb6941094ce084dfb6c

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 정리하기

[오늘 공부한 부분] 

• 중간 발표 사전 질문 답변 준비하기
• 중간 발표 후 기술스택 선정이유 정리
• https://www.notion.so/cd4bad2d032343c8bafcb640b597f6bc

https://www.notion.so/cef12775fbfa4eb6941094ce084dfb6c