Інтеграція Google Cloud IoT у мобільний додаток

Розробники мобільних IoT-додатків на GCP часто стикаються з необхідністю забезпечити двосторонній зв'язок між сотнями пристроїв та мобільними клієнтами в реальному часі. Телеметрія з датчиків надходить з інтенсивністю до 1000 повідомлень на секунду, а затримка понад 500 мс робить систему непридатною для критичних сценаріїв. При цьому MQTT-брокер повинен аутентифікувати кожен пристрій без вбудовування секретів у клієнт. Google Cloud IoT Core спрощував задачу, але його відключення змусило шукати альтернативи. Ми реалізували гібридну архітектуру на EMQX, Cloud Pub/Sub та Firestore для 20+ проєктів з парком від 100 до 5000 пристроїв. Нижче — робочі схеми та конкретні конфігурації, перевірені в бою. Якщо вам потрібна надійна IoT-інфраструктура — отримайте консультацію. Наші інженери підготують архітектуру за 2 дні. Маємо 5 років досвіду та сертифікацію GCP.

Як інтегрувати Google Cloud IoT у мобільний додаток

Ключове завдання — забезпечити двосторонній зв'язок між пристроями та мобільним клієнтом з мінімальною затримкою. Рішення — гібридна архітектура на базі власного MQTT-брокера, Cloud Pub/Sub та Firestore. Нижче розберемо робочі схеми.

Проблеми, які вирішуємо

• Пристрої надсилають телеметрію (до 1000 повідомлень на секунду), але мобільний додаток не отримує її в реальному часі — затримка понад 2 секунди неприйнятна.
• Потрібен зворотний зв'язок: надіслати команду на пристрій (наприклад, увімкнути клапан) з підтвердженням виконання.
• Push-сповіщення про події не приходять або приходять із запізненням; критично для систем безпеки.
• Безпека: вбудовування Service Account ключів у клієнт неприпустиме — використовуємо JWT-токени Firebase Auth.
• Міграція з готового IoT Core — страх перед вендор-локом та складністю переходу.

Кожна проблема має готове рішення в GCP-стеку. Ми використовуємо Firestore як єдиний шлюз між пристроями та мобільним клієнтом, а MQTT-брокер — для збору телеметрії.

Альтернативи Google Cloud IoT Core

Google рекомендує кілька шляхів:

1. MQTT-міст через Cloud Pub/Sub напряму з власним брокером (EMQX, HiveMQ, Mosquitto). EMQX у 2 рази вища пропускна здатність порівняно з Mosquitto при рівних ресурсах.
2. Партнерські платформи — Clearblade IoT Core, Cognite. Міграція на Clearblade мінімально змінює клієнтський код.
3. Інші хмари — AWS IoT Core або Azure IoT Hub. Але якщо ви залишаєтесь у GCP, гібридна схема вигідніша на 30–50% за вартістю.

Ми найчастіше рекомендуємо Cloud Pub/Sub + EMQX для клієнтів, які бажають залишитись у GCP.

Архітектура мобільного додатка на базі GCP

Для мобільного клієнта пряме підключення до Cloud Pub/Sub через gRPC вимагає Google Cloud credentials, які не можна вбудовувати в додаток. Використовуємо Firebase Authentication + Cloud Firestore як транспортний шар для IoT-станів.

Схема роботи (підтверджена на парку 500+ пристроїв):

1. IoT-пристрої публікують телеметрію → MQTT-брокер (EMQX) → Cloud Pub/Sub (через Rule Engine).
2. Cloud Function читає з Pub/Sub і записує в Firestore.
3. Мобільний додаток (Flutter/React Native) підписується на зміни Firestore через snapshots().
4. Команди від додатка записуються в колекцію commands → Cloud Function публікує назад у MQTT-брокер.
5. Push-сповіщення про критичні події — через FCM.

Затримка від події до оновлення в додатку — менше 500 мс (у типовій конфігурації). Економія до 40% порівняно з прямим MQTT-шлюзом без Pub/Sub.

Flutter реалізація:

FirebaseFirestore.instance .collection('devices') .doc(deviceId) .snapshots() .listen((snapshot) { final state = DeviceState.fromJson(snapshot.data()!); // оновлюємо UI }); 

React Native — аналогічно через @react-native-firebase/firestore.

Порівняння архітектур

Як вибрати MQTT-брокер для Google Cloud IoT?

EMQX — наш вибір для продакшену: Rule Engine знижує затримки та виключає зайві Cloud Functions.

Cloud Run + MQTT для IoT

Більш правильна архітектура для production: EMQX або HiveMQ на Cloud Run / GKE → Cloud Pub/Sub → Cloud Functions → Firestore. EMQX підтримує Rule Engine (аналог AWS IoT Rules): можна прямо з брокера публікувати в Pub/Sub за умовами без окремих Cloud Functions.

Мобільний клієнт підключається до EMQX через MQTT over WebSocket з JWT-аутентифікацією (видається Firebase Auth). EMQX перевіряє токен через HTTP Authentication hook — запит до вашого бекенду при кожному підключенні.

Чому гібридна архітектура EMQX + Firestore вигідніша?

Чистий MQTT без Pub/Sub призводить до втрати повідомлень при перевантаженнях і складної інтеграції з мобільними клієнтами. Firestore як буфер забезпечує at-least-once доставку та спрощує відстеження стану. За нашими вимірами, така змішана схема на 40% дешевша при тому ж навантаженні. Зв'яжіться з нами для аудиту вашого IoT-проєкту — ми підберемо оптимальну архітектуру.

Firebase Cloud Messaging для IoT-подій

Push-сповіщення по IoT-подіях — нативна сильна сторона GCP-стеку. Cloud Function тригериться по Pub/Sub повідомленню, надсилає FCM notification через Admin SDK:

await admin.messaging().send({ token: userFcmToken, notification: { title: 'Датчик руху', body: 'Рух виявлено в передпокої' }, data: { deviceId: '...', eventType: 'motion' } }); 

На Flutter firebase_messaging обробляє сповіщення в background через onBackgroundMessage handler. Важливо: на Android обробник має бути top-level функцією, не методом класу — інакше крэш при отриманні сповіщення в killed state.

Як ми це робимо: покроковий план

Для клієнта з парком 500+ пристроїв (температурні датчики в логістиці) реалізували:

1. Розгорнули EMQX на Cloud Run з вертикальним автоскейлінгом (обробляє 10 000 повідомлень/с).
2. Налаштували Rule Engine — фільтр аномалій (перевищення порогу температури) з публікацією тільки аномалій в Pub/Sub (зниження об'єму даних у 3 рази).
3. Cloud Function пише аномалії в Firestore; звичайні дані — в BigQuery для аналітики.
4. Мобільний додаток на Flutter підписується на Firestore через snapshots().
5. Команди (наприклад, «вимкнути живлення») записуються в commands і доставляються через MQTT назад.
6. Push-сповіщення про критичні події — через FCM (час доставки <1 с).

Результат: затримка від події до сповіщення <500 мс, економія 40% на хмарних витратах порівняно з попередньою архітектурою на чистому MQTT. Наприклад, щомісячна економія клієнта склала $4 800 при початкових витратах $12 000.

Типові помилки при інтеграції GCP IoT

• Вбудовування Service Account key в IPA/APK — грубейше порушення безпеки. Завжди використовуйте Firebase Auth + JWT.
• Ігнорування лімітів Firestore: до 1 MiB на документ, до 10 000 записів на секунду на базу. Для високонавантажених сценаріїв — буферизація через Pub/Sub.
• Відсутність механізму підтвердження доставки команд. Використовуйте окрему колекцію ack в Firestore для зворотного зв'язку з пристроєм.

Що входить у роботу та терміни

• Архітектурна документація зі схемою потоків даних.
• Прототип мобільного додатка з інтеграцією Firestore та FCM.
• Конфігурація MQTT-брокера (EMQX/HiveMQ) з JWT-аутентифікацією через HTTP Hook.
• Налаштування Cloud Pub/Sub та Cloud Functions.
• Інструкція з розгортання та експлуатації.
• Навчання команди замовника.
• Письмова гарантія на терміни та результати.

Терміни: базова архітектура (MQTT-брокер + Pub/Sub + Firestore + мобільний клієнт) — 3–4 тижні. Додавання push-сповіщень та автоматизації на Cloud Functions — ще 1–2 тижні. Вартість розраховується індивідуально, виходячи з об'єму повідомлень та необхідних обчислювальних ресурсів. Орієнтовна вартість від $15 000 для проєкту з 500+ пристроями.

Якщо ви шукаєте надійну IoT-інфраструктуру на GCP — отримайте консультацію. Наші інженери підготують архітектуру за 2 дні. Ми маємо 5-річний досвід і сертифікацію GCP, виконали понад 20 успішних проєктів.