<aside> 🏁 실전 프로젝트 5주차에 가장 집중해주셔야 할 것은 “프로젝트의 완성도 높이기”입니다. MVP에 추가 및 보완해야 할 기능, 우리의 프로젝트가 기술적으로 인정 받을 수 있는 특징을 정리해주세요. 멘토님들과 함께 프로젝트를 높은 완성도로 마무리 할 수 있는 방향을 점검해 봅니다.

</aside>

• 지금까지 배운 트러블 슈팅에 대해 고민하신 후, 가장 적합하다고 생각하는 트러블 슈팅을 한 가지 이상 작성해 주세요!

• 프로젝트에 새롭게 도입한 기술이 있다면 정리해 주세요! (도입 이유도 꼭 적어주세요!)

  • Kafka
    • 사용자가 상품에 구매하는 API 동작 로직에서 주문 생성 과정을 비동기 처리하여 주문 API의 속도 성능을 개선하기 위해서 도입
    • Kafka 서버 세팅
      • Kafka << 사용한 명령어 모음
    • Application 세팅
      • Producer에 전송 실패 시, 전송 재시도 로직, 수량을 다시 복구 로직 구현
      • Consumer에 DefaultErrorHandler(재시도, Message 처리 실패시 로직) 추가
      • Consumer에는 ConcurrentMessageListenerContainer 세팅(다수 consumer)
    • 추가 고려 사항
      • kafka 서버를 현재 t3.small 로 1대로 운영. 이를 2n-1개로 운영할 것인가
      • scale out 환경에서 sse 도입할 경우, 각 서버는 다른 서버의 사용자가 요청한 주문 정보를 어떻게 알아와서 response 할 것인가
      • 현재 broker 서버에 1개의 topic과 12개의 partition 존재. 이를 consumer에서는 concurrency=3으로 세팅하여 1개의 consumer가 1개의 partition을 담당하도록 설정하였는데, auto scaling 환경에서 고려해야 할 점은 무엇인가. ⇒ partition과 consumer 생성 전략.
  • Spring Batch
    • Spring Batch 를 적용하여, 오픈런 상품을 업데이트하는 로직을 단순 scheduler를 통해서 구현하는 것이 아니라, 하나의 Job으로 정의하고 Step을 tasklet으로 정의하여 DB 작업의 상태를 저장 가능
    • Spring batch에서 제공하는 jobExplorer.findRunningJobExecutions("productJob"); 과 redis의 분산락 메커니즘을 사용하여 여러 대의 인스턴스에서 배치 작업이 실행될 때, 이를 1대의 인스턴스에서만 실행할 수 있도록 처리 완료.
    • 추가 성능 개선이 필요한 부분
      • Spring batch를 통해 ((페이지를 조회 → 레디스에 추가))하는 방식을 chunk 단위로 transaction을 관리하면서 대용량 데이터를 빠르게 처리하는 로직이 추가되면 좋을 것으로 판단.
      • batch 작업이 실패했을 때, 이를 재시도 로직 추가
      • Error Handling 로직 추가

• 이번 주 한 일

  • 팀 전체 (리더님께서 필두로 정리해 주세요.)
    • Spring Batch를 이용해 하나의 EC2에서 스케줄러 작동
    • Kafka 연결 후 구매 로직 완성 <<ec2에서 돌려볼 필요 있음…>>

• 이외에도 기술적인 방향을 잡기 위한 질문을 정리해오시면 가장 좋습니다!

  → 4 주차 멘토님께 드릴 질문 리스트

• 숙제: 멘토링 결과 다음 주까지 해올 일

  • 팀 전체 (리더와 부리더님께서 필두로 정리해 주세요.)