1. 어려웠던 부분 : 

• 리프레시 토큰을 이용해 액세스 토큰 재발급을 하는 api가 이상하게 게임룸페이지 안에서는 정상 작동하지 않았다. 로비페이지 랜딩페이지, 커뮤니티 페이지에서는 문제없이 토큰 재발급이 되고 로그인이 순조롭게 연장이 되는데 확실하진 않지만 WebRTC 때문인지 WebSocket 때문인지 뭔가 충돌이 있는 듯 하다. 
• 처음에 의심한 부분은 아래 사진과 같이 다른 페이지들에서는 Request Header 부분에 키값이 accesstoken 으로 그리고 밸류가 토큰값으로 잘 들어가는데  게임룸에서는 cookie 라는 키값에 밸류로 액세스토큰 값과 닉네임 값이 같이 들어가 있는 부분이었다. 결론적으로 이 부분은 상관이 없던 문제 였던 것 같다.

• 프론트엔드 팀원분과 오랜 삽질 끝에 문제의 해결책을 발견할 수 있었다. 일단 프론트엔드에서 액세스토큰 발급을 일정 시간이 지나면 setTimeout() 으로 토큰 재발급 api 요청을 하도록  하고 있는데, 이 코드가 전역적으로 반영이 되는 구조였다. 그런데 이상하게 WebRTC 코드가 있는 GameRoomRTC 컴포넌트에는 반영이 되지 않았다. 
• 그래서 아래와 같이 [ GameRoomRTC ] - [ WebRTC signaling ] 이 처음 시작되는 [ useEffect ] 안에서 액세스 토큰을 만드는 setAccessToken() 함수를 호출하여 유저이 토큰정보를 담아서 보내주도록 코드를 수정하였다. 이렇게 일부러 함수를 따로 선언하고 호출했더니 게임룸에서도 제대로 토큰 재발급 api가 작동했다.

  // WebRTC signaling section
  useEffect(() => {
    setAccessToken(getAccessToken('AccessToken'));
    if (!sessionStorage.getItem('normalEnter')) {
      useToast('정상적인 접근이 아닙니다', 'warning');
      navigate('/rooms');
    }
    connect();
    socketRef.current = new SockJS(`${process.env.REACT_APP_SIGNAL_URL}`);

2. 느낀 점 : 

• 이제 프로젝트도 마무리 단계이다. 프론트엔드팀은 유저 피드백을 반영해서 UX/UI 수정하느라 바쁘고 백엔드는 그동안 구현한 개념 공부를 하고 있다. 이제 진짜 일주일 남았다는 사실이 믿기지가 않는다. 오늘도 새벽 3시가 넘은 시간까지 같이 버그를 수정하고 브로셔 작업, 영상촬영 스크립트 작업을 했다. 우리 팀원들은 다 좋은 개발자가 될 것 같다.

3. 새로 알게 된 내용 :

• 새로 알게 된 내용은 아닌데 오늘 트러블 슈팅을 비롯해 웹소켓 동시성 제어도 그렇고 일단 뭔가 해결은 됐는데 왜 어떤 이유로 트러블이 발생했는지 원인을 모르는 경우가 꽤 있다. 
• 시니어님이 일단 원인부터 알아야 된다고 하셨는데, 원인 그거 어떻게 알 수 있나요 ㅜ ? ㅎㅎ 

4. 셀프칭찬 (오늘 잘한 일) : 

• 오늘도 잘 버텼따 아 . 깊게 파고드는 것은 정말 힘들지만 해결하고 나면 뿌듯하다 ! 

5. 내일 할 일 : 영상 제출 및 개념 정리 공부 / 코드 리팩토링 

[ 오늘 한 일 ] 

• 리프레시토큰 버그 수정
• 브로셔 작성
• 깃허브 리드미 작성
• 설문 이벤트 당첨자 발표

[ 나몰닭 FE Github 주소 ] 

https://github.com/namoldak/Frontend/blob/dev/src/components/GameRoom/GameRoomRTC.jsx

https://www.notion.so/802c9f1f4fce4ed29557a7ea2768fd6b

나몰닭 서비스는 게임이다보니, 게임룸을 입장할 경우 충돌이 발생할 수 있다고 가정하였다. 실제로 팀원들과 테스트해 본 결과 게임룸에 여러명이 동시 입장을 시도할 경우 서버가 터져버리는 버그가 발생하였다. 우리 팀은 게임룸 입장 로직에 아래와 같이 비관적 락을 DB에 걸어주었다. 아래의 조치를 통해 DB엔 트랜잭셔널 직렬화가 잘 처리되었지만, 웹소켓 연결은 여전히 충돌이 일어났다. 웹소켓 동시성 제어 관련은 다음 게시글에 포스팅하기로 하고, 오늘은 일단 DB관련 동시성 제어에 대해 포스팅 해보려 한다.

@Lock(LockModeType.PESSIMISTIC_WRITE)
@Query("select b from GameRoom b where b.gameRoomId = :gameRoomId")
Optional<GameRoom> findByGameRoomId2(Long gameRoomId); // 게임룸 단건 조회

비관적 락

• 자원 요청에 따른 동시성문제가 발생할것이라고 예상하고 락을 걸어버리는 방법론
• 트랜잭션의 충돌이 발생한다고 가정 = 사용자들이 같은 데이터를 동시에 수정 할 것이라고 가정
• 하나의 트랜잭션이 자원에 접근시 락을 걸고, 다른 트랜잭션이 접근하지 못하게 하는 방식 = 한사용자가 데이터를 읽는 시점에 Lock을 걸고 조회 또는 갱신 처리가 완료될 때 까지 유지
• 데이터베이스에서 Shared Lock(공유, 읽기 잠금) 이나 Exclusive Lock(배타, 쓰기 잠금) 을 건다.
• Shared Lock 의 경우, 다른 트랜잭션에서 읽기만 가능. 또한 Exclusive lock 적용이 불가능(읽는동안 변경하는것을 막기 위해)
• Exclusive lock 의 경우. 다른 트랜잭션에서 읽기, 쓰기가 둘다 불가능. 또한 Shared, Exclusive Lock 적용이 추가적으로 불가능 (쓰는동안 읽거나, 다른 쓰기가 오는것을 막기위해)

장점

• 충돌이 자주 발생하는 환경에 대해서는 롤백의 횟수를 줄일 수 있으므로 성능에서 유리
• 데이터 무결성을 보장하는 수준이 매우 높다.

단점

• 데이터 자체에 락을 걸어버리므로 동시성이 떨어져 성능 손해를 많이 보게 된다. 특히 읽기가 많이 이루어지는 데이터베이스의 경우에는 손해가 더 두드러짐.
• 첫번째 사용자가 트랜잭션을 완료하기 전까지 다른 사용자들이 데이터를 수정할수 없기때문에 제어를 잘못하면 동시성을 저해 받게 된다.
• 서로 자원이 필요한 경우에, 락이 걸려있으므로 데드락이 일어날 가능성이 있다.

낙관적 락

• 자원에 락을 걸어서 선점하지말고, 동시성 문제가 발생하면 그때 가서 처리 하자는 방법론 
• 낙관적 동시성 제어는 사용자들이 동시에 데이터를 수정하지 않을 것이라고 가정한다. = 트랜잭션의 충돌이 발생하지 않을것이라고 기대
• 일단 충돌이 나는것을 막지 않고, 충돌이 난것을 감지하면 그때 처리
• 따라서 데이터를 읽을때는 Lock을 설정하지 않는다. 그러므로 데이터를 수정하고자 하는 시점에 앞서 반드시 읽은데이터가 다른 사용자에 의해 변경 되었는지를 검사해야 한다.
• 일반적으로 version 의 상태를 보고 충돌을 확인하며, 충돌이 확인된경우 롤백을 진행시킴 (hashcode나 timestamp를 이용해서 충돌을 확인할 수 도 있다.)
• DB단에서 동시성을 처리하는것이 아닌, 어플리케이션단에서 처리
• 이때 여러 작업이 묶인 트랜잭션으로 요청이 간 경우가 실패한경우, 개발자가 직접 롤백 처리 를 해주어야합니다.

장점

• 충돌이 안난다는 가정하에, 동시 요청에 대해서 처리 성능이 좋다.

단점

• 잦은 충돌이 일어나는경우 롤백처리에 대한 비용이 많이 들어 오히려 성능에서 손해를 볼 수 있다.
• 롤백 처리를 구현하는게 복잡할 수 있다.

언제 사용할까?

• 비관적락 은 데이터의 무결성이 중요하고, 충돌이 많이 발생하여 잦은 롤백으로 인한 효율성 문제가 발생하는것이 예상되는 시나리오에서좋다.
• 비관적 동시성 제어는 동시성이 저하 되지만 데이터를 일일이 검사하지 않아도 된다. 만약 데이터 정합성이 중요한 업무(금융) 라면 비관적 동시성 제어로 동시성이 저하 되더라도 for update 문으로 예외처리를 하여 오히여 동시성을 높이면서 좋은 데이터 정합성을 가질 수 있다.
• 낙관적락 은 실제로 데이터 충돌이 자주 일어나지 않을것이라고 예상되는 시나리오에서 좋다.
• 낙관적 동시성 제어는 크게 경합이 벌어지지 않는 업무 ( 쇼핑몰) 등에서 사용하고, Lock이 짧아져 동시성을 높이는것이 좋다.
  하지만 상품 조회시점과 결제 시점에 가격이 다를 수 있으므로 반드시 데이터 수정시 일관성 검사를 거쳐야만 한다.

[ 참고 자료 ]

https://velog.io/@kw78999/DB-%EB%B9%84%EA%B4%80%EC%A0%81-vs-%EB%82%99%EA%B4%80%EC%A0%81-%EB%8F%99%EC%8B%9C%EC%84%B1-%EC%A0%9C%EC%96%B4

https://unluckyjung.github.io/db/2022/03/07/Optimistic-vs-Pessimistic-Lock/

https://cult.honeypot.io/reads/optimistic-vs-pessimistic-concurrency/

1. 어려웠던 부분 :

• 이번주에 드디어 준비한 서비스 배포를 했다. 그런데 하자마자 큰 이슈가 발생했다. 바로 웹소켓 연결이 게임을 끝내고 게임방을 나가도 끊어지지 않아서 계속 채팅이 콘솔로그로 확인했을 때 보이는 문제였다. 이 부분을 프론트엔드 코드에서 웹소켓 연결을 끊어주는 부분을 추가하여 해결 할 수 있었다.
• 리프레시 토큰의 경우에도 처음에 액세스 토큰을 이용하여 토큰 재발행 api 호출을 어떻게 해야할지 몰라 에러 코드로 프론트엔드와 맞춰보기도하고 별짓 다 해보면서 많이 헤맸다. 그러다 프론트에서 setTimeout()을 이용하여 토큰 만료 일정 시간 전 요청이 가도록 수정하여 해결 할 수 있었다.
• 이미지 파일을 저장하고 있는 S3의 엔드포인트 주소가 이미지 url에 그대로 노출되고 있었는데, 이 부분도 CloudFront와 Route53을 이용한 서브 도메인 적용하여 해결하였다. AWS에서 설정해줘야할 부분이 많아서 헤맸지만 결국 해냄 ! 
• 유저 테스트를 하면서 간혹 카카오로그인으로 서비스 이용시 에러가 발생하는 이슈가 있었다. 알고보니 카카오 로그인 옵션 중 이메일 허용이 선택사항으로 되어 있었는데, 이 부분을 체크하지 않고 로그인한 경우 원활한 서비스 이용이 불가능 했다. kakao developers에서 이메일 체크를 필수사항으로 변경 후 에러 해결 ! 
• 이밖에 일주일 동안 유저 피드백을 토대로 다양한 UX수정이 있었다. 나름 잘 준비했다고 생각했는데, 배포 첫날부터 여러 이슈가 있어서 정신없이 보낸 한 주였다.

2. 느낀 점 : 

• 서비스 배포후 추가기능 구현과 유저 피드백 반영을 하느라 정신이 없는 한 주를 보냈다.
• 그래도 짧은 시간 내에 다양한 트러블 슈팅을 해결해서 뿌듯하다.
• 다시한번 느끼지만, 혼자 였으면 하지 못했거나 포기했을 많은 부분들을 팀원들과 같이 했기 때문에 헤쳐나갈 수 있었다.
• 지금은 이렇게 서로 도와주는 분위기고 물어보는 분위기라 해결을 하는데, 만약에 현업에서 일을 하는 상황이라면 어떻게 혼자 잘 극복할 수 있을까 라는 생각이 든다.

3. 새로 알게 된 내용 :

• S3 엔드포인트 주소는 노출되면 안된다.
• 리프레시 토큰은 클라이언트 쿠키로 노출되면 안된다. 서버에만 저장하자! 
• 웹소켓 연결이 불안정한 이유를 synchronized 키워드로 잡는 것은 지양해야 한다. (여러 방법 시도했지만 이 방법 외에 먹히는게 없어서 일단 적용)
• 카카오톡 회원탈퇴는 일반 탈퇴와 달리 카카오에 별도의 redirect url을 요청해야한다. 
• 기능뿐만 아니라 UX적인 측면에서 유저 피드백을 반영해서 빠르게 서비스를 개선시키는 경험을 했다.

4. 셀프칭찬 : 

• 실제로 서비스를 배포해보면서 다양한 경험을 할 수 있는 뜻깊은 주차였다. 
• 좋은 개발자가 될지 아니면 다른 길을 걷게 될지 모르겠다. 그렇지만 이 경험이 내 인생에 분명 플러스가 될 것 같다. 
• 이제 진짜 일주일 남았다. 지금까지 잘 버텨온 내 자신이 대견하다 ㅎ _ ㅎ ... ! 
• 제로베이스 비전공자가 호기롭게 Spring 을 기술스택으로 선택해서 참 용캐도 살아남았다. 잘했숴 

5. 다음주 할 일 : 최종 발표회 준비 ! 

[ 이번주 공부한 부분]

노션 : https://www.notion.so/ad96dfad0856455c922e9d0f756a7f60

[27] 5주차 기술멘토링 피드백 정리

[26] Refresh Token with Redis final! 최종 버전 :)

1. 어려웠던 부분 : 

• 오늘도 돌아온 토요일 답게 시니어님께 피드백을 듣는 시간을 가졌다. 리프레시 토큰과 관련해서 어디에 저장하고 어떻게 관리하는가에 대한 질문을 주셨는데, 현재 우리는 서버에도 저장하고 클라이언트 헤더에도 리프레시토큰을 저장하고 있었다. 처음 리프레시 토큰 레퍼런스 깃헙 자료를 참고로 구현하다보니 구현 후에 이 부분이 궁금했는데, 멘토링 덕분에 궁금증이 해결되었다. 클라이언트에는 리프레시 토큰을 저장하지 않는게 맞다. 그래서 액세스 토큰은 클라이언트 쿠키에 저장하고 리프레시 토큰은 서버에만 저장하는 방식으로 수정했다.

2. 느낀 점 : 

• 확실히 멘토링 할때마다 시니어님의 조언으로 궁금증이 해소되는 부분이 많다. 우리가 헷갈려하고 궁금했던 부분들을 스스로 찾아 볼 수 있도록 키워드를 던져주시고 알려주시는데, 실제로 내가 다니는 회사에 이런 시니어분이 있다면 정말 좋을 것 같다는 생각을 했다.

3. 새로 알게 된 내용 :

• 리프레시 토큰은 클라이언트에 노출되어선 안된다 !! 명심 하자 !! 
• 지금 수정된 방식이라면 확실히 보안적으로 좋을 것 같다.

4. 셀프칭찬 (오늘 잘한 일) : 

• 받았던 피드백을 바로 반영해서 수정했다! 

5. 내일 할 일 : WIL 작성

• 최종발표회 준비에 많은 시간을 쏟기 보다 그 이후에 면접을 보고 개발자로 커리어를 시작하는게 중요
• 따라서 추가기능이나 구현을 먼저 하는 방향으로
• 그리고 이력서를 미리 준비할 것 ! ( 포맷 미리 잡고 준비하기 )
• 최종발표회는 기술적으로 까다롭게 물어보지 않는 편, 다음주는 이력서 작성법, 모의면접 잘 활용해서 취업에 집중 하기 !

• 우리 프로젝트에서 기술적으로 강점을 삼을 만할 항목을 정리해 주세요. (최종 발표 및 면접에서 프로젝트를 진행할 때 어떤 도전을 했는지 말할 수 있는 좋은 소스가 됩니다)
  • [ FE ] : 더 나은 유저 경험을 위한 무한 스크롤 기능
  • [ FE / BE] : 잦은 로그아웃 방지를 위한 Refresh Token 사용
  • [ FE / BE ] : WebSocket을 이용한 채팅 서비스 구현 및 화상 채팅을 위한 WebRTC 사용
  • [ BE ] : 서비스 로직 동시성 제어를 위한 DB 비관적 락 및 동기화 작업
  • [ BE ] : S3 엔드포인트 노출을 방지하기 위한 CloudFront 사용
  • [ BE ] : 개발 환경에 집중하기 위한 CI / CD 인프라 구축
  • [ BE ] : SockJS와 STOMP를 이용한 텍스트 채팅

• 프로젝트에 적용했던 핵심 기술 목록을 작성해 주시고, 각 기술을 도입하게된 의사결정 과정을 정리해주세요.구분 요구사항 선택지 핵심 기술을 선택한 이유 및 근거

멘토님이 주신 질문 ( 면접 활용 )

질문1) 왜 낙관적 락 대신 비관적 락을 사용했는지?

- 우리 서비스는 여러명이 동시에 입장할 경우 무조건 충돌이 발생할 것으로 예상했다.

- 따라서 미리 락을 걸어주는게 더 적합하다고 판단.

- 충돌이 발생했을 경우 오버헤드가 생기는 Optimistic Lock보다 충돌이 발생하지 않았을 경우 오버헤드가 발생하는 Pessimistic Lock이 더 효율적이라고 판단했다.

질문2) 어떤 방식으로 CI/CD를 구현 했는지?그 과정에서 어떤 트러블 슈팅이 있었는지?

( - 문제를 해결했던 경험은 사소하더라도 잘 정리를 해놨다가 어필을 하는게 좋다.

 - 면접의 80프로는 문제 해결 경험을 묻는 경우이다. )

- 깃헙 액션과 AWS의 Code Deploy 를 사용하여 구현했다.

- EC2 인스턴스에 배포 파일이 들어가나 실행되지 않는 이슈가 있었다.

- 원인은 gradle.yml 파일 순서가 잘못되어 있었다. 빌드 전 암호화된 properties 파일이 들어갔어야 하는데 순서가 빌드 후에 작성되어 있었다. 당연히 properties에 들어가있는 키들이 적용이 안 되어 우분투에 있는 배포 파일을 수동 실행시켜도 오류가 떴음. gradle.yml 파일 내 스텝 순서 변경해서 이슈를 해결했다.

질문3) 리프레시 토큰을 어디다 저장하고 있는지 ? 

- 현재 클라이언트는 쿠키에 서버에는 Redis DB에 저장하고 있다.

- 리프레시 토큰을 클라이언트에 보낼 필요가 없다. 서버에만 저장하면 됨.

- 액세스 토큰으로만 인증요청이 가능하기 때문, 따라서 클라이언트에 리프레시토큰을 제외하고 액세스토큰만 담아주는 로직으로 변경할 것, (클라이언트 단에는 리프레시 토큰을 들고있으면 안된다. 노출이되면 안됨.) 

질문4) 싱크로나이즈드 성능 저하 문제가 있는데 최선의 방법이었는지?

-웹소켓 끊기는 이슈는 다른 원인이 있을 것이다. ( 문제 코드 전달 드리기 ) 

추가 조언

• 보통 서비스가 커지면 scale up 보다는 scale out을 많이 하기 때문에 도커를 사용을 권장함. ( 경험해 보기 )
• 다음주(마지막)에 취업과 관련한 정보를 알려줄 예정 - 이력서, 면접, 좋은회사 고르는 법, 책 추천 등