이 연재글은 Google Cloud Platform의 3번째 글입니다.

Google Cloud Platform

GCP Pubsub

Google Cloud에서 제공하는 GCP PubSub는 데이터를 수집하고 배포하는 스트리밍 분석 및 데이터 통합 파이프라인에 사용되는 서비스입니다. 메시징 중심 애플리케이션 또는 태스크 병렬화를 위한 큐로 사용될 수 있습니다. PubSub를 사용하면 게시자 및 구독자라는 이벤트 제작자 및 소비자 시스템을 쉽게 만들 수 있습니다.

  • Kafka 및 Pulsar가 제공하는 분산 메시지 스트리밍 + ActiveMQ 및 RabbitMQ와 같은 기존 메시징 미들웨어의 기능(데드 레터 큐와 필터링 등)을 제공합니다.
  • GCP CloudFunctions/Cloud Run(AWS의 Lambda)은 PubSub과 쉽게 통합되며 간단하게 메시지 스트리밍 프로세서를 구현할 수 있습니다.
  • PubSub 스트림 데이터는 Bigquery, Cloud storage로 export할 수 있더 실시간으로 대용량 데이터 분석이 가능합니다.

Topic과 Subscription

PubSub는 Topic 단위로 메시지 타입을 구분하고 메시지를 발행할 수 있습니다. 하나의 Topic에서 발행되는 메시지는 여러 구독자(Subscription)에게 스트리밍 될 수 있으며 SubscriptionId를 통해 동일한 메시지를 여러 구독자가 서로 다른 용도로 사용할 수 있습니다.

Topic(주제)

동일한 주제의 메시지를 전달하기 위해 Topic을 생성해서 사용합니다. Kafka의 Topic과 비슷합니다. 다만 PubSub은 Managed Service로서 환경 별로 다른 endpoint를 제공하지 않습니다. 따라서 하나의 프로젝트내에서 여러가지 사용환경(sandbox, qa, prod)을 구축해서 사용한다면 같은 주제에 대해서 환경별로 Topic 이름을 생성해서 사용해야 합니다.

Topic 생성 Option

  • Add a default subscription : Topic 생성과 동시에 기본 SubscriptionId를 생성
  • Use a schema : 형식에 맞는 메시지만 발행 가능 하도록 메시지 포맷(스키마) 설정
  • Set message retention duration : 메시지 유지 기간 설정. 기본 7일 ~ 최대 31일 (기간에 따라 비용 발생)
  • Use a customer-managed encryption key(CMEK)
    • 메시지 암호화에 사용할 encryption key 설정

Subscription(구독)

Topic(주제)에 게시된 메시지를 전달 받으려면 구독을 해야 합니다. kafka의 consumer-group id처럼 PubSub에서는 subscription id를 사용하며 Topic으로부터 개별적으로 메시지를 수신하여 사용할 수 있습니다. Topic 메시지는 구독 시점 이후의 메시지부터 전달 받게 되므로 최초 메시지부터 받기를 원한다면 Topic 생성시 기본 Subscription Id를 생성해 사용하는 것이 좋은 선택일 수 있습니다.

Subscription 생성 Option

  • Delivery type
    • Pull : 구독자가 서버에 전달 받을 메시지를 요청
    • Push : 메시지가 게시되는 즉시 구독자 endpoint url로 메시지를 푸시
  • Message retention duration
    • 메시지 유지기간 설정
    • 10분~7일 까지 설정 가능
    • 수신확인(ack)를 이후에도 일정 저장 기간 메시지를 유지하는 옵션을 제공 ( Retain acknowledged messages )
  • Expiration period
    • 구독(subscription) 만료기간 설정
      • 일정기간만 구독을 허용해야 할 경우 유용한 기능
      • 만료기간은 최대 365일 까지 설정할 수 있으며 만료기간이 없도록 설정도 가능
  • Acknowledgement deadline
    • 수신 확인 데드라인 설정
    • 10초 ~ 600초까지 설정 가능
    • 설정된 시간이 초과될때까지 구독 애플리케이션에서 응답을 주지 않으면 해당 메시지는 메시지 열로 다시 들어가 처리를 반복하게 된다.
  • Subscription filter
    • 필터 구문이 적용되면 구독자는 해당 필터에 일치하는 메시지만 받도록 제한을 건다.
  • Exactly once delivery(Preview)
    • 정확히 한번만 메시지 배달을 보장받도록 설정
    • 활성화하면 구독으로 보낸 메시지는 메시지의 확인 기한이 만료되기 전에 다시 보내지 않는것이 보장된다. 확인된 메시지는 구독으로 다시 전송되지 않으며, 기본 승인(ack) 기한은 권장되는 최소값인 60초로 늘어난다.
  • Message ordering
    • 동일한 ordering key로 태그된 메시지들에 대해서 메시지 전달 순서를 보장하는 기능
    • kafka의 Partition Key와 비슷하며 한번 설정하면 수정 불가 함
  • Dead lettering
    • 최대 배달 시도 횟수를 지정하고 횟수를 초과하면 DeadLetter topic으로 메시지를 이동 시켜주는 기능
  • Retry Policy
    • 처리하지 못한 메시지에 대해 즉시 재시도 또는 Backoff delay 타임 이후에 재시도 하도록 설정할 수 있다.

PubSub 사용시 고려해야할 사항

메시지 작업 처리가 오래 걸리는 경우

  • Acknowledgement deadline 값을 적정한 값으로 세팅한다. (10초 ~600초)
  • 작업시 Acknowledgement deadline 시간을 초과할경우 동일 메시지가 계속 재시도 되므로 주의한다.

작업시간이 10분 이상이 걸리는 작업의 경우

메시지 순서 보장이 필요할 경우

  • 구독 생성시 Message ordering을 세팅한다.
  • 해당 설정은 SubscrionID 생성시에만 세팅 가능하고 한번 세팅한 다음에는 변경이 불가능하므로 주의해서 설정한다.

메시지 처리에 실패하여 별도 프로세스에서 메시지를 처리해야 할 경우

  • Dead letter queue를 설정한다. Dead letter queue에 넣기전 재 시도는 횟수는 최소 5회에서 최대 100회 까지 설정 가능하다.

재 시도시 일정 시간 후에 다시 재시도 해야 할 경우

  • backoff delay 시간을 설정한다.

메시지 예약(delay), 처리 속도 조절, 임시 중지 기능이 필요시

  • PubSub에서는 해당기능을 제공하지 않으므로 해당 기능을 제공하는 Cloud Task 사용을 검토한다.

연재글 이동[이전글] Google Cloud CLI (gcloud cli) 설치 및 사용
[다음글] Spring Cloud GCP Pub/Sub Starter를 사용한 연동 실습

RELATED ARTICLESMORE FROM AUTHOR