구독자 개요

이 문서에서는 Pub/Sub의 구독 방법에 대해 간략히 설명합니다. 가져오기 및 내보내기 전달 구독에 대한 자세한 내용은 구독자 가져오기 가이드구독자 내보내기 가이드를 참조하세요.

주제에 게시된 메시지를 받으려면 해당 주제에 대한 구독을 생성해야 합니다. 구독자 애플리케이션은 구독이 생성된 이후에 주제에 게시된 메시지만 사용할 수 있습니다. 구독은 주제에 게시된 메시지를 수신하고 처리하는 구독자 애플리케이션과 주제를 연결합니다. 한 주제에 여러 구독이 존재할 수 있지만, 한 구독은 하나의 주제에만 연결됩니다.

구독 생성 및 업데이트에 관한 자세한 내용은 주제 및 구독 관리를 참조하세요.

최소 1회 전송

Pub/Sub는 게시된 각 메시지를 모든 구독에 최소한 한 번은 전송합니다. 하지만 이러한 최소 1회 전송에는 몇 가지 예외사항이 적용됩니다.

  • 기본적으로, 최대 유지 기간인 7일 이내에 전달할 수 없는 메시지는 삭제되어 액세스할 수 없게 됩니다. 이 현상은 대부분 구독자가 메시지 흐름을 따라잡지 못할 때 발생합니다. 사용자가 메시지 보관 기간을 구성할 수 있습니다(범위: 10분~7일). 메시지 보관 설정에 관한 자세한 내용은 메시지 재생 및 삭제를 참조하세요.
  • 구독이 생성되기 전에 게시된 메시지는 일반적으로 구독에 전달되지 않습니다. 따라서 구독 없이 주제에 게시된 메시지는 구독자에게 전달되지 않습니다.

메시지가 구독자에게 전달되면 구독자는 메시지를 확인해야 합니다. 전달되었지만 아직 구독자가 확인하지 않은 메시지는 대기 상태로 간주됩니다. Pub/Sub는 확인하지 않은 메시지를 반복해서 전달합니다. 하지만 메시지가 하나의 구독자에 대해 대기 상태인 경우 Pub/Sub는 다른 구독자에게 같은 구독에 대해 전달하지 않습니다. 구독자는 대기 중인 메시지를 확인하기 위한 ackDeadline이라고 하는 구성 가능하며 제한된 시간을 갖습니다. 기한이 지나면 메시지는 더 이상 대기 상태로 간주되지 않으며 Pub/Sub에서는 메시지를 다시 전송하려고 합니다.

일반적으로 Pub/Sub는 각 메시지를 게시된 순서대로 1회 전달합니다. 하지만 간혹 메시지가 순서대로 전달되지 않거나 여러 번 전달되기도 합니다. 일반적으로 전달을 1회 이상 수용하려면 메시지를 처리할 때 구독자에게 멱등성이 있어야 합니다. Apache Beam programming model을 사용하여 Pub/Sub 메시지 스트림을 한 번만 처리할 수 있습니다. Apache Beam I/O 커넥터를 사용하면 제어된 소스 및 싱크를 통해 Cloud Dataflow와 상호작용할 수 있습니다. Apache Beam PubSubIO 커넥터(자바Python용)를 사용하여 Cloud Pub/Sub에서 읽을 수 있습니다. 서비스의 표준 정렬 API를 이용해 Cloud Dataflow로 순서에 따른 처리를 하는 방법도 있습니다. 순서 처리를 하는 또 다른 방법은 구독한 주제의 게시자가 메시지에 순서 토큰을 넣는 것입니다. 자세한 내용은 메시지 순서를 참조하세요.

가져오기 또는 내보내기 전달

구독은 메시지 전달을 위해 가져오기 또는 내보내기 방법을 사용합니다. 전달 방법은 언제든 변경하거나 구성할 수 있습니다.

가져오기 구독

가져오기 전달에서는 구독자 애플리케이션이 Pub/Sub 서버에 메시지 검색을 요청합니다.

  1. 구독 애플리케이션은 가져오기 방법을 명시적으로 호출해, 전달할 메시지를 요청합니다.
  2. Pub/Sub 서버가 메시지(큐가 비어 있다면 오류)와 확인 ID에 반응합니다.
  3. 구독자는 반환된 확인 ID를 이용해 확인 방법을 명시적으로 호출함으로써 메시지 수신을 확인합니다.

가져오기 구독 메시지 요청 흐름

내보내기 구독

내보내기 전달에서는 Pub/Sub가 구독자 애플리케이션에 메시지 수신을 요청합니다.

  1. Pub/Sub 서버는 각 메시지를 미리 구성된 엔드포인트에 있는 구독자 애플리케이션에 하나의 HTTPS 요청으로 전송합니다.
  2. 엔드포인트가 HTTP 성공 상태 코드를 반환해 메시지를 확인합니다. 성공적이지 않은 응답은 메시지를 다시 전송해야 한다는 뜻입니다.

내보내기 구독 메시지 요청 흐름

Pub/Sub는 성공 응답을 수신하는 속도에 따라 내보내기 요청 비율을 동적으로 조정합니다.

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

가져오기 내보내기
  • 대량 메시지(초당 1개보다 훨씬 많음)
  • 메시지 처리의 효율성과 처리량이 대단히 중요함
  • 자체 서명되지 않은 SSL 인증서가 있는 공개 HTTPS 엔드포인트를 설정하기 어려움
  • 여러 주제를 같은 webhook으로 처리해야 함
  • App Engine 표준 및 Cloud Functions 구독자
  • Google Cloud 종속 항목(사용자 인증 정보와 클라이언트 라이브러리 등)을 설정하기 어려운 환경

다음은 가져오기와 내보내기 전달의 비교 표입니다.

  가져오기 내보내기
엔드포인트 자격을 증명한 인터넷상의 모든 기기는 Pub/Sub API를 호출할 수 있음 공개 웹에 액세스 가능한, 자체 서명되지 않은 인증서가 있는 HTTPS 서버 수신 엔드포인트는 Pub/Sub 구독과 분리될 수 있으며, 따라서 여러 구독의 메시지를 단일 엔드포인트에 전송할 수 있음
부하 분산 여러 구독자가 같은 '공유' 구독에 가져오기 호출을 보낼 수 있음. 각 구독자는 메시지 하위 집합을 수신하게 됨 가져오기 엔드포인트가 부하 분산기가 될 수 있음
구성 구성할 필요가 없음 구독자와 같은 프로젝트에 있는 App Engine은 구성할 필요가 없음.
내보내기 엔드포인트의 구성(및 확인)은 다른 모든 엔드포인트의 Google Cloud Console에서 필요함. 엔드포인트는 DNS 이름을 통해 연결할 수 있으며, SSL 인증서가 설치되어 있어야 함.
흐름 관리 구독자 클라이언트가 전달 속도를 조절함. 구독자는 확인 기한을 동적으로 수정하며, 따라서 메시지 처리에 걸리는 시간이 임의로 길어질 수 있음 Pub/Sub 서버가 자동으로 흐름 제어를 구현함. 클라이언트 측에서 메시지 흐름을 처리할 필요는 없지만, HTTP 오류를 되돌려보내 클라이언트가 현재 메시지 부하를 처리할 수 없음을 표시할 수는 있음
효율성 및 처리량 일괄 전달과 확인 및 대량의 동시 소비가 가능해 낮은 CPU와 대역폭에서도 높은 처리량을 구현함. 메시지 전달 시간 최소화를 위해 적극적인 폴링을 사용하면 효율성이 떨어질 수 있음 요청당 메시지 1개를 전달하며 대기 메시지 최대 숫자를 제한함

구독의 수명

기본적으로, 구독은 31일 동안 활동이 없으면 만료됩니다(예: 활성화된 연결, 가져오기 요청, 내보내기 성공이 없는 경우). Pub/Sub가 구독자 활동을 감지하면 구독 삭제 시계가 다시 시작됩니다. 구독 만료 정책을 사용하면 비활동 기간을 구성하거나 활동에 관계없이 구독 기간을 무한대로 설정할 수 있습니다. 구독 수동 삭제도 가능합니다.

삭제된 구독과 같은 이름으로 새 구독을 생성할 수 있지만 생성한 새 구독은 이전 구독과 관련이 없습니다. 삭제한 구독에 확인하지 않은 메시지가 많이 있더라도 동일한 이름으로 지정한 새 구독은 생성 시점에 백로그가 없을 것입니다(전달 대기 중인 메시지가 없음).

구독 작업에 대한 자세한 내용은 구독 구성을 참조하세요.