Продолжаю цикл из трех статей об облачном умном доме.

В предыдущей статье было рассмотрено оборудование для очувствления умного дома, а также алгоритмы преобразования сенсорных данных в управляющие команды для исполнительных устройств. Основным компонентом умного дома является контроллер, который большую часть времени работает автономно в соответствии с логикой, заложенной на этапе настройки. Различные устройства (IP-камеры, датчики, исполнительные устройства) подключаются к контроллеру, который пересылает данные, полученные с этих утройств, в облако.

Теперь поговорим об архитектуре облачного сервиса для хранения и обработки информации с датчиков и камер.

Преимущества облачного сервиса

Облачный сервис умного дома предлагает простой, гибкий и недорогой способ хранения и доступа к данным, полученным от устройств умного дома. Пользователю облачного сервиса не нужно беспокоиться о сохранности своих данных. Возможности многопроцессорного медиасервера, оснащенного дисковой корзиной с RAID-массивом из нескольких 10 — 12 ТБ дисков, намного превосходят по емкости SD- или Flash-карту внутри контроллера умного дома. Кроме того, карты памяти ненадежны, так как имеют ограниченное число циклов перезаписи и часто выходят из строя. Глубина хранения данных в облаке определяется тарифом пользователя и легко настраивается в его личном кабинете.

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

Данные в облаке удобно не только хранить, но и обрабатывать, предоставляя пользователю статистику за различные периоды времени. Ниже будет рассмотрен пример вычисления средней температуры в помещении за неделю на основе измерений мультисенсора.

Архитектура облачного сервиса

В предыдущей статье шла речь о контроллере умного дома, который устанавливается на стороне пользователя и взаимодействует с облачным сервисом по нескольким протоколам:

• MQTT используется для обмена JSON-сообщениями между контроллером и сервером бизнес-логики;
• HTTP для получения IP-адреса наименее загруженного медиасервера от балансировщика нагрузки кластера медиасерверов;
• RTMP для передачи потока H.264 + AAC на медиасервер.

Теперь рассмотрим облачный сервис умного дома — основные компоненты, из которых он состоит, и как происходит взаимодействие с контроллером умного дома.


(кликните на картинку, чтобы открыть в большем разрешении)

Сервер бизнес-логики является ключевым элементом во всей схеме информационного обмена внутри облачного сервиса. Его основное назначение — управление различными серверными подсистемами посредством RESTful API интерфейсов. Он реализует логику работы облачного сервиса на основе модели пользователя: запись видеоархива и измерений датчиков в зависимости от выбранного тарифа, взаимодействие между пользователем и контроллером умного дома итд.

Брокер MQTT необходим для обмена JSON-сообщениями между контроллерами умного дома, установленными на клиентской стороне, и сервером бизнес-логики. Клиенты подписываются на топики внутри брокера, которые служат каналами передачи сообщений. В качестве MQTT-брокера используется Eclipse Mosquitto.

Кластер медиасерверов — это распределенная система хранения, обработки, поиска и воспроизведения видеоинформации для IP-камер облачного умного дома. Специальный балансировщик нагрузки собирает информацию о текущей производительности каждого сервера в кластере, вычисляет наименее загруженный и сообщает его IP-адрес контроллеру умного дома, который передает на него видео с камер.

Облачная база данных необходима для хранения модели пользователя облачного сервиса, конфигурации и текущего состояния его оборудования, а также метаинформации о записях видеоархива. В качестве реализации облачной БД используется СУБД MySQL.

Сенсорная база данных — это нереляционная NoSQL база данных. В ней хранятся события и измерения датчиков умного дома, упорядоченные по времени. Применение СУБД InfluxDB, оптимизированной для работы с данными такого типа, значительно повышает производительность облачного сервиса.

Бэкенд клиентского приложения — это серверное приложение, главная функция которого — предоставление данных, полученных из облачной и сенсорной БД, в удобном формате для последующего отображения клиентским приложением на устройстве пользователя. Также бэкенд формирует команды управления в JSON-формате для контроллера умного дома. Бэкенд разработан на основе PHP-фреймворка Laravel. Более подробно он будет рассмотрен в следующей статье, посвященной клиентскому приложению для взаимодействия с облачным умным домом.

Провайдер Push-уведомлений доставляет сообщения о событиях умного дома на мобильное устройство пользователя, чтобы тот мог оперативно вмешаться в ситуацию (например, при протечке воды или появлении задымления вызвать соответствующие службы реагирования). В качестве провайдера Push-уведомлений был выбран сервис OneSignal, который имеет удобный RESTful API интерфейс и функцию идентификации мобильных устройств, необходимую для корректной работы уведомлений внутри личного кабинета пользователя.

Сервер бизнес-логики

Как уже было сказано ранее, сервер бизнес-логики — ключевой компонент облачного умного дома. Основываясь на модели пользователя (информационном описании пользователя системы, включающем в себя системные, персональные, финансовые и логические признаки), он управляет разнообразными сервисами внутри облака, которые имеют различную реализацию и функциональное назначение и связываются друг с другом посредством RESTful API интерфейсов.



Модуль бизнес-логики внутри сервера отвечает за выполнение следующих операций:

1. управление хранением измерений датчиков и событий детекторов движения с IP-камер умного дома внутри сенсорной БД;
2. управление записью медиапотока IP-камеры, транслируемого контроллером умного дома, в архив медиасервера (постоянная / по детектору движения);
3. трансляция команд от клиентского приложения в контроллер умного дома;
4. трансляция конфигурации контроллера умного дома (подключенных устройств, правил продукционной логики, определяемых пользователем);
5. отправка Push-уведомлений о состоянии контроллера умного дома и подключенных устройств в клиентское приложение.

Особенностью работы сервера бизнес-логики является межпроцессное взаимодействие с удаленными приложениями, выполняющимися на нескольких серверах в сети Интернет. Большую часть времени приложение сервера бизнес-логики находится в состоянии ожидания на блокировках ввода-вывода, поэтому оно разработано на основе многопоточной архитектуры и состоит из набора конечных подзадач.

Для обеспечения максимальной эффективности работы внутренняя реализация сервера бизнес-логики должна быть наиболее простой (принцип KISS). Так как модель пользователя полностью детерминирована и не содержит изменяющихся связей между признаками, то нет и необходимости в гибком механизме логического вывода (как в контроллере умного дома, где логика работы настраивается пользователем). Поэтому работа модуля бизнес-логики внутри сервера может быть описана обычной алгоритмической блок-схемой с условными переходами.


(кликните на картинку, чтобы открыть в большем разрешении)

Сразу после запуска сервер бизнес-логики переходит в состояние ожидания сообщений по протоколам MQTT (от контроллеров умного дома) и HTTP (от бэкенда клиентского приложения). В случае, если сообщение приходит по протоколу HTTP, то это означает, что пользователь взаимодействует с клиентским приложением и отправляет команды контроллеру умного дома или обновляет его конфигурацию. Чтобы сообщение от клиента попало в контроллер умного дома, оно транслируется сервером бизнес-логики в соответствующий топик MQTT-брокера, на который подписан контроллер (подзадача SendGatewayMessage).

На стадии инициализации контроллер умного дома ожидает, когда пользователь зарегистрирует его в личном кабинете. Поэтому выполняется подзадача CheckGatewayExistance, которая проверяет соответствующий статус в облачной БД MySQL. Для регистрации в личном кабинете контроллер отправляет свою полную конфигурацию серверу бизнес-логики, а тот, в свою очередь, транслирует ее бекенду клиентского приложения (подзадача SendBackend), который создает и обновляет конфигурационные записи в облачной и сенсорной базах данных.

Когда контроллер умного дома успешно зарегистрирован в личном кабинете пользователя, то сервер бизнес-логики загружает модель пользователя из облачной БД в свою оперативную память и начинает обрабатывать сообщения от IP-камер и датчиков Z-Wave в соответствии со следующим алгоритмом бизнес-логики.

JSON-сообщение от Z-Wave датчика с информационными полями:

{
	"vendor": "*****",
	"version": "3.0.0",
	"timestampMs": "1571754749561",
	"clientType": "gateway",
	"deviceId": "c8e8de37-d301-45f4-ba01-************",
	"deviceType": "sensor",
	"protocol": "zwave",
	"messageType": "sensorData",
	"homeId": "0xefa0cfa7",
	"nodeId": "19",
	"sensorType": "SENSOR MULTILEVEL",
	"label": "Temperature",
	"sensorData": "26.1",
	"units": "C",
	"gatewayId": "6774f85a-0a5b-4059-9b68-************"
}

Когда по протоколу MQTT приходит сообщение от датчика Z-Wave, то выполняются следующие подзадачи:

• StoreSensorDataMySQL обновляет (UPDATE) существующую запись в облачной БД MySQL, где хранится информация о текущем состоянии и измерениях с датчика. Это необходимо для клиентского приложения, отображающего для пользователя текущее состояние умного дома;
• StoreSensorDataInfluxDB добавляет (INSERT) новую запись в сенсорную БД InfluxDB, где хранится история измерений с датчика. Эта информация используется при расчете статистических данных за различные периоды времени (например, энергопотребление за день, месяц или год) и отображении в клиентском приложении в виде графиков и таблиц;
• SendPushNotification формирует JSON-сообщение, содержащее временную метку, название датчика, текстовое описание события, идентификатор смартфона пользователя, с которым тот зашел в личный кабинет, внутренний идентификатор приложения в системе провайдера OneSignal. Далее, это сообщение отправляется провайдеру Push-уведомлений через RESTful API https://onesignal.com/api/v1/notifications, который доставляет его на смартфон пользователя.

Пример JSON-сообщения от IP-камеры с информационными полями:

{
	"vendor": "*****",
	"version": "3.0.0",
	"timestampMs": "1571753150317",
	"clientType": "gateway",
	"deviceId": "1616453d-30cd-44b7-9bf0-************",
	"deviceType": "camera",
	"protocol": "onvif",
	"messageType": "deviceState",
	"deviceState": "streamingOn",
	"mediaserverIp": "***.***.***.***",
	"applicationName": "rtp-live-iot",
	"gatewayId": "6774f85a-0a5b-4059-9b68-************"
}

Когда по протоколу MQTT приходит сообщение от IP-камеры, то сервер бизнес-логики извлекает его тип из поля messageType. В зависимости от значения этого поля выполняются следующие действия:

• «messageType»: «deviceState» — сообщение содержит информацию об изменении состояния IP-камеры. Выполняется подзадача UpdateCameraState, обновляющая информацию в облачной БД. Если при этом поле deviceState принимает значения streamingOn или streamingOff (IP-камера отправляет/останавливает поток данных на медиасервер), то выполняется подзадача RecordMediaStream, формирующая с учетом модели пользователя команду для включения/отключения режима архивной записи и отправляющая ее на медиасервер;
• «messageType»: «sensorData» — информация о срабатывании детектора движения на IP-камере. Если в модели пользователя режим записи в архив установлен как «по детектору движения», то выполняется подзадача RecordMediaStream. Далее выполняются подзадачи StoreSensorDataInfluxDB (сохранение истории срабатывания детектора в сенсорной БД) и SendPushNotification (рассылка Push-уведомлений через провайдера);
• «messageType»: «preview» — сообщение содержит кадр уменьшенного изображения с IP-камеры, который периодически пересылается в облако. Подзадача StorePreview сохраняет его в облачной БД. Далее он используется в клиентском приложении при отображении списка камер;
• «messageType»: «command» — команда, посылаемая контроллером умного дома при изменении его настроек пользователем через Web-интерфейс. Выполняется подзадача RecordMediaStream, которая в зависимости от модели пользователя включает/выключает режим записи на медиасервере.

(кликните на картинку, чтобы открыть в большем разрешении)

В результате работы модуля бизнес-логики формируется очередь задач (task queue) — последовательность минимальных участков кода, выполняющихся независимо друг от друга. Очередь задач передается на исполнение пулу потоков (thread pool), который распределяет задачи по свободным ядрам центрального процессора. Когда в процессе исполнения возникает блокировка ввода-вывода, то поток приостанавливается, переходя в состояние ожидания, и освобождает ядро центрального процессора, что позволяет пулу потоков начать незамедлительное выполнение следующей задачи из очереди. В момент, когда снимается блокировка ввода-вывода, заблокированный поток меняет свое состояние на рабочее и продолжает исполнение как только освободится одно из ядер центрального процессора.

Таким образом, благодаря декомпозиции задачи бизнес-логики на множество отдельных подзадач, выполняющихся одновременно, повышается производительность сервера бизнес-логики. Масштабирование системы достигается путем увеличения количества ядер центрального процессора и наращиванием количества серверов бизнес-логики в системе.

Приложение сервера бизнес-логики разработано на языке С++ и запускается как сервис systemd операционной системы Linux Debian Sarge. Для дополнительного контроля работоспособности используется система мониторинга ресурсов monit, перезапускающая сервис при возникновении проблем с производительностью.

В настоящее время в облачном сервисе работает один сервер бизнес-логики, запущенный на виртуальной машине Яндекс.Облако. Параметры виртуальной машины — 4 ядра vCPU c гарантированной долей 20%, 2 GB RAM, 100 GB HDD. По расчетам данной производительности достаточно для обработки сообщений от ~ 1000 контроллеров умного дома с 3 IP-камерами и 5 датчиками Z-Wave каждый (в процессе эксплуатации системы расчеты будут уточняться).

Медиасервер

Медиасервер — это выделенный сервер (dedicated server), на котором установлено специальное программное обеспечение для:

• получения потоков видео- и аудиоданных от устройств-энкодеров по специализированным сетевым протоколам;
• хранения данных в виде файлов архива в своей файловой системе;
• трансляции информации из файлов архива в стандартном потоковом формате для воспроизведения на клиентских устройствах.

В качестве медиасервера в системе облачного умного дома используется Wowza Streaming Engine 4.7.2 с дополнительными модулями, разработанными на языке Java, для записи потоковых данных в файловый архив и для работы с облачной БД.


(кликните на картинку, чтобы открыть в большем разрешении)

Поток медиаданных от контроллера умного дома в формате RTMP поступает в медиасервер и выравнивается по временным меткам в jitter-буфере. Это необходимо для компенсации влияния задержек сетевых пакетов при передаче потока данных по сети Интернет.

Для записи видеопотока в файловую систему медиасервера в виде файла MP4 сервер бизнес-логики отправляет на медиасервер следующую команду через RESTful HTTP API:

http://<mediaserverIp>:<port>/v2/servers/_defaultServer_/vhosts/_defaultVHost_/applications/rtp-live-iot/instances/_definst_/streamrecorders/1616453d-30cd-44b7-9bf0-************
{
	"instanceName": "_definst_",
	"fileVersionDelegateName": "CustomFileVersionDelegate",
	"serverName": "",
	"recorderName": "1616453d-30cd-44b7-9bf0-************",
	"segmentSchedule": "",
	"outputPath": "",
	"currentFile": "",
	"applicationName": "rtp-live-iot",
	"fileTemplate": "",
	"segmentationType": "SegmentByDuration",
	"fileFormat": "MP4",
	"recorderState": "",
	"option": "",
	"currentSize": "0",
	"segmentSize": "0",
	"segmentDuration": "1800000",
	"backBufferTime": "0",
	"currentDuration": "0",
	"startOnKeyFrame": "true",
	"recordData": "false",
	"moveFirstVideoFrameToZero": "true",
	"defaultRecorder": "false",
	"splitOnTcDiscontinuity": "false"
}

В поле recorderName указывается имя видеопотока (идентификатор IP-камеры на контроллере умного дома), в поле fileVersionDelegateName — имя унаследованного класса для определения пути к папке и имени файла. Код класса на языке Java приведен в следующем листинге:

import java.io.File;
import java.util.Calendar;
import java.util.TimeZone;

import com.wowza.wms.livestreamrecord.manager.IStreamRecorder;
import com.wowza.wms.livestreamrecord.manager.IStreamRecorderFileVersionDelegate;
import com.wowza.wms.logging.WMSLoggerFactory;

public class CustomFileVersionDelegate implements IStreamRecorderFileVersionDelegate
{
    @Override
    public String getFilename(IStreamRecorder recorder)
    {
        String	sDisk = GetDisk();
        if(sDisk == null)
        {
            WMSLoggerFactory.getLogger(null).error("CustomFileVersionDelegate::getFilename(): No drive chosen");
            return null;
        }
	
        String sStreamName = recorder.getStreamName();
        int nCameraId = Integer.parseUnsignedInt(ServiceQueries.GetCameraId(sStreamName));
	
        TimeZone tz = TimeZone.getTimeZone("Europe/Moscow");
        Calendar now = Calendar.getInstance(tz);

        String sDirPath =
                ServerParams.m_sServerContentPath +
                "/" + sDisk +
                "/" + Integer.toString(nCameraId / 200) +
                "/" + sStreamName +
                "/" + String.format("%1$tY/%1$tm/%1$td", now);

        String sFullFilePath =
                sDirPath +
                "/" + sStreamName +
                "_" + String.format("%1$tH_%1$tM_%1$tS", now) +
                ".mp4";

        File dirs = new File(sDirPath);
        dirs.setExecutable(true);
        dirs.setWritable(true);
        dirs.mkdirs();
	
        WMSLoggerFactory.getLogger(null).info(
                "CustomFileVersionDelegate::getFilename(): Filename created: " + sFullFilePath);
		
        return sFullFilePath;
    }
}

В классе CustomFileVersionDelegate перегружена виртуальная функция getFilename базового класса IStreamRecorderFileVersionDelegate, которая вызывается медиасервером перед началом записи потока в файл. Функция создает папку на диске с путем sDirPath и возвращает полный путь к файлу sFullFilePath.

Так как объем медиаданных очень велик, фаловая система включает в себя несколько физических дисков большого объема (8 — 12 ТБ), смонтированных как поддиректории. В качестве целевого диска при записи выбирается диск с наибольшим количеством свободного места. Для оптимальной работы файловой системы при доступе к файлу путь к целевой папке формируется следующим образом:

/content/<diskId>/<cameraIdDivideBy200>/<streamUuid>/<year>/<month>/<day>/

где diskId — идентификатор диска (смонтированная папка),
cameraIdDivideBy200 — результат целочисленного деления идентификатора камеры на 200,
streamUuid — идентификатор медиапотока,
year, month, day — год, месяц и день записи соответственно.

Это позволяет избежать большого количества подпапок внутри одной папки и, соответственно, драматического падения производительности всей файловой системы при увеличении количества IP-камер в облачных умных домах.

Информация об IP-адресе медиасервера, пути к файлу с медиаданными, времени начала и конца записи в файл сохраняется в облачной БД и далее используется клиентским приложением для отображения временной шкалы архива, на которой можно выбрать и воспроизвести видеозапись.

Чтобы получить видеопоток, фронтенд клиентского приложения обращается к медиасерверу, посылая следующие команды по протоколу HTTP. Для «живого» видеопотока:

https://<mediaserverIp>:<port>/rtp-live-iot/<streamUuid>/playlist.m3u8

Для архивного видеопотока:

https://<mediaserverIp>:<port>/vod/_definst_/mp4:<diskId>/<cameraIdDivideBy200>/<streamUuid>/<year>/<month>/<day>/<fileName>/playlist.m3u8?wowzaplaystart=<offsetMs>&wowzaplayduration=<durationMs>

где fileName — имя архивного файла на диске,
offsetMs — смещение воспроизведения относительно начала файла в миллисекундах,
durationMs — продолжительность воспроизведения в миллисекундах.

Медиасервер отправляет поток в формате HLS, который позволяет отображать видео H.264+AAC во всех современных браузерах и мобильных устройствах с операционными системами iOS и Android. Пакетайзер HLS кодирует поток в виде отдельных чанков и пересылает по протоколу HTTP как ответ на запрос от мобильного приложения.

Для оптимизации затрат на хранение и доступа к архивным файлам медиасервер облачного умного дома разработан на аппаратной платформе Supermicro CSE-825TQ, motherboard X8DT6, 2xCPU Intel Xeon E5645 2.4 GHz, 32 GB RAM, 44 TB HDD Adaptec AAC-RAID. Медиасервер устанавливается как выделенный сервер на хостинговой площадке и подключается к Интернет-каналу с гарантированной шириной 400 Мбит/с. Производительности одного медиасервера достаточно для обработки медиапотоков с ~400 IP-камер с кодеком H.264, разрешением кадра 720p и битрейтом 1 Мбит/с.



Соответственно, чтобы иметь возможность обрабатывать потоки с 1000 IP-камер, необходимо установить 3 медиасервера и равномерно распределить нагрузку между ними. Для этого используется балансировщик нагрузки (load balancer), который подключается к медиасерверу Wowza Streaming Engine как отдельный плагин Dynamic Load Balancing AddOn. При этом различают, собственно, балансировщик нагрузки (или origin server), который периодически получает значения метрик производительности от конечных медиасерверов (или edge servers) и на основе этой информации находит наименее загруженный сервер в кластере.

Контроллер умного дома обращается к балансировщику по протоколу HTTP и в ответ получает IP-адрес этого сервера, на который контроллер передает медиапоток с IP-камеры по протоколу RTMP. В метрику производительности входит количество установленных соединений с источниками и потребителями медиапотоков и текущая пропускная способность Интернет-канала на сервере. В настройках балансировщика можно также указать выбор edge-сервера с учетом его геопространственного положения, что позволяет размещать серверы в разных городах и странах для создания распределенной сети доставки контента CDN.

Сенсорная база данных

Как упоминалось ранее в предыдущей статье, показания датчиков Z-Wave, а также текущее состояние и события IP-камер пересылаются в JSON-формате контроллером умного дома в облако по протоколу MQTT. Сервер бизнес-логики декодирует эти сообщения и выполняет подзадачу StoreSensorDataInfluxDB, которая передает данные в сенсорную БД по протоколу HTTP.


(кликните на картинку, чтобы открыть в большем разрешении)

Сенсорная БД облачного умного дома разработана на основе InfluxDB 1.7.x — СУБД с открытым исходным кодом для работы с временными последовательностями (time series), которая используется во многих проектах Интернета Вещей для хранения данных с датчиков и аналитики. Запросы к сенсорной БД формируются на языке InfluxQL аналогичном традиционному SQL.

Время хранения данных в облачном умном доме определяется выбранным тарифом согласно модели пользователя. Из-за существенной разницы в объеме видеоданных и данных с датчиков время их хранения будет отличаться. Размер видеоархива измеряется в сутках (7, 14, 30 суток на разных тарифах), а размер архива датчиков — в годах (3, 5, 7 лет соответственно). Поэтому для каждого контроллера умного дома при его регистрации в личном кабинете пользователя внутри сенсорной БД создаются 2 отдельных БД с различными политиками хранения (retention policy):

CREATE DATABASE "gateway_6774f85a_0a5b_4059_9b68_************_cameras" WITH DURATION 720h SHARD DURATION 1h;
CREATE DATABASE "gateway_6774f85a_0a5b_4059_9b68_************_sensors" WITH DURATION 61320h SHARD DURATION 24h;

За создание, редактирование и удаление БД внутри сенсорной БД отвечает бэкенд клиентского приложения. Например, если пользователь облачного умного дома меняет тариф, то бекенд посылает следующие команды для внесения изменений в политику хранения:

ALTER RETENTION POLICY "autogen" ON "gateway_6774f85a_0a5b_4059_9b68_************_cameras" DURATION 168h SHARD DURATION 1h;

При удалении контроллера умного дома из личного кабинета пользователя бекенд удаляет соответствующие БД:

DROP DATABASE "gateway_6774f85a_0a5b_4059_9b68_************_cameras";
DROP DATABASE "gateway_6774f85a_0a5b_4059_9b68_************_sensors";

Сервер бизнес-логики при получении информационного сообщения от контроллера умного дома выполняет запрос на вставку данных в сенсорную БД:

INSERT device_20873eb0_dd5e_4213_a175_************,class=METER,label=Energy,units=kWh value_float=0.05 1572194550125;

Пример таблицы с данными от датчиков Z-Wave для одного контроллера умного дома:



Одна из самых полезных функций облачного дома — это вычисление статистики на основе полученных данных. Пользователю необходимо знать среднюю температуру в комнате или сколько электроэнергии он потратил за месяц.

Язык InfluxQL позволяет выполнять запросы с помощью аналитических функций. Например, для подсчета средней температуры за неделю необходимо выполнить следующий запрос:

SELECT MEAN("value_float") FROM device_63c660da_f0e8_4eca_8d5f_************ WHERE label = 'Temperature' AND time >= '2019-10-21T00:00:00.000Z' AND time <= '2019-10-27T23:59:59.999Z' GROUP BY time(1d) fill(null);

Результаты этого запроса приведены в таблице:



В следующей статье, целиком посвященной клиентскому приложению, будет подробно рассмотрено вычисление статистики по разным параметрам и построение таблиц и графиков на ее основе.

В системе облачного умного дома СУБД InfluxDB развернута на одной виртуальной машине Яндекс.Облако с параметрами: 4 ядра vCPU c гарантированной долей 20%, 2 GB RAM, 100 GB HDD. По расчетам данной конфигурации достаточно для хранения сенсорных данных от 3000 IP-камер и 5000 датчиков Z-Wave в течение 7 лет.

Заключение

В статье была рассмотрена архитектура облачного сервиса для умного дома, алгоритм работы сервера бизнес-логики, архитектура медиасервера для записи, хранения и воспроизведения потоков медиаданных с IP-камер, а также архитектура сенсорной БД для хранения и анализа данных с датчиков умного дома. Система облачного сервиса работает как на выделенных, так и на виртуальных серверах, для большей устойчивости расположенных на разных хостингах. В настоящее время система проходит опытную эксплуатацию.

Чем старше данные, хранящиеся в облаке, тем реже обращается к ним пользователь. В следующей версии облачного сервиса предполагается применить механизм прореживания (или передискретизации) данных с помощью InfluxDB Continuous Queries, чтобы уменьшить количество хранимых данных с помощью агрегирующих функций и, тем самым, увеличить емкость сенсорной БД.



Также в следующей версии облачного сервиса будет реализован кластер серверов бизнес-логики по принципу кластера медиасерверов, рассмотренному в этой статье. На рисунке показана архитектура такого кластера, где несколько edge-серверов (на каждом из которых установлен отдельный MQTT-брокер и ПО сервера бизнес-логики) пересылают метрики производительности на origin-сервер, вычисляющий IP-адрес наименее нагруженного сервера. Это позволит масштабировать систему в большем объеме и преодолеть существующее ограничение в 1000 умных домов.