Налаштування AWS SQS/SNS: черги, сповіщення, відмовостійкість

Налаштування AWS SQS / SNS для черг і сповіщень

Відзначимо: коли чергу повідомлень налаштовано неправильно, втрати даних і дублювання стають рутиною. На одному проекті Standard черга з VisibilityTimeout 30 секунд обробляла відео по 5 хвилин — повідомлення перечитувалося 10 разів, забиваючи логи і збільшуючи вартість у 3 рази. Ми виправляємо такі конфігурації вже понад 5 років: проектуємо SQS і SNS так, щоб backlog не зростав, а повідомлення доставлялися рівно один раз. Наші інженери мають 5+ років досвіду з AWS, виконали 50+ проектів з SQS/SNS, SLA за інцидентами — 99.9%.

Які проблеми вирішуємо?

Чому 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 може бути в 300 разів продуктивнішим (необмежений throughput проти 300 TPS).

Уникнення дублювання через VisibilityTimeout

Після ReceiveMessage повідомлення приховано на VisibilityTimeout (за замовчуванням 30 с). Якщо споживач не викликав DeleteMessage — воно стає видимим для повторної обробки. Типова помилка: тайм-аут менший за час обробки. Наприклад, обробка відео 5 хвилин, тайм-аут 30 с — задача запускається десятки разів паралельно. Правило: тайм-аут ≥ max(час обробки) * 1.5. Для непередбачуваних задач використовуйте ChangeMessageVisibility для продовження.

Long Polling (WaitTimeSeconds: 20) обов'язковий. Short polling перевіряє лише частину серверів — порожня відповідь при непорожній черзі. Згідно з документацією AWS, Long Polling знижує кількість API-викликів до 30–40%. При інтенсивному навантаженні це дає економію до $300 на місяць.

Налаштування Dead-Letter Queue

DLQ — окрема черга для повідомлень після N невдалих спроб. maxReceiveCount = 3–5. Без DLQ зламане повідомлення буде нескінченно крутитися в черзі, блокуючи FIFO або витрачаючи ресурси. Dead-Letter Queue обов'язково моніторити: CloudWatch Alarm на ApproximateNumberOfMessagesVisible > 0 — сигнал про проблеми в споживачах.

Принцип роботи Long Polling

Long Polling зменшує затримку і кількість порожніх відповідей. При WaitTimeSeconds = 20 запит висить до 20 секунд, поки не з'явиться повідомлення. Це знижує навантаження на мережу і вартість API-викликів. Увімкнути можна через консоль або SDK — QueueAttributeName: 'ReceiveMessageWaitTimeSeconds'. Без Long Polling порожні відповіді можуть становити до 90% запитів — зайві витрати. Порівняно з Short Polling, Long Polling зменшує кількість API-викликів до 70%.

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 і автомасштабуванням Lambda. Максимальний 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}

Моніторинг і типові метрики

Процес роботи

1. Аналітика: вивчаємо вашу поточну архітектуру, навантаження, SLA. Виявляємо вузькі місця: дублювання, втрати, затримки.
2. Проектування: обираємо типи черг, параметри (VisibilityTimeout, Long Polling), проектуємо DLQ і Fan-out.
3. Реалізація: налаштування IAM-політик, розгортання через Terraform або CloudFormation, інтеграція з Lambda і EventBridge.
4. Тестування: навантажувальні тести, перевірка відмовостійкості, сценарії помилок.
5. Деплой і моніторинг: розгортання, налаштування CloudWatch алертів, дашбордів.

Що входить до роботи

• Аудит поточної подійної архітектури
• Проектування SQS/SNS з урахуванням навантажень і гарантій
• Налаштування DLQ, Long Polling, IAM-політик
• Інтеграція з Lambda, EventBridge, CloudWatch
• Моніторинг і алерти (CloudWatch, SNS->Slack/PagerDuty)
• Документація і навчання команди
• Підтримка протягом 30 днів після здачі

Строки та вартість

Базове налаштування SQS + SNS з Fan-out — 1–2 дні, орієнтовна вартість від $500. Складна event-driven архітектура з фільтрацією, DLQ, Lambda і моніторингом — 3–5 днів, від $1500. Вартість розраховується індивідуально — напишіть нам для оцінки. Економія від використання Long Polling може становити до $300 на місяць.

Наші інженери мають 5+ років досвіду з AWS, виконали 50+ проектів з SQS/SNS, SLA за інцидентами — 99.9%. Зв'яжіться з нами, щоб оцінити ваш проект.