Arsitektur produk platform IoT di Google Cloud

Produk platform IoT biasanya menyediakan konektivitas data MQTT dan HTTPS dasar. Library ini juga memungkinkan Anda menyediakan perangkat, serta menyediakan autentikasi dan pengelolaan, penyimpanan dan visualisasi telemetri, pemrosesan data, dan pemberitahuan. Organisasi sering menggunakan platform IoT jika broker MQTT mandiri tidak memadai untuk kasus penggunaan dan diperlukan produk platform IoT yang lebih lengkap. Platform IoT menyediakan antarmuka terpadu untuk mengelola koleksi perangkat yang heterogen. Antarmuka ini penting untuk banyak aplikasi perangkat yang terhubung, dan ini adalah perbedaan utama antara platform IoT dan broker MQTT mandiri. Dokumen ini menguraikan pertimbangan dan rekomendasi arsitektur dasar yang perlu Anda buat sebelum men-deploy arsitektur produk platform IoT di Google Cloud.

Dokumen ini adalah bagian dari serangkaian dokumen yang memberikan informasi tentang arsitektur IoT di Google Cloud dan migrasi dari IoT Core. Dokumen lain dalam rangkaian ini mencakup hal berikut:

Diagram berikut menunjukkan contoh arsitektur dengan produk platform IoT umum yang berjalan di Google Cloud.

Arsitektur platform IoT umum (alur peristiwa yang dijelaskan dalam teks berikut.

Seperti yang ditunjukkan pada diagram sebelumnya, platform IoT men-deploy broker atau endpoint MQTT untuk konektivitas perangkat. Platform IoT terhubung ke Load Balancer Jaringan proxy eksternal untuk mendistribusikan traffic dari perangkat edge. Aplikasi IoT tambahan dapat terhubung ke platform IoT melalui Pub/Sub, atau dengan menggunakan konektor Dataflow MQTT.

Platform IoT menyediakan serangkaian layanan pengelolaan perangkat. Seperti yang ditampilkan dalam diagram, layanan ini adalah sebagai berikut:

  • Penyimpanan kredensial perangkat
  • Mesin aturan
  • Autentikasi dan otorisasi perangkat
  • Pengelolaan konfigurasi perangkat
  • Registri Perangkat:
  • Pengelolaan update perangkat

Produk platform IoT secara umum juga mencakup layanan seperti fitur digital twin, antarmuka pengembangan dengan kode rendah, kemampuan pemberitahuan dan notifikasi, serta fungsi analisis lainnya.

Pertimbangan dan pilihan arsitektur

Bagian berikut menjelaskan pilihan arsitektur yang dapat Anda buat untuk arsitektur produk platform IoT, dan dampak dari pilihan ini.

Endpoint penyerapan

Sebagian besar aplikasi platform IoT komersial menyertakan endpoint MQTT, dan biasanya juga merupakan endpoint HTTPS untuk penyerapan data dari perangkat terhubung.

MQTT

Platform IoT mengimplementasikan endpoint MQTT dengan salah satu cara berikut:

  • Konektor antara MQTT dan layanan pesan lain
  • Broker MQTT yang menerapkan spesifikasi MQTT penuh

Saat mengevaluasi platform IoT komersial, penting untuk mengetahui pendekatan sebelumnya yang telah dipilih vendor untuk produk sehingga Anda dapat menentukan implikasi kasus penggunaan Anda.

Dalam beberapa kasus, endpoint MQTT hanya menghubungkan klien MQTT dengan layanan pesan backend, seperti Kafka atau Pub/Sub. Endpoint jenis ini biasanya tidak menerapkan spesifikasi protokol MQTT yang lengkap, dan sering kali tidak menyertakan fitur seperti QoS level 1 dan 2, atau langganan bersama. Keuntungan dari pendekatan ini adalah mengurangi kompleksitas dalam platform IoT, karena tidak ada aplikasi broker MQTT yang terpisah. Biaya operasional lebih rendah, dan pemeliharaan lebih sederhana daripada jika platform menggunakan broker MQTT terpisah. Namun, karena dukungan untuk fitur protokol MQTT yang lebih canggih menjadi lebih sedikit, pendekatan ini berarti memiliki fleksibilitas dan fungsionalitas yang lebih sedikit untuk transportasi pesan MQTT dibandingkan dengan broker MQTT mandiri yang menerapkan spesifikasi MQTT lengkap.

Platform IoT lainnya menyediakan broker MQTT lengkap sebagai bagian dari platform, seperti yang ditunjukkan pada contoh arsitektur dalam dokumen ini. Broker ini mungkin adalah salah satu broker open source yang ada, atau implementasi broker eksklusif. Broker MQTT penuh memberikan kemampuan MQTT dua arah penuh yang dijelaskan sebelumnya, tetapi broker penuh dapat menambah kompleksitas dan biaya operasional untuk pengelolaan platform IoT.

HTTPS dan protokol tambahan lainnya

Selain MQTT, banyak platform IoT menyediakan lebih banyak endpoint penyerapan data daripada yang ditunjukkan dalam arsitektur utama yang dijelaskan dalam dokumen ini.

HTTPS adalah protokol alternatif yang umum bagi MQTT untuk kasus penggunaan perangkat yang terhubung. MQTT memiliki overhead yang lebih tinggi daripada MQTT, tetapi lebih banyak didukung oleh perangkat seluler seperti ponsel, serta browser web dan aplikasi lainnya. Layanan ini sering digunakan dalam aplikasi perangkat terhubung tertentu, dan didukung oleh platform open source seperti Eclipse Hono dan banyak produk komersial.

Banyak aplikasi perangkat yang dibatasi menggunakan (Constrain Application Protocol (CoAP), yang didefinisikan dalam RFC 7252) sebagai alternatif MQTT. CoAP menargetkan klien dengan overhead rendah dan jejak kecil untuk perangkat dan sensor tersemat. Banyak aplikasi platform IoT komersial juga menyediakan endpoint CoAP.

Load balancing

Untuk mengetahui informasi selengkapnya tentang pemilihan load balancer terbaik untuk arsitektur Anda, lihat bagian load balancing pada arsitektur broker MQTT mandiri di Google Cloud karena pertimbangan tersebut juga berlaku untuk kasus ini singkat ini.

Autentikasi perangkat dan pengelolaan kredensial

Pengelolaan kredensial dan autentikasi perangkat adalah bagian penting dari operasi platform IoT. Metode autentikasi yang didukung oleh perangkat yang terhubung sangat bervariasi di seluruh aplikasi dan faktor bentuk perangkat. Anda harus memilih metode autentikasi yang sesuai untuk kasus penggunaan target dan mengimplementasikan skema autentikasi yang dipilih dengan benar.

Tidak seperti MQTT Broker mandiri, platform IoT menyediakan layanan terintegrasi untuk mengelola identitas dan kredensial perangkat. Sebagian besar platform IoT menggunakan autentikasi sertifikat klien X.509 untuk autentikasi, autentikasi berbasis token JWT (sering digabungkan dengan OAuth 2.0), serta autentikasi nama pengguna dan sandi. Beberapa platform juga mendukung integrasi dengan penyedia autentikasi LDAP eksternal.

Untuk beberapa perangkat yang memiliki batasan tertentu, autentikasi JWT atau nama pengguna dan sandi mungkin lebih tepat karena skema ini memerlukan lebih sedikit resource pada perangkat terhubung. Saat menggunakan JWT atau autentikasi nama pengguna dan sandi, Anda harus mengenkripsi koneksi jaringan secara terpisah ke autentikasi mTLS, karena koneksi terenkripsi tidak diperlukan oleh salah satu metode autentikasi ini. Sebaliknya, autentikasi sertifikat X.509 memakai lebih banyak resource pada perangkat terhubung, tetapi biasanya digunakan dalam koneksi yang dienkripsi mTLS sehingga memberikan tingkat keamanan yang tinggi.

Menyediakan kredensial autentikasi pada perangkat edge pada waktu produksi juga merupakan bagian penting dari skema autentikasi perangkat yang terhubung, tetapi berada di luar cakupan dokumen ini.

Untuk informasi selengkapnya tentang pengelolaan kredensial dan autentikasi, lihat Praktik terbaik untuk menjalankan backend IoT di Google Cloud.

Kelola perangkat terhubung

Biasanya, perangkat yang terhubung akan memublikasikan peristiwa telemetri dan informasi status ke platform melalui salah satu endpoint penyerapan seperti MQTT. Jika Anda menggunakan platform IoT multi-protokol, perangkat dapat berkomunikasi menggunakan salah satu protokol yang didukung.

Sebaiknya organisasi Anda menggunakan platform IoT yang memiliki kemampuan berikut:

  • Update software dan sistem: Pengiriman dan rollback firmware, software, dan update aplikasi ke perangkat yang terhubung. Update ini biasanya juga memerlukan penyimpanan dan pengelolaan update itu sendiri.
  • Pembaruan konfigurasi: Pengiriman, penyimpanan, dan rollback pembaruan pada konfigurasi aplikasi yang di-deploy di perangkat terhubung.
  • Pembuatan dan pengelolaan kredensial: Pembuatan kredensial perangkat baru, pengiriman kredensial tersebut ke perangkat yang terhubung, mengaudit upaya dan aktivitas akses perangkat, serta pencabutan yang disusupi atau masa berlaku kredensial berakhir pada waktu yang tepat.
  • Rules engine dan pemrosesan data: Definisi dan eksekusi aturan berbasis data dan langkah pemrosesan data lainnya. Kemampuan ini sering kali menyertakan beberapa jenis antarmuka dengan sedikit kode untuk menentukan aturan dan pipeline pemrosesan data.

Workload backend

Sebagian besar platform IoT menyediakan penyimpanan data internal dan kemampuan transpornya sendiri, sehingga Anda dapat terhubung ke beban kerja dan aplikasi backend. AMQP, RabbitMQ, dan Kafka biasanya digunakan untuk menyediakan transportasi data internal. Semuanya dapat dihubungkan ke Pub/Sub menggunakan Pub/Sub SDK. Anda juga dapat menggunakan sistem database terintegrasi seperti PostgreSQL untuk menyimpan data di platform. Dalam banyak kasus, platform IoT dapat dikonfigurasi untuk menggunakan salah satu produk Cloud Storage secara langsung, seperti Cloud SQL, Firebase, atau BigQuery.

Jika platform IoT memiliki broker MQTT yang lengkap, aplikasi backend juga dapat berkomunikasi dengan perangkat menggunakan kemampuan platform MQTT. Jika mendukung MQTT, aplikasi tersebut dapat terhubung dengan broker sebagai pelanggan. Jika tidak ada dukungan MQTT, Apache Beam akan menyediakan driver MQTT, yang memungkinkan integrasi dua arah dengan Dataflow serta deployment Beam lainnya.

Kasus penggunaan

Bagian berikut menjelaskan contoh skenario ketika platform IoT adalah pilihan arsitektur yang lebih baik daripada broker MQTT mandiri atau koneksi langsung ke Pub/Sub.

Pengelolaan perangkat smart

Aplikasi yang mengelola beberapa peralatan smart sangat cocok untuk platform IoT. Contoh aplikasi semacam ini adalah platform untuk mengelola peralatan dapur seperti mesin pencuci piring dan mesin pembuat kopi. Perangkat ini umumnya terhubung ke aplikasi berbasis cloud, baik secara langsung melalui Wi-Fi maupun melalui gateway lokal yang menggunakan Bluetooth Hemat Energi (BLE) atau protokol lokal lainnya. Kemampuan pengelolaan platform IoT di sini penting, untuk memantau status setiap perangkat, mengelola update software dan patch keamanan, serta merekam aktivitas perangkat untuk memberikan informasi penting kepada produsen dan pelanggan. Kemampuan ini berada di luar cakupan pialang MQTT dasar. Setidaknya, repositori informasi perangkat, database status perangkat, datastore telemetri, dan antarmuka analisis, semuanya sangat penting untuk membangun platform alat smart yang sukses.

Logistik dan pelacakan aset

Untuk aplikasi logistik dan pelacakan aset, produk platform IoT menawarkan fungsionalitas yang lebih lengkap daripada broker MQTT dasar, sehingga merupakan pilihan yang lebih baik untuk kasus penggunaan ini. Pemantauan status saat ini dan sebelumnya serta lokasi sejumlah besar aset bergantung pada database status perangkat dan sistem pengelolaan identitas yang andal. Saat di-deploy, aset baru harus dihubungkan ke platform dengan sesedikit mungkin friksi, dan kemudian dipantau sepanjang siklus proses aset. Dalam banyak kasus, aplikasi juga mengumpulkan informasi sensor lain tentang aset, seperti suhu lokal, kelembapan, dan tekanan atmosfer, atau data akselerasi dan posisi 3D untuk mendeteksi gerakan atau penurunan yang tidak terduga. Semua data ini harus diserap dan dikaitkan dengan aset yang benar untuk analisis di aplikasi backend apa pun, sehingga pengelolaan perangkat dengan fitur lengkap yang disediakan oleh platform IoT memiliki kemampuan yang penting.

Langkah selanjutnya