Nail/IoT
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
master
IoT/doc/thinking/iot-sqs-handoff-2026-10-05.md
T

15 KiB
Raw Permalink Blame History

IoT ↔ SQS: сводка всех находок и мыслей (handoff для нового чата/репы)

Дата: 2026-10-05. Назначение: полностью самодостаточный документ — чтобы, открыв его в НОВОЙ репе или новом чате, можно было продолжить без чтения истории. Вся информация ниже взята из реального кода/доков репозитория IoT (/home/naeel/nubes/IoT), а НЕ из памяти и НЕ из чужих заметок.

0. КЛЮЧЕВОЙ РАЗВОРОТ: что в какой репе

Есть ДВА разных проекта, в ДВУХ разных репах:

Проект Репа Что делает Состояние
shared-sqs отдельная репа (SQS-service) SQS-совместимая очередь (AWS API, Go, форк GoAWS), multi-tenant ГОТОВ, работает на проде v0.1.35 (все тесты зелёные, нагрузка без ошибок)
IoT эта репа (/home/naeel/nubes/IoT) телеметрия устройств: MQTT → SQS → PostgreSQL → REST MVP, не production-ready (есть подтверждённые блокеры)

Зависимость: IoT потребляет shared-sqs как внешний сервис (очередь телеметрии iot-telemetry). shared-sqs от IoT не зависит.

Вывод о порядке (отвечая на вопрос «что сначала — SQS или IoT»):

  • shared-sqs фактически уже готов и работает раньше, чем IoT дотянет до production. Его «доделывать» не надо для старта работ по IoT.
  • Порядок работ по сути такой: SQS уже есть (работает) → теперь доработки IoT, который на него опирается.
  • Если планируется создавать оба «с нуля» — логический порядок архитектурно: сначала SQS, потом IoT (т.к. IoT от него зависит).

ВНИМАНИЕ про ветки IoT-репы (важно, легко запутаться):

  • Актуальный код IoT (монолит iot-service, internal/service/, internal/storage/iotpg/) лежит на ветке feature/replace-kafka-with-sqs. Имя ветки — ПЕРЕЖИТОК старой миграции Kafka→SQS (апрель 2026), к текущей задаче отношения не имеет. Не путать имя с сутью: это текущая ветка IoT.
  • Ветка master — СТАРАЯ, без монолита (там легаси: internal/api/, CRD, k8s-манифесты, deployments/, examples/, config/crd/). НЕ актуальна.
  • На master ошибочно закоммичены 3 файла документации (см. раздел 5).

1. Что такое текущий IoT (архитектура)

Монолит iot-service — один Go-бинарник с тремя ролями в одном процессе:

  1. REST API + MQTT auth/acl на порту :9090 (устройства хранятся в PostgreSQL);
  2. bridge — MQTT-подписка на EMQX → отправка в shared-SQS;
  3. consumer — чтение из shared-SQS (long-poll) → запись в per-tenant PostgreSQL.

Конвейер телеметрии:

устройство → wss → EMQX (authn+authz напрямую в PG) → бридж → shared-SQS
  → consumer → per-tenant PostgreSQL → REST API (/v1/namespaces/{ns}/iot/telemetry)

Стек:

  • Go 1.25, gorilla/mux, paho.mqtt.golang, aws-sdk-go-v2 (SQS), lib/pq.
  • EMQX 5.5.1 (образ naeel/iot-emqx), shared-SQS (SQS-совместимая очередь), PostgreSQL managed (per-tenant БД).
  • Модуль: gitea.services.ngcloud.ru/Nail/IoT.

Ключевые файлы актуального кода (на ветке feature):

  • cmd/iot-service/main.go — точка входа: config → PG → SQS → API + горутины bridge/consumer.
  • internal/service/config/config.go, defaults.go — env-конфигурация.
  • internal/service/api/router.go, middleware/auth.go — маршруты + JWT.
  • internal/service/api/handler/*.go — devices, mqtt_auth, telemetry, admin, sqsstats.
  • internal/service/store/*.go — устройства в PG (iot_devices).
  • internal/storage/iotpg/iot_telemetry_store.go — запись телеметрии (batch).
  • internal/service/bridge/*.go — bridge → SQS.
  • internal/service/consumer/*.go — SQS → PG.
  • internal/service/sqsclient/sqsclient.go — SQS-клиент (endpoint override).
  • emqx/emqx.conf — конфиг EMQX (auth/ACL — напрямую в PostgreSQL).

2. Как IoT использует shared-sqs (факты)

  • Внутренний endpoint shared-sqs (тот же кластер Nubes, realm iot-naeel): http://containerk8s.f1ffb134-7d16-45bd-8bef-69f6ec8ab33c.svc.cluster.local:4100 (вшит дефолтом в config/defaults.go).
  • Очередь: iot-telemetry, регион us-east-1.
  • Тенант IoT: t-fec713a719ad0b33; креды детерминированы из email: tenantID t-+sha256(email)[:8], AccessKey SSAK-+sha256(email)[:12], SecretKey sha256(email+":shared-sqs:secret-key:v1").
  • Лимиты shared-sqs: 50 очередей на тенанта, сообщение до 256 КБ, Receive 1–10.
  • В бридже: неблокирующий SQS-диспетчер (канал 10000 + 4 worker'а, ретраи 1/2/4с), дроп при переполнении буфера и при oversize >250 КБ.
  • В consumer: long-poll 20с, VisibilityTimeout 120с (в коде), backoff при сбое PG (1с→60с), DeleteMessage после обработки.

3. ПОДТВЕРЖДЁННЫЕ БЛОКЕРЫ IoT (для доработок)

Источник: два независимых анализа + ревью Opus + моя перепроверка построчно. Все — по КОДУ, с точными ссылками. Сгруппировано по приоритету.

P0 — компрометация/потеря данных или доступ к чужим данным

P0-1. Tenant-изоляция не работает.

  • internal/service/api/middleware/auth.go (validateJWT, ~стр. 62, 120): проверяет только наличие sub и (необязательно) exp, а sub НИКАК не сверяется с {namespace} из URL.
  • Обработчики берут namespace из пути (handler/devices.go:91, handler/telemetry.go:19) без сверки с токеном.
  • Итог: любой валидный токен читает/пишет ЛЮБОЙ namespace — горизонтальный доступ к чужим устройствам и телеметрии.

P0-2. Проверка подписи JWT необязательна.

  • auth.go (~стр. 70): при пустом JWT_HMAC_SECRET подпись НЕ проверяется — только структура токена. Токен подделывается вручную ({"sub":"x","exp":...}).
  • config/config.go (~стр. 118): дефолт секрета пустой, секрет не в списке required env.

P0-3. Пароли устройств в открытом виде.

  • store/open.go:21: mqtt_password TEXT — хранится открытым текстом.
  • handler/devices.go:189: пароль отдаётся повторно через GET /devices/{name}.
  • emqx/emqx.conf:46: password_hash_algorithm name=plain.
  • Компрометация БД = все пароли устройств + возможность выдать их повторно.

P0-7. Потеря телеметрии: SQS-удаление до фактической записи.

  • consumer/consumer.go:78: удаляет сообщение из SQS после processTelemetry==nil.
  • iotpg/iot_telemetry_store.go:356-376: InsertTelemetry при неполном батче кладёт строку В ПАМЯТЬ и возвращает nil (запись ещё не сделана).
  • iotpg/iot_telemetry_store.go:129-135 (flushAll): подменяет буфер на пустой ДО записи в PG, при ошибке — только логирует.
  • Итог: краш между «кладём в буфер» и «flush» → сообщение уже удалено из SQS, в PG не попало → безвозвратная потеря.

P0-8. Нет идемпотентности (дубли).

  • iot_telemetry таблица: id BIGSERIAL, без ключа дедупликации.
  • bridge/handler.go:19: envelope без message-id.
  • At-least-once SQS → молчаливые дубли при повторе сообщения.

P1 — важные риски эксплуатации

P1-4. Лишние HTTP-auth/ACL-эндпоинты.

  • router.go:50-51: /internal/mqtt/auth и /internal/mqtt/acl висят на публичном порту 9090 БЕЗ аутентификации.
  • Но EMQX ходит по PG-auth напрямую (emqx/emqx.conf, backend=postgresql), эти эндпоинты — НЕиспользуемый fallback. Рекомендация: удалить, а не защищать.
  • Риск: кто достучался до порта — перебирает пароли устройств и получает ACL.

P1-5. AUTH_TEST_MODE=true на проде.

  • Был включён для диагностики DevOps (HISTORY §38); любой Bearer-токен проходит.
  • Нужно выставить false + задать JWT_HMAC_SECRET.

P1-9. /health не отражает состояние.

  • router.go:72: healthHandler всегда {"status":"ok"}, не проверяет bridge/consumer/PG/SQS.
  • main.go: ошибки bridge.Run/consumer.Run только логируются; горутина завершается, а liveness остаётся зелёным.

P1-10. Дропы в бридже без метрик.

  • bridge/sender.go:73: дроп при переполнении RAM-очереди (10000).
  • bridge/sender.go:112: дроп после исчерпания ретраев.

P2 — обвязка/гигиена

P2-6. TLS. sslmode=require (без verify-full) к PG; EMQX verify=verify_none (emqx.conf:40).

P2-11/P2-12. Нет тестов и CI. *_test.go отсутствует; .github/workflows нет (в .github/ только правила).

P2-13. /metrics заявлен, но не зарегистрирован.

  • config/defaults.go:6: в комментарии упомянут /metrics, но роут в router.go НЕ создан. prometheus — только indirect dep. Rate-limiting нет.

P2-14. Легаси не вычищено.

  • Остались cmd/iot-operator, controllers/, internal/api/ (старый k8s-код), cmd/mqtt-bridge, cmd/sqs-consumer; k8s/controller-runtime в go.mod (~12 строк); бинарники в bin/, ws-probe/ws-probe.

P2-15. Дрейф доков.

  • doc/deployment-nubes-production.md — образы v0.1.2; Makefile — v0.1.13.
  • loadtests/README.md — visibility «30с» (в коде 120с), описывает уже исправленную блокировку MQTT-обработчика.

P2-16. emqx.conf: cookie = "iot-emqx-cookie-mvp" захардкожен.

ПЛАТФОРМА (вне нашего кода, но блокирует прод)

  1. wss-обрывы ~150с на внешнем шлюзе Nubes (детерминированно, доказано с 3 независимых точек: станция, Vultr; внутри кластера и с ВМ — чисто). Тикет Nubes подготовлен (doc/thinking/nubes-devops-report-2026-08-16.md).
  2. MSS/MTU-баг — плавающий обрыв ответов >~15–64 КБ (баг нестабилен по маршруту/времени). Обход в коде: offset-пагинация API, внутренний endpoint SQS.

4. Что уже ХОРОШО (не трогать без нужды)

  • Конвейер end-to-end работает и проверен на проде (HISTORY: baseline 2390/2390 без потерь/дублей, ACL-нарушения отсекаются, reconnect-storm чистый).
  • Уже исправлены (по итогам ревью 2026-08-16): асинхронный SQS-диспатчер, VisibilityTimeout 120с, backoff, graceful shutdown, batch-INSERT) — НЕ регрессировать это.
  • EMQX auth/ACL — напрямую в PostgreSQL, без зависимости от монолита.
  • MQTT-reconnect с повторной подпиской (OnConnectHandler).
  • Документация: деплой без kubectl, интеграция с SQS, 10 нагрузочных сценариев.

5. Что уже записано в этой репе (файлы документации)

  • doc/thinking/readiness-assessment-2026-10-05.md — два анализа (5/10 и 60–65%) + моё мнение.
  • doc/thinking/remediation-plan-2026-10-05.md — план доработок (4 трека, P0/P1/P2).
  • doc/thinking/opus-review-prompt.md — промпт для ревью (allowlist файлов).
  • ВНИМАНИЕ: эти 3 файла лежат в ветке master (коммит a4e8fd5, запушен), а НЕ на актуальной feature/replace-kafka-with-sqs, где живёт код. doc/sqs-integration.md, doc/deployment-nubes-production.md, HISTORY/ — на feature-ветке.

Backup-ветки (сохранение состояний):

  • backup/2026-08-17-feature-sqs (старая точка).
  • backup/2026-10-05-feature-sqs (сделана 2026-10-05, на 12db7d3).

6. Рекомендуемый порядок работ (по плану)

  1. P0-1 + P0-2 — tenant-граница (связать sub с namespace) + обязательная подпись JWT.
  2. P0-7 + P0-8 — доставка без потерь (ack только после успешного flush) + dedup (message-id).
  3. P0-5 — выключить AUTH_TEST_MODE.
  4. P0-3 + P1-4 — пароли (не отдавать повторно/хешировать) + удалить /internal/mqtt/*.
  5. P1-9 + P1-10 — честный /health + метрики дропов.
  6. P1-11 + P1-12 — Go-тесты + CI.
  7. P2 (гигиена: легаси, доки, cookie, TLS).
Reference in New Issue View Git Blame Copy Permalink