Інтеграція 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 рекомендує кілька шляхів:
- MQTT-міст через Cloud Pub/Sub напряму з власним брокером (EMQX, HiveMQ, Mosquitto). EMQX у 2 рази вища пропускна здатність порівняно з Mosquitto при рівних ресурсах.
- Партнерські платформи — Clearblade IoT Core, Cognite. Міграція на Clearblade мінімально змінює клієнтський код.
- Інші хмари — 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+ пристроїв):
- IoT-пристрої публікують телеметрію → MQTT-брокер (EMQX) → Cloud Pub/Sub (через Rule Engine).
- Cloud Function читає з Pub/Sub і записує в Firestore.
- Мобільний додаток (Flutter/React Native) підписується на зміни Firestore через
snapshots(). - Команди від додатка записуються в колекцію
commands→ Cloud Function публікує назад у MQTT-брокер. - 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.
Порівняння архітектур
| Архітектура | Переваги | Недоліки |
|---|---|---|
| Pub/Sub + Firestore | Простота, інтеграція з Firebase Auth, реалтайм | Ліміти Firestore на запити |
| EMQX на GKE + Pub/Sub | Rule Engine, висока продуктивність | Складніше розгортання |
| AWS IoT Core | Готове рішення, Device Shadow | Вендор-лок, міграція |
Як вибрати MQTT-брокер для Google Cloud IoT?
| Брокер | Масштабованість | JWT-аутентифікація | Ліцензія |
|---|---|---|---|
| EMQX | Висока (2000+ підключень на інстанс) | HTTP Auth Hook | Open Source |
| HiveMQ | Висока | Плагін | Комерційна |
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+ пристроїв (температурні датчики в логістиці) реалізували:
- Розгорнули EMQX на Cloud Run з вертикальним автоскейлінгом (обробляє 10 000 повідомлень/с).
- Налаштували Rule Engine — фільтр аномалій (перевищення порогу температури) з публікацією тільки аномалій в Pub/Sub (зниження об'єму даних у 3 рази).
- Cloud Function пише аномалії в Firestore; звичайні дані — в BigQuery для аналітики.
- Мобільний додаток на Flutter підписується на Firestore через
snapshots(). - Команди (наприклад, «вимкнути живлення») записуються в
commandsі доставляються через MQTT назад. - 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 успішних проєктів.