베하 ~! 😊
오늘은 'Pub/Sub'에 대해 알아보겠습니다.
Pub/Sub은 구글 클라우드 플랫폼(GCP)에서 제공하는 메시징 서비스 중 하나로, 이벤트 기반 아키텍처를 구현하는 데 사용됩니다. 여러 컴포넌트 간에 데이터를 안전하게 전송하고 분산된 시스템 간에 통신하는 데 중요한 역할을 합니다.
Pub/Sub을 알기 전부터 Message Queue에 대해서 간단하게 설명하고 넘어가겠습니다.
Message Queue란?
- 분산 시스템에서 각 컴포넌트 간의 통신을 돕는 소프트웨어 패턴 중 하나
- 비동기적으로 메시지를 주고받을 수 있도록 설계되었으며, 시스템의 다양한 부분 간에 데이터를 안전하게 전송하는 데 사용
(1) 비동기 통신: 송신자와 수신자가 실시간으로 직접 통신하지 않고, 메시지 큐를 통해 비동기적으로 통신합니다. 이는 각 컴포넌트가 독립적으로 동작하고 상호 의존성을 낮출 수 있도록 돕습니다.
(2) 탄력성: 시스템 부하가 증가해도 메시지 큐는 메시지를 안전하게 저장하고, 시스템이 준비되면 메시지를 처리합니다. 이는 시스템의 확장성을 향상시키고 안정성을 제공합니다.
(3) 해결책 분리: 메시지 큐를 사용하면 서로 다른 컴포넌트 간에 데이터 교환을 통일된 방식으로 처리할 수 있습니다. 이로써 시스템의 유연성과 유지보수성이 향상됩니다.
Pub/Sub이란?
- 메시지를 생성하는 서비스를 해당 메시지를 처리하는 서비스에서 분리하는 확장 가능한 비동기 메시징 서비스
- 여기서 메시징 서비스란, 메시지들을 Queue에 넣고, 차례대로 전달해주는 서비스를 뜻합니다.
- 데이터를 수집하고 배포하는 스트리밍 분석 및 데이터 통합 파이프라인에 사용
- 즉, GCP에서 Pub/Sub 서비스는 BigQuery, 데이터 레이크, 운영 데이터베이스로 스트리밍하기 위한 이벤트 수집
주요 구성 요소
- Publisher(게시자)
- 특정 주제에 대한 메시지를 만들어 메시징 서비스로 전송(게시)
- Message
- 서비스를 통해 이동하는 데이터
- Topic에 쌓이는 터
- Topic(주제)
- 메시지를 전송하는 이름이 지정된 리소스
- 메시징 서비스에서 메시지가 쌓이는 Queue 담당
- Schema
- Pub/Sub 메시지의 데이터 형식을 제어하는 이름이 지정된 항목
- Subscription(구독)
- 특정 주제의 메시지 수신 의향을 나타내는, 이름이 지정된 항목
- Subscription은 하나의 Topic에 대해서 단일 혹은 여러개 생성 가능
- Subscriber (구독자)
- 지정한 구독에 대한 메시지를 수신
위 예시로 보는 워크플로
- 2개의 Publisher 애플리케이션인 Publisher 1과 Publisher 2가 단일 Pub/Sub 주제로 메시지를 전송합니다. (여기에는 Publisher 1은 A 메시지를 전송하고 게시자 2는 B 메시지를 전송합니다.)
- Topic 자체는 2개의 Subscription(여기에는 Subscription 1과 Subscription 2)에 연결됩니다.
- Topic는 Schema에도 연결됩니다.
- 각 Subscription(구독)은 Topic에서 A와 B 메시지의 복사본을 수신합니다.
- Subscription(구독) 1은 2개의 구독자 애플리케이션에 연결됩니다. 2개의 구독자 애플리케이션은 Topic으로부터 Message 하위 집합을 수신합니다. 이 예시에서 주제로부터 구독자 1은 B 메시지를 수신하고 구독자 2는 A 메시지를 수신합니다.
- Subscription(구독) 2는 구독자 3이라는 단일 구독자 애플리케이션에만 연결됩니다. 따라서 구독자 3은 주제에서 모든 메시지를 수신합니다.
Pub/Sub 게시 및 구독 패턴
- 팬인(다대일)
- 여러 Publisher 애플리케이션이 단일 Topic로 메시지를 게시
- 단일 주제는 단일 구독에 연결됨
- 구독이 단일 구독자 애플리케이션에 연결되고, 주제로부터 모든 게신된 메시지를 가져옴
- 부하 분산(다대다)
- 단일 또는 여러 Publisher 애플리케이션이 단일 Topic로 메시지를 게시함
- 단일 Topic는 단일 구독에 연결되어 있어서, 결과적으로 여러 개의 구독자 애플리케이션에 연결됨
- 각 구독자 애플리케이션은 게시된 메시지의 하위 집합을 가져오고 어떠한 2개의 구독자 애플리케이션도 동일한 메시지 하위 집합을 가져오지 않음
- 팬아웃(일대다)
- 여러 게시자 애플리케이션이 단일 주제로 메시지를 게시함
- 단일 주제는 여러 구독에 연결되어 있음
- 각 구독은 단일 구독자 애플리케이션에 연결됨
- 각 구독자 애플리케이션은 주제로부터 동일한 게시된 메시지 집합을 가져옴 한 주제에 여러 개의 구독이 있으면 각 구독을 대신해서 메시지를 수신하는 구독자로 모든 메시지를 전송해야함
- 또한 각 구독에 여러 구독자를 연결하고 각 구독자에 대해 부하 부산된 메시지 하위 집합을 가져올 수 있음
일반 사용 사례
(1) 사용자 상호작용 및 서버 이벤트 수집
- 최종 사용자 앱의 사용자 상호작용 이벤트 또는 시스템의 서버 이벤트를 사용하려면 이를 Pub/Sub로 전달해야 할 수 있습니다. 그런 후 이벤트를 데이터베이스로 전송하는 Dataflow와 같은 스트림 처리 도구를 사용할 수 있습니다. 이러한 데이터베이스 예시에는 BigQuery, Cloud Bigtable, Cloud Storage가 있습니다. Pub/Sub를 사용하면 여러 클라이언트의 이벤트를 동시에 수집할 수 있습니다.
(2) 실시간 이벤트 배포
- 원시 또는 처리된 이벤트를 팀과 조직 전체의 여러 애플리케이션에서 실시간으로 처리할 수 있습니다. Pub/Sub는 '엔터프라이즈 이벤트 버스' 및 이벤트 기반 애플리케이션 설계 패턴을 지원합니다. Pub/Sub를 사용하면 이벤트를 Pub/Sub로 내보내는 여러 Google 시스템과 통합할 수 있습니다.
(3) 데이터베이스 간 데이터 복제
- Pub/Sub는 일반적으로 데이터베이스의 변경 이벤트를 배포하는 데 사용됩니다. 이러한 이벤트는 BigQuery 및 다른 데이터 스토리지 시스템에서 데이터베이스 상태 및 상태 기록의 뷰를 구성하는 데 사용될 수 있습니다.
(4) 병렬 처리 및 워크플로
- Pub/Sub 메시지를 사용하여 Cloud Functions에 연결하면 여러 작업자 간에 많은 태스크를 효율적으로 배포할 수 있습니다. 이러한 태스크의 예시에는 텍스트 파일 압축, 이메일 알림 전송, AI 모델 평가, 이미지 형식 재지정이 있습니다.
(5) 엔터프라이즈 이벤트 버스
- 전사적 실시간 데이터 공유 버스를 만들어 비즈니스 이벤트, 데이터베이스 업데이트, 분석 이벤트를 조직 전체에 배포할 수 있습니다.
(6) 애플리케이션, 서비스, IoT 기기에서 데이터 스트리밍
- 예를 들어 SaaS 애플리케이션은 이벤트의 실시간 피드를 게시할 수 있습니다. 또는 가정용 센서가 Dataflow 파이프라인을 통해 다른 Google Cloud 제품에서 사용할 수 있도록 Pub/Sub로 데이터를 스트리밍할 수 있습니다.
(7) 분산 캐시 갱신
- 예를 들어 애플리케이션이 무효화 이벤트를 게시하여, 변경된 객체의 ID를 업데이트합니다.
(8) 안정성을 위한 부하 분산
- (EX) 서비스 인스턴스가 여러 영역에 있는 Compute Engine에 배포되어도 공통 주제를 구독할 수 있습니다. 영역에 장애가 발생하면 나머지가 자동으로 부하를 선택합니다.
특징과 장점
(1) 확장성
- Pub/Sub은 대규모 데이터 처리 및 분산 시스템에서 효과적으로 확장 가능
(2) 신뢰성
- 메시지는 안전하게 보관되며, 장애가 발생해도 손실 없이 메시지가 전달
(3) 다양한 프로토콜 지원
- RESTful API 및 클라이언트 라이브러리를 통해 다양한 언어로 구현 가능
그럼 다음 시간에 봐요 ~
베빠 ~ 😊
[참고자료]
'Database' 카테고리의 다른 글
| Airflow 환경 이전 (0) | 2023.12.24 |
|---|---|
| Python 클라이언트 라이브러리를 사용하여 Cloud Pub/Sub로 메시지 게시 (0) | 2023.12.15 |
| Parquet 데이터 수정하기 (2) | 2023.12.08 |
| Cloud Spanner (0) | 2023.11.24 |
| Redis란 (0) | 2023.11.10 |
댓글