Настройка GCP Pub/Sub для надёжной доставки сообщений

resource "google_pubsub_topic" "orders" {
  project = var.project_id
  name = "orders"
  message_retention_duration = "604800s"
  schema_settings {
    schema = google_pubsub_schema.order.id
    encoding = "JSON"
  }
}

resource "google_pubsub_schema" "order" {
  project = var.project_id
  name = "order-schema"
  type = "AVRO"
  definition = file("schemas/order.avsc")
}

resource "google_pubsub_subscription" "orders_processor" {
  project = var.project_id
  name = "orders-processor"
  topic = google_pubsub_topic.orders.id
  ack_deadline_seconds = 60
  message_retention_duration = "604800s"
  retain_acked_messages = false
  expiration_policy {
    ttl = ""
  }
  retry_policy {
    minimum_backoff = "10s"
    maximum_backoff = "600s"
  }
  dead_letter_policy {
    dead_letter_topic = google_pubsub_topic.orders_dlq.id
    max_delivery_attempts = 5
  }
}

resource "google_pubsub_topic" "orders_dlq" {
  project = var.project_id
  name = "orders-dlq"
  message_retention_duration = "2592000s"
}

Dead Letter Policy критически важна. Без неё «отравленное» сообщение (malformed payload, которое всегда крашит обработчик) будет повторно доставляться до бесконечности, блокируя обработку остальных. DLQ перехватывает его после 5 попыток — вы получаете алерт и можете исправить payload.

Обработка сообщений с Python

from google.cloud import pubsub_v1
import json

def process_message(message: pubsub_v1.subscriber.message.Message):
    try:
        data = json.loads(message.data.decode("utf-8"))
        order_id = data.get("order_id")
        if not is_already_processed(order_id):
            process_order(data)
            mark_as_processed(order_id)
        message.ack()
    except Exception as e:
        print(f"Error: {e}")
        message.nack()

subscriber = pubsub_v1.SubscriberClient()
subscription_path = subscriber.subscription_path(PROJECT_ID, "orders-processor")
flow_control = pubsub_v1.types.FlowControl(max_messages=100)
streaming_pull_future = subscriber.subscribe(
    subscription_path,
    callback=process_message,
    flow_control=flow_control,
)

FlowControl(max_messages=100) ограничивает количество одновременно обрабатываемых сообщений. Без этого быстрый producer может заполнить память consumer'а.

Безопасность: IAM и сервисные аккаунты

gcloud pubsub topics add-iam-policy-binding orders \
  --member=serviceAccount:[email protected] \
  --role=roles/pubsub.publisher

gcloud pubsub subscriptions add-iam-policy-binding orders-processor \
  --member=serviceAccount:[email protected] \
  --role=roles/pubsub.subscriber

Мониторинг и алертинг

Ключевые метрики в Cloud Monitoring:

• pubsub.googleapis.com/subscription/num_undelivered_messages — растёт? Consumer не справляется.
• pubsub.googleapis.com/subscription/oldest_unacked_message_age — если > ack_deadline, сообщения повторно доставляются.
• pubsub.googleapis.com/subscription/dead_letter_message_count — алерт при ненулевом значении.

При нагрузке 200 тыс. сообщений/сек num_undelivered_messages должен быть близок к нулю. Правильная настройка алертов сокращает MTTR на 60% (по данным Google Cloud Pub/Sub documentation).

Сравнение: Pub/Sub vs Cloud Tasks vs RabbitMQ

Pub/Sub выигрывает в скорости и managed-удобстве, Cloud Tasks — если нужна дедупликация и порядок, RabbitMQ — для самописных решений под жёстким контролем.

Процесс внедрения и сроки

Мы работаем по этапам:

1. Анализ архитектуры и требований к событийной модели.
2. Проектирование топиков, подписок, схем.
3. Реализация Terraform-модулей с параметрами (ack deadline, retry, DLQ).
4. Интеграция с потребителями (pull/push).
5. Настройка мониторинга и алертов.
6. Документирование runbook'ов и обучение команды.

Что входит в работу

При заказе настройки Pub/Sub под ключ вы получаете:

• Топики и подписки с правильными параметрами (ack deadline, retry, DLQ).
• Schema validation для защиты от невалидных данных.
• IAM-роли и сервисные аккаунты.
• Terraform-код (модули) в ваш репозиторий.
• Дашборды мониторинга в Cloud Monitoring и алерты.
• Документацию по архитектуре и runbook.
• Обучение команды основам идемпотентности и обработки ошибок.
• Поддержку при запуске (1 неделя).

Сроки: топология с одним топиком и подписками — 1 день. Сложные event-driven схемы с несколькими топиками, schema validation и push-интеграцией с Cloud Run/Functions — 2–3 дня. Стоимость рассчитывается индивидуально.

Хотите получить надёжную событийную архитектуру? Свяжитесь с нами для предварительной оценки вашего проекта. Закажите настройку Pub/Sub под ключ — мы гарантируем стабильную работу при любых нагрузках.

Рекомендуем ознакомиться с официальной документацией Google Pub/Sub для углублённого изучения.