안녕하세요. 이벤트에 빠진 개발자 stark입니다!최근 저는 DDD에 푹 빠지게 되었습니다. 그래서 회사 선배님께 책을 빌려서 읽기도 하고 세미나도 보면서 정말 많은 공부를 하고 있습니다. DDD관련 책을 읽던 도중 '이벤트 소싱'이라는 목차가 등장했고 읽다 보니 엄청난 호기심이 생겼습니다. 왜냐하면 저는 주로 헥사고날 아키텍처와 EDA를 사용하여 개발을 해왔지만 제가 이벤트를 사용하게 되는 상황은 단순히 비관심사를 분리하는 상황뿐이었습니다. 특히 이벤트와 DDD와 조금만 검색해 봐도 Command와 Query를 분리하는 CQRS가 나옵니다. 그러다 보니 어느 순간부터 저도 코드에 "적용해 볼까?"라는 생각이 들면서 계속해서 고민하게 되었습니다. 가장 걸림돌이 된 것은 제가 이벤트 소싱과 CQRS의 개념..

안녕하세요! 글쓰는 개발자 stark입니다. 저는 최근 1년간 주로 MSA 프로젝트를 진행해 왔는데요 프로젝트를 설계하고 개발하면서 항상 같은 고민을 해왔습니다. 바로 MSA 서버 간 데이터 동기화 방법을 설계하는 것입니다.  MSA 서버 간 데이터 동기화를 진행한 이유저는 MSA 프로젝트 설계할 때 아래와 같이 각 서버별로 전용 DB를 가지도록 설계하였습니다. 만약 유저에 대한 정보를 유저 DB만 가지고 있다면 아래와 같이 게시글 서버, 소셜 서버, 미디어 서버에서는 비즈니스 로직에서 유저의 정보가 필요할 때마다 유저 서버에 API요청을 보내서 유저의 데이터를 받아와야 할 것입니다. 이렇게 되면 서버 간의 강한 결합(의존성)과 장애 전파가 될 수 있다는 문제점을 가지게 됩니다.만약 위의 상황을 아래와 ..

지금까지 내가 헥사고날 아키텍처를 설계해 보며 배운 점을 정리해 봤다.📌 서론지금까지 3번 정도 헥사고날 아키텍처를 적용시켜서 프로젝트를 만들어봤다. 첫 번째 설계에서는 왜 port 같은 것을 사용해서 이렇게 복잡하고 어렵게 설계하는 거지? 이런 생각이 많이 들었다. 원리를 이해하지 못하고 단순히 이게 좋다니까 해봐야겠다! 이런 생각을 하면서 개발을 진행했었던 것 같다. 관련된 자료를 열심히 찾아보기도 했지만 사실 제대로 알지 못하고 개발을 진행했다. 이렇게 원리를 잘 모르고 일단 개발해 보자는 마인드로 개발을 진행한 후 다시 한번 돌아보니 도메인 내부에 비즈니스 로직을 넣어두는 중요성을 놓치고 있었다. 그래서 서비스의 로직이 엄청 커지고 패키지도 많고 클래스도 많다 보니 오히려 이전과 큰 차이는 없으..

우리 팀은 MSA에서 SNS를 사용하여 서버 간 통신을 할 때 어떻게 완전한 Zeropayload를 적용했는지 소개한다. 우리 팀은 MSA 아키텍처를 구성하면서 Zipkin을 사용하여 분산추적을 설계했고 그 과정은 traceId를 SNS메시지를 통해 서로 주고받아서 추적하도록 설계했는데 여기에서 무언가 찝찝함이 계속 느껴졌다. 왜냐하면 지금 설계한 아키텍처에서는 Zeropayload정책이 지켜지지 않은 것 같았기 때문이다. 최소한이면서 꼭 필요한 정보만 담는 것이 Zeropayload 정책인데 나는 message안에 memberId라는 값 1개만 넣어서 메시지를 발행하는 것이 아니라 traceId를 같이 담아서 보내줘야만 했다. 이런 상황을 해결해보고자 다른 기업이나 지식 공유자 분들께서는 어떤 방식으로..

유실된 SNS메시지를 스케쥴러와 스프링 배치로 처리하는 방법을 설명한다. 우리는 MSA프로젝트에서 Transactional Outbox pattern을 사용해서 스프링 이벤트를 발행해서 SNS메시지 발행 + 발행여부를 본인 DB에 저장하는 것을 이벤트 리스너를 통해 동시에 진행하도록 설계를 완료했다. 이제 우리는 스프링 이벤트가 발행되어 SNS메시지 발행내역을 DB에 저장하는 것은 Transactional로 묶어두었으니 메시지 유실이 발생해도 발행여부는 false로 남으니 이것들만 찾아서 메시지 재발행을 하면 된다. 우리 팀은 이 유실된 메시지를 스케쥴러를 통해 5분마다 스프링 배치로 event_record_table에서 발행여부가 false인 유실된 메시지를 가지고 와서 SNS메시지를 재발행시키기로 결..

Spring MSA 프로젝트에서 단일 책임 원칙을 지키기 위한 리팩토링 우리팀은 MSA프로젝트에서 분산추적을 위해 Zipkin을 적용했다. 여기서 서버간 추적을 공유하기 위해서는 TraceId를 공유해야 한다는 것을 알게되었고 이에 SNS 메시지를 발행할때 snsClient.publish()메서드의 인자로 넣어주는 json 데이터에 TraceId도 포함해서 보내도록 로직을 수정했다. 이렇게 잘 사용하다가 우리는 코드 리뷰를 진행했는데 이때 평양냉면님이 이것은 단일 책임 원칙을 어기는것이 아닌가? 라는 질문을 해서 같이 이에대한 토론을 해본 결과 리팩토링을 진행하는것이 좋겠다고 결론이 나와 리팩토링을 진행했다. 오늘 포스트에서는 그 내용을 소개하고자 한다. Zipkin 설정을 했던 내용이 궁금하다면? ⬇️..

이번 포스트에서는 Sampling을 사용해서 내가 원하는 http요청만 Zipkin으로 추적해보도록 하자 MSA에서 요청 추적은 시스템의 성능과 안정성을 모니터링하는 데 중요한 역할을 한다. 최근 프로젝트에서 우리는 Zipkin 로그에 ALB의 Health Check 요청이 과도하게 기록되는 문제에 직면했다. 이 글에서는 이 문제를 인식하고 해결하기 위한 우리 팀의 접근 방법을 공유하려 한다. 이 포스트는 아래에 링크걸어놓은 이전 포스트에서부터 이어지는 내용입니다! Zipkin 로그 최적화: AWS ALB 헬스 체크 설정과 로그 추적 간소화 Zipkin 추적 로그에서 ALB가 헬스체크를 진행하다보니 계속해서 로그가 남았던 문제를 해결해 보고자 한다. 이번 포스트는 아래의 내용에서 이어지는 글입니다! Sp..

Zipkin 추적 로그에서 ALB가 헬스체크를 진행하다보니 계속해서 로그가 남았던 문제를 해결해 보고자 한다. 이번 포스트는 아래의 내용에서 이어지는 글입니다! SpringBoot MSA 로깅: Zipkin을 사용한 분산 추적에서 예외상황을 다루는 방법 이번 포스트에서는 저번 포스트에서 설명하지 못했던 서버 간 통신에서 예외가 발생했을 때는 Zipkin 추적을 어떻게 할지 설명한다. 1. Zipkin 예외처리를 위해 @SqsListener 메서드 분석하기 1-1. 레시 curiousjinan.tistory.com 지금까지 진행한 MSA 프로젝트에는 멤버와 레시피 서버 두 가지가 있었다. 이 서버들은 SNS와 SQS를 통해 서로 데이터베이스를 동기화하는 방식으로 설계되었고 Zipkin을 도입하여 로그 추적..