Налаштування 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 для поглибленого вивчення.