코드리뷰 요청 PR

[ss0ngcode]

안녕하세요. 멘토님!

코드리뷰 관련하여 자세한 내용은 노션에 적어뒀습니다!

https://www.notion.so/240902_E2E_3-_-0866d25872314ac1b5a5ac639f1a8aa2?pvs=4

감사합니다!

[yoowonyoung]

통계 서비스 리팩토링

• 한번의 메서드 호출에 쿼리가 수십개 날라간다면, 일단 로직의 설계가 잘못된것은 아닌지 한번 되짚어볼 필요가 있겟죠. BusStaticsService의 예를 보겠습니다. 지금의 로직을 보면, 반복문 안에서 find 호출이 많은것을 알 수 있습니다. 이 부분에 의해서 N번 쿼리 호출이 일어나기 때문에 메서드 호출 한번에 수십개의 쿼리가 발생 하는것이겟죠. 여기서 timeInterval 별로, seat 별로 반복적으로 호출이 일어나게 되는데, 이 부분을 한번에 모두 가져올수는 없는것인지 로직 자체를 고민 해보거나, 테이블 설계 자체를 되짚어볼 필요가 있습니다. 이것이 근본적인 해결책이 될것이에요
• 도저히 로직, 테이블 재설계로는 안되겟다 한다면 쿼리 결과 자체를 캐싱 하는 방법도 있습니다. 물론 모든 데이터에 대해서는 캐싱이 불가능 하겟지만, 조회 조건에 맞는 버스 도착정보같은것은 캐싱이 가능하고 그 노선에서 몇좌석이 남았나는 계산을 해야겟지만요

DynamicSchedulingConfig

• 어... 일단 런타임에 동적으로 스케줄링 관리가 왜 필요한것일까요? 정말로 필요 하다면 이것을 왜 어드민페이지에서 관리 하는 것일까요? 이렇게 모든 기능을 직접 구현해서 사용 하게된다면 구현의 실수가 발생할 수 있습니다. 예를들어서 Cron식을 평가하는 코드에서 버그가 잠재되어 있어서 모든 Cron 식을 1분에 한번씩 실행하게 된다면, 이게 설정한 Cron식의 문제인지 Cron식을 평가하는 코드의 문제인지, 아니면 스케줄링이 설정된 메서드의 문제인지를 판단하는데 시간이 오래걸릴거에요. 이러한 이유 때문에 이 모든것을 직접 관리하는것 보단 적절한 다른 툴을 사용하는것도 방법입니다. 저라면 Spring Batch와 Jenkins를 이용할것같아요. Spring Batch로 배치Job을 구성한 후, 해당 배치Job을 Jenkins의 Job으로 관리하면서 Jenkins의 Job에 스케줄링을 거는것이죠. 그렇다면 Jenkins를 통해 권한관리는 물론 스케줄링 관리도 가능하며 Jenkins의 다양한 플러그인으로 작업 실패시 알림등 추가적인 기능을 활용 할수도 있어요

Exception Handling 관련

• Spring에서는 ControllerAdvice 라는 좋은 기능이 있습니다. 한번 ControllerAdvice에 대해서 찾아보면서 Spring의 메인 컨셉중 하나인 AOP에 대해서도 조금 더 공부 해보시면 좋을것 같아요

CI/CD 관련

• 일단 CI 와 CD는 분리 하는것을 추천 할게요. 보통 CI/CD라고 통합해서 부르지만 두개는 엄연히 다른 역할을 하고 있죠. 특히 CI 종료 이후 바로 CD로 연결 되고 있다면 주의 해야 할게 원치 않는 프로덕션 배포가 이뤄질 수 있다는 점을 유념해야 합니다. 이 이야기를 왜 하냐면, Github Action과 Jenkins 사용을 고민 했다고 하셨는데, 저라면 둘 다 쓰는것을 추천 하기 위해서에요. Github Action으로 CI를 담당, 지속적으로 docker image를 빌드해서 Dockerhub에 push이후, Dockerhub에 올라간 이미지를 이용 Jenkins로 배포를 하는 젠킨스를 이용한 CD를 구축 하는것입니다. 이 과정에서 Github Action에서 Dockerhub에 push가 다 끝난 이후 Jenkins 를 트리거 할수도 있거든요(Jenkins 훅 과 같은 기능 활용). 특히 동작 시 해당 클라우드 환경의 ip를 얻어 인바운드 규칙에 일시적으로 IP를 할당하고 배포가 마무리 된 이후에 삭제하는 방식으로 구성하였습니다. 이 과정을 매번 해야한다면 잘못된것이죠
• docker image관리와 관련해서는 프론트 서버와 백 서버를 빌드하고 docker image를 생성하여 docker hub에 올리게 됩니다. 이 과정을 이미 거치고 있기 때문에 빌드 자체가 불가능한 경우는 docker image 역시 빌드가 안되기때문에 문제는 안될것이구요. 그게 아니라 어플리케이션 로직에 문제가 있다면 docker image 관리의 문제가 아니라 어플리케이션의 문제죠. docker image의 할 일은 빌드가 잘된 코드를 가지고 해당 코드가 돌아갈 환경을 만들 뿐이라 문제가 있는 이미지가 만들어진다면 이걸 만드는 과정의 문제인거지 이미지의 문제는 아니라고 봐요. 이미지가 잘 만들어졌는데 서비스가 동작하지 않는다는건 빌드의 문제가 아닌 서비스 로직의 문제인거니깐요. 현업에서는 이런 서비스 로직의 문제를 배포 방식을 통해서 해결하곤 하는데요, 무중단 배포에 대해서 공부 해보면서 블루 - 그린 배포, 카나리 배포, 롤링 배포에 대해서 공부 해보시면, 그 과정에서 이런 배포방식을 통해서 서비스의 문제를 어떻게 파악하고 배포를 중단 혹은 되돌릴수 있는지에 대해서 공부 하실수 있을꺼에요