MQTT adalah protokol standar OASIS untuk aplikasi perangkat terhubung yang menyediakan pesan dua arah dengan menggunakan arsitektur perantara publikasi dan langganan. Protokol MQTT ringan digunakan untuk mengurangi beban jaringan dan klien MQTT sangat sedikit dalam meminimalkan penggunaan resource pada perangkat yang terbatas. Salah satu solusi untuk organisasi yang ingin mendukung aplikasi perangkat terhubung di Google Cloud adalah dengan menjalankan perantara MQTT mandiri di Compute Engine atau GKE. Untuk men-deploy perantara MQTT di organisasi, Anda harus membuat beberapa keputusan penting yang memengaruhi keseluruhan arsitektur; terkhusus pada load-balancing dan lingkungan deployment. Dokumen ini menjelaskan arsitektur untuk men-deploy perantara MQTT yang merupakan aplikasi inti dalam deployment MQTT di Google Cloud. Dokumen ini juga menjelaskan keputusan yang perlu diambil saat men-deploy perantara ini dan bagaimana pengaruhnya terhadap arsitektur.
Dokumen ini adalah bagian dari serangkaian dokumen yang memberikan informasi tentang arsitektur IoT di Google Cloud. Dokumen lain dalam rangkaian ini mencakup hal berikut:
- Ringkasan arsitektur perangkat terhubung di Google Cloud
- Arsitektur perantara MQTT mandiri di Google Cloud (dokumen ini)
- Arsitektur produk platform IoT di Google Cloud
- Praktik terbaik untuk menjalankan backend IoT di Google Cloud
- Perangkat pada arsitektur Pub/Sub ke Google Cloud
- Praktik terbaik untuk menyediakan dan mengonfigurasi sistem serta server edge dan bare metal secara otomatis
Diagram berikut menunjukkan arsitektur perantara MQTT yang berjalan di Google Cloud.
Arsitektur pada gambar sebelumnya disusun sebagai berikut:
- Perantara MQTT di-deploy sebagai cluster yang terdiri dari tiga instance yang terhubung ke layanan Cloud Load Balancing. Untuk cloud load balancer, Anda dapat memilih salah satu dari beberapa produk load-balancing yang akan dijelaskan kemudian dalam dokumen ini.
- Cluster perantara mencakup penyimpanan kredensial perangkat serta layanan autentikasi dan otorisasi perangkat. Cluster ini terhubung dengan workload backend melalui Dataflow atau Pub/Sub.
- Di sisi klien, gateway edge menyediakan komunikasi dua arah antara perangkat edge dan cluster perantara MQTT melalui MQTT dengan TLS.
Secara umum, kami merekomendasikan Anda untuk men-deploy aplikasi perantara MQTT pada arsitektur ini dalam cluster untuk skalabilitas. Faktor-faktor seperti fungsionalitas pengklasteran, pengelolaan cluster penambahan dan penurunan skala, sinkronisasi data, dan penanganan partisi jaringan ditangani oleh implementasi perantara tertentu (seperti HiveMQ, EMQX, VerneMQ, mosquito, dan lainnya).
Pertimbangan dan pilihan arsitektur
Bagian berikut menjelaskan berbagai pilihan arsitektur dan pertimbangan yang harus Anda buat untuk arsitektur perantara MQTT mandiri dan dampak dari pilihan Anda terhadap arsitektur.
Perangkat terhubung
Perangkat edge yang terhubung ke internet memublikasikan peristiwa telemetri dan informasi lain ke perantara MQTT. Untuk mengimplementasikan arsitektur perantara MQTT mandiri yang dijelaskan dalam dokumen ini, perangkat harus memiliki klien MQTT, kunci publik sertifikat server untuk autentikasi TLS, dan kredensial yang diperlukan untuk melakukan autentikasi dengan perantara MQTT.
Selain itu, perangkat edge umumnya memiliki konektor ke sensor lokal, sistem data lokal, dan perangkat lain yang tidak memiliki akses internet atau konektivitas IP. Misalnya, perangkat edge dapat berfungsi sebagai gateway untuk perangkat lokal terbatas lainnya yang terhubung ke gateway dengan menggunakan BLE, ke koneksi berkabel, atau ke protokol jarak dekat lainnya. Spesifikasi terperinci dari arsitektur perangkat terhubung berada di luar cakupan panduan ini.
Load balancing
Dalam arsitektur, layanan load-balancing eksternal dikonfigurasikan di antara jaringan publik dan cluster perantara MQTT. Layanan ini menyediakan beberapa fungsi jaringan penting termasuk distribusi koneksi masuk di seluruh node backend, enkripsi sesi, dan autentikasi.
Google Cloud mendukung beberapa jenis load balancer. Untuk memilih load balancer terbaik bagi arsitektur Anda, pertimbangkan hal-hal berikut:
mTLS. mTLS menangani enkripsi dan metode autentikasi perangkat, sedangkan TLS standar hanya menangani enkripsi dan memerlukan metode autentikasi perangkat yang terpisah:
- Jika aplikasi Anda menggunakan mTLS untuk autentikasi perangkat dan perlu menghentikan tunnel TLS, sebaiknya gunakan Load Balancer Jaringan passthrough eksternal atau Load Balancer Jaringan proxy eksternal dengan proxy TCP target. Network Load Balancers proxy eksternal menghentikan sesi TLS dan melakukan proxy koneksi ke node perantara beserta kredensial autentikasi apa pun yang terdapat dalam pesan. Jika memerlukan informasi koneksi klien sebagai bagian dari skema autentikasi, Anda dapat mempertahankannya dalam koneksi backend dengan mengaktifkan protokol PROXY.
- Jika aplikasi Anda tidak menggunakan mTLS, sebaiknya gunakan Network Load Balancer proxy eksternal dengan proxy SSL target untuk memindahkan pemrosesan TLS dan SSL eksternal ke load balancer. Network Load Balancers proxy eksternal menghentikan sesi TLS dan melakukan proxy koneksi ke node perantara beserta kredensial autentikasi apa pun yang terdapat dalam pesan. Jika memerlukan informasi koneksi klien sebagai bagian dari skema autentikasi, Anda dapat mempertahankannya dalam koneksi backend dengan mengaktifkan protokol PROXY.
Endpoint HTTP(S). Jika Anda perlu mengekspos endpoint HTTP(S), sebaiknya konfigurasikan Load Balancer Aplikasi eksternal secara terpisah untuk endpoint ini.
Untuk informasi selengkapnya tentang jenis load balancer yang didukung Cloud Load Balancing, lihat Ringkasan load balancer Google Cloud.
Strategi load balancing
Setiap layanan load balancing mendistribusikan koneksi dari perangkat edge di seluruh node dalam cluster berdasarkan salah satu dari beberapa algoritma atau mode balancing. Untuk MQTT, strategi load balancing afinitas sesi lebih baik daripada load-balancing acak. Karena koneksi server klien MQTT merupakan koneksi dengan sesi dua arah yang persisten, status tetap dipertahankan pada node perantara yang mengalami penghentian koneksi. Dalam konfigurasi cluster, jika koneksi klien terputus dan terhubung kembali ke node yang berbeda, status sesi akan dipindahkan ke node baru yang akan menambah beban pada cluster. Masalah ini sebagian besar dapat dihindari dengan menggunakan load balancing afinitas sesi. Jika klien sering mengubah alamat IP, koneksi dapat terputus, tetapi dalam kebanyakan kasus, afinitas sesi lebih baik digunakan untuk MQTT. Afinitas sesi tersedia di semua produk Cloud Load Balancing.
Autentikasi perangkat dan pengelolaan kredensial
Aplikasi perantara MQTT menangani autentikasi perangkat dan kontrol akses secara terpisah dari Google Cloud. Aplikasi perantara juga menyediakan penyimpanan kredensial dan antarmuka pengelolaannya sendiri. Protokol MQTT mendukung autentikasi dasar nama pengguna dan sandi di paket Connect awal dan bidang ini juga sering digunakan oleh implementasi perantara untuk mendukung bentuk autentikasi lain seperti Sertifikat X.509 atau autentikasi JWT. MQTT 5.0 juga menambahkan dukungan untuk metode autentikasi yang ditingkatkan kualitasnya dan menggunakan autentikasi gaya respons dan tantangan. Metode autentikasi yang digunakan bergantung pada pilihan aplikasi perantara MQTT dan kasus penggunaan perangkat yang terhubung.
Terlepas dari metode autentikasi yang digunakan perantara, perantara akan mempertahankan penyimpanan kredensial perangkat. Penyimpanan ini dapat berada di database SQL lokal atau file datar. Beberapa perantara, termasuk HiveMQ dan VerneMQ, juga mendukung penggunaan layanan database terkelola seperti Cloud SQL. Anda memerlukan layanan terpisah untuk mengelola penyimpanan kredensial perangkat dan menangani integrasi apa pun dengan layanan autentikasi lainnya seperti IAM. Pengembangan layanan ini berada di luar cakupan panduan ini.
Untuk informasi selengkapnya tentang pengelolaan kredensial dan autentikasi, lihat Praktik terbaik untuk menjalankan backend IoT di Google Cloud.
Workload backend
Setiap kasus penggunaan perangkat terhubung mencakup satu atau beberapa aplikasi backend yang menggunakan data yang ditransfer dari perangkat terhubung. Terkadang, aplikasi ini juga perlu mengirimkan perintah dan pembaruan konfigurasi ke perangkat. Pada arsitektur perantara MQTT mandiri dalam dokumen ini, perintah data masuk dan keluar akan dialihkan melalui perantara MQTT. Ada berbagai topik dalam hierarki topik perantara untuk membedakan antara data dan perintah.
Data dan perintah dapat dikirim ke aplikasi perantara dan backend dengan menggunakan salah satu dari beberapa cara berikut. Jika aplikasi itu sendiri mendukung MQTT atau jika aplikasi tersebut dapat dimodifikasi untuk mendukung MQTT, aplikasi tersebut dapat berlangganan langsung ke perantara sebagai klien. Pendekatan ini memungkinkan Anda menggunakan kemampuan pengiriman pesan dua arah Pub/Sub MQTT secara langsung dengan menggunakan aplikasi untuk menerima data dari perangkat terhubung serta mengirimkan perintah ke perangkat tersebut.
Jika aplikasi Anda tidak mendukung MQTT, ada beberapa opsi lainnya. Dalam arsitektur yang dijelaskan pada dokumen ini, Apache Beam menyediakan driver MQTT yang memungkinkan integrasi dua arah dengan Dataflow dan deployment Beam lainnya. Banyak juga perantara yang memiliki kemampuan plugin yang mendukung integrasi dengan layanan seperti Pub/Sub Google. Integrasi ini biasanya merupakan integrasi satu arah untuk integrasi data, meskipun beberapa perantara mendukung integrasi dua arah.
Kasus penggunaan
Arsitektur perantara MQTT sangat cocok untuk kasus penggunaan perangkat yang dijelaskan pada bagian berikut.
Penyerapan data berbasis standar dari perangkat yang heterogen
Saat Anda ingin mengumpulkan dan menganalisis data dari berbagai perangkat yang heterogen, perantara MQTT sering dijadikan solusi yang tepat. Karena MQTT merupakan standar yang diadopsi dan diimplementasikan secara luas, banyak perangkat edge yang memiliki dukungan bawaan untuk kasus ini, bahkan klien MQTT ringan tersedia untuk menambahkan dukungan MQTT ke perangkat yang tidak mendukungnya. Paradigma publikasi dan langganan juga merupakan bagian dari standar MQTT, sehingga perangkat yang mendukung MQTT dapat memanfaatkan arsitektur ini tanpa perlu melakukan implementasi tambahan. Sebaliknya, perangkat yang terhubung ke Pub/Sub perlu mengimplementasikan Pub/Sub API atau menggunakan SDK Pub/Sub. Menjalankan perantara MQTT yang mematuhi standar di Google Cloud dapat memberikan solusi sederhana untuk mengumpulkan data dari berbagai perangkat.
Saat perangkat terhubung tidak dikontrol oleh aplikasi Anda tetapi oleh pihak ketiga, Anda mungkin tidak memiliki akses ke software sistem dan pengelolaan perangkat itu sendiri akan menjadi tanggung jawab pihak lain. Dalam situasi tersebut, sebaiknya jalankan perantara MQTT dan berikan kredensial autentikasi kepada pihak ketiga untuk menyiapkan saluran komunikasi perangkat ke cloud.
Komunikasi dua arah untuk integrasi aplikasi banyak pihak
Kemampuan pesan dua arah MQTT membuatnya sangat cocok untuk kasus penggunaan aplikasi seluler banyak pihak seperti pengiriman makanan on-demand atau aplikasi chat web berskala besar. MQTT memiliki beban protokol yang rendah dan klien MQTT memiliki permintaan resource yang rendah. MQTT juga memiliki fitur pemilihan rute publikasi dan langganan, beberapa tingkat kualitas layanan (QoS), retensi pesan bawaan, dan dukungan protokol yang luas. Perantara MQTT dapat menjadi komponen inti dari platform pesan yang skalabel untuk aplikasi layanan on-demand dan kasus penggunaan serupa.
Pengiriman pesan yang terintegrasi edge-to-cloud
Karena standardisasi dan beban rendah yang ditawarkan MQTT, MQTT juga dapat menjadi solusi yang baik untuk mengintegrasikan aplikasi pesan lokal dan berbasis cloud. Misalnya, operator pabrik dapat men-deploy beberapa perantara MQTT di lingkungan lokal untuk terhubung ke sensor, mesin, gateway, dan perangkat lain yang berada dibelakang firewall. Perantara MQTT lokal dapat menangani semua perintah dan kontrol serta pesan telemetri dua arah untuk infrastruktur lokal. Perantara lokal juga dapat dihubungkan melalui langganan dua arah ke cluster perantara MQTT paralel di cloud yang memungkinkan komunikasi antara cloud dan lingkungan edge tanpa mengekspos perangkat dan sistem lokal ke internet publik.
Langkah berikutnya
- Pelajari cara menghubungkan perangkat dan membangun aplikasi IoT di Google Cloud dengan menggunakan Intelligent Products Essentials.
- Pelajari praktik untuk menyediakan dan mengonfigurasi sistem dan server edge serta bare metal secara otomatis.
- Untuk arsitektur referensi, diagram, dan praktik terbaik lainnya, jelajahi Cloud Architecture Center.