MSA 환경에서 분산 트랜잭션 방식으로 구현 시 서비스 간 이벤트 발행이 필수이다.각 서비스에서는 별도의 트랜잭션으로 로직을 처리하고 이벤트를 발행하게 되는데 이때 트랜잭션이 커밋 또는 롤백된 경우에만 이벤트가 발행되도록 보장해야 한다. 이 글에서는 Outbox 패턴과 Spring의 @TransactionalEventListener 방식을 고민한 끝에 @TransactionalEventListener를 사용하여 문제를 해결한 사례를 공유하고자 한다. Outbox 패턴 vs. @TransactionalEventListenerMSA 환경에서는 서비스 간 데이터 일관성을 유지하기 위해 분산 트랜잭션 처리가 필요하다. 이때 트랜잭션 커밋 또는 롤백 시에만 카프카 이벤트가 발행되도록 보장해야 한다.Outbox 패..
기술 블로그
서론기존 마이페이지 기능은 사용자 서비스(user-service)가 상품 서비스(goods-service)와 주문 서비스(order-service)에 대해 각각 동기 방식으로 데이터를 요청했다. 이때 REST 기반의 통신을 지원하는 OpenFeign, 안전성을 위한 Resilience4j를 통해 서비스 간 통신을 진행한다. 이러한 구성은 다른 서비스에 장애가 발생하더라도 적절한 장애 처리가 가능했지만, 동기 방식의 통신 특성상 각 요청이 순차적으로 처리되어 전체 응답 시간이 길어진다는 단점이 존재했다. 성능 개선을 위해 CompletableFuture를 이용해 비동기 병렬 처리 방식으로 전환하기로 결정하였다.최종적으로 마이페이지 조회 시 필요한 여러 서비스의 데이터를 동시에 요청하고, 모든 요청이 완료될..
서론MSA 환경에서 상품 주문 처리 기능을 구현하는 과정에서 트랜잭션과 이벤트 발행의 실행 시점 차이로 인해 문제가 발생하였다. MSA 환경에서 트랜잭션과 이벤트 발행의 중요성트랜잭션과 이벤트 간의 일관성을 보장하는 것은 시스템의 안전성, 데이터 일관성, 그리고 서비스 간 느슨한 결합을 유지하는 데 중요하다.데이터 일관성 유지: 트랜잭션이 성공적으로 커밋된 경우에만 이벤트를 발행함으로써, 데이터 일관성을 보장해야 한다.ex) 주문 처리가 성공적으로 이루어진 경우에만 결제 처리 이벤트를 발행해야 한다.분산 시스템에서의 느슨한 결합: 이벤트 기반 아키텍처는 서비스 간의 느슨한 결합을 지원한다.트랜잭션 결과에 따라 이벤트를 발행하면, 각 서비스는 독립적으로 작동할 수 있으며, 이벤트를 구독하는 방식으로만 다른..
서론상품 재고 관리의 중요성상품 재고 관리는 커머스 프로젝트에 있어 핵심적인 과제 중 하나이다.재고 부족으로 인한 판매 기회 손실, 정확도 저하로 인한 고객 만족도 감소 등 다양한 문제가 발생할 수 있다.이로인해 실시간으로 정확한 재고 파악과 이를 기반으로 빠르게 의사결정을 내리는 것이 중요하다. 레디스(Redis)를 활용한 재고 관리 시스템의 필요성이러한 상품 재고 관리에 있어 레디스(Redis)를 활용한 방식은 큰 강점을 가진다.레디스는 키-값 저장소로써, 빠른 데이터 처리 속도와 싱글 쓰레드를 통한 높은 동시성 처리 능력을 가진다.이를 통해 대규모 트래픽이나 대량의 데이터가 발생하는 상황에서도 실시간으로 재고 정보를 업데이트하고 조회할 수 있다. 현재 커머스 프로젝트에서 상품 재고를 레디스 캐시(C..
자바 스프링 MSA 환경에서 카프카를 이용해 주문 취소 기능을 구현하며 발생한 문제와 해결 방법에 대해 작성한다. 소개구현하고자 하는 바는 다음과 같다.사용자는 자신의 주문에 대해 '주문 취소'를 요청한다.주문 서비스는 주문 취소 작업 처리 후 카프카에 '주문 취소 토픽'에 이벤트를 발행한다.이때 주문 취소 토픽은 하나의 파티션으로 구성되어 있다.상품 서비스와 결제 서비스는 '주문 취소 토픽'에서 이벤트를 소비해서 작업을 처리한다. 문제주문 서비스에서 주문 상태를 취소로 변경하고 주문 취소 이벤트를 카프카 주문 취소 토픽에 발행해 상품 서비스와 결제 서비스에서 해당 주문 취소 토픽을 구독하고 이벤트를 소비하려 했다. 그러나 테스트 결과는 달랐다. 이벤트가 제대로 발행되는 것은 확인했으나, 두 서비스 모두..
서론상품의 주문 처리 속도는 고객 만족도에 직접적인 영향을 미친다.데이터베이스로 재고를 관리하는 방법은 데이터의 일관성을 유지하는 데는 효과적이지만, 높은 트래픽이 발생하면 데이터베이스에 과부하가 걸려 사용자 경험에 부정적인 영향을 미친다.이 문제를 해결하기 위해, 데이터베이스 대신 Redis 캐시를 사용하여 상품 재고를 관리하는 방식으로 시스템을 개선하기로 결정하였다. Redis는 고성능 키-값 저장소로, 빠른 읽기 및 쓰기 속도를 제공한다.성능 개선 과정은 크게 세 단계로 나누어 진행했다.Write-Through 쓰기 전략: Redis와 데이터베이스 모두 데이터를 쓰는 방식Write-Back 쓰기 전략: Redis에만 데이터를 쓰고 특정 조건에서 데이터베이스에 데이터를 업데이트하는 방식Redis의 L..
주문 요청이 들어오면, 상품 서비스에서 요청을 받게 된다. 그러면 상품 서비스는 상품 재고를 검사하고 해당 상품이 현재 구매 가능한 시각인지 검사 그리고 재고를 감소시키는 작업을 수행한다. 시간 효율성을 위해 상품 재고를 Redis에 Cache하여 사용하려 한다. 트러블 슈팅현재 상품 재고를 레디스에 캐싱하여 관리한다. 또한 동시성 제어를 위해 Redisson Lock을 사용한다.주문 요청이 들어오면 상품 서비스에서 로직은 다음과 같다.레디스에서 상품 재고 조회재고가 부족하다면 재고 부족 예외 발생레디스에 상품 재고 정보가 없다면 데이터베이스에서 조회 후 캐싱데이터베이스로부터 상품 조회구매 가능한 시간인지 검사구매가 불가능한 시간이라면 예외 발생레디스 상품 재고 감소데이터베이스 상품 재고 감소 기존 코드..
채팅 기능 기본 설정 설명에 앞서, 시스템에서 채팅 기능이 어떻게 동작하는지 로직을 우선 설명하도록 한다. 웹소켓 생명주기 관리🥸우리 시스템의 대략적인 웹소켓 연결 과정은 다음과 같다. 웹소켓 연결 초기화사용자가 로그인을 완료하면, "ISLOGIN" 쿠키 값을 확인하여 로그인 상태(True)일 경우에 한 번만 웹소켓 연결을 요청한다.웹소켓 연결 유지 관리웹소켓 연결이 성공적으로 이루어지면, 서버는 사용자의 ID를 웹소켓 세션에 저장한다.리액트 클라이언트는 웹소켓을 통한 모든 통신 과정을 진행하기 전에 웹소켓 연결 상태를 확인한다. 연결이 끊어진 경우, 자동 재연결 시도와 함께 필요한 토픽 구독을 재요청한다.토픽 구독 및 메시지 처리사용자는 서버로부터 자신의 ID를 받고, 이를 사용하여 알림 및 채팅방 ..
WebSocket, Stomp, Kafka, MongoDB, MySQL, Redis를 사용하여 채팅 기능을 구현하였다.이번에는 시간 타입 변경(String -> LocalDateTime)에 의한 성능 개선 경험 그리고 Kafka를 사용한 성능 개선 경험에 대해 작성해보려 한다. 성능 테스트 구성테스트에 앞서 WebSocket 테스트를 위해서는, JMeter에 WebSocket 플러그인을 설치해야 한다. Thread Group 구성웹소켓 연결 시작(WebSocket Open Connection)웹소켓 연결 요청(SEND CONNECT)채팅방 구독 요청(SEND SUBSCRIBE)메시지 전송(SEND CHAT)응답 대기(READ CHAT)웹소켓 연결 해제(DISCONNECT)※ 이때, 채팅방 구독 해제와 웹..
이전 글에서는 채팅 기능에 WebSocket, Kafka, MongoDB를 사용하는 이유에 대해 작성해보았다.이번에는 채팅 기능에서 사용되는 도메인 설계에 대해 작성해보려 한다. 도메인 설계채팅 기능에 사용되는 도메인과 저장되는 저장소 목록은 다음과 같다.채팅방(ChatRoom): RDBMS채팅 메시지(ChatMessage, Message): MongoDB채팅 알림(ChatNotification, Notification): RDBMS채팅방 입장 상태 (ChatRoomParticipant): REDIS 채팅방(ChatRoom)채팅방은 사용자들이 서로 메시지를 주고받을 수 있는 공간으로, 관계형 데이터베이스(RDBMS)에 저장된다. 채팅방 정보는 사용자 정보와 긴밀히 연결되어 있어, 조회 시 사용자 정보를 ..
