스프링부트 3.x.x에 gRPC 예외 처리 인터셉터를 적용시켜 보자📌 서론저번 포스트에서 SpringBoot3.3.1에 gRPC를 적용시켰다. 완전히 최신 버전을 사용해보고자 했기에 java, gradle, protobuf, spring 버전에 따른 오류도 조금씩 있었는데 아직 이 부분은 조금씩 진행하면서 코드를 개선하는 중이다. (계속 업데이트해서 올릴 예정)이번 포스트에서 소개할 내용은 gRPC의 예외처리 방법이다. http에서는 예외가 발생하면 @RestControllerAdvice를 사용해서 전역 예외처리를 하곤 한다. 그럼 gRPC도 예외처리를 하는 방법이 있지 않을까? 당연히 예외처리가 가능하다.검색을 해보니 SpringBoot에서는 gRPC의 예외처리를 인터셉터를 통해 처리한다는 것을 알아..

SpringBoot3.3.1에 gRPC를 적용시켜 보자📌 서론개인적인 공부를 하면서 MSA 프로젝트를 구성할 때 유저(Client)의 기본적인 요청에 대해서 먼저 http로 받아서 처리하고 만약 서버 간 소통이 필요하다면 그때는 gRPC를 사용하도록 하기 위해 gRPC를 도입해보고자 했다. 아무것도 모르는 상태에서 공부를 시작했고 일단 도입해 보면서 발전시켜 가자는 목표로 코드에 1차 적용을 시켰다. 막상 적용시켜보니 버전에 대해서 이슈가 조금 있어서 생각보다 오래 걸렸지만 잘 동작하는 것을 보니 매우 뿌듯했다.혹시나 gRPC를 도입하고자 하는 분들을 위해 적용방법을 남기고 가능하면 조금 더 좋은 방법이 있다면 도움을 받고싶다.코드는 아래 Repo에 넣어두었습니다! GitHub - wlsdks/grpc..

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

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문이다. 만..

MSA에서 Zipkin을 사용하여 분산추적 로깅을 구현해 보자 이벤트를 사용해서 데이터베이스의 정합성 보장 문제는 해결했지만 아직 이 과정들을 전부 로그를 통해서 추적하는 것은 적용시키지 못했다. 로그가 정말 중요한 만큼 zipkin을 사용하여 제대로 로그를 추적해 보도록 하자. 이번 포스트에서는 ZIpkin을 활용하여 MSA 환경에서 분산 로그 추적을 구현하는 과정을 단계별로 설명한다. 1. ECR 리포지토리 생성하기 ECR(Elastic Container Registry)은 AWS에서 제공하는 Docker 컨테이너 이미지를 저장하기 위한 서비스다. 여기서는 Zipkin 이미지를 위한 저장소를 만드는 방법을 설명한다. 1-1. Zipkin 이미지를 저장할 AWS ECR 생성 zipkin 용 reposi..

이번에는 멤버 서버의 SNS로 발행한 메시지를 받은 레시피 서버의 SQS리스너 동작에 대해서 설명한다. 이 글은 이전에 작성한 MSA 이벤트 정합성 보장방법 1탄에서 이어지는 내용이라 이것을 읽기 전에 꼭 아래의 글을 보고 오자 Spring Event와 AWS SNS, SQS를 활용한 MSA 데이터 정합성 보장 전략 나는 DB 정합성 보장을 위해 Spring Event를 다음과 같이 사용했다. 잠시 이전 글의 서론을 다시 가져왔다. 한번 읽어보자 내가 구성한 MSA 프로젝트에서는 멤버 서버와 또 다른 서버가 상호 작용한다 curiousjinan.tistory.com 1. 포스트 내용 요약 1-1. 이전 포스트의 내용 요약 내가 구성한 MSA 프로젝트에서는 멤버 서버와 또 다른 서버가 상호 작용한다. 만약..

SpringFramework 4.2 이후의 Spring 이벤트의 업데이트 사항을 알아보자 내가 구성한 MSA 프로젝트에서는 멤버 서버와 또 다른 서버가 상호 작용한다. 이 중, 유저가 닉네임을 변경할 때 멤버 서버의 닉네임 변경 메서드가 jpa를 통해 데이터베이스의 변경 사항을 커밋한다. 흥미로운 점은, DB 커밋 직후 비즈니스 로직을 종료하는 게 아니라 '유저 정보가 업데이트되었다'는 Spring 이벤트를 발행하고 종료한다. 그럼 이 이벤트를 구독하는 스프링 리스너가 AWS SNS에 "유저 정보가 업데이트되었다'는 메시지를 발행하도록 했다. 이러한 Spring 이벤트의 활용 방식에 대해 깊이 있게 이해하고자 Spring Framework 4.2 이후 추가된 기능들을 공식 페이지에서 직접 탐구해 보았다...