1. 어려웠던 부분 : 오늘은 내일 발표를 위해 여러가지 테스트를 해보았다. 우리가 아직 생각하지 않았던 부분이 동시성제어 문제였는데, 분명히 터질거라고 예상은 하고 있었다. 먼저 아래와 같은 실험을 해봤다.

1. 한 방에 4명이 맥시멈이다. 일단 3명을 입장시켜 놓고 나머지 1자리를 두고 3명이 동시에 입장해보기. 

 - 이 실험은 다행히 문제없이 통과되었다.

2. 방을 3-4개 만들어 놓고 동시에 시작해보기

- 오! 터졌다 ^^! 어떤 방은 시작이되고 어떤 방은 제대로 시작이 되지 않는다. 웹소켓에  게임의 기본설정 정보를 gameStartSet이라는 Repository에 저장하고 있는데 그부분에서 터지는 것 같다! 

일단 여러 자료를 통해 동시성제어엔 비관적락과 낙관적락이 있다는 것은 알았고, 우린 이 정보를 Redis에 저장하고 있기 때문에 Redis에서 동시성제어 하는 법을 열심히 구글링해 보았다.

구글링을 통해 첫번째로 아래의 방법을 시도했다.

1. @EnableTransactionManagement 을 붙이고 Redisconfig 파일에 아래 코드 추가하기 -> 실패 ! 여전히 오류 발생

    @Bean
    public PlatformTransactionManager transactionManager() {
        return new JpaTransactionManager();
    }

위 방법 참고자료 : https://wildeveloperetrain.tistory.com/137

2. SessionCallBack 사용 - 이부분 코드는 팀원분한테 있어서 나중에 업로드 할 예정

결과적으로 위 콘솔에 뜬 에러는 사라지긴 했지만, 여전히 게임 동시시작에 문제가 있고, 몇 번의 테스트 후 서버가 먹통이 되고 다운되어 버렸다. 

어떻게 수정해야할지 아직 잡히지 않아서 더 공부하고 적용해 봐야할 것 같다.

2. 느낀 점 : 거의다 끝났다고 생각했지만, 역시나 끝은 없다. 너무 어렵다 ㅎㅎㅎ 하하핳 !! 

3. 새로 알게 된 내용 : 지난번에 팀원분이 CI/CD 테스트를 여러번 하셨던 적이 있는데 그때도 서버가 다운되어 버리는 문제가 있었다. 이번에도 여러번 테스트를하니 서버가 그냥 먹통이 되어버렸다. 이럴때 해결 방법 ! 일단 AWS에 가서 먹통이 되어버린 인스턴스를 중지시킨다. 그리고 다시 새로운 인스턴스를 생성하고 생성중이 뜨면 다시 중지시키고 원래 먹통이라 중지시켰던 인스턴스를 다시 재부팅한다. 신기하게도 먹힘... ! 원래 협업에선 이렇게 안할텐데 제대로된 방법을 모르겠다  ㅎ... 

4. 셀프칭찬 (오늘 잘한 일) : 팀원들과 같이 동시성제어에 관련된 비관적락 낙관적락 트랜잭션 등에 관한 공부를했다. 어제부터 집안일 때문에 중간 중간 집중이 되지 않았지만, 최대한 팀원들한테 티 안내고 피해주지 않으려고 정말 많이 노력했다 ! 프로젝트가 끝나면 바로 고모가 좋아하셨던 꽃을 사서 인사드리러 가야지! 이효리가 한 말중에 그런 말이 있다. 다른사람은 몰라도 나 자신은 내가 노력한 걸 알아주면 된다고. 잘 하고 있어! 끝까지 잘 하자 ! 

5. 내일 할 일 : 중간 회고 발표 / 피드백 정리하기

[오늘 공부한 부분] 

• 동시성 제어 - 비관적 락 / 낙관적 락 ( 우테코 짱 )
• https://www.youtube.com/watch?v=w6sFR3ZM64c
  https://www.youtube.com/watch?v=ZXV6ZqMyJLg
  https://www.youtube.com/watch?v=onBpJRDSZGA

1. 어려웠던 부분 : 오늘까지 이번주 토요일에 있을 중간 회고 발표 자료를 제출해야 했다. 프론트엔드분들은 바쁘기 때문에 일단 백엔드에서 깃허브 리드미 작성과 발표자료 준비를 했다. 기술스택 선정 이유가 중요한데 이유를 설명하기가 생각보다 쉽지 않았다. 이부분이 중요할텐데.. 허허 ... ! 그리고 해결된 줄 알았던 https 배포에 또 문제가 생겼다. 현재 프론트엔드는 AWS cloudfront 를 이용해 배포가 되었고 백엔드는 AWS EC2를 사용해 배포를 한 상태인데, 계속 이부분에서 오류가 생긴다. 결국 팀의 리더분이 백엔드임에도 불구하고 혼자 뚝딱뚝딱 프론트엔드 서버를 EC2로 재배포 하셨다. 당장의 문제는 해결되긴 했는데, 정확한 이유를 알지 못해서 찝찝하다.

2. 느낀 점 : 우리팀 백엔드분들을 보시면 참 잘하신다. 문제가 발생하면 구글링해서 뚝딱 하고 고쳐내고, 코드도 뚝딱 하고 만들어내고. 그리고 심지어 매번 테스트 할때마다 프론트엔드한테 부탁하기가 미안하다고 VSCode 까지 다운받아서 직접 로컬서버를 띄우고 작업을 하시기에 이르렀다. 진짜 멋지고 대단하다. 근데 나를 돌아보면, 난 아직도 로직을 구현하는데 시간도 걸리고 어떤 개념을 보았을 때 이해하는데도 상당한 시간이 걸린다. 나름대로 나도 열심히 해오고 있다고 생각했는데, 이 부트캠프 안에서 이렇게 실력차이를 느낄때마다 좀 막막한 마음은 어쩔 수 없다. 언제쯤 나도 빠릿빠릿한 이해력을 가질 수 있을까. 

3. 새로 알게 된 내용 : 오늘 발표 전 테스트를 하면서 위 사진과 같은 오류를 발견했다. 원래 맥시멈 4명만 입장이 가능한데, 만약 직접 url주소를 치고 들어오면 저렇게 입장이 되어버린다. 로직이 잘못되었나 라는 생각에 백엔드 코드를 수정해야하나 싶었는데 놀랍게도 프론트엔드에서 저 부분을 막아줄 수 있다고 하셨다. 이번 프로젝트를 하면서 프론트엔드가 참 하는일이 많다는 것을 몸소 느끼고 있다. 클라이어트단에서 막아주는 부분이 정말 많고 그밖에 뷰작업, 세심한 디테일 작업까지. 누가 프론트엔드가 쉽다고 했던가. 

4. 셀프칭찬 (오늘 잘한 일) : 사실 오늘 집에 일이 생겨서 집중이 잘 안되는 하루였다. 프로젝트 끝날때까지 멘탈을 잘 잡고 싶어서 집중은 안되지만 인강을 틀어놓고 최대한 집중하려고 했다. 홧탱 ! 

5. 내일 할 일 : 발표 전 마지막 준비 + 사소한 에러 잡기 ! 

[오늘 공부한 부분] 

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

Docker 설치

• https://docs.docker.com/desktop/install/mac-install/

설치 확인

• 터미널창을 열고 docker -v 입력
• 버전 정보가 뜬다면 설치 완료!

Docker Command 명령어

컨테이너 생성 

docker run [OPTIONS] IMAGE[:TAG|@DIGEST] [COMMAND] [ARG...]

docker run --name "컨테이너이름" "이미지"

docker run -it --name test-ubuntu ubuntu:20.04 /bin/bash

• 컨테이너 내부에 들어가기 위해 터미널창을 실행하고 키보드 입력을 위해 -it 옵션을 준다.
• 추가적으로 프로세스가 종료되면 컨테이너가 자동으로 삭제되도록 --rm 옵션도 추가 한다.
• --rm 옵션이 없다면 컨테이너가 종료되더라도 삭제되지 않고 남아 있어 수동으로 삭제 해야 한다.

※ 터미널창이 아니더라도 Docker GUI를 이용하면 더 편리하게 사용할 수 도 있다. 

[ 참고 자료 ]

생활코딩 Docker 

https://www.opentutorials.org/course/128/8657

https://acdongpgm.tistory.com/234

https://www.youtube.com/watch?v=IiNI6XAYtrs 

1. 어려웠던 부분 : 오늘은 지금까지 계속 속을 썩이고 있는 CI/CD 에서 CD부분 오류를 해결하려고 시도했다. 성공한 듯 했으나 숨겨져야할 appication.properties 파일이 깃헙에 올라가버린 참사가 발생해서 그렇다면 이 파일을 암호화해보기로 했다. GPG암호화 라고 검색하면 파일을 암호화 하는 법이 나온다. 내가 하진 않았지만 팀원분이 하시는 걸 보니, 암호화를 하면 .tar 라는 파일이 생성되고 깃헙에 올렸을 때 자물쇠가 채워진 채로 올라간다. 신기하다  ! 그래서 CD의 결론은 결국 성공한 줄 알았으나 하지 못했다는 점... 그리고 웹소켓 세션도 지난주 멘토링때 레디스에 저장하시면 된다고 하셔서 다른 팀원분이 계속해서 여러가지 방법으로 시도를 하셔지만 결론은 성공하지 못했다. 우리가 내린 결론 = 세션을 객체 자체론 레디스에 저장할 수 없다는 것 ! 세션 아이디만 String 값으로 빼서 저장하는 건 가능한데, 우리가 필요한 작업은 객체 자체를 넣는 것이기 때문에 일단 철수하기로 ...

2. 느낀 점 : 프론트엔드 분들은 뷰작업과 백엔드에서 만들어놓은 코드에 값을 붙이시느라 정신없이 바쁘다. 백엔드는 상대적으로 시간이 남았다. 물론 몇가지 해결해야할 에러들이 있고 내가 맡았던 부분이 아니라 지식이 많이 부족해서 같이 구글링을 도와드려도 사실 이해가 잘 되지 않았다. 뭔가 붕 뜬 느낌이다. 이 시간을 어떻게 밀도있게 잘 보낼 수 있을까

3. 새로 알게 된 내용 : 오늘 어제 들었던 도커관련된 강의를 좀 더 찾아보고 팀원분이 맡으셨던 CI/CD가 해결이 잘 되지 않아 나도 같이 공부를 해보았다. 내가 개념이 좀 더 있으면 같이 에러를 해결하는데 좀 더 도움이 될까 싶어서였다. CI/CD는 자동 빌드, 테스트, 배포를 해주는 인프라 작업이다. 이를 통해 개발자가 좀 더 개발에만 집중할 수 있도록 해준다. 여러가지 프로그램이 있는데 그중에서 우리는 깃헙액션과 AWS CodeDeploy를 사용한 CI/CD 시도 하고 있다. 젠킨스 라는 프로그램도 많이 사용되고 있는데, 깃헙액션보다 사전에 환경설정을 해줘야 할 부분이 많아서 깃헙액션을 사용하기로 했다. 배움엔 끝이 없다 ! 

4. 셀프칭찬 (오늘 잘한 일) : CI/CD에 관련도니 우테코 영상및 여러가지 자료들을 찾아보았다. 글로만 봤을 땐 참 쉬운데, 내가 직접 깃헙에서 CI 파일을 구축하려고 해보니 경로설정때문에 꽤 애를 먹었다. 그냥 블로그 글만 보고 복붙해서 되는게 아니라, 각자 파일의 구조에 따라 다르다는 것 ...! 결국 테스트용 파일 하나 다시 만들어서 CI에 성공했다. 코린이인 나에겐 아직도 어려운게 너무 많다. 삽질의 연속인 하루하루 ... 그래도 삽질을 통해 하나 더 배웠다. 

5. 내일 할 일 : 이번주 중간발표 자료 준비

[오늘 공부한 부분] 

• CI/CD 공부

[14] 2주차 기술멘토링 피드백 정리

[15] Spring CI/CD

사전 지식 

코딩의 과정

CI/CD

사용자에게 우리가 만들어낸 프로젝트를 배포했는데 어떠한 동작이 올바르게 동작하지 않아 문제가 발생했다고 가정해보자.

개발자들에게는 비상이 걸릴 것이다. 급한 프로젝트일수록 더욱 빠르게 문제를 수정해야만 한다. 수정을 했으면 다시 컴파일, 빌드, 배포하는 과정을 통해 수정된 코드가 제대로 동작하는지 테스트하고 검증할 필요가 있다. 이 과정들은 시간도 많이 걸리고 실수하기도 쉽다.

수정된 코드에 문제가 다시 생기면 또 다시 과정을 반복해야한다. 이를 위해서 CI/CD가 생겨났다.

CI (Continuous Integration)

• CI는 지속적 통합이라는 뜻으로 개발을 진행하면서도 품질을 관리할 수 있도록 하는 것
• 여러 명이 하나의 코드에 대해서 수정을 진행해도 지속적으로 통합하면서 관리할 수 있음을 의미한다.
• CI가 나오기 전까지는 개발을 끝마치고 배포가 되어야만 코드에 오류는 없는지, 올바르게 동작하는지를 검증하며 코드 품질을 관리할 수 있었다. 하지만 개발자가 직접 코드를 병합하고 빌드, 테스트를 검증하는 것은 시간이 많이 소요될 뿐만 아니라 귀찮고 그 양도 프로젝트의 크기가 커질수록 많아질 수밖에 없다. 이를 자동화하면 개발자가 빌드와 테스트를 직접 하지 않고도 수정한 코드를 브랜치에 병합하기만 하면 자동으로 빌드와 테스트를 검증할 수 있다.
• 개발자가 단위별로 구현한 부분을 병합할 때마다 자동화된 빌드와 테스트가 트리거되어 실행된다. 결과를 통해 우리는 어떤 부분에서 문제가 있는지 배포 전에 확인할 수 있고, 배포가 완성된 후에야 버그를 수정할 수 있던 기존의 문제를 빠르고 정확하게 해결할 수 있다
• 결과적으로 버그를 신속하게 찾아 해결할 수 있을 뿐 아니라, 소프트웨어 품질을 개선하고 새로운 소프트웨어 업데이트를 검증하고 릴리즈하는데에 걸리는 시간을 단축할 수도 있다.

CI의 간단한 순서는 아래와 같다.

1. 개발자가 구현한 코드를 기존 코드와 병합한다.
2. 병합된 코드가 올바르게 동작하고 빌드되는지 검증한다.
3. 테스트 결과 문제가 있다면 수정하고 다시 1로 돌아간다. 문제가 없다면 배포를 진행한다.

CD(Continuous Deployment)

• 이제 지속적 통합을 거친 코드에 대해서 신뢰할 수 있고 바로 배포할 수 있다.
• CD는 지속적 배포로 소프트웨어가 항상 신뢰 가능한 수준에서 배포될 수 있도록 관리하자는 개념으로 지속적 제공(Continuous Delivery)로 사용되기도 한다.
• 지속적 제공은 CI를 통해서 새로운 소스코드의 빌드와 테스트 병합까지 성공적으로 진행되었다면, 빌드와 테스트를 거쳐 github과 같은 저장소에 업로드하는 것을 의미한다.
• 지속적 배포는 이렇게 성공적으로 병합된 내역을 저장소뿐만 아니라 사용자가 사용할 수 있는 배포환경까지 릴리즈하는 것을 의미한다.
• 대표적인 CI/CD의 방법으로는 Travis와 Jenkins가 있다.

[ 참고 자료 ]

https://www.youtube.com/watch?v=sIPU_VkrguI 

https://tecoble.techcourse.co.kr/post/2021-08-14-ci-cd/

https://www.redhat.com/ko/topics/devops/what-is-ci-cd