지난 글에서 카프카 서버 3대로 클러스터를 구성하고 레플리케이션까지 실습해보았다. https://mari-laveau.tistory.com/312 이제 기본기는 어느 정도 배웠으니, 지금까지 배운 것들(토픽, 컨슈머 그룹, 파티션, 레플리케이션, 재시도, DLT)을 한 번에 써먹는 미니 MSA 프로젝트를 만들며 실습을 진행하였다. Kafka는 MSA 구조에서 많이 사용된다고 했는데, 실제로 어떤 식으로 쓰이는지 눈으로 확인해보는 게 목적이다. 프로젝트 설계구현할 기능은 단순하다. 회원 가입을 하면 회원가입 축하 이메일을 발송하게 만들기.User Service (8080) : 회원 가입 기능만 담당. 가입한 사용자 정보를 User DB에 저장Email Service (8081) : 이메일 발송 기능만 담당..

지난 글까지는 EC2에 카프카 노드 1대만 띄워놓고 실습을 진행했었다. https://mari-laveau.tistory.com/307 그러다 문득 의문이 들었다. "지금 구조에서 이 카프카 서버가 고장나면 어떻게 되는 거지?" 노드가 1대뿐이니 메시지를 전달하는 것 자체가 막혀서 서비스 장애로 직결된다. 이번에는 카프카의 고가용성(시스템이 장애 상황에서도 멈추지 않고 정상적으로 서비스를 제공할 수 있는 능력)을 확보하는 방법을 실습하며 정리한다. 노드, 클러스터, 브로커, 컨트롤러, 레플리케이션이란?노드(node) : 카프카가 설치되어 있는 서버 단위클러스터(cluster) : 여러 대의 서버가 연결되어 하나의 시스템처럼 동작하는 서버들의 집합브로커(broker) : 메시지를 저장하고 클라이언트의 요청..

최근 소마 프로젝트를 진행하면서 문득 오류와 의문이 생긴 경우가 생겼다.우리는 동승 택시 프로젝트이다보니 동승 관련(매칭) 부분에서 많은 부하가 있을 것이라고 판단하였고, 추후 배포가 된 이후 로직이 변경되거나 다시 배포할 경우 가장 핵심인 부분이 재배포될 때 전체를 다시 배포하는 것보다 하나의 모듈(매칭)만 바꿔서 배포하는 것이 더 좋다고 판단되어 MSA를 고려한 DDD + Modular monolith 구조를 사용하여 모듈 간 의존성을 없애고 개발하기로 결정하였다. 이때 모듈(서버) 간의 통신이 필요한 경우가 생기며 통신 수단에 대해서 고려해보았다. 상황은 동승방을 사용자가 생성하고 다 모이면 매칭방에 있는 사람들을 태울 배차 서비스가 실행이 되어야 하며 동시에 근처에 있는 기사에게 알림을 전송해야 ..

최근 프로젝트를 진행하면서 프로모션으로 선착순 쿠폰 기능을 도입하면 좋겠다고 생각하였다.하지만 해당 서비스를 구현하기 위해서는 여러가지 요소들을 고려할게 많았다 선착순 쿠폰 발급시스템의 요건은 다음과 같다.들어오는 순서대로 쿠폰을 발급해야 한다(First Come, First Served)정해진 수량만큼 쿠폰을 발급해야 한다(5000개의 쿠폰이 발급됬을 경우 5000개 초과의 쿠폰이 발급되면 정합성이 유효하지 않다)단기간에 증가하는 트래픽을 견뎌야 한다. 주어진 요건에 따라 기술적 해결책을 생각해 보았다.들어온 순서대로 쿠폰을 발급해야 한다.Http Request에 대한 개별 Thread(Tomcat)의 요청이 순서대로 수행될 수 있도록 제어해야함정해진 수량만큼 쿠폰을 발급해야 한다.동시성을 제어해야함여..

지난 글에서 Kafka의 기본 개념을 정리하며 실습을 하다가 한 가지 의문이 남았었다. API 요청을 세 번 연속으로 보내면 컨슈머가 메시지를 하나씩만 처리해서, 3초짜리 이메일 발송 3개에 9초가 걸리는 현상이었다. https://mari-laveau.tistory.com/306 원자적 UPDATE -> Redis Lua Script 순으로 처리량을 개선해보았었다. 그러다 이메일 발송처럼 오래 걸리는 " data-og-host="mari-laveau.tistory.com" data-og-source-url="https://mari-laveau.tistory.com/306" data-og-url="https://mari-laveau.tistory.com/306" data-og-image="https://..

들어가기에 앞서최근 선착순 쿠폰 발급 프로젝트에서 동시성 제어를 실습하며 비관적 락 -> 원자적 UPDATE -> Redis Lua Script 순으로 처리량을 개선해보았었다. 그러다 이메일 발송처럼 오래 걸리는 작업을 API 요청 안에서 동기적으로 처리하는 게 맞는지 의문이 들었고, 메시지 큐를 공부하기 위해 Kafka 입문 강의를 수강하며 실습을 진행하였다.실습은 Producer 쪽은 기존에 진행하던 쿠폰 프로젝트에 파일 몇 개만 추가해서 진행했고, Consumer는 별도의 Spring Boot 프로젝트로 구성하였다. Kafka 브로커는 EC2에 설치해두고 사용했다. Kafka의 기본 구성 (Topic, Producer, Consumer)프로듀서(Producer) : 카프카에 메시지(데이터)를 전달하..