포스팅 개요

 안녕하세요 매일 수 많은 고민과 함께 새로운 것을 알게되고 성장을 느끼는 F4팀의 김혁준입니다.
저희 팀은 미술품 경매를 주제로 MSA 프로젝트를 설계할 때 구현 방식에 대해 고민하다가 Kafka를 떠올렸습니다.
이번 포스팅에서는 프로젝트에서 Kafka를 어떻게 활용하는지, 저희 팀이 어떤 고민을 했고 왜 Kafka를 떠올렸는지 말씀드리겠습니다.
(kafka에 대한 간단한 설명입니다.)
kafka 기술 블로그

프로젝트에서 Kafka 활용 로직

image

입찰 요청 (Auction-Service)

 상품 상세 조회 페이지에서 사용자가 입찰 가격과 비밀번호를 입력한 후 입찰 버튼을 누르면 먼저 입찰 요청이 유효한지 (계좌의 사용 가능한 금액이 입찰 요청 금액 이상인지, 결제 비밀번호가 일치 하는지, 경매중인 상품인지) 검사한 후에 유효한 경우 입찰 요청 이벤트를 발행합니다. 이때, 입찰 요청에 대한 순서가 같은 상품에 대해서는 지켜져야 한다는 생각을 하여 이벤트의 key값을 상품의 id로 지정해줍니다.

입찰요청

Client가 Browser에서 입찰 가격, 결제 비밀번호를 적은 후 입찰 요청

유효성 검사

Client가 입찰 가격에 해당하는 금액을 보유하고 있는지, 결제 비밀번호가 일치하는지, 경매 중인 상품인지에 대한 유효성 검사 진행 (입찰 요청이 유효한 요청인지 확인) 유효한 요청인 경우 kafka 이벤트 발행 (key : 상품 id)



입찰 결과 확인 (Auction-Price-Updater)

 입찰 요청 이벤트를 구독하는 Service에서 입찰 요청의 value를 활용하여
이미 입찰에 성공한 사용자가 요청한 경우, 입찰 요청 가격이 현재 입찰 가격보다 낮은 경우에는 FAIL
그 외에 경우에는 SUCCESS
서버의 에러로 입찰 요청이 무효가 된 경우 ERROR를 담아서 이벤트를 발행합니다.
입찰에 성공한 경우에는 추가로 상품의 경매에 관한 정보를 변경하고 MockAPI에 기존 입찰자와 새로운 입찰자의 사용 가능 금액 변경을 요청합니다.

입찰 요청 결과

②에서 발행한 이벤트에 대해 입찰 결과에 대해 판단 후 기록 위한 이벤트 발행 입찰 성공한 경우 상품 현재 경매 정보 변경 및 계좌 변경 요청



입찰 요청 기록

입찰 결과 확인에서 발행한 이벤트의 value를 활용하여 데이터를 테이블 구조에 알맞게 정제한 후 DB에 저장합니다.

기록

③에서 발행한 이벤트에 대해 데이터 정제 후 DB에 기록



Schedule

스케줄러에서 일정한 시간마다 경매가 종료된 상품의 정보를 활용하여
상품을 낙찰받은 사용자에게 낙찰 되었다는 email을 전송하고
낙찰 받은 사용자의 실제 잔액에서 낙찰 금액을 차감합니다.
다른 두 서비스를 호출하는 방식보다 event를 발행 후 두 서비스가 event를 구독하는 방식을 선택하여 요청을 단순화 했습니다.

스케줄러 통해 경매가 종료된 상품 이벤트 발행
Email-Service, Payment-Service가 구독 후 로직 수행



Cluster 구성

image
 저희 팀은 Confluent Kafka를 사용하였습니다. Confluent에서 제공하는 SaaS형 카프카는 완전 관리형이기 때문에 카프카 클러스터 서버를 쉽게 구성할 수 있고 웹 대시보드를 사용해 토픽 생성/삭제 등을 수행할 수 있습니다.
 Kafka의 데이터 처리 속도 뿐만 아니라 안정성까지 확보하기 위해 저희 팀은 클러스터에 브로커 3개와 replication factor를 3으로 설정할 예정입니다.
Kafka Cluster를 잘 모르신다면 Cluster 기술 블로그 를 참고해주세요



마무리

 경매가 저희 팀에게 익숙한 주제는 아니지만 실시간 경매 서비스를 구현하기 위해 어떤 점을 고려해야 할지, 그 점을 어떻게 구현할 것인지에 대한 고민을 끊임없이 하고있습니다😅

저희가 프로젝트를 구현하기 위해 고민한 부분은

첫 번째로는 입찰 요청 트래픽이 한 번에 많이 발생했을 경우에 어떻게 효율적으로 처리할 것인가.
두 번째로는 같은 가격의 입찰 금액을 요청했을 경우에 입찰 요청 순서가 중요할텐데 어떻게 순서를 보장할 것인가.
세 번째로는 어떻게 데이터의 손실을 발생시키지 않을 수 있을까 입니다.

저희는 세 고민을 해결하기 위해 Kafka를 사용하였습니다. Broker 세 개로 Cluster를 구성하여 데이터 처리의 효율성을 높이고, Event의 Key값을 상품의 Id로 하여 같은 상품에 대해 입찰 요청 순서를 보장하였습니다. 또한 Kafka를 이벤트 버스로 사용하면서 Replication을 활용하여 데이터의 손실도 방지할 수 있었습니다.😊

저희 팀은 매일 회의를 진행하며 각자 고민하는 점을 얘기하여 프로젝트가 점점 더 발전할 수 있는 방향을 찾아가고 있습니다. 저희 블로그를 우연히 들어오셨다면 저희의 MSA 도전기를 꼭 봐주세요 감사합니다.😁