Pub/Sub(Publish/Subscribe) 메시징, 백엔드 시스템의 핵심 패턴을 파헤치다!
직접 호출(Direct Calls) 방식의 문제점을 지적하며, Pub/Sub(Publish/Subscribe) 아키텍처의 필요성을 강조함
토픽(Topic)을 중심으로 발행자(Publisher)와 구독자(Subscriber)를 분리하여 시스템의 유연성을 확보함
At-least-once 및 At-most-once 배달 보장(Delivery Guarantee) 방식을 비교하며, DLQ(Dead Letter Queue)의 중요성을 설명함
AWS SNS+SQS, Google Cloud Pub/Sub, Azure Service Bus 등 주요 클라우드 서비스의 Pub/Sub 구현 방식을 소개함
직접 호출 방식의 문제점과 Pub/Sub(Publish/Subscribe)의 대안
게시물에서는 직접 호출(Direct Calls) 방식의 단점을 지적하며, Pub/Sub(Publish/Subscribe) 아키텍처의 필요성을 강조한다. 특히, 서비스 B의 지연이나 장애 발생 시 서비스 A가 영향을 받는 강결합(Tight Coupling) 문제를 지적한다. Pub/Sub(Publish/Subscribe)는 발행자와 구독자를 분리하여 시스템의 확장성(Scalability)과 탄력성(Resilience)을 향상시킨다.
토픽(Topic) 기반 메시지 전달과 팬아웃(Fan-out) 방식
게시물은 토픽(Topic)을 중심으로 메시지가 전달되는 과정을 설명한다. 발행자는 토픽에 메시지를 발행하고, 토픽은 해당 메시지를 여러 구독자에게 전달하는 팬아웃(Fan-out) 방식을 사용한다. 이로 인해 새로운 구독자를 추가해도 발행자 측의 변경이 필요 없으며, 각 구독자는 독립적으로 메시지를 처리하여 시스템의 병렬 처리(Parallel Processing) 능력을 높인다.
배달 보장(Delivery Guarantee) 방식과 DLQ(Dead Letter Queue)
게시물은 At-most-once와 At-least-once 배달 보장 방식의 차이점을 설명한다. At-most-once는 메시지 손실 가능성이 있지만 빠르며, At-least-once는 메시지 중복 처리 가능성이 있지만 데이터 손실을 방지한다. 또한, 처리 실패 메시지를 위한 DLQ(Dead Letter Queue)의 중요성을 강조하며, 시스템의 안정성(Stability)을 확보하는 방법을 제시한다.
실제 인프라 매핑 및 Encore 프레임워크
게시물은 AWS SNS+SQS, Google Cloud Pub/Sub, Azure Service Bus 등 클라우드 서비스의 Pub/Sub 구현 방식을 소개한다. 또한, Encore 프레임워크를 사용하여 Pub/Sub 인프라를 코드 레벨에서 선언하고 관리하는 방법을 제시한다. 인프라 자동화(Infrastructure Automation)를 통해 개발 생산성을 높이고, 운영 부담(Operational Burden)을 줄일 수 있음을 강조한다.
