구독 유형 선택

이 문서는 사용자의 비즈니스 요구사항에 적합한 Pub/Sub 구독 유형을 선택하는 데 도움이 됩니다.

시작하기 전에

  • 구독에 대해 알아보기

Pub/Sub 구독 비교 표

다음 표는 애플리케이션에 맞는 전달 방법을 선택하는 지침을 제공합니다.

Pub/Sub 구독에서 지원되는 기능
사용 사례 Pull 구독
  • 대량 메시지(초당 GB)
  • 메시지 처리의 효율성과 처리량이 대단히 중요함
  • 자체 서명되지 않은 SSL 인증서가 있는 공개 HTTPS 엔드포인트를 설정할 수 없는 환경
Push 구독
  • 여러 주제를 같은 웹훅으로 처리해야 함
  • App Engine 표준 및 Cloud Run 함수 구독자
  • Google Cloud 종속 항목(사용자 인증 정보와 클라이언트 라이브러리 등)을 설정하기 어려운 환경
내보내기 구독
  • 메시지가 초당 수백만 개까지 확장될 수 있는 대량 메시지
  • 메시지가 추가 처리 없이 Google Cloud 리소스에 직접 전송됨
엔드포인트 Pull 구독

사용자 인증 정보를 증명한 인터넷상의 모든 기기는 Pub/Sub API를 호출할 수 있음
Push 구독
  • 공개 웹에 액세스 가능한, 자체 서명되지 않은 인증서가 있는 HTTPS 서버
  • 수신 엔드포인트는 Pub/Sub 구독과 분리될 수 있으며, 따라서 여러 구독의 메시지가 단일 엔드포인트에 전송됨
내보내기 구독
  • BigQuery 구독의 BigQuery 데이터 세트 및 테이블
  • Cloud Storage 구독의 Cloud Storage 버킷
부하 분산 Pull 구독
  • 여러 구독자가 같은 '공유' 구독에 가져오기 호출을 보낼 수 있음
  • 각 구독자는 메시지 하위 집합을 수신함
Push 구독

push 엔드포인트가 부하 분산기가 될 수 있음
내보내기 구독

Pub/Sub 서비스가 자동으로 부하를 분산함
구성 Pull 구독

구성할 필요가 없음
Push 구독
  • 구독자와 같은 프로젝트에 있는 App Engine 앱은 구성할 필요가 없음
  • 푸시 엔드포인트 확인은 Google Cloud 콘솔에서 필요하지 않음
  • 엔드포인트는 DNS 이름을 통해 연결할 수 있으며, SSL 인증서가 설치되어 있어야 함
내보내기 구독
  • 적절한 권한으로 구성된 BigQuery 구독에 대해 BigQuery 데이터 세트와 테이블이 있어야 함
  • 적절한 권한으로 구성된 Cloud Storage 구독에 대한 Cloud Storage 버킷이 있어야 함
흐름 관리 Pull 구독

구독자 클라이언트가 전달 속도를 조절함. 구독자는 확인 기한을 동적으로 수정하며, 따라서 메시지 처리에 걸리는 시간이 임의로 길어질 수 있음

Push 구독

Pub/Sub 서버가 자동으로 흐름 제어를 구현함. 클라이언트 측에서 메시지 흐름을 처리할 필요는 없지만 HTTP 오류를 되돌려보내 클라이언트가 현재 메시지 부하를 처리할 수 없음을 표시할 수는 있음

내보내기 구독

Pub/Sub 서버가 Google Cloud 리소스에 대한 메시지 쓰기를 최적화하기 위해 자동으로 흐름 제어를 구현함

효율성 및 처리량 Pull 구독

일괄 전송, 확인, 대량의 동시 소비가 가능하여 낮은 CPU와 대역폭에서 높은 처리량을 달성함. 메시지 전송 시간 최소화를 위해 적극적인 폴링을 사용하면 효율성이 떨어질 수 있음

Push 구독

요청당 메시지 1개를 전달하며 대기 메시지 최대 숫자를 제한함
내보내기 구독

확장성은 Pub/Sub 서버에 의해 동적으로 처리됨

내보내기 구독을 사용해야 하는 경우

내보내기 구독이 없는 경우 가져오기 또는 내보내기 구독과 구독자(예: Dataflow)가 메시지를 읽고 Google Cloud 리소스에 기록해야 합니다. 메시지를 저장하기 전에 추가 처리가 필요하지 않은 경우 Dataflow 작업을 실행하는 오버헤드가 필요하지 않습니다.

내보내기 구독은 다음과 같은 이점이 있습니다.

  • 간단한 배포. 콘솔, Google Cloud CLI, 클라이언트 라이브러리, Pub/Sub API에서 단일 워크플로를 통해 내보내기 구독을 설정할 수 있습니다.

  • 낮은 비용. Dataflow 작업을 포함하는 비슷한 Pub/Sub 파이프라인의 추가 비용 및 지연 시간을 줄여 줍니다. 이러한 비용 최적화는 스토리지 이전 추가 처리가 필요하지 않은 메시징 시스템에 유용합니다.

  • 최소한의 모니터링. 내보내기 구독은 멀티 테넌트 Pub/Sub 서비스의 일부이며 사용자가 별도의 모니터링 작업을 실행할 필요가 없습니다.

  • 유연성. BigQuery 구독은 연결된 주제의 스키마를 사용할 수 있습니다. 이는 Pub/Sub에서 BigQuery로 기록하는 기본 Dataflow 템플릿에서는 사용할 수 없습니다. 마찬가지로, Cloud Storage 구독은 파일 크기 및 경과 시간을 기준으로 구성 가능한 파일 일괄 처리 옵션을 제공합니다. 이는 Pub/Sub에서 Cloud Storage로 쓰기 위한 기본 Dataflow 템플릿에서 구성할 수 없습니다.

그러나 데이터가 BigQuery 테이블 또는 Cloud Storage 버킷과 같은 Google Cloud 리소스에 저장되기 전에 일부 데이터 변환이 필요한 Pub/Sub 시스템에는 여전히 Dataflow 파이프라인이 권장됩니다.

Dataflow를 사용하여 변환을 통해 Pub/Sub에서 BigQuery로 데이터를 스트리밍하는 방법은 Pub/Sub에서 BigQuery로 스트리밍을 참조하세요.

Dataflow를 사용하여 변환으로 Pub/Sub에서 Cloud Storage로 데이터를 스트리밍하는 방법은 Dataflow를 사용하여 Pub/Sub에서 메시지 스트리밍을 참조하세요.

다음 단계

각 구독 유형의 워크플로 알아보기