Min'sLog

Outbox·Inbox의 기본 개념을 정리한 뒤, 팀원이 구현한 Commerce의 Outbox 발행과 Payment의 Inbox 수신 코드를 읽었다.흐름도를 만들고, 읽으면서 생긴 질문을 따로 정리했다.이번에는 특히 OutboxRelay가 어디까지 책임지는지, 왜 보낼 메시지를 먼저 선점하고 커밋하는지, 다른 서비스도 같은 Outbox를 사용할 수 있는지가 궁금했다. Inbox에서는 형식이 잘못된 메시지로 수신이 멈추면 어떻게 다시 진행하는지 살펴봤다.개념을 코드에 대입하니, 메시지를 저장하는 테이블뿐 아니라 트랜잭션이 끝나는 지점과 실패 뒤에 남는 상태를 함께 봐야 흐름을 이해할 수 있었다.개념 보충: Outbox와 Inbox가 맡는 일Outbox는 업무 상태와 발행할 이벤트를 같은 로컬 DB 트랜잭션..

1. 정산 시스템에서 Spring Batch의 적용 범위를 검토현재 커머스 정산 시스템 프로젝트를 설계하고 있다. MSA 환경에서 대용량 데이터 처리를 맡는 서비스를 분리해 구성하는 과정에서 Spring Batch를 도입하자는 선택이 있었다.이때 정산 업무 중 어떤 영역을 배치로 처리할지 검토하게 됐다. 처음에는 주기적으로 실행하는 작업이면 배치라고 생각했다. 정산 대상을 모아 금액을 계산하는 과정과 실제로 지급하는 과정도 하나의 작업으로 이해하고 있었다.하지만 정산 흐름을 나눠 살펴보니, 같은 정산 업무 안에서도 처리 시점과 실패 이후의 대응 방식이 달랐다. 워커에 대해 별도로 찾아보면서 배치와 지급 워커의 역할을 구분하게 됐다.2. 개념 보충: 실행 주기와 처리 방식은 구분스케줄러는 작업을 언제 실행..

- 프로젝트 githubhttps://github.com/logistics-group3/logistics-management1. 팀 프로젝트 발표와 내가 맡은 부분오늘은 물류 관리 팀 프로젝트의 발표가 있었다.이번 프로젝트에서 내가 개발·구현하고 테스트한 범위는 user-service를 중심으로 한 인증·인가 흐름과, Gateway에서 사용하는 사용자 권한 재확인 캐시를 Redis로 공유하도록 고도화하는 작업이었다.기존 로컬 캐시는 각 Gateway 인스턴스의 메모리에 따로 저장된다. Gateway를 수평 확장하면 같은 사용자의 정보가 인스턴스마다 별도로 남고, 권한 변경을 반영하는 시점도 달라질 수 있다. 여러 인스턴스가 같은 캐시를 바라보도록 만드는 것이 Redis 도입의 근거였다. 팀에서도 도입하기..

MSA에서 주문과 배송을 서로 다른 서비스가 처리한다면, 배송 생성은 성공했는데 주문 저장은 실패할 수 있다. 이런 상황에서 데이터의 일관성을 어떻게 맞추는지 Saga 패턴을 중심으로 정리했다.1. 서비스가 나뉘면 트랜잭션도 나뉜다하나의 DB에서 주문과 배송을 같은 트랜잭션으로 저장한다면, 중간에 실패했을 때 함께 롤백할 수 있다. 하지만 주문 서비스와 배송 서비스가 각자의 DB를 관리하면 상황이 달라진다.주문 서비스의 일반적인 로컬 @Transactional은 HTTP로 호출한 배송 서비스의 DB 작업까지 묶어 주지 않는다. 주문 저장이 롤백되어도 배송 서비스에서 이미 커밋한 데이터는 남는다.개념 보충: Saga는 여러 서비스에 걸친 작업을 로컬 트랜잭션의 순서로 나누어 처리한다. 중간에 실패하면 이미..

오늘은 RabbitMQ의 기본 개념을 공부하고, 주문 ID를 메시지로 보내는 Spring Boot 예제 프로젝트를 학습하였다.메모에 적은 개념을 실제 설정과 코드에 연결해 정리했다.공식 문서를 바탕으로 추가한 동작 설명은 개념 보충, 원본 코드와 다른 발행 방식은 참고 예시로 구분했다.1. RabbitMQ와 메시지 전달 구조메모에는 메시지 브로커를 “송신자와 수신자 사이에서 데이터를 전달하는 매개체”라고 정리했다. RabbitMQ는 이러한 메시지 브로커다.주문 서비스가 결제 서비스를 직접 호출하는 대신, 주문에 관한 메시지를 RabbitMQ에 보내고 결제 서비스가 이를 받아 처리하는 구조를 만들 수 있다.개념 보충: 각 구성 요소의 역할구성 요소역할이번 예제Message전달하는 데이터문자열 형태의 주문 ..

오늘은 Redis를 활용한 인메모리 캐싱을 공부했다.Cache Hit, Cache Miss 같은 기본 용어와 세 가지 캐싱 전략을 정리하고, Spring Boot에서 캐시를 설정하는 구성 요소와 어노테이션을 살펴봤다.1.Redis와 캐싱의 기본 용어Redis는 데이터를 메모리에 두고 빠르게 읽고 쓸 수 있는 저장소다.캐시로 활용할 때는 DB에서 조회한 데이터나 계산 결과의 복사본을 저장해 반복 작업을 줄인다.여기서는 DB를 원본 저장소, Redis를 캐시로 사용하는 구조를 다룬다.용어의미Cache Hit요청한 데이터가 캐시에 있어 캐시에서 가져오는 경우Cache Miss요청한 데이터가 캐시에 없어 원본 조회 등이 필요한 경우Caching Strategy데이터를 언제 캐시에 넣고, 원본 저장소에 언제 반영..

오늘은 진행 중인 물류 배송 팀 프로젝트에 Prometheus, Grafana, Zipkin을 적용했다.여러 서비스로 나뉜 MSA 환경에서 서비스의 상태와 요청의 이동 경로를 살펴보기 위한 구성이다.세 도구가 각각 어떤 역할을 하는지 개념을 보충하고, 프로젝트에 반영된 설정을 중심으로 정리했다.설정은 2026년 10월 16일 기준 팀 저장소의 dev 브랜치를 기준으로 하며, 아래 코드는 관련 repo이다.팀 프로젝트의 모니터링 구성과 가이드학습 키워드: Prometheus, Grafana, Zipkin, 메트릭, 분산 추적, Spring Boot Actuator, Micrometer1. 세 도구는 무엇을 보여 줄까?도구역할확인할 수 있는 내용Prometheus메트릭 수집·저장·조회요청 수, 오류율, 응답..

오늘은 프로젝트의 기술 스택을 아는 것, 애매한 것, 모르는 것으로 나누고, Eureka와 LoadBalancer가 서비스 호출에 어떻게 참여하는지에 대해학습을 진행했다.order-service가 hub-service를 호출하는 상황을 기준으로, 서비스의 위치를 찾는 과정과 실제 요청을 보내는 과정을 연결해 정리하였다.학습 키워드: Eureka, 서비스 디스커버리, Spring Cloud LoadBalancer, 클라이언트 측 로드 밸런싱, OpenFeign1. 서비스 목록을 관리하는 Eureka와 호출 대상을 고르는 LoadBalancer같은 서비스를 여러 개 실행하면 호출할 수 있는 대상도 여러 개가 된다. 이때 실행 중인 서비스 하나하나를 인스턴스라고 한다. 예를 들어 hub-service를 세 개..