IoT/doc/sqs-integration.md

Интеграция IoT ↔ shared-sqs: состояние и рекомендации

Составлено 2026-08-16 на основе работ по сервису shared-sqs (SQS-совместимая очередь на платформе Nubes). IoT будет использовать shared-sqs так же, как сам shared-sqs использует managed-сервисы платформы.

1. Что такое shared-sqs (кратко)

• SQS-совместимая очередь (AWS API), Go, multi-tenant, форк GoAWS.
• Версия на проде: v0.1.35.
• Внешний endpoint: https://sqs.containerk8s.dev.nubes.ru (регион us-east-1).
• Внутренний endpoint (для подов в том же кластере Nubes, realm iot-naeel): http://containerk8s.f1ffb134-7d16-45bd-8bef-69f6ec8ab33c.svc.cluster.local:4100
• Реализовано: CreateQueue, GetQueueUrl, ListQueues, SendMessage(+Batch), ReceiveMessage, DeleteMessage(+Batch), ChangeMessageVisibility(+Batch), PurgeQueue, DeleteQueue, Get/SetQueueAttributes, TagQueue/Untag/List, FIFO (порядок + dedup 5 мин), Dead Letter Queues (RedrivePolicy).
• Лимиты: 50 очередей на тенанта, сообщение до 256 КБ, Receive 1–10 сообщений.

2. Что сделано и проверено (состояние на 16.08)

• Все тесты зелёные: api_test 22/22, sdk_test 15/15, FIFO/DLQ e2e PASS.
• План проверок выполнен полностью (таймауты сервера, рестарты, long-poll, CLI в нагрузке, память 2ч, граница лимита 50).
• Нагрузка: 168 591 операция без единой сервисной ошибки.
• Сравнение с Yandex YMQ: shared-sqs быстрее (p50 6–8мс из внутренней сети, 89–90мс из интернета против 60–62мс / 138–150мс у YMQ).

3. Известные проблемы ПЛАТФОРМЫ (не сервиса)

1. Таймауты каждые 31–33с на внешнем пути (интернет → шлюз Nubes): ~5.5% запросов не получают ответ 30с. Доказано серверным tcpdump: в момент сбоя запрос не доходит до пода; внутри кластера потерь нет (port-forward — 24977 раундов, 0 сбоев). Тикет в поддержку Nubes подготовлен.
2. MSS=1448 на шлюзе при MTU пода 1400/underlay 1450: тела >~1400 байт могут виснуть ~51с (PMTUD сломан).

4. Рекомендации по интеграции IoT → shared-sqs

1. Использовать AWS SDK (aws-sdk-go или boto3) с переопределением endpoint'а. Не писать свой HTTP-клиент.
2. Ходить по внутренней сети, если IoT на Nubes в том же кластере: внутренний URL из п.1 полностью обходит проблемный внешний шлюз — таймаутов 31–33с и MTU-проблем там нет. Это главная рекомендация.
3. Клиентские ретраи обязательны: retries ≥ 3, read_timeout ≥ 30с (для внешнего пути). При внутреннем пути достаточно дефолтов.
4. Размер сообщений: до ~1300 байт — безопасно всегда; большие тела — только после фикса MSS шлюзом, либо бить на части.
5. Receive: VisibilityTimeout ставьте с запасом на обработку (30с+); ChangeMessageVisibility(0) — мгновенный возврат в очередь; long-poll (WaitTimeSeconds) поддерживается.
6. FIFO: обязателен MessageGroupId; dedup-окно 5 минут; порядок гарантирован внутри группы.
7. DLQ: настраивается RedrivePolicy (deadLetterTargetArn, maxReceiveCount); ARN DLQ должен быть tenant-scoped (как в тестах).
8. Лимит: 50 очередей на тенанта — держать список очередей под контролем.
9. Мониторинг: /health отдаёт {"status":"ok","version":...}; метрики платформы — Grafana (как для остальных managed-сервисов).

5. Аутентификация

• Креды тенанта детерминированы: tenantID t-+sha256(email)[:8], AccessKey SSAK-+sha256(email)[:12], SecretKey sha256(email+":shared-sqs:secret-key:v1").
• IoT получит свой тенант/креды через консоль Nubes (как другие сервисы).

6. Что осталось до полного прода

• Отправить тикет Nubes (таймауты шлюза + MSS) — единственный блокер для интернет-клиентов. Для внутренней интеграции IoT блокеров нет.