К содержимому

Телеметрия миллиона устройств: уроки архитектуры

2 минуты чтения #iot #архитектура

Обновлено:

Когда парк устройств переваливает за сотни тысяч, телеметрия перестаёт быть «просто очередью с метриками» и становится отдельной инженерной дисциплиной. Рассказываю, как устроен наш пайплайн от датчика до дашборда и какие три решения я бы принял иначе.

Форма пайплайна

Классическая цепочка выглядит так:

устройство → MQTT-брокер → ingest-шлюз → шина (Kafka)
          → потоковая агрегация → TSDB → API → дашборды

Каждое звено масштабируется независимо, и это главный принцип: пики нагрузки в IoT приходят волнами — массовое переподключение после сбоя сети оператора создаёт нагрузку в 50 раз выше средней.

Ошибка №1: доверять часам устройства

Дешёвый контроллер с дрейфующими часами присылает событие «из будущего» или из 1970 года — и агрегаты за час превращаются в мусор. Мы потеряли две недели, вычищая последствия.

Решение: на шлюзе каждое событие получает два времени — device_time и ingest_time. Все системные агрегаты строятся по времени приёма, время устройства остаётся для диагностики.

Ошибка №2: экономить на схеме данных

Первая версия протокола была «гибким JSON». Через полгода никто не мог сказать, какие поля реально присылают устройства с прошивкой двухлетней давности. Миграция на строгую схему (Protobuf + реестр схем с проверкой совместимости) заняла месяц — тот самый месяц из заголовка.

Ошибка №3: один storage для всех вопросов

Мы пытались отвечать и на «что с устройством прямо сейчас», и на «покажи тренд за год» из одной базы. Не работает: это разные паттерны доступа. Сейчас у нас горячий слой (последнее состояние, key-value), тёплый (90 дней сырых событий, TSDB) и холодный (паркет в объектном хранилище).

Что сработало хорошо

  • Backpressure с самого начала. Шлюз умеет отвечать устройствам «приходи позже» — это спасало нас трижды.
  • Симулятор парка. Генератор нагрузки, изображающий миллион устройств с реалистичными сбоями, окупился за первый же нагрузочный тест.
  • Бюджет кардинальности. Каждый новый тег в метриках проходит ревью: неконтролируемая кардинальность — тихий убийца TSDB.

Если выносить один урок: в IoT-телеметрии самое дорогое — не хранение и не трафик, а исправление данных задним числом. Всё, что защищает корректность данных на входе, окупается многократно.