멘토링 날짜 : 2024년 2월 7일 수요일 오전 10:10

⭐ 이번 주 한 일

• 팀원 개인
  • 김재윤
  • 임지훈
  • 장규빈
  • 황규정

⭐ 질문 정리

• [김재윤] 오픈소스 기여를 해보고 싶은데 (바쁘면 취업 이후로), 저와 같은 신입 개발자가 도전할 만한 범위나 분야가 있을까요? (우선 생각해둔 레포로는 spring data redis가 있습니다 하하,,)

  • 오픈소스 커미터.. 스프링 진영에서는 불가능 ㅠㅠ
  • 스프링 오픈 소스 이지만, 컨트리뷰터는 특정 재단에서 해서 일반 사용자는 불가

• [임지훈]

  1. SpringBoot의 Retry를 사용하게되면 트랜잭션과 동일한 스레드를 재사용하게 되어서 성능 상 이슈가 있다고 생각합니다. 튜터님의 의견이 궁금합니다.

     • 어떤 곳에서는 직접 스레드풀을 만드셔서 관리해주시기도 하더라구요. 실제로 이렇게 하는지 궁금합니다. (Custom-RetryHandler)

     Request를 다시 보내거나, Batch를 돌리는 게 나을 듯

     특정 부분의 메서드 재사용시, 아래와 같은 단점 존재

     • 성능 상 이슈
     • 데이터 정합성이 꺠질 가능성

  2. JPA의 Dirty Checking 에 대해서는 Pessimistic Lock 을 걸지 않아도 될까요? MySQL의 MVCC로 제어가 가능한 부분인지 궁금합니다.

     • 입찰에 의한 주문 시나리오에서, JPA의 Dirty Checking 에 의한 구매자,판매자의 Point 증감 처리
       • BuyBidProvider.java
       • SellNowProvider.java
       • BuyNowProvider.java
     • 아무리 테스트 해도 구매자,판매자의 포인트 증감에서는 에러가 나지 않아, MVCC로 제어되는거구나 넘겨짚었는데 확실치가 않습니다.
       • BuyNowConcurrentTest.java
       • SellNowConcureentTest.java

  3. Pub/Sub 구조로 리팩터링한 페이먼츠 개발이 굉장히 어색하다고 느껴집니다. 튜터님의 의견이 궁금합니다.

     • ApplicationPublisher를 통해 분산서비스에 대한 Event Handler를 분리했습니다.

     • Pub/Sub 구조는 One-way 식 코드패턴입니다.

     • 하지만 페이먼츠 구조는 Two-way 로 처리됩니다.

     • 왜냐하면 페이먼츠는 특성 상 결제 상태에 따른 비즈니스 처리가 상당히 많이 필요하기 때문입니다.

       • 결제 이전 비즈니스 로직, 결제 중 비즈니스 로직, 결제 후 비즈니스 로직

       • 이에 따라 결국 이벤트 핸들러 또한 비즈니스 로직 처리를 하게 되었습니다.

         

     • 하지만 분사서비스 호출과 비즈니스를 분리하게 된다면, 에러 발생에 따른 롤백처리가 어려워집니다.

       페이먼츠는 따로 모놀리식으로 분리해서 분산서비스를 받아주도록 하자.

       • Message Queue 를 사용하여 페이먼츠를 처리
       • 페이먼츠만 단일 엔드포인트를 사용하여 트랜잭션 관리를 분리

  4. [개인질문] 제 이력서 상, 현 프로젝트에 관해 어필한 부분이 없는지 궁금합니다 (곧 인턴십 면접 할 수도 있을 것 같습니다) 임지훈 Ver4

• 어필할 부분

  • 내가 어필하고 싶은 부분과 면접관이 관심있는 부분과 상당히 차이가 있을 수 있다. → 노력이 필요. 채용 공고를 보며 우대사항이나 자격 요건 등을 보며 원하는 내용을 우선 확인하고, 프로젝트에서 해당 부분을 찾아서 작성하기
  • 프로젝트 전반적으로 어필할 만한 부분
    • 데드락 동시성 이슈 문서. 아직 완성은 안 됐지만, 어필할만한 부분.
    • pub/sub, cascade, cqrs 적용기 등 글 괜찮.