[회고] 동시성 프로젝트를 마치며

개요

GitHub - countdown10/count10shop: [내배캠] 동시성 제어 프로젝트

카운트다운10 | Notion

 

이번 내배캠에서 count10shop이라는 프로젝트를 진행을 하면서 느낀점에 대해서 적고자 한다.

 

 

---

 

느낀점

좋았던 점

• CI/CD를 적용을 하고 push하고 pull_request를 하면서 바로 테스트를 확인해볼수 있던 점
• 각 인원의 역할 분배가 잘 이루어져 다른 사람의 작업을 신경 쓰지 않아도 진행이 되었던 점
• 추가 기능뿐만 아니라 외부 도구들까지 사용해서 작업을 했던 점

아쉬웠던 점

• 배포까지 완성을 하였으나, 각 외부 도구들을 Docker 이미지를 만들어서 진행을 하였으나,
  docker network 설정, application.yml설정까지 끝냈으나, 실전 배포에서는 연결이 잘 안되었던 점
• 그라파나, 무중단 배포를 못해본 점
• 팀원들과 자신이 만든 부분을 공유하고 공부하지 못한 점

발전할 점

• 많은 외부 도구들을 사용을 하면 어떻게 발표를 할지 알아가는 점
• 코드 리뷰를 할 때 이 코드가 어떻게 돌아갈지만 아는 것이 아니라 추가적으로 보안적, 서버적으로 넓게 볼 수 있는 시야를 가져야할 점
• 각종 데이터를 처리를 할 경우 어떤 락을 사용할지 자세하게 생각을 하는 것
• 로그 같은 데이터를 처리시 저장을 할 때 값을 비정규화(반정규화)를 통해서 저장을 할 점
  • ex) 상품을 한 유저가 구매를 하여 로그가 남음
    로그에 남기는 데이터가 구매한 유저, 구매한 상품, 날짜 등 일 경우
    나중에 DB에 저장을 할 경우는 아이디 값만 저장이 될 것인데, 그 상품이 변경이 되는 경우는 어떻게 변경이 되는가?
• ECR로 이미지만 배포를 하였지만 MSA 환경으로 배포를 시도를 해볼수 있는 점
• 팀장으로써 각 팀원들의 실례가 되지 않지만 적당히 미뤄붙일 줄 알아야한다는 점

---

있었던 일을 남겨보자.

CI/CD로 빠른 에러 대처

PR 중에 이미 develop에 올라간 파일을 merge가 안되어있어서 fast-forward를 진행을 하고 진행을 하는 일이 있었다.

 

어느 순간부터 테스트를 통과하지 못하는 일이 생겨서 기존 커밋 로그를 확인 하였다.

 

팀원이 문제를 확인을 하지 못하여서 빠르게 로그로 에러가 생기는 커밋을 확인하였고, 수정후 다시 올렸다.

이후 작업을 한 팀원에게 해당 커밋과 PR내용을 드리면서 수정을 부탁드렸다.

 

이렇게 해보니 진짜 실무자가 된것 같은 느낌이 들어서 신기하고 재미가 있었다.

 

적용한 프로그램들

 

docker compose을 사용하면서 배포를 진행을 하였다.

 

실제 실무 환경에서는 이러면 안되는 것은 알았지만

 

블로그 주인장은 무중단 배포까지 해볼 생각으로 구성을 하였다.

 

핵심으로 바뀌는 것은 스프링 이미지만 바뀔 것이라고 생각을 하였기 때문에 나머지는 전부 올라가 있어도 될 것이라 생각을 하였다.

추후 나머지 시스템들도 MSA환경에 들어가게 되면 각각 하나의 시스템을 차지를 하고 연결을 할 것이기 때문에 상관이 없을 것이라 생각을 하였다.

 

하지만 무중단 배포는 진행을 하지 못하였다.

 

각종 데이터를 처리를 할 경우 어떤 락을 사용할지 자세하게 생각을 하는 것

이번 프로젝트를 발표를 하면서 다른 팀이 어떤 락을 사용하는지 왜 해당 락을 선택을 했는지에 대해서 확인을 해보았다.

 

락은 크게 3가지 종류로 있다고 알고 있다.

• 낙관적 락 : 별로 동시성 문제가 생길 경우가 없을 거야!
• 비관적 락 : 이 도메인은 무조건 동시성 문제가 생길 거야
• 분산 락 : 비관적 락 + 락에 대한 통신을 redis같은 케시 DB에게 맡기는 것

그리고 솔직히 분산 락만 나올 줄 알았다.

 

하지만 다른 조에서는 낙관적 락을 선택, 우리 조는 비관적 락을 선택, 분산 락을 선택을 한 조는 별로 확인을 하지 못하였다.

한 조에서 낙관적 락을 선택을 전략이 매우 현명했는데, 한정판 쿠폰처럼 동시성이 무조건 발생하고, 현금과 관련된 중요한 도메인이 아니니 낙관적 락을 선택을 하여서 적용한 점이 순간 "아차!"라고 생각을 하게 되었다.

 

 

발표를 할 때 질문을 받은 사항

ex) 상품을 한 유저가 구매를 하여 로그가 남음
로그에 남기는 데이터가 구매한 유저, 구매한 상품, 날짜 등 일 경우
나중에 DB에 저장을 할 경우는 아이디 값만 저장이 될 것인데, 그 상품이 변경이 되는 경우는 어떻게 변경이 되는가?

 

이 내용을 질문을 들었을 때는 로그에 남기니까 문제가 없는 것이 아닌가라는 생각을 들었지만

 

생각을 해보니, 구매를 한 내용이 바뀐다면 현재 프로젝트는 아이디 값이 남게 되므로 나중에 값이 변경이 되면 구매 내역이 값이 정상적이지 않게 되는 것이였다.

 

이 질문을 받고, 좀 더 넓게 볼 필요가 있다고 생각이 들었다.

 

• 코드 리뷰를 할 때 이 코드가 어떻게 돌아갈지만 아는 것이 아니라 추가적으로 보안적, 서버적으로 넓게 볼 수 있는 시야를 가져야할 점

그래서 다음과 같은 발전할 점에 대해서 적었다.

 

 

마치며

프로젝트로 순수하게 해보며 배워가는 점이 많다고 생각이 든다.

 

단순하게 생각했던 코드들도 사실 다시 보면 수정을 해야할 점이 정말 많다는 생각이 든다.

 

그리고 지금까지는 내가 소스 코드가 정상적으로 돌아갈지만 생각을 했던 것 같다.

앞으로는 좀더 넓게 로직상으로 생각을 하려고 노력을 해야될 것 같다.

 

로직에 문제가 없는지를 생각을 더 해보고, DB상으로 문제가 없는지 생각을 해볼 수 있도록 노력해야겠다.