Pub/Sub 서비스 개요

Pub/Sub는 게시/구독(Pub/Sub) 서비스로, 메시지 전송자가 메시지 수신자와 분리되는 메시징 서비스입니다. 다음 그림에 설명된 바와 같이 Pub/Sub 서비스의 주요 개념은 다음과 같습니다.

Pub/Sub 서비스의 여러 구성요소와 구성요소 간 관계를 보여주는 그림입니다.
그림 1 2개의 게시자 클라이언트가 서로 다른 2개의 메시지를 공통 Pub/Sub 주제로 전송합니다.

다음은 Pub/Sub 서비스의 구성요소입니다.

  • 게시자(또는 제작자): 특정 주제에 대한 메시지를 만들어 메시징 서비스로 전송(게시)합니다.

  • 메시지: 서비스를 통해 이동하는 데이터

  • 주제: 메시지 피드를 나타내는, 이름이 지정된 항목입니다.

  • 스키마: Pub/Sub 메시지의 데이터 형식을 제어하는 이름이 지정된 항목입니다.

  • 구독: 특정 주제의 메시지 수신 의향을 나타내는, 이름이 지정된 항목입니다.

  • 구독자(또는 소비자): 지정한 구독에 대한 메시지를 수신합니다.

다음 절차에서는 Pub/Sub 서비스의 워크플로에 대해 논의합니다.

  1. 2개의 게시자 애플리케이션인 게시자 1과 게시자 2가 단일 Pub/Sub 주제로 메시지를 전송합니다. 게시자 1은 A 메시지를 전송하고 게시자 2는 B 메시지를 전송합니다.

  2. 주제 자체는 2개의 구독에 연결됩니다. 여기에는 구독 1과 구독 2가 있습니다.

  3. 주제는 스키마에도 연결됩니다.

  4. 각 구독은 주제에서 A와 B 메시지의 복사본을 수신합니다.

  5. 구독 1은 2개의 구독자 애플리케이션인 구독자 1과 구독자 2에 연결됩니다. 2개의 구독자 애플리케이션은 주제로부터 메시지 하위 집합을 수신합니다. 이 예시에서 주제로부터 구독자 1은 B 메시지를 수신하고 구독자 2는 A 메시지를 수신합니다.

  6. 구독 2는 구독자 3이라는 단일 구독자 애플리케이션에만 연결됩니다. 따라서 구독자 3은 주제에서 모든 메시지를 수신합니다.

Pub/Sub에서 메시지의 수명 주기

단일 게시자 클라이언트가 주제에 연결되었다고 가정합니다. 주제에는 단일 구독이 연결됩니다. 단일 구독자가 구독에 연결됩니다.

Pub/Sub 내에서 메시지 흐름을 보여주는 그림입니다.
그림 2 Pub/Sub를 통한 게시자 클라이언트에서 구독자 클라이언트로의 메시지 흐름.

다음 단계에서는 Pub/Sub에서의 메시지 흐름 방식을 설명합니다.

  1. 게시자 애플리케이션이 Pub/Sub 주제에 메시지를 전송합니다.

  2. 메시지가 스토리지에 기록됩니다.

  3. 스토리지에 메시지를 기록하는 것과 함께 Pub/Sub이 해당 주제의 모든 연결된 구독에 메시지를 전달합니다.

    이 예시에서는 단일 구독입니다.

  4. 구독이 메시지를 연결된 구독자 애플리케이션으로 전송합니다.

  5. 구독자가 메시지 처리 확인을 Pub/Sub로 전송합니다.

    각 구독에 대해 하나 이상의 구독자가 메시지를 확인하면 Pub/Sub가 메시지를 스토리지에서 삭제합니다.

Pub/Sub에서 메시지 상태

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

Pub/Sub 서비스의 메시지 상태는 세 가지입니다.

  • 확인된 메시지(acked). 구독자 애플리케이션이 주제에서 구독으로 전송된 메시지를 처리한 후 Pub/Sub로 다시 확인을 전송합니다. 주제의 모든 구독이 메시지를 확인했으면 게시 메시지 소스 및 스토리지에서 메시지가 비동기적으로 삭제됩니다.

  • 미확인된 메시지(unacked). Pub/Sub에 확인 기한 내에 확인이 수신되지 않으면 메시지가 한 번 넘게 전달될 수 있습니다. 예를 들어 구독자가 기한 만료 후 확인을 전송하거나 일시적인 네트워크 문제로 인해 확인이 손실될 수 있습니다. 미확인된 메시지는 메시지가 게시된 이후 메시지 보존 기간이 만료될 때까지 계속 전달됩니다. 이 시점에서 메시지가 만료됩니다.

  • 부정값으로 확인된 메시지(nacked). 구독자가 메시지를 부정값으로 확인하면 Pub/Sub가 이를 즉시 다시 전송합니다. 잘못된 메시지로 인해 또는 메시지 처리가 불가능하여 구독자가 메시지를 부정값으로 확인하면 해당 메시지가 손실되지 않고 결국 처리되었는지 확인하는 데 도움이 됩니다. 메시지를 부정값으로 확인하려면 modifyAckDeadline에 0 값을 사용하면 됩니다.

Pub/Sub 게시 및 구독 패턴 선택

게시자 및 구독자 클라이언트가 여러 개 있으면 설정하려는 게시 및 구독 아키텍처 종류도 선택해야 합니다.

다양한 게시 및 구독 패턴을 보여주는 그림입니다.
그림 3 게시자-구독자 관계는 다대일(팬인), 다대다(부하분산), 일대다(팬아웃)일 수 있습니다.

지원되는 Pub/Sub 일부 게시 구독 패턴에는 다음이 포함됩니다.

  • 팬인(다대일). 이 예시에서는 여러 게시자 애플리케이션이 단일 주제로 메시지를 게시합니다. 이 단일 주제는 단일 구독에 연결됩니다. 그러면 구독이 단일 구독자 애플리케이션에 연결되고 주제로부터 모든 게시된 메시지를 가져옵니다.

  • 부하 분산(다대다). 이 예시에서는 단일 또는 여러 게시자 애플리케이션이 단일 주제로 메시지를 게시합니다. 이러한 단일 주제는 단일 구독에 연결되어 있어서, 결과적으로 여러 개의 구독자 애플리케이션에 연결됩니다. 각 구독자 애플리케이션은 게시된 메시지의 하위 집합을 가져오고 어떠한 2개의 구독자 애플리케이션도 동일한 메시지 하위 집합을 가져오지 않습니다. 이 부하 분산 사례에서는 여러 구독자를 사용해서 규모에 맞게 메시지를 처리합니다. 더 많은 메시지를 지원해야 할 경우에는 동일한 구독으로부터 메시지를 수신할 구독자를 더 추가합니다.

  • 팬아웃(일대다). 이 예시에서는 단일 또는 여러 게시자 애플리케이션이 단일 주제로 메시지를 게시합니다. 이러한 단일 주제는 여러 구독에 연결되어 있습니다. 각 구독은 단일 구독자 애플리케이션에 연결됩니다. 각 구독자 애플리케이션은 주제로부터 동일한 게시된 메시지 집합을 가져옵니다. 한 주제에 여러 개의 구독이 있으면 각 구독을 대신해서 메시지를 수신하는 구독자로 모든 메시지를 전송해야 합니다. 동일한 메시지 집합에서 여러 다른 데이터 작업을 수행해야 하는 경우 팬아웃이 적합한 옵션입니다. 또한 각 구독에 여러 구독자를 연결하고 각 구독자에 대해 부하 분산된 메시지 하위 집합을 가져올 수 있습니다.

Pub/Sub 구성 옵션 선택

다음 옵션 중 하나를 사용해서 Pub/Sub 환경을 구성할 수 있습니다.

  • Google Cloud 콘솔
  • Google Cloud CLI
  • Cloud 클라이언트 라이브러리(상위 수준 클라이언트 라이브러리)
  • REST 및 RPC API(하위 수준 클라이언트 라이브러리)

선택할 Pub/Sub 구성 옵션은 사용 사례에 따라 달라집니다.

Google Cloud 콘솔을 처음 사용하고 Pub/Sub를 테스트하고 싶으면 콘솔 또는 gcloud CLI를 사용합니다.

상위 수준의 클라이언트 라이브러리는 최소한의 운영 오버헤드와 처리 비용을 가진 높은 처리량과 짧은 지연 시간이 필요한 경우에 권장됩니다. 기본적으로 상위 수준 클라이언트 라이브러리는 StreamingPull API를 사용합니다. 상위 수준의 클라이언트 라이브러리에는 인증, 처리량, 지연 시간 최적화, 메시지 형식 지정, 기타 기능을 위해 기본 API 호출을 처리하는 사전 빌드된 함수와 클래스가 포함됩니다.

하위 수준 클라이언트 라이브러리는 자동 생성된 gRPC 라이브러리이며 서비스 API를 직접 사용할 때 작동합니다.

다음은 클라이언트 라이브러리를 사용하기 위한 몇 가지 권장사항입니다.

  • 적합한 클라이언트 라이브러리 언어를 선택합니다. Pub/Sub 클라이언트 라이브러리의 성능은 언어별로 다릅니다. 예를 들어 Java 클라이언트 라이브러리는 세로 확장 측면에서 Python 클라이언트 라이브러리보다 효율적이며 더 많은 처리량을 감당할 수 있습니다. Java, C++, Go는 게시 또는 구독 부하를 처리하는 데 필요한 컴퓨팅 리소스 측면에서 보다 효율적인 언어입니다.

  • 최신 버전의 클라이언트 라이브러리를 사용합니다. Pub/Sub 클라이언트 라이브러리는 새로운 기능 및 버그 수정으로 계속해서 업데이트됩니다. 해당 언어에 대해 최신 버전의 클라이언트 라이브러리를 사용해야 합니다.

  • 게시자 클라이언트를 재사용합니다. 메시지를 게시할 때는 게시 요청마다 게시자 클라이언트를 새로 만드는 대신 동일한 게시자 클라이언트를 재사용하는 것이 더 효율적입니다. 이는 새 게시자 클라이언트를 만든 후 첫 번째 게시 요청을 수행하려면 승인된 연결을 설정하는 데 일정 시간이 필요하기 때문입니다. 명시적 게시자 클라이언트가 없는 Node와 같은 일부 언어에서는 게시 메서드를 호출하는 객체를 재사용합니다. 예를 들어 Node에서는 주제 객체를 저장하고 재사용합니다.

Pub/Sub 설정 방법

다음은 Pub/Sub 구성을 위한 대략적인 단계입니다.

  1. Pub/Sub를 설정할 수 있는 Google Cloud 프로젝트를 만들거나 선택합니다.

  2. Pub/Sub API를 사용 설정합니다.

  3. Pub/Sub 실행에 필요한 역할과 권한을 얻습니다.

  4. 주제를 만듭니다.

  5. 메시지 구조가 중요한 경우 메시지에 대해 스키마를 정의합니다.

  6. 주제에 스키마를 연결합니다.

  7. 주제에 메시지를 게시할 수 있는 게시자 클라이언트를 구성합니다.

  8. 필요한 경우 흐름 제어, 일괄 메시징, 동시 실행 제어와 같은 고급 게시 옵션을 구성합니다.

  9. 원하는 메시지 수신 방법에 따라 구독 유형을 선택합니다.

  10. 선택한 주제에 대한 구독을 만듭니다.

  11. 구독에서 메시지를 수신할 수 있는 구독자 클라이언트를 구성합니다.

  12. 필요한 경우 1회만 전송, 임대 관리, 정렬된 전송, 흐름 제어와 같은 고급 메시지 전송 옵션을 구성합니다.

  13. 게시자 클라이언트에서 주제로의 메시지 게시를 시작합니다.

  14. 동시에 이러한 메시지를 수신하고 처리할 구독자 클라이언트를 설정합니다.

주제, 구독, 스키마, 스냅샷 이름 지정 가이드라인

Pub/Sub 리소스 이름은 주제, 구독, 스키마, 스냅샷과 같은 Pub/Sub 리소스를 고유하게 식별합니다. 리소스 이름은 다음 형식이어야 합니다.

projects/project-identifier/collection/ID

  • project-identifier: Google Cloud 콘솔에서 사용 가능한 프로젝트 ID 또는 프로젝트 번호여야 합니다. 예를 들어 my-cool-project는 프로젝트 ID입니다. 123456789123은 프로젝트 번호입니다.

  • collection: topics, subscriptions, schemas, snapshots 중 하나여야 합니다.

  • ID: 다음 가이드라인을 준수하세요.

    • goog 문자열로 시작하지 않도록 합니다.
    • 문자로 시작합니다.
    • 3~255자여야 합니다.
    • 다음 문자(글자 [A-Za-z], 숫자 [0-9], 대시 -, 밑줄 _, 마침표 ., 물결표 ~, 더하기 기호 +, 퍼센트 기호 %)만 포함해야 합니다.

    URL로 인코딩하지 않고 리소스 이름에 이전 목록의 특수문자를 사용할 수 있습니다. 하지만 다른 특수문자를 URL에 사용하는 경우 올바르게 암호화되거나 디코딩되었는지 확인해야 합니다. 예를 들어 mi-tópico는 잘못된 ID입니다. 그러나 mi-t%C3%B3pico는 유효합니다. 이 형식은 REST를 호출할 때 중요합니다.

다음 단계