| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | 5 | 6 | 7 |
| 8 | 9 | 10 | 11 | 12 | 13 | 14 |
| 15 | 16 | 17 | 18 | 19 | 20 | 21 |
| 22 | 23 | 24 | 25 | 26 | 27 | 28 |
- DI
- JdbcTemplate
- CORS
- JPA
- JPQL
- MSA
- redis
- dockerhub
- docker
- securitycontextholderfilter
- @Transactional
- Spring
- Spring Data JPA
- 쿠버네티스
- Web
- docker compose
- 서블릿 컨테이너
- Dead Letter Queue
- 지연 로딩
- DLQ
- Spring Container
- 페이징
- mybatis
- 스프링 부트
- Routing Key
- 컨테이너
- kafka
- AWS
- @ComponentScan
- JWT
- Today
- Total
목록2026/02 (15)
look-forest
Routing 모델메시지를 Routing Key에 따라 특정 큐에 전달하는 기능.Direct Exchange와 Topic Exchange 모두에서 사용 가능.특징Direct ExchangeTopic Exchange라우팅 키 매칭 방식정확히 일치패턴 기반 (*, # 지원)특징매칭에 제한이 있음매우 유연(다양한 패턴 매칭)사용 사례단순 명확한 목적의 라우팅복잡하고 동적인 라우팅Topic 의 경우 패턴 매칭 기반 라우팅으로 binding key와 매칭되는 메시지만 수신* : 한 단어에 해당하는 모든 단어 수신# : 0개 이상의 단어 (와일드 카드)주요 특징고성능메시지를 필요한 곳에만 전달하기 때문에, 네트워크 부하 감소 효과가 있고 브로드캐스팅보다 자원 효율적 사용라우팅 키 기반의 메시지 분배각 큐는 하나 이..
Publish / Subscribe 모델Pub/Sub은 메시지 발행(Publish)과 구독(Subscribe)의 개념을 기반으로 하는 메시징 패턴(메시지 전달 모델)으로, 하나의 메시지가 복제되어 여러 “독립적인 소비자 그룹”에 각각 전달되는 모델이다.Publisher는 특정 대상이 아니라 주제(이벤트)에 메시지를 발행여러 Subscriber가 동시에 메시지를 수신 (여러 독립 구독자에게 복제 전달)Fanout Exchange와의 차이Pub/Sub = "신문을 여러 사람이 구독"Fanout = "신문을 그냥 무조건 모든 우편함에 배달"경쟁 소비자 모델과의 차이큐가 여러 개에 각각의 컨슈머 / 메시지 복제 있음, 여러 구독자가 동일 메시지 수신 → Pub/Sub큐가 하나에 컨슈머 여러개 / 메시지 복제 없..
Consumer간 작업 분배 - WorkQueue Work Queues : Competing Consumers PatternWork Queue 패턴에서는 여러 소비자가 하나의 큐에서 메시지를 가져가 경쟁적으로 처리한다.작업 부하를 효율적으로 분산하고, 병렬 처리를 가능하게 만들어 처리량을 향상시키는 효과가 있다. Round-Robin 방식(default)과 Fair Dispatch 방식을 사용하여 메시지를 Consumer 간에 분배Fair Dispatch 방식은 개발자가 코드 레벨에서 컨슈머간 분배 조정.메시지 수동 확인(Manual Acknowledgement) 모드로 설정해야함. (AMQP 기본 값 Auto)메시지 처리 비중(Prefetch Count) 설정 등을 통해 조정 가능주요 특징경쟁적인 메시..
Exchange 유형에 따른 처리 흐름1. Direct Exchange메시지를 발행할 때 사용하는 라우팅 키와 동일한 키로 익스체인지에 바인딩 된 모든 큐에 메세지를 전달.해당 라우팅 키와 일치하는 큐에만 메시지가 전달되는 방식이기 때문에 Direct Exchange 라고 한다.매핑이 정확하게 되는 한개의 키만 있으니까 1:1로 가능할거 같은데, 하나의 라우팅 키에 대해 여러 큐가 바인딩될 수 있기 때문에 1:N 매칭이 가능하다. 활용메시지가 명확하게 특정 큐로 전달되어야 할 때 큐마다 고유한 라우팅 규칙을 적용하여 메시지를 분류해야 할 때 예시 업무: 주문 상태 처리, 결제 처리, 사용자 알림 시스템 등- 주문 상태별로 라우팅 키를 정의하고, 각 상태에 해당하는 큐가 메시지를 받는다 2. Topic E..
개요RabbitMQ는 메시지 브로커이다. 애플리케이션 사이에서 메시지를 받아서 적절한 Queue로 라우팅하고 Consumer에게 전달하는 중간 서버이다. 시스템 간 비동기 메시징을 가능하게 하여 서비스 간 통신을 안정적이고 효율적으로 처리할 수 있게 해준다.최근 MSA 환경에서 가장 일반적으로 쓰이는 기술 중 하나이며, 대량의 데이터 전송 시 발생할 수 있는 과부화를 분산시키며비동기 처리와 지연이 필요한 작업을 효과적으로 관리해 줄 수 있다.클러스터를 설정할 때 큐를 HA(High Available)로 설정하여 여러 노드에 저정함으로써 메시지 손실을 방지하고, Federation 플러그인을 통해 데이터 동기화와 다중 마스터 복제를 구성할 수도 있다. 메세지큐를 사용하는 이유비동기 메시지를 사용하여 다른 ..
kafka의 고가용성(시스템이 장애 상황에서도 멈추지 않고 정상적으로 서비스를 제공할 수 있는 능력)을 확보하는 방법을 이해하려면 아래 용어들을 먼저 알고있어야 한다. 노드, 브로커, 컨트롤러, 클러스터, 레플리케이션노드(node)와 클러스터(cluster)란?Node는 서버 1대라는 의미이고, Cluster는 여러 대의 서버가 연결되어 하나의 시스템처럼 동작하는 서버들의 집합이라는 뜻으로 널리 쓰인다. kafka에서 Node는 카프카가 설치되어 있는 서버를 의미하고, 클러스터는 노드들의 묶음이다.노드(node)가 고장나게 되면 메시지를 전달하는 것 자체가 막히기 때문에, 서비스 장애가 일어나게 된다. 그래서 실무에서는 최소 3대의 노드(node)를 구성한다.3대의 노드로 클러스터를 구성하면, 3대의 노..
문제: Consumer가 메시지를 한 번에 하나씩만 처리하는 현상 API 요청을 3번 연속으로 보내면, sleep 3초를 걸어놨기 때문에 Consumer에 로그가 3초 간격으로 총 9초가 걸린다. Consumer 역할을 하는 Spring Boot는 멀티 쓰레드 기반으로 여러 개의 요청을 병렬 처리할 수 있는 구조임에도,왜 비효율적으로 요청을 하나씩 처리하고 있는 걸까?이 문제의 원인은 Kafka의 중요한 개념인 Partition과 밀접한 관련이 있다.파티션(Partition)파티션(Partition)이란?큐를 여러개로 늘려서 병렬 처리를 가능하게 하는 기본 단위메시지를 순차 처리하는 것보다 병렬 처리하는 것이 훨씬 빠르므로, 파티션은 메시지 처리량에 큰 영향을 미치는 핵심 요인이다. 파티션의 특징1. 각..
Consumer가 실제 작업에 실패했을 때 사용자에게 실패 여부를 전달할 수 없다는 단점이 있었다. 이번 시간에는 그 단점을 재시도(Retry) 방식을 활용해 해결해보자.실패한 메시지 Retry 설정목적: 일시적 오류 극복메시지 재시도 메커니즘은 일시적인 네트워크 문제나 서비스 불안정성 같은 오류를 자동으로 극복하여 메시지 처리를 완료하는 데 기여한다. 이는 시스템의 견고성과 신뢰성을 높이는 핵심적인 방법이다. 의도적으로 실패 상황을 만들기 위해 Consumer 코드에 아래 코드를 삽입하고 요청을 보내봤다.// 잘못된 이메일 주소일 경우 실패 가정if (emailSendMessage.getTo().equals("fail@naver.com")) { throw new RuntimeException("잘못된..