Налаштування Message Queue (Amazon SQS/SNS) для DevOps-інфраструктури
Служба підтримки скаржиться на дублювання замовлень, а розробники — на втрату подій після деплою? Ймовірно, черга повідомлень налаштована неправильно. Ми, як DevOps-інженери з багаторічним досвідом, вирішували подібні проблеми десятки разів. Налаштуємо вам надійний обмін повідомленнями на Amazon SQS та SNS під ключ за 1–3 дні. Зв'яжіться з нами для аудиту — виявимо проблеми з чергами за годину.
Черги повідомлень в AWS вирішують два різні завдання, які часто плутають. SQS — черга з pull-моделлю: consumer сам забирає повідомлення, обробляє, видаляє. SNS — pub/sub брокер з push-доставкою: один publisher, багато підписників, доставка в реальному часі. Неправильний вибір між ними — джерело проблем з надійністю та вартістю.
Як вибрати між Standard та FIFO?
Standard Queue — висока пропускна здатність (мільйони повідомлень на секунду), at-least-once delivery (повідомлення може прийти двічі), порядок не гарантовано. Підходить для більшості завдань, де consumer ідемпотентний. FIFO Queue — строго один раз, строго в порядку, але максимум 3000 TPS (з batching — 30000 TPS). Використовуємо для фінансових транзакцій, обробки замовлень, де порядок критичний. Ім'я черги обов'язково закінчується на .fifo. Standard Queue в 1000 разів дешевше FIFO при високих навантаженнях — різниця у вартості зберігання та операцій суттєва.
Порівняємо характеристики:
| Властивість | Standard | FIFO |
|---|---|---|
| Throughput | ~мільйони msg/s | 3000 TPS (30000 з батчингом) |
| Доставка | At least once | Exactly once |
| Порядок | Не гарантовано | Строгий порядок |
| Суфікс імені | не потрібен | .fifo |
| Сценарій | Ідемпотентні consumer | Критичний порядок |
Часта помилка — ставити FIFO скрізь «про всяк випадок». Це обмежує пропускну здатність і здорожує. Якщо порядок не потрібен — Standard. В одному проекті клієнт ставив FIFO на всі черги і отримував 500 TPS при потребі в 2000 — після заміни на Standard пропускна здатність зросла в 10 разів, а витрати знизилися на 40%.
Чому DLQ обов'язковий?
DLQ — черга для повідомлень, які не вдалося обробити після N спроб. Без DLQ «отруйне» повідомлення (poison pill) буде нескінченно повертатися в чергу і блокувати обробку. Ми завжди включаємо DLQ з трьома спробами — це стандарт для production.
Налаштовуємо redrive policy:
{
"deadLetterTargetArn": "arn:aws:sqs:eu-west-1:123456789:myapp-dlq.fifo",
"maxReceiveCount": 3
}Після 3 невдалих спроб — повідомлення йде в DLQ. На DLQ — окремий CloudWatch Alarm на ApproximateNumberOfMessagesVisible > 0. Якщо в DLQ щось з'явилося — потрібно розбиратися негайно.
Terraform-приклад створення черги з DLQ
resource "aws_sqs_queue" "main" {
name = "myapp-orders.fifo"
fifo_queue = true
content_based_deduplication = true
visibility_timeout_seconds = 300
redrive_policy = jsonencode({
deadLetterTargetArn = aws_sqs_queue.dlq.arn
maxReceiveCount = 3
})
}
resource "aws_sqs_queue" "dlq" {
name = "myapp-orders-dlq.fifo"
fifo_queue = true
}visibility_timeout_seconds має бути більшим за максимальний час обробки повідомлення. Якщо Lambda timeout 60 секунд — ставимо visibility timeout 90–120 секунд (запас 100%). Інакше Lambda ще обробляє, а SQS вважає повідомлення «не забраним» і віддає іншому consumer.
Якщо ваша черга вже втрачає повідомлення — замовте аудит, ми знайдемо причину за день.
SNS Fan-Out паттерн
SNS + SQS разом дають fan-out: одне повідомлення публікується в SNS топік, доставляється в кілька SQS черг одночасно. Кожен consumer обробляє незалежно. Типовий випадок: подія order.created → SNS → три черги: billing-queue, inventory-queue, notification-queue. Три різні сервіси обробляють незалежно, не знаючи один про одного.
SNS підтримує filter policies — підписник отримує лише повідомлення з певними атрибутами. Наприклад, billing-queue отримує лише події з amount > 100, notification-queue — всі. Це знижує навантаження на 30–40%.
Інтеграція з Lambda
Lambda Event Source Mapping для SQS — вбудований механізм polling. Lambda-функція запускається автоматично при появі повідомлень. Важливі параметри:
-
batch_size— скільки повідомлень Lambda отримує за виклик (1–10000). Для FIFO рекомендуємо невеликі батчі (10–50) — весь батч блокується при помилці обробки одного повідомлення. -
maximum_batching_window_in_seconds— Lambda чекає вказаний час (до 300 секунд), щоб набрати повний батч. Економить виклики при низькому трафіку. -
function_response_types: ["ReportBatchItemFailures"]— частковий успіх батча. Lambda повідомляє SQS, які саме повідомлення не оброблені (а не весь батч). ReportBatchItemFailures — критично важливо для FIFO. Без нього при помилці одного з 10 повідомлень всі 10 йдуть в retry.
Шифрування та IAM
SQS підтримує SSE через AWS KMS (SQS-Managed Key або Customer Managed Key). Для production використовуємо CMK — це дає audit trail через CloudTrail. Права на SQS жорстко через IAM: producer має лише sqs:SendMessage, consumer — sqs:ReceiveMessage, sqs:DeleteMessage, sqs:GetQueueAttributes. Жодних sqs:* в production. Крім IAM, налаштовуємо resource-based політики для кросс-акаунтного доступу.
Моніторинг
Ключові CloudWatch метрики:
| Метрика | Що сигналізує |
|---|---|
ApproximateAgeOfOldestMessage |
Черга не встигає оброблятися |
ApproximateNumberOfMessagesVisible |
Нагромаджується беклог |
NumberOfMessagesSent |
Різке падіння = проблема у producer |
DLQ ApproximateNumberOfMessagesVisible > 0 |
Є зламані повідомлення |
Також додаємо алерт по ApproximateAgeOfOldestMessage при перевищенні 5 хвилин — це дозволить помітити проблему до того, як черга виросте до тисяч повідомлень.
Що ви отримаєте за підсумком роботи
Після завершення налаштування ми передаємо:
- Конфігураційні файли Terraform (модулі для SQS, SNS, Lambda, CloudWatch).
- IAM політики з мінімальними правами.
- Налаштовані CloudWatch дашборди та алерти.
- Документацію щодо структури черг та схем інтеграції.
- Рекомендації щодо продуктивності та вартості (наприклад, використання reserved concurrency для Lambda, економія до 30% на розмірі батча).
Щоб отримати готову конфігурацію, зв'яжіться з нами.
Процес роботи
- Аналітика — рев'ю поточної архітектури, розбір проблем з чергами (втрати, дублювання, затримки).
- Проектування — вибір типів черг, схеми маршрутизації, політик доступу.
- Реалізація — написання Terraform/IaC, налаштування інтеграцій, тестування.
- Тест — навантажувальне тестування, перевірка ідемпотентності та обробки помилок.
- Деплой — розгортання в production з post-mortem планом.
Строки
Базова налаштування SQS + Lambda integration + DLQ + CloudWatch алерти — 1 день. Повна конфігурація з SNS fan-out, filter policies, FIFO для ordered processing, шифрування KMS, Terraform-модуль — 2–3 дні. Точну оцінку дамо після аудиту вашої інфраструктури. Зв'яжіться, щоб обговорити деталі. Отримайте консультацію та попередній розрахунок.
Наші інженери мають багаторічний досвід з AWS та реалізували десятки проектів з чергами повідомлень. Поділіться вашою ситуацією — оцінимо проект та запропонуємо оптимальне рішення під ключ.
Amazon SQS Documentation: https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/welcome.html
