시작하며안녕하세요. 개발자 stark입니다. 오늘은 서킷 브레이커를 적용해 봅시다. 마이크로서비스 아키텍처(MSA)에서는 외부 API 호출 시 장애에 대한 대응이 매우 중요합니다. Spring Boot 애플리케이션에서 Feign 클라이언트를 사용할 때 Resilience4j의 CircuitBreaker를 적용하여 원격 호출 실패 시 Fallback 로직을 실행하는 방법을 소개하고자 합니다.  최근에 제가 LinkedIn을 보다가 Resilience4J에 대한 글을 보고 크게 감명을 받았습니다. 저도 MSA 프로젝트를 하면서 서킷 브레이커는 반드시 적용시켜야 한다는 것은 알고 있었습니다. 그러나 이것을 어떻게 설명할지에 대해서 고민만 하고 있었는데 요즘 수많은 장애들을 겪으며 조금 더 회복 탄력성이 필요하..

우리 팀은 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을 도입하여 로그 추적..

이번 포스트에서는 저번 포스트에서 설명하지 못했던 서버 간 통신에서 예외가 발생했을 때는 Zipkin 추적을 어떻게 할지 설명한다. 1. Zipkin 예외처리를 위해 @SqsListener 메서드 분석하기 1-1. 레시피 서버의 @SqsListener 메서드를 다시 한번 확인해 보자 이전 포스트부터 기록해둔 SqsListener 코드에는 이미 try-catch-finally가 되어있는데 이건 추적에 대한 예외처리가 완료된 상황의 코드다. 이렇게 포스트를 작성한 이유는 모든 동작에 이상이 없는 것을 확인하고 블로그에 글을 작성했더니 예외처리가 된 채로 코드를 캡처해서 글을 작성하게 되어버렸다. 1-2. Zipkin추적의 예외처리가 적용될 try-resource문법 여기서 중요한 부분은 catch문이다. 만..

저번 포스트에서 서버 간 분산 추적을 위해 Zipkin을 적용시켰는데 제대로 추적되지 않았다. 이것을 해결해 보자 이전 글은 아래의 포스트에 있다. SpringBoot MSA 로깅: Zipkin을 활용하여 효율적인 분산 로그 추적 하기 MSA에서 Zipkin을 사용하여 분산추적 로깅을 구현해 보자 이벤트를 사용해서 데이터베이스의 정합성 보장 문제는 해결했지만 아직 이 과정들을 전부 로그를 통해서 추적하는 것은 적용시키지 못 curiousjinan.tistory.com 1. Zipkin 적용시 발생한 문제점과 글을 이해하기 위해 알아야 할 내용 1-1. Zipkin을 적용하다 발생한 문제점 1. 각 SpringBoot서버에 Zipkin 적용은 완료했는데 서버 간 요청 추적이 제대로 되고 있지 않다. 2. ..