전체 글 (43) 썸네일형 리스트형 RabbitMQ에 대해 알아보자 - (10) Header 기반 라우팅 / Headers Exchange 전략 들어가기 앞서RabbitMQ의 Headers Exchange는 기존의 Fanout, Direct, Topic과는 다르게 라우팅 키가 아닌 메시지의 헤더 값을 기준으로 큐로 라우팅하는 방식입니다.메시지 자체의 메타데이터(header)를 활용하므로, 보다 정교하고 유연한 조건 기반 라우팅이 가능하다는 장점이 있습니다.복잡한 조건 매칭이나 다중 속성을 고려한 분기 로직이 필요한 경우 유용하게 사용할 수 있습니다. 동작 : 메시지의 헤더(key-value)에 따라 큐에 라우팅Exchange : Headers Exchange사용 예제 : 국가별 정책 분기, 사용자 속성 기반 라우팅, A/B 테스트 등Headers 모델 / 전략 설명Headers Exchange는 바인딩할 때 라우팅 키가 아닌 헤더 조건을 명시하며.. RabbitMQ에 대해 알아보자 - (9) Topic 패턴 / Topic Exchange 전략 들어가기 앞서RabbitMQ에서 Topic 패턴은 보다 유연한 메시지 라우팅이 필요할 때 사용하는 전략입니다. Direct Exchange가 단일 라우팅 키로 메시지를 분기하는 방식이라면, Topic Exchange는 패턴 매칭을 통해 동적으로 메시지를 다양한 큐에 분배할 수 있는 것이 특징입니다. 복잡한 메시지 분기 구조가 필요한 서비스(예: 마이크로서비스 간 이벤트 전파, 로그 분류, 사용자 그룹별 알림 시스템 등)에 적합하게 사용됩니다. 동작 : 라우팅 키 패턴을 이용해 다수 큐로 메시지 분기Exchange : Topic Exchange사용 예제 : 로그 수집 (info.log, error.db 등), 마이크로서비스 이벤트 분배, 역할/지역 기반 라우팅 등Topic 모델 / Topic Exchang.. RabbitMQ에 대해 알아보자 - (8) Routing 패턴 / Direct Exchange 전략 들어가기 앞서RabbitMQ의 Routing 패턴은 하나의 메시지를 특정 큐에만 전달하고 싶을 때 사용하는 메시징 방식입니다.Fanout Exchange와 달리, 라우팅 키를 기반으로 Exchange와 큐 간의 연결을 제어할 수 있다는 점이 특징입니다. 일반적으로는 Direct Exchange를 활용하며, 알림 시스템에서 사용자 역할별로 메시지를 분기하거나, 로그 레벨에 따라 로그 메시지를 구분하는 용도로 자주 사용됩니다.동작 : 라우팅 키에 따라 지정된 큐로만 메시지를 전달Exchange : Direct Exchange사용 예제 : 사용자 역할 기반 알림, 로그 레벨 필터링, 주문 상태별 이벤트 처리Routing 모델 / Direct Exchange 전략Routing 패턴은 메시지를 발행할 때 라우팅 .. RabbitMQ에 대해 알아보자 - (7) Pub-Sub 패턴 / Fanout Exchange 전략 들어가기 앞서RabbitMQ의 Publish-Subscribe 패턴은 하나의 메시지를 여러 소비자에게 동시에 전달해야 할 때 사용하는 대표적인 메시징 방식이다.보통 Fanout Exchange 전략을 활용해 구현하며, 로그 수집, 이벤트 브로드캐스트, 시스템 알림 등에서 자주 사용된다.동작 : 하나의 메시지를 여러 소비자에게 동시에 전달Exchange : Fanout Exchange사용 예제 : 로그 수집, 이벤트 브로드캐스트, 시스템 알림 등Pub-Sub 모델 / Fanout Exchange 전략Pub/Sub는 Producer가 메시지를 발행하고, Subscriber가 해당 메시지를 구독하는 방식의 메시징 패턴 입니다. RabbitMQ에서는 Fanout Exchange를 활용하여, 발행된 메시지를 연결.. RabbitMQ에 대해 알아보자 - (6) Exchange 전략 들어가기 앞서이번 포스팅에서는 RabbitMQ의 Exchange 전략들에 대해서 알아볼 예정입니다. 이전 포스팅과 설명드린 것과 같이, exchange와 work queue의 개념은 다음과 같습니다. 이전 포스팅에서는 work queue에 대한 개념을 공부했고, 이번 포스팅에서는 exchange에 대한 개념을 공부할 예정입니다.exchange : 프로듀서에게 메시지를 받아 어떤 큐로 보낼지 결정 (프로듀서 → 큐)work queue : 큐에 있는 메시지를 어떤 컨슈머에게 보낼지 결정 (큐 → 컨슈머) https://www.rabbitmq.com/tutorials공식 문서에 각 전략에 대한 예제 가이드가 있으니, 함께 참고해 주시면 감사하겠습니다.Exchange란?Exchange는 프로듀서(Produce.. RabbitMQ에 대해 알아보자 - (5) Work Queue를 통한 분산처리 들어가기 앞서오늘은 RabbitMQ의 Work Queue에 대해서 알아볼 예정입니다. 추후 exchange에 대해 공부할 예정인데, 저는 exchange와 work queue가 같은 개념의 용어로, exchange모델 중 하나가 work queue인줄 알았습니다. exchange : 프로듀서에게 메시지를 받아 어떤 큐로 보낼지 결정 (프로듀서 → 큐)work queue : 큐에 있는 메시지를 어떤 컨슈머에게 보낼지 결정 (큐 → 컨슈머) 먼저 두 개념에 대해 한번 설명하고 가면 좋을것 같아, 간단하게 설명드리게 되었습니다.Work Queue작업큐(Work Queue)는 여러개의 메시지를 큐에 쌓아두고, 이를 여러 개의 컨슈머가 분산 처리하는 구조를 의미합니다.작업큐를 통해 작업 부하를 효율적으로 분산.. RabbitMQ에 대해 알아보자 - (4) 메시지 실패 처리 DLQ, DLX, PLQ 들어가기 앞서이전 포스팅에서 간단하게 언급하기는 하였지만, 메시징 시스템을 구성함에 있어 중요한 부분은 컨슈머가 메시지를 처리에 실패 했을 경우 어떻게 처리할 것인지에 대한 방안을 마련하는게 중요하다고 생각합니다. 그래서 오늘은 DLQ, DLX, PLQ에대해 알아볼 예정입니다. DLX (Dead Letter Exchange) : 죽은 메시지(dead letter)를 받는 특수한 ExchangeDLQ (Dead Letter Queue) : DLX를 통해 전달된 실패 메시지를 저장하는 큐PLQ (Parking Lot Queue) : DLQ에서 재처리를 시도했지만 계속 실패한 메시지를 별도로 보관하는 큐 DLX (Dead Letter Exchange)DLX는 실패한 메시지를 받는 특수한 Exchage 입니다... RabbitMQ에 대해 알아보자 - (3) 메시지 처리에 실패하게 된다면? 들어가기 앞서RabbitMQ를 구성해 보고 그 과정에 대해 느낀 부분을 작성하려고 합니다. RabbitMQ 뿐만 아니라 Kafka와 같이 비동기 메시지 시스템의 가장 중요한 부분은 오류나 장애를 어떻게 처리할 것인지가 중요한 부분이라고 생각합니다. 이러한 부분을 중점으로 RabbitMQ에 대해 알아 보려 합니다. 혹시 DLQ, DLX, PLQ에 대한 내용을 보기 위해 들어 오신 분들은 아래 링크를 추천드립니다.RabbitMQ에 대해 알아보자 - (4) 메시지 실패 처리 DLQ, DLX, PLQ 자세한 코드는 제 깃허브 링크에서 확인해 주시면 감사하겠습니다.ACK (Acknowledgment) RabbitMQ에서 ACK(Acknowledgment)는 메시지를 소비자(Consumer)가 정상적으로 처리했음을.. RabbitMQ에 대해 알아보자 - (2) RabbitMQ vs Kafka 들어가기 앞서RabbitMQ와 Kafka의 차이에 대해 알아 보려고 합니다. 저는 현업에서 Kafka만 사용해 보아서, 두개의 차이에 대해 정확히 알지 못 합니다. 이번 글에서는 RabbitMQ 위주로 간단하게 정리하고, 차근차근 Kafka까지 깊게 공부해 가며, 두 기술의 차이에 대해 알아볼 예정입니다. Kafka vs RabbitMQ: 메시지 브로커의 두 축, 언제 어떤 선택을 할 것인가?1. 개요 및 철학적 차이항목KafkaRabbitMQ설계 철학분산 로그 기반의 고성능 스트리밍 플랫폼클래식 메시지 브로커 + AMQP 기반 라우팅용도데이터 스트리밍, 이벤트 소싱, 로그 저장 등작업 큐, 이벤트 전달, 비동기 메시징 등메시지 흐름Append-only log 저장, 컨슈머는 offset 기반으로 읽음메.. RabbitMQ에 대해 알아보자 - (1) 간단한 이해 들어가기 앞서최근 백엔드 개발자에게 비동기 메세지 시스템은 필수적인 기술 스택이라고 생각합니다. Kafka, RabbitMQ 등 이미 많이들 사용하고 계시거나 들어보셨을 텐데, 저는 실무에서 Kafka를 사용해 보았지만, 이미 인프라가 잘 구축되어 있어, 제가 주도적으로 구축하거나 깊이 이해하고 있지 못하고 있습니다. 그래서 앞으로 비동기 메세지 시스템에 대해 공부할 예정이며, 오늘은 RabbitMQ에 대해서 공부해 볼 예정입니다. 이번 포스팅에서는 대략적으로 RabbitMQ가 무엇인지 간단하게 개념을 알아볼 예정이며, 자세한 내용은 다른 포스팅들을 함께 참고해 주시면 감사하겠습니다. RabbitMQ에 대해 알아보자 - (2) RabbitMQ vs KafkaRabbitMQ에 대해 알아보자 - (3) 메.. DBCP (Database Connection Pool) 들어가기 앞서 오늘은 DB의 connection pool에 대해 공부해 볼 예정입니다. 아래 영상 함께 참고해 주시면 감사하겠습니다. https://www.youtube.com/watch?v=zowzVqx3MQ4&t=661sDB Connection Pool 란?일반적으로 서버에서 데이터베이스에 요청을 하게 되면, Connection을 맺게 됩니다. 이러한 Connection을 맺는 과정에서 서버와 데이터베이스는 TCP 통신을 기반으로 네트워크 통신을 하게 됩니다. (TCP 통신은 높은 신뢰성으로 송수신이 가능!) 하지만 connection을 맺는 과정은 생각보다 오래 걸립니다. connection 생성을 위해서는 3-way handshake, connection 제거를 위해서는 4-way handsha.. 데이터베이스 락 (Lock) with MySQL 들어가기 앞서https://www.youtube.com/watch?v=EBBS_giQ4AM 오늘은 데이터베이스 락에 대해 알아볼 예정입니다. 데이터베이스 락은 동시성 이슈가 발생할때 보통 사용이 됩니다. 하지만 성능 저하가 심하기 때문에 사용시 많은 주의가 필요하고, 대체할 수 있는 방안이 있기에 잘 사용하지 않는데요. 그래도 데이터베이스 락은 가장 기본적인 개념이기 때문에 중요하다고 생각합니다. 또한 일반적으로 락을 개인적으로 설정하지 않아도 데이터베이스에서 default로 락이 설정되는 경우도 있어, 동작원리를 이해하고 있는 것이 중요하다고 생각합니다. 데이터베이스 락(lock)데이터베이스 락(lock)은 여러 트랜잭션이 동시에 같은 데이터에 접근할 때, 데이터의 정합성과 일관성을 보장하기 위해 사.. 스프링 Transaction 전파 속성 들어가기 앞서트랜잭션이 중첩이 중첩으로 선언이 되면 어떻게 처리가 될까요? 이번 글에서는 Transaction 전파 속성에 대해서 알아 볼 예정입니다. 개발을 하다보면 @transactional 안에 또 @transactional을 선언 하는 경우가 많이 있습니다. 이런 경우 트랜잭션의 전파 속성에 따라 동작이 달라지게 됩니다. 트랜잭션 전파 속성이란, 트랜잭션이 진행중일 때 추가 트랜잭션 진행을 어떻게 할지 결정하는 것입니다. 트랜잭션 전파 속성에 대해 잘 모르고 계셨던 분이시라면, 한 번 이 글을 읽어봐 주세요~! https://www.youtube.com/watch?v=b0s9RzKyHN0 물리 트랜잭션과 논리 트랜잭션Spring 트랜잭션에서 물리적 트랜잭션(Physical Transaction.. 네이버의 Fixture Monkey 사용기 들어가기 앞서이번 글에서는 네이버의 Fixture Monkey 라이브러리에 대해 설명 드릴 예정입니다. Fixture Monkey는 테스트 코드 작성시 fixture 생성을 편리하게 해주는 라이브러리 입니다. Java와 Kotlin을 사용하는 개발자 분들이시라면 꼭 추천 드리며, 블로그 글 읽기가 귀찮으신 분들은 Naver D2 영상이나 공식 페이지 참조 부탁드립니다 :) https://naver.me/FFGei9Tm NAVER D2테스트 객체는 엣지 케이스까지 찾아주는 Fixture Monkey에게 맡기세요bridge-now.naver.com https://naver.github.io/fixture-monkey/v1-1-0-kor/docs/introduction/overview/ 개요Fixture Mo.. 의미 있는 테스트 코드에 대해 알아보자 들어가기 앞서오늘은 단위 테스트에 대해 공부하려고 합니다. 이전에 회사를 다닐때 단위 테스트는 조금 논란의 대상이였습니다.찬성 : 단위 테스트를 통해 사이드 이펙트를 사전에 검증할 수 있고, 서비스를 안정적으로 운영하는데 도움이 돼. 특히 다른 사람의 코드를 건드릴때 단위 테스트만 있어도 큰 도움이 돼.반대 : 일정이 바쁜데 단위 테스트 작성할 시간이 어디 있어. 그리고 코드 커버리지 채우기 위한 비효율적인 작업만 하잖아. 그냥 대충해실제로 이전 회사에서 단위 테스트를 정말 의미 있게 사용하는 팀은 크게 없었습니다. 또한 다들 회의적인 반응이 항상 있었습니다. 그러면 지금 까지 글을 읽고, 너가 다녔던 회사가 기술적으로 좋지 않은 회사를 다녀서 그랬던거 아니야? 라고 하실수 있지만, 그 당시 네카라쿠배 .. 이전 1 2 3 다음
