Настройка AWS SQS / SNS для очередей и уведомлений
Отметим: когда очередь сообщений настроена неправильно, потери данных и дублирование становятся рутиной. На одном проекте Standard очередь с VisibilityTimeout 30 секунд обрабатывала видео по 5 минут — сообщение перечитывалось 10 раз, забивая логами и увеличивая стоимость в 3 раза. Мы исправляем такие конфигурации уже более пяти лет: проектируем SQS и SNS так, чтобы backlog не рос, а сообщения доставлялись ровно один раз.
Какие проблемы решаем?
Почему Standard или FIFO?
Standard Queue — at-least-once, порядок не гарантирован, throughput почти неограничен. Подходит для email, обработки изображений, индексации. Дублирование возможно — потребитель должен быть идемпотентным.
FIFO Queue — exactly-once, порядок внутри Message Group. Throughput: 300 TPS без batching, 3000 TPS с batching (batch size 10). Имя заканчивается на .fifo. Нужен MessageGroupId при отправке. Не используйте FIFO там, где достаточно Standard — это лишние ограничения. На практике Standard в 2 раза быстрее FIFO при одинаковой нагрузке на CPU.
| Параметр | Standard | FIFO |
|---|---|---|
| Доставка | at-least-once | exactly-once |
| Порядок | не гарантирован | гарантирован внутри группы |
| Throughput | неограничен | 300/3000 TPS |
| Дубликаты | возможны | исключены |
Как избежать дублирования через VisibilityTimeout?
После ReceiveMessage сообщение скрыто на VisibilityTimeout (по умолчанию 30 с). Если потребитель не вызвал DeleteMessage — оно становится видимым для повторной обработки. Типичная ошибка: таймаут меньше времени обработки. Например, обработка видео 5 минут, таймаут 30 с — задача запускается десятки раз параллельно. Правило: таймаут ≥ max(время обработки) * 1.5. Для непредсказуемых задач используйте ChangeMessageVisibility для продления.
Long Polling (WaitTimeSeconds: 20) обязателен. Short polling проверяет только часть серверов — пустой ответ при непустой очереди. Согласно документации AWS, Long Polling снижает количество API-вызовов до 30–40%.
Как настроить Dead-Letter Queue?
DLQ — отдельная очередь для сообщений после N неудачных попыток. maxReceiveCount = 3–5. Без DLQ сломанное сообщение будет бесконечно крутиться в очереди, блокируя FIFO или тратя ресурсы. Dead-Letter Queue обязательно мониторить: CloudWatch Alarm на ApproximateNumberOfMessagesVisible > 0 — сигнал о проблемах в потребителях. Получите консультацию по настройке DLQ у наших инженеров.
Как работает Long Polling и зачем его включать?
Long Polling уменьшает задержку и количество пустых ответов. При WaitTimeSeconds = 20 запрос висит до 20 секунд, пока не появится сообщение. Это снижает нагрузку на сеть и стоимость API-вызовов. Включить можно через консоль или SDK — QueueAttributeName: 'ReceiveMessageWaitTimeSeconds'. Без Long Polling пустые ответы могут составлять до 90% запросов — лишние расходы.
Fan-out через SNS: рассылка событий нескольким потребителям
SNS топик → несколько SQS очередей: одно событие order.created параллельно обрабатывается billing, notification, inventory. Каждый сервис — в своём темпе. Важно: Access Policy SQS должна разрешать sns:SendMessage. Message Filtering — подписчик получает только нужные события, например, по региону. Это снижает нагрузку без лишнего кода.
{
"FilterPolicy": {
"event_type": ["order.created", "order.cancelled"],
"priority": [{"numeric": [">=", 5]}]
}
}Lambda как потребитель SQS
Event Source Mapping управляет polling и масштабированием. Максимальный batch size: 10000 для Standard, 10 для FIFO. ReportBatchItemFailures — используйте всегда. При ошибке одного сообщения возвращаются только неудачные, остальные не дублируются.
def handler(event, context):
failed_items = []
for record in event['Records']:
try:
process(record['body'])
except Exception:
failed_items.append({"itemIdentifier": record['messageId']})
return {"batchItemFailures": failed_items}Мониторинг и типичные метрики
| Метрика | Алерт | Что значит |
|---|---|---|
ApproximateAgeOfOldestMessage | > max TTL * 0.7 | Потребитель не справляется |
ApproximateNumberOfMessagesNotVisible | Резкий рост | Потребители взяли сообщения, но не обрабатывают |
NumberOfMessagesSent vs Deleted | Divergence | Backlog накапливается |
Процесс работы
- Аналитика: изучаем вашу текущую архитектуру, нагрузку, SLA. Выявляем узкие места: дублирование, потери, задержки.
- Проектирование: выбираем типы очередей, параметры (VisibilityTimeout, Long Polling), проектируем DLQ и Fan-out.
- Реализация: настройка IAM-политик, развертывание через Terraform или CloudFormation, интеграция с Lambda и EventBridge.
- Тестирование: нагрузочные тесты, проверка отказоустойчивости, сценарии ошибок.
- Деплой и мониторинг: развертывание, настройка CloudWatch алертов, дашбордов.
Основные шаги настройки SQS и SNS
1. Проверить, какой тип очереди нужен: Standard или FIFO. 2. Определить VisibilityTimeout: замерить максимальное время обработки, умножить на 1.5. 3. Создать DLQ с maxReceiveCount = 3. 4. Включить Long Polling (WaitTimeSeconds = 20). 5. Настроить IAM-роли: разрешить SNS писать в SQS, Lambda читать из SQS. 6. Протестировать сценарий ошибки — сообщение должно уйти в DLQ. 7. Настроить CloudWatch алерты на возраст сообщений и размер DLQ.Что входит в работу
- Аудит текущей событийной архитектуры
- Проектирование SQS/SNS с учётом нагрузок и гарантий
- Настройка DLQ, Long Polling, IAM-политик
- Интеграция с Lambda, EventBridge, CloudWatch
- Мониторинг и алерты (CloudWatch, SNS->Slack/PagerDuty)
- Документация и обучение команды
- Поддержка в течение 30 дней после сдачи
Сроки и стоимость
Базовая настройка SQS + SNS с Fan-out — 1–2 дня. Сложная event-driven архитектура с фильтрацией, DLQ, Lambda и мониторингом — 3–5 дней. Стоимость рассчитывается индивидуально — напишите нам для оценки. Получите консультацию и конфигурацию за 1 день.
Наши инженеры имеют многолетний опыт и сертификацию AWS Solutions Architect. SLA по инцидентам — 99.9%. Свяжитесь с нами, чтобы оценить ваш проект.
