메시지 큐는 분산 시스템에서 컴포넌트간의 데이터를 전달하는데 주로 사용되는 통신 방법입니다. (MSA에서도 중요한 역할)
대량의 데이터를 분산 시스템에서 다룰 때 큰 시스템 개선 효과를 볼 수 있습니다.
특징
1. 비동기 메시지 전달
queue에 메시지를 넣고 수신자의 응답을 기다릴 필요 없이 다음 작업으로 넘어갈 수 있습니다.
2. 데이터 유실 방지
HTTP 직접 통신이 아닌 queue를 사용하기 때문에, 수신자쪽의 서버에 문제가 생기더라도 데이터가 유실되지 않은 채로 보관이 가능합니다.
피크시간에 발생하는 부하가 분산되기 때문에 장애에 유연하고 독립적인 설계가 가능합니다.
이 때 , 메시지 전달 속도의 차이를 조절하면 시스템의 전체적인 성능이 향상될 수 있습니다.
3. 발신자(producer)/수신자(consumer)
어떤 topic을 구독하는 모든 수신자에게 메시지를 전송할 수 있습니다.
topic을 구독하는 consumer가 메시지를 한번 consume하면 queue에서 삭제됩니다.
부하에 따라 같은 메시지큐를 listening하는 consumer를 여러개 둘 수 있습니다.
따라서 발신자와 수신자가 서로에 대한 정보 없이 데이터를 교환할 수 있습니다.
즉, 결합이 낮아 높은 확장성을 제공합니다.
패턴
1. 로드밸런싱
브로커가 consumer 중 하나를 임의로 지정해 하나의 consumer에게만 메시지를 전달하는 패턴입니다.
메시지 처리비용이 비싸 처리를 병렬화하기 위해 consumer를 추가하고 싶을 때 유용합니다.
2. 팬아웃 (fan-out)
모든 consumer에게 메시지가 전달되어, 서로 간섭 없이 동일한 메시지를 받아 처리할 수 있습니다.
사용이 필요한 경우
1. 시스템간 느슨한 결합이 필요한 경우
2. 특정 시간에 트래픽이 몰리는 경우
3. 사용할 수 있는 자원에 비해 처리해야할 데이터 양이 많은 경우
4. 다수의 어플리케이션이 어떤 데이터 저장소를 공유해야 할 경우
사례 예시
- 대규모 이벤트 처리
- 로그 수집
- 데이터 동기화
구현체
1. RabbitMQ

AMQP(Advanced Message Queue Protocol)이라는 프로토콜을 구현한 시스템입니다.
Exchange라는 라우터 역할의 컴포넌트가 있습니다. (로드 밸런싱)
여러개의 consumer와 queue가 있을 때 효율성이 높습니다.
2. kafka
pub-sub 모델의 분산 메시지 큐입니다.
대량의 메시지, 실시간 데이터 처리에 주로 사용됩니다.
설정한 보관주기만큼 디스크에 메시지를 저장합니다. (에러시 데이터 유실 없이 consumer에 다시 메시지 전달할 수 있음)
consumer가 메시지를 소비하는 순서가 중요하지 않을 때 사용됩니다.
단순 TCP 기반 프로토콜 사용으로 오버헤드가 감소할 수 있습니다.
참고
https://www.myanglog.com/message%20queue%EB%A5%BC%20%ED%99%9C%EC%9A%A9%ED%95%B4%EB%B3%B4%EC%9E%90
'백엔드 Backend > 기본 개념' 카테고리의 다른 글
RestAPI - Dto에서 @JsonInclude 사용하기 (3) | 2025.01.08 |
---|---|
Cloud Native와 MSA (0) | 2025.01.03 |
실시간 통신 기능 (1) (1) | 2024.08.14 |
캐시 / 캐시 전략 (1) | 2024.08.12 |
JWT 토큰 (0) | 2024.08.08 |
메시지 큐는 분산 시스템에서 컴포넌트간의 데이터를 전달하는데 주로 사용되는 통신 방법입니다. (MSA에서도 중요한 역할)
대량의 데이터를 분산 시스템에서 다룰 때 큰 시스템 개선 효과를 볼 수 있습니다.
특징
1. 비동기 메시지 전달
queue에 메시지를 넣고 수신자의 응답을 기다릴 필요 없이 다음 작업으로 넘어갈 수 있습니다.
2. 데이터 유실 방지
HTTP 직접 통신이 아닌 queue를 사용하기 때문에, 수신자쪽의 서버에 문제가 생기더라도 데이터가 유실되지 않은 채로 보관이 가능합니다.
피크시간에 발생하는 부하가 분산되기 때문에 장애에 유연하고 독립적인 설계가 가능합니다.
이 때 , 메시지 전달 속도의 차이를 조절하면 시스템의 전체적인 성능이 향상될 수 있습니다.
3. 발신자(producer)/수신자(consumer)
어떤 topic을 구독하는 모든 수신자에게 메시지를 전송할 수 있습니다.
topic을 구독하는 consumer가 메시지를 한번 consume하면 queue에서 삭제됩니다.
부하에 따라 같은 메시지큐를 listening하는 consumer를 여러개 둘 수 있습니다.
따라서 발신자와 수신자가 서로에 대한 정보 없이 데이터를 교환할 수 있습니다.
즉, 결합이 낮아 높은 확장성을 제공합니다.
패턴
1. 로드밸런싱
브로커가 consumer 중 하나를 임의로 지정해 하나의 consumer에게만 메시지를 전달하는 패턴입니다.
메시지 처리비용이 비싸 처리를 병렬화하기 위해 consumer를 추가하고 싶을 때 유용합니다.
2. 팬아웃 (fan-out)
모든 consumer에게 메시지가 전달되어, 서로 간섭 없이 동일한 메시지를 받아 처리할 수 있습니다.
사용이 필요한 경우
1. 시스템간 느슨한 결합이 필요한 경우
2. 특정 시간에 트래픽이 몰리는 경우
3. 사용할 수 있는 자원에 비해 처리해야할 데이터 양이 많은 경우
4. 다수의 어플리케이션이 어떤 데이터 저장소를 공유해야 할 경우
사례 예시
- 대규모 이벤트 처리
- 로그 수집
- 데이터 동기화
구현체
1. RabbitMQ

AMQP(Advanced Message Queue Protocol)이라는 프로토콜을 구현한 시스템입니다.
Exchange라는 라우터 역할의 컴포넌트가 있습니다. (로드 밸런싱)
여러개의 consumer와 queue가 있을 때 효율성이 높습니다.
2. kafka
pub-sub 모델의 분산 메시지 큐입니다.
대량의 메시지, 실시간 데이터 처리에 주로 사용됩니다.
설정한 보관주기만큼 디스크에 메시지를 저장합니다. (에러시 데이터 유실 없이 consumer에 다시 메시지 전달할 수 있음)
consumer가 메시지를 소비하는 순서가 중요하지 않을 때 사용됩니다.
단순 TCP 기반 프로토콜 사용으로 오버헤드가 감소할 수 있습니다.
참고
https://www.myanglog.com/message%20queue%EB%A5%BC%20%ED%99%9C%EC%9A%A9%ED%95%B4%EB%B3%B4%EC%9E%90
'백엔드 Backend > 기본 개념' 카테고리의 다른 글
RestAPI - Dto에서 @JsonInclude 사용하기 (3) | 2025.01.08 |
---|---|
Cloud Native와 MSA (0) | 2025.01.03 |
실시간 통신 기능 (1) (1) | 2024.08.14 |
캐시 / 캐시 전략 (1) | 2024.08.12 |
JWT 토큰 (0) | 2024.08.08 |