Notice
Recent Posts
Recent Comments
Link
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 | 29 | 30 |
Tags
- Out of Memory
- 디비아엔씨
- charcter set
- 내부 jar 파일 참조
- Rag
- 실손보험 청구 전산화
- 실손24
- Python
- Tableau
- message sender
- batch job
- db inc.
- app$innerclass.class
- apk 컴파일
- GA4
- jar manifest
- publish subscribe style
- dbms 변경
- jar 패키징
- 주가정보발송
- log insert shell
- 주식데이터수집
- JMeter
- memory analyzer tool
- 말로코딩
- delivery혁신팀
- OOM
- java oom
- 외부 jar 파일 참조
- mariadb
Archives
- Today
- Total
IT 트랜드 공유
[아키텍처] Publish Subscribe Style 본문
728x90
반응형
SMALL
1. 개요
Summary | 송신자와 수신자를 연결하지 않고도 여러 관심 소비자에게 비동기적으로 이벤트를 알릴 수 있다. |
Context | 클라우드 기반 및 분산형 애플리케이션에서 시스템 구성 요소는 이벤트가 발생할 때 다른 구성 요소에 정보를 제공해야 하는 경우가 많습니다. |
Problem |
비동기 메시징은 발신자와 소비자를 분리하고 발신자가 응답을 기다리지 못하도록 차단하는 효과적인 방법입니다. 그러나 각 소비자에 대한 전용 메시지 큐를 사용하면 많은 소비자에게 효과적으로 확장되지 않습니다. 또한 일부 소비자는 정보의 하위 집합에만 관심이 있을 수 있습니다. 발신자는 신원을 알지 못한 채 모든 관심 있는 소비자에게 이벤트를 어떻게 알릴 수 있을까요? |
Solution | 발신자가 사용하는 입력 메시징 채널. 발신자는 알려진 메시지 형식을 사용하여 이벤트를 메시지로 패키징하고 입력 채널을 통해 이러한 메시지를 전송합니다. 이 패턴의 발신자는 게시자라고도 합니다 . 소비자당 하나의 출력 메시징 채널. 소비자는 구독자 라고 합니다 . 해당 메시지에 관심이 있는 모든 구독자를 위해 입력 채널에서 출력 채널로 각 메시지를 복사하는 메커니즘입니다. 이 작업은 일반적으로 메시지 브로커나 이벤트 버스와 같은 중개자가 처리합니다. |
2. 필요성
- 확장 가능하며 유지 관리 가능한 소프트웨어 시스템을 구축하는 데 필수적입니다.
- 결합, 확장성 및 유연성과 같은 시스템 설계의 주요 과제를 해결하여 이벤트 중심 아키텍처, 분산 시스템 및 실시간 애플리케이션의 기본 패턴이 됩니다.
- Pub/Sub를 채택함으로써 개발자는 더 쉽게 확장하고, 더 탄력적이며, 현대 소프트웨어 환경의 복잡성을 처리하는 데 더 적합한 시스템을 만들 수 있습니다.
3. 사용사례
- RSS(Rich Site Summary)
- YouTube
- Kafka(오픈 소스 메세지 브로커)
- 다수의 소비자에게 정보를 방송해야 하는 경우
- 서로 다른 플랫폼, 프로그래밍 언어, 통신 프로토콜을 사용할 수 있는 하나 이상의 독립적으로 개발된 애플리케이션이나 서비스와 통신하는 경우
- 소비자에게 실시간 응답을 요구하지 않고도 소비자에게 정보를 보내는 경우
4. 적용의 장단점
장점 | 디커플링: Pub-Sub는 메시지 생성자와 소비자를 분리하여 각 구성 요소를 독립적으로 발전시킬 수 있습니다. 확장성: 기존 시스템을 변경하지 않고도 새로운 게시자와 구독자를 쉽게 추가할 수 있어 확장성을 지원합니다. 비동기 통신: Pub-Sub는 비동기 메시징을 지원합니다. 즉, 게시자와 구독자가 실시간으로 상호 작용할 필요가 없어 시스템 복원력과 성능이 향상됩니다. 유연성: 이 패턴은 구독자가 런타임에 주제를 구독하거나 구독 취소할 수 있는 동적 구독을 지원하여 통신 흐름 관리에 더 큰 유연성을 제공합니다. |
단점 | 복잡성: Pub-Sub 시스템을 구현하면 특히 브로커를 관리하고 메시지 전달을 보장할 때(예: 정확히 1회 전달) 더욱 복잡해질 수 있음 메시지 오버헤드: 메시지 양이 많은 시스템에서 주제를 통해 메시지를 관리하고 라우팅하면 성능 및 리소스 활용 측면에서 오버헤드가 발생할 수 있음 디버깅 난이도: 구성 요소를 분리하면 시스템 전체에서 메시지 흐름을 추적하기가 더 어려워질 수 있으므로 디버깅이 더 어려워질 수 있음 |
5. 기타
- 보안: Pub-Sub 시스템에서 인증, 승인, 암호화와 같은 보안 조치를 구현하는 것은 매우 중요합니다. 분리 및 간접 통신으로 인해 취약점이 발생할 수 있기 때문입니다.
- 지속성: 일부 Pub-Sub 시스템은 메시지 지속성을 지원합니다. 즉, 구독자가 일시적으로 오프라인 상태인 경우에도 메시지가 저장되고 구독자에게 전달됩니다. 이는 분산 시스템에서 안정적인 통신을 보장하는 데 중요할 수 있습니다.
- QoS(서비스 품질): 다양한 Pub-Sub 시스템은 최대 1회, 최소 1회 또는 정확히 1회 전송과 같은 다양한 수준의 QoS를 제공합니다. QoS 선택은 애플리케이션 요구 사항에 따라 다릅니다.
[참고 사이트]
https://learn.microsoft.com/en-us/azure/architecture/patterns/publisher-subscriber
728x90
반응형
LIST
'아키텍처' 카테고리의 다른 글
[Clustering] Weblogic OHS 클러스터링 (0) | 2024.08.16 |
---|