현재 내가 소마에서 진행하고 있는 프로젝트는 모여타라는 서비스로 목적지가 비슷한 사람들을 묶어 택시를 함께 타게 해주는 서비스이다. 승객이 먼저 모여 해당 방의 정원이 차면 매칭방에 지정한 출발지를 기준으로 3km 내의 기사를 호출하여 기사와 동승방이 매칭이 되어 함께 타서 비용을 절감할 수 있는 택시 모빌리티 서비스이다. 이때 매칭방과 관련해서 최대 3분동안 1km부터 시작해서 500m 씩 넓혀가며 최대 3km 인근의 기사를 찾아 호출한다. 그냥 간단하게 3km로 찾으면 되지 않나요? 라고 생각할 수 있지만 우리는 동승 택시 서비스이기에 혼자타는 것보다는 당연히 사람들이 인원이 다 모여야 하는 대기 시각 + 기사와 매칭방이 매칭이 되는 시각 까지 하면 사용자가 어느정도 시간을 투자해야 된다고 생각하여 ..

지난 글에서 카프카 서버 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://..