HAN STORY

[싹틔움] 알림 서버측 에러로 인한 Kafka Message 소비 실패 시나리오 대비 안전 장치 고민 - DLQ ( Dead Letter Queue )

💡 개요이전 글: [싹틔움] 에러로 인한 Kafka Message 전송 실패 시나리오 대비 안전 장치 고민💡 개요 아웃박스 패턴 구현 고민1 : 아웃박스 패턴을 적용하면 Kafka 메세지 전송 전에 무조건 DB 로 부터 조회를 해서 불러오다보니 리소스가 낭비되지 않을까?고민1 해결: 아웃박스 패턴 변형hanstory33.tistory.com 메인서버에서 Kafka 를 전송 시에 생기는 에러는 Redis 와 Outbox 패턴을 변형해 대비를 해놓았다.추가로 Kafka Message 는 전송이 되었지만 Consumer 인 알림서버에서 이 Message 를 소비하지 못 했을 때의 시나리오를 대비해 안전 장치가 필요하다고 판단했고, 이를 DLQ 와 수동 재처리 API 를 통해 해결하고자 했다. 💡 DLQ ..

💡 개요 아웃박스 패턴 구현 고민1 : 아웃박스 패턴을 적용하면 Kafka 메세지 전송 전에 무조건 DB 로 부터 조회를 해서 불러오다보니 리소스가 낭비되지 않을까?고민1 해결: 아웃박스 패턴 변형 구조 구현 고민2 : 재전송을 시도해도 계속해서 Sent 값이 False 인 경우는 어떻게 처리하면 좋을까?고민2 해결: Redis 도입을 통해 각 데이터별 Count 및 Webhook 연결을 통한 운영 처리 고민3 : DLQ Topic 도입을 하는 것이 좋을까?이전 글: [싹틔움] API Gateway 도입을 통한 인증 역할 분담💡 개요이전 글https://hanstory33.tistory.com/318 [싹틔움] 04/07 개발일지 FeignClient 도입으로 분산 서버에서의 인증 문제 해결💡 개요..

💡 개요이전 글 [싹틔움] 04/07 개발일지 FeignClient 도입으로 분산 서버에서의 인증 문제 해결💡 개요메인서버와 알림서버가 분리된 현 구조의 알림서버는 누구나 다른 사람의 알림을 확인할 수 있다는 치명적인 오류가 있었다. 이를 해결하기 위한 고민을 담았다. 💡 문제 분석 @GetMappinhanstory33.tistory.com 기존 클라이언트에서 알림서버에 구독을 요청하고, Feign Client 를 이용해서 메인서버로 회원 정보를 가져올 때 매 번 요청마다 인증을 하기 위해서 메인서버에 요청을 하는 방식이 오버헤드가 발생하는 부분이라고 판단했다.메인서버와 알림서버 상단에 API Gateway 를 두어서 인증을 담당하는 서버를 따로 분리하도록 설정하고자 했다. 💡 아키텍처 수정🌱 ..

💡 개요메인서버와 알림서버가 분리된 현 구조의 알림서버는 누구나 다른 사람의 알림을 확인할 수 있다는 치명적인 오류가 있었다. 이를 해결하기 위한 고민을 담았다. 💡 문제 분석 @GetMapping(value = "/v1/notifications/{userId}/subscribe", produces = MediaType.TEXT_EVENT_STREAM_VALUE) public SseEmitter subscribe(@PathVariable Long userId) { SseEmitter emitter = notificationService.subscribe(userId); 기존 방식에서는 단순히 userId 값을 param 으로 받아서 구독하고 해당 userId 로 들어오는 알림 ..

✔️ Feign Client 란?Feign Client 는 HTTP 요청을 인터페이스만으로 처리를 할 수 있게 도와주는 클라이언트이다.Spring Cloud 에서 제공하는 @FeignClient 어노테이션을 이용해서 메서드 호출처럼 외부 API 나 다른 마이크로서비스를 쉽게 호출할 수 있게 한다. ✔️ 넷플릭스는 왜 Feign Client 를 만들었을까?넷플릭스는 전 세계 수억 명에게 서비스를 제공하면서, 초대형 마이크로서비스 아키텍처로 전환했다.서비스 간의 수많은 HTTP 통신을 안정적이고 효율적으로 처리해야 했고, 이 과정에서 문제들을 겪는다.  HTTP 요청 코드가 너무 많고 반복적이다.실패 처리(fallback)나 로드밸런싱을 일일이 다 구현해야 한다.코드가 복잡해서 유지보수가 힘들다.그래서 간결..

💡 목표싹틔움 서버에 Kafka 를 도입해 메인서버와 알림서버 사이에서 데이터들이 성공적으로 주고 받을 수 있고자 했다.📚 메인서버 Kafka 설정KafkaConfig더보기@Configuration@EnableKafkapublic class KafkaConfig { @Value("${app.kafka-brokers}") private String kafkaBrokers; @Bean public KafkaTemplate kafkaTemplate() { return new KafkaTemplate(producerFactory()); } @Bean public ProducerFactory producerFactory() { Map produce..

📚 RabbitMQ특징프로토콜: AMQP (표준 메시징 프로토콜 지원)메시지 전달: Push 모델 기반. 브로커가 소비자에게 메시지를 적극적으로 전달.큐 중심 설계: 메시지가 큐에 저장되고, 소비자가 이를 처리하는 전통적인 방식. 메시지 삭제는 소비자가 처리 후 ACK(확인 응답)를 보내면 이루어짐.라우팅: Exchange를 통해 Direct, Topic, Fanout, Headers 방식으로 유연하게 메시지 라우팅 가능.구성: 단일 노드에서 동작 가능하며, 클러스터링 지원은 있지만 Kafka만큼 분산 시스템에 특화되지 않음. 메시지 보장: 메시지 확인 및 재전송 메커니즘으로 높은 신뢰성 제공한다.사용 사례작업 큐 관리: 예를 들어, 사용자 등록 후 환영 이메일 전송, 이미지 변환 작업 등 비동기 작업..

🌱 개요싹틔움 메인서버에서 알림 기능을 구현하는 서버를 따로 분리해 MSA 방식으로 구현하고자 했다. 🌱 왜 굳이 서버를 분리할까?1. 독립적인 확장성알림 기능은 사용량이 급격하게 늘어날 수 있는 부분이다. 그렇기 때문에 MSA 로 분리하면 알림 서버만 별도로 스케일 업/아웃할 수 있어 유연성이 증가한다. 2. 장애 격리알림기능에 트래픽이 몰리거나, 카카오 등 외부 API 알림 기능을 구현할 때 이 기능에서 문제가 생겨도 메인 서버에 영향을 주지 않아 안정성이 증가한다. 3. 독립적인 배포 및 개발알림 서버는 다른 주기로 배포하거나, 다른 언어나 프레임 워크로 개발이 가능해진다.  4. 유지보수 용이성관심사가 명확하게 분리되어 집중적으로 관리할 수 있고 다른 팀원들과 협업시에도 수월하다. 코드베이스가..