퍼블리시-서브스크라이브 패턴
Publish–subscribe pattern |
소프트웨어 아키텍처에서 publish-subscribe는 메시지 발신인(퍼블리셔)이 특정 수신인(사용자)에게 직접 송신하도록 메시지를 프로그래밍하지 않고 게시된 메시지를 어떤 사용자가 있는지 모르는 클래스로 분류하는 메시징 패턴입니다.마찬가지로 서브스크라이버는 1개 또는 여러 클래스에 관심을 나타내며 어떤 퍼블리셔가 존재하는지 파악하지 않고 관심 있는 메시지만 받습니다.
Publish – Subscribe는 메시지큐 패러다임의 형제로서 일반적으로 대규모 메시지 지향 미들웨어 시스템의 일부입니다.대부분의 메시징 시스템은 API에서 pub/sub 모델과 메시지 큐 모델(JMS)을 모두 지원합니다.
이 패턴에 의해 네트워크의 scalability와 동적인 네트워크토폴로지가 향상되어 퍼블리셔와 퍼블리셔 데이터의 구조를 변경할 수 있는 유연성이 저하됩니다.
메시지 필터링
퍼블리시/서브스크라이브 모델에서는 일반적으로 사용자는 퍼블리시된 총 메시지의 서브셋만 받습니다.수신 및 처리를 위한 메시지 선택 프로세스를 필터링이라고 합니다.필터링에는 주제 기반과 내용 기반이라는 두 가지 일반적인 형식이 있습니다.
토픽 기반 시스템에서는 메시지는 "토픽" 또는 명명된 논리 채널에 게시됩니다.토픽 기반 시스템의 사용자는 자신이 등록한 토픽에 게시된 모든 메시지를 수신합니다.퍼블리셔는 서브스크라이버가 구독할 수 있는 토픽을 정의합니다.
콘텐츠 기반 시스템에서 메시지는 해당 메시지의 속성 또는 내용이 사용자가 정의한 제약조건과 일치하는 경우에만 사용자에게 전달됩니다.메시지 분류는 사용자가 담당합니다.
시스템에 따라서는, 2개의 혼재를 서포트하고 있습니다.퍼블리셔는 토픽에 메시지를 투고하고, 서브 스크라이버는 1개 이상의 토픽에 컨텐츠 베이스의 구독을 등록합니다.
토폴로지
많은 퍼블리셔-서브스크라이브 시스템에서는 퍼블리셔가 메시지를 중간 메시지브로커 또는 이벤트버스에 투고하고 서브스크라이버는 그 브로커에 서브스크립션을 등록하여 브로커가 필터링을 실행할 수 있습니다.일반적으로 브로커는 스토어 앤 포워딩 기능을 실행하여 게시자에서 구독자에게 메시지를 라우팅합니다.또한 브로커는 라우팅 전에 큐 내의 메시지에 우선순위를 부여할 수 있습니다.
사용자는 빌드 시간, 초기화 시간 또는 실행 시 특정 메시지에 등록할 수 있습니다.GUI 시스템에서 사용자는 빌드 시간 등록에 대응하는 사용자 명령(버튼 클릭 등)을 처리하도록 코드화할 수 있습니다.일부 프레임워크 및 소프트웨어 제품에서는 XML 컨피규레이션파일을 사용하여 사용자를 등록합니다.이러한 컨피규레이션파일은 초기화시에 읽힙니다.가장 정교한 대체 방법은 실행 시 가입자를 추가하거나 삭제할 수 있는 경우입니다.후자의 접근방식은 데이터베이스 트리거, 메일링 리스트, RSS 등에서 사용됩니다.
DDS(Data Distribution Service) 미들웨어는 중간에 브로커를 사용하지 않습니다.대신 pub/sub 시스템의 각 퍼블리셔와 서브스크라이버는 IP 멀티캐스트를 통해 서로에 대한 메타데이터를 공유합니다.퍼블리셔와 서브스크라이버는 이 정보를 로컬로 캐시하고 공유 인식에서 서로의 검출에 따라 메시지를 라우팅합니다.실제로 브로커리스 아키텍처에서는 퍼블리셔에서 서브스크라이버로의 효율적인 분산 루팅을 가능하게 하는 오버레이 네트워크를 구축하기 위해 퍼블리셔/서브스크라이브 시스템이 필요합니다.Jon Kleinberg는 효율적인 분산형 라우팅에는 Navigable Small World 토폴로지가 필요하다는 것을 증명했습니다.이러한 Small World 토폴로지는 보통 분산형 또는 연합형 퍼블리시/[1]구독 시스템에 의해 구현됩니다.지역 대응 퍼블리시/구독 시스템은[2] 단거리 및 저비용 링크를 통해 구독을 라우팅하는 Small World 토폴로지를 구축하여 구독 전달 시간을 단축합니다.
역사
가장 먼저 공개된 pub/sub 시스템 중 하나는 1987년 ACM(Association for Computing Machine) 심포지엄 on Operating Systems Principle Conference(SOSP '87)에서 설명한 Isis Toolkit의 "뉴스" 서브시스템이었습니다.123–180"[3] 입니다.
이점
느슨한 커플링
출판사들은 구독자들과 느슨하게 연결되어 있고, 그들의 존재를 알 필요도 없다.토픽을 중심으로 퍼블리셔와 서브스크라이버는 시스템토폴로지에 대해 모르는 채로 있을 수 있습니다.각 시스템은 서로 독립적으로 정상 작동 상태로 계속 작동할 수 있습니다.기존의 긴밀하게 결합된 클라이언트와 서버 패러다임에서는 서버 프로세스가 실행되지 않는 동안에는 클라이언트는 서버에 메시지를 게시할 수 없으며 클라이언트가 실행되지 않는 한 서버는 메시지를 수신할 수 없습니다.많은 펍/서브 시스템은 출판사와 구독자의 위치를 분리할 뿐만 아니라 일시적으로 분리할 수도 있습니다.이러한 pub/sub 시스템에서 미들웨어 분석가가 사용하는 일반적인 전략은 퍼블리셔를 다운하여 서브스크라이버가 백로그(대역폭 조절의 일종)에서 작업할 수 있도록 하는 것입니다.
확장성
Pub/sub는 병렬 운영, 메시지 캐싱, 트리 기반 또는 네트워크 기반 라우팅 등을 통해 기존 클라이언트 서버보다 뛰어난 확장성을 제공합니다.단, 긴밀하게 결합된 대규모 기업 환경에서는 시스템이 확장되어 수천 대의 서버가 펍/서브 인프라스트럭처를 공유하는 데이터 센터가 되면서 현재의 벤더 시스템은 이러한 이점을 상실하는 경우가 많습니다.이러한 상황에서 펍/서브 제품의 확장성은 연구 과제입니다.
한편, 기업 환경 이외에서는 Pub/sub 패러다임은 RSS나 Atom 등의 웹 신디케이션 프로토콜을 통해 인터넷 전체에 분산된 메시징을 제공함으로써 단일 데이터 센터의 볼륨을 훨씬 능가하는 확장성을 입증하고 있습니다.이러한 신디케이션 프로토콜은 로우엔드 웹 서버라도 수백만 개의 개별 서브스크라이버 노드에 메시지를 신디케이션할 수 있는 기능을 제공하는 대신 지연 시간이 길어지고 전달 보증이 부족합니다.
단점들
펍/서브 시스템의 가장 심각한 문제는 퍼블리셔와 서브스크라이버의 분리라는 주요 이점의 부작용입니다.
메시지 배달 문제
펍/서브 시스템은 확실한 배송 등 특정 애플리케이션에서 필요로 하는 보다 강력한 시스템 속성을 제공할 수 있도록 신중하게 설계되어야 합니다.
- pub/sub 시스템의 브로커는 지정된 시간 동안 메시지를 전달하도록 설계되어 있지만 모든 사용자가 메시지를 정상적으로 수신했는지 여부에 관계없이 전달 시도를 중지할 수 있습니다.이와 같이 설계된 pub/sub 시스템은 이러한 확실한 전달을 필요로 하는 애플리케이션에 대한 메시지 전달을 보장할 수 없습니다.이러한 확실한 전달을 실현하기 위해서(예를 들면, 서브 스크라이버에게 수신 확인 메시지를 발행하도록 요구함으로써) 그러한 퍼블리셔와 서브스크라이버 쌍의 설계의 보다 긴밀한 결합을 pub/sub 아키텍처 밖에서 실시할 필요가 있습니다.
- pub/sub 시스템의 퍼블리셔는, 실제로는 수신하고 있지 않은 서브 스크라이버가 수신하고 있다고 가정할 수 있습니다.공장에서는 기기가 이러한 문제를 표시하고 기록하는 가입자에게 문제 또는 장애를 퍼블리시할 수 있는 펍/서브 시스템을 사용하는 경우가 있습니다.로거에 장애가 발생했을 경우(크래시), 기기 문제의 퍼블리셔는 반드시 로거 장애 통지를 수신할 필요는 없습니다.또, 에러 메세지는 Pub/sub 시스템의 어느 기기에서도 표시 또는 기록되지 않습니다.이는 클라이언트/서버 시스템 등 대체 메시징 아키텍처의 설계 과제이기도 합니다.클라이언트/서버 시스템에서는, 에러 로거에 장해가 발생하면, 에러 로거(서버)의 장해가 통지됩니다.단, 클라이언트/서버 시스템은 다중 로깅 서버를 온라인으로 하거나 폴백로깅 서버를 동적으로 생성하여 이 장애에 대처해야 합니다.이로 인해 클라이언트 및 서버 설계 및 클라이언트/서버 아키텍처 전체에 복잡성이 가중됩니다.단, pub/sub 시스템에서는 기존 로거와 완전히 중복된 다중 로깅 가입자를 시스템에 추가하여 시스템상의 다른 기기에 영향을 주지 않고 로깅 신뢰성을 높일 수 있습니다.펍/서브 시스템에서는 기기 문제 메시지 로깅의 기본 기능을 구현한 후 보증 오류 메시지 로깅 기능을 점진적으로 추가할 수 있다.
pub/sub 패턴은 퍼블리셔 및 서브스크라이버노드의 수가 적고 메시지볼륨이 적은 소규모 네트워크에 적합합니다.그러나 노드 및 메시지의 수가 증가함에 따라 불안정성이 증가할 가능성이 높아져 Pub/sub 네트워크의 최대 확장성이 제한됩니다.대규모 스루풋의 불안정성의 예는 다음과 같습니다.
- 부하 서지: 가입자가 네트워크 throughput을 포화시킨 후 메시지볼륨이 낮은 기간(사용률이 낮은 네트워크 대역폭)을 요구하는 기간
- 속도 저하: 시스템을 사용하는 응용 프로그램이 증가함에 따라(다른 pub/sub 채널에서 통신하는 경우에도) 개개의 사용자에 대한 메시지 볼륨플로우가 느려집니다.
브로커(서버)를 사용하는 pub/sub 시스템의 경우 브로커가 사용자에게 메시지를 보내는 인수는 대역 내이며 보안 문제가 발생할 수 있습니다.브로커가 속아 잘못된 클라이언트에 알림을 보내 클라이언트에 대한 서비스 거부 요구를 증폭시킬 수 있습니다.생성된 구독을 추적하기 위해 리소스를 할당할 때 브로커 자체에 과부하가 걸릴 수 있습니다.
브로커에 의존하지 않는 시스템에서도 가입자는 수신이 허가되지 않은 데이터를 수신할 수 있습니다.승인되지 않은 게시자가 Pub/sub 시스템에 잘못되거나 손상된 메시지를 삽입할 수 있습니다.이는 메시지를 브로드캐스트 또는 멀티캐스트하는 시스템에서 특히 그렇습니다.암호화(예를 들어 Transport Layer Security(SSL/TLS))는 무단 액세스를 방지할 수 있지만 인증된 게시자에 의해 손상된 메시지가 유입되는 것을 방지할 수 없습니다.클라이언트/서버 시스템 등 pub/sub 이외의 아키텍처도 악의적으로 동작하는 인증된 메시지 발송인에게 취약합니다.
「 」를 참조해 주세요.
- 확장성이 뛰어난 또 다른 웹 동기 프로토콜인 Atom
- 데이터 전달 서비스(DDS)
- 이벤트 주도형 프로그래밍
- 고급 아키텍처
- IGMP(Internet Group Management Protocol
- 메시지 브로커
- 메시지 큐
- 옵서버 패턴
- 생산자-소비자
- 푸시 테크놀로지[1]
- 확장성이 뛰어난 웹 동기 프로토콜인 RSS
- 유저넷
- WebSub, 펍/서브 구현
레퍼런스
- ^ a b Chen, Chen; Tock, Yoav; Girdzijauskas, Sarunas (2018). "BeaConvey: Co-Design of Overlay and Routing for Topic-based Publish/Subscribe on Small-World Networks". Proceedings of the 12th ACM International Conference on Distributed and Event-based Systems - DEBS '18. Hamilton, New Zealand: ACM Press: 64–75. doi:10.1145/3210284.3210287. ISBN 9781450357821. S2CID 43929719.
- ^ Rahimian, Fatemeh; Le Nguyen Huu, Thinh; Girdzijauskas, Sarunas (2012), Göschka, Karl Michael; Haridi, Seif (eds.), "Locality-Awareness in a Peer-to-Peer Publish/Subscribe Network", Distributed Applications and Interoperable Systems, Springer Berlin Heidelberg, vol. 7272, pp. 45–58, doi:10.1007/978-3-642-30823-9_4, ISBN 9783642308222
- ^ Birman, K.; Joseph, T. (1987). "Exploiting virtual synchrony in distributed systems". Proceedings of the Eleventh ACM Symposium on Operating Systems Principles - SOSP '87. pp. 123–138. doi:10.1145/41457.37515. ISBN 089791242X. S2CID 7739589.
