IoT Real-Time

Tesla отправляет 1 KB данных в секунду с каждого автомобиля. Умножьте на 5 миллионов машин - и получите задачу, где каждая ошибка в архитектуре стоит миллионы долларов в месяц.

• **AWS IoT Core** обслуживает более 1 млрд устройств глобально; принимает 500 000 сообщений/сек и гарантирует SLA 99.9% availability
• **Tesla** использует MQTT + AWS IoT для телеметрии всего флота; при OTA-обновлении прошивки 5 млн машин получают файлы поэтапно - по 100K автомобилей в час, чтобы не перегрузить CDN
• **Philips Hue Bridge** - edge-контроллер для до 50 умных ламп в доме: команды обрабатываются локально за 50 мс без интернета, синхронизация с облаком идёт в фоне
• **Siemens MindSphere** (промышленный IoT) обрабатывает телеметрию с 1.4 млн промышленных устройств; edge-фильтрация снижает cloud-трафик в 200 раз

Device Telemetry

Телеметрия устройств - это непрерывный поток данных от сенсоров к облаку: температура, давление, GPS-координаты, состояние батареи. Tesla Model 3 отправляет ~1 KB телеметрии каждую секунду через 4G, итого около 86 MB данных на автомобиль в день. AWS IoT Core принимает до 500 000 сообщений в секунду от 1+ млрд устройств глобально.

Стандартный протокол для IoT-телеметрии - MQTT (Message Queuing Telemetry Transport). Он разработан для устройств с ограниченными ресурсами: минимальный overhead заголовка 2 байта (у HTTP - 200+ байт). QoS уровни: 0 (at-most-once, fire-and-forget), 1 (at-least-once, с подтверждением), 2 (exactly-once, двухфазный handshake). Для battery-powered устройств используют QoS 0 чтобы не тратить ресурсы на ACK.

• **MQTT retain flag**: последнее сообщение сохраняется на брокере; новый подписчик сразу получает текущее состояние
• **Last Will Testament (LWT)**: при обрыве соединения брокер автоматически публикует заданное сообщение - удобно для детектирования offline
• **Payload compression**: MessagePack вместо JSON уменьшает payload до 40-60%; критично для GPRS с 9.6 kbps
• **Batching**: Tesla группирует показания в пакеты по 10-60 секунд для экономии трафика и батареи

IoT Commands

Командное управление устройствами - это обратный канал: от облака к устройству. Tesla может удалённо обновить ПО, открыть двери, изменить параметры климата - всё через command channel. Главная сложность: устройства часто offline (спящий режим, нет сети). AWS IoT Device Shadow решает это через концепцию «желаемого состояния» (desired) и «текущего состояния» (reported).

Паттерн Device Shadow решает проблему eventual consistency для IoT. Облако записывает "desired" и не ждёт устройство онлайн. При подключении устройство получает delta (разницу между desired и reported) и синхронизируется. Version number предотвращает конфликты при одновременных обновлениях. Google Cloud IoT Core и Azure IoT Hub реализуют аналогичный паттерн под названиями Device Twins.

1. Облако записывает desired state в Shadow: {"desired": {"fanSpeed": 3}}
2. Shadow вычисляет delta = desired - reported и публикует на delta-топик
3. Устройство (онлайн или при следующем пробуждении) получает delta
4. Устройство применяет команду и публикует новый reported state
5. Shadow обновляет version, delta исчезает при совпадении desired и reported

Edge Computing

Edge computing - обработка данных непосредственно на устройстве или шлюзе, без отправки в облако. Tesla Neural Network Autopilot обрабатывает видео с 8 камер (~2 Gbit/s сырых данных) прямо на FSD Computer в автомобиле. Отправлять такой объём в облако в реальном времени физически невозможно. В облако уходят только аннотированные события (~10 KB/мин).

AWS Greengrass - edge runtime для запуска Lambda-функций на локальном шлюзе. Позволяет выполнять ML-инференс, фильтровать данные и реагировать на события без интернет-соединения. Типичный паттерн: edge фильтрует 99% телеметрии (норма), отправляет в облако только аномалии. Это снижает стоимость AWS IoT Core ($1 за 1 млн сообщений) в 10-100 раз.

IoT at Scale

AWS IoT Core обслуживает более 1 миллиарда активных IoT-устройств. Масштабирование IoT имеет специфические bottleneck: не CPU и память, а количество persistent MQTT-соединений и fan-out сообщений. 100 000 устройств в одной группе получают broadcast - это 100 000 параллельных write операций через брокер.

Thundering herd - типичная проблема при масштабировании IoT: все устройства переподключаются одновременно после outage брокера. Решение - exponential backoff с jitter: каждое устройство ждёт random(0, min(cap, base * 2^attempt)) секунд перед переподключением. AWS рекомендует base=1с, cap=300с. Без jitter 1 млн устройств создают пик в 1 млн соединений в первую секунду.

• **Connection limit**: AWS IoT Core - 500 000 persistent соединений на endpoint по умолчанию
• **Message size**: MQTT payload до 128 KB; для firmware update используется S3 + pre-signed URL
• **Topic sharding**: разбить fleet на группы, использовать иерархические топики
• **Exponential backoff + jitter**: обязателен для reconnect логики каждого устройства
• **Fleet indexing**: AWS IoT позволяет строить запросы по fleet (все устройства с battery < 20%)

Итоги

• **MQTT** - стандарт IoT-телеметрии: 2-байтовый заголовок, QoS уровни 0/1/2, retain flag и LWT для детектирования offline-устройств
• **Device Shadow** (AWS) / Device Twin (Azure) - state-based паттерн для командного управления offline-устройствами: desired vs reported, delta при подключении
• **Edge computing** - фильтрация 99% данных на шлюзе, отправка в облако только аномалий; снижает стоимость и латентность реакции на критические события
• **Thundering herd** - главная проблема масштабирования; exponential backoff с jitter - обязательный паттерн в firmware каждого IoT-устройства

Связанные темы

IoT real-time пересекается с несколькими слоями архитектуры:

• Rate Limiting Real-Time — AWS IoT Core тарифицирует по числу сообщений; без rate limiting на edge один сломанный датчик может обнулить весь бюджет
• WebSocket Security — MQTT over WebSocket (порт 443) используется когда firewall блокирует порт 8883; те же паттерны аутентификации через TLS-сертификаты
• Live Dashboards — Grafana + InfluxDB - стандартный стек для визуализации IoT-телеметрии в реальном времени; aggregation windows определяют точность графиков

Вопросы для размышления

• Умный термостат на батарейке отправляет телеметрию раз в 5 минут. Как реализовать мгновенное управление (включить кондиционер) без постоянного MQTT-соединения?
• Edge-шлюз фильтрует аномалии и отправляет только 1% данных в облако. Как убедиться, что не пропускаются медленно развивающиеся аномалии (дрейф базовой температуры за недели)?
• 500 000 IoT-устройств прошивки нужно обновить в течение 24 часов. Как организовать rollout чтобы не перегрузить CDN и откатиться при обнаружении бага в новой версии?

Связанные уроки

• sd-09-message-queue