Daripada menerapkan arsitektur khusus untuk menghubungkan perangkat ke aplikasi analisis, beberapa organisasi mungkin mendapatkan manfaat dengan terhubung langsung ke Pub/Sub dari perangkat edge. Kami rekomendasikan pendekatan ini untuk organisasi dengan sedikit perangkat terhubung yang menggabungkan data dari sejumlah besar perangkat dan sensor di jaringan lokal. Pendekatan ini juga direkomendasikan jika organisasi Anda memiliki perangkat terhubung di lingkungan yang lebih aman, seperti pabrik. Dokumen ini menguraikan pertimbangan arsitektur tingkat tinggi yang perlu Anda lakukan untuk menggunakan pendekatannya guna menghubungkan perangkat ke produk Google Cloud.
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 yang terhubung di Google Cloud
- Arsitektur broker MQTT mandiri di Google Cloud
- Arsitektur produk platform IoT di Google Cloud
- Praktik terbaik untuk menjalankan backend IoT di Google Cloud
- Perangkat pada arsitektur Pub/Sub yang terhubung ke Google Cloud (dokumen ini)
- Praktik terbaik untuk menyediakan dan mengonfigurasi sistem serta server edge dan bare metal secara otomatis
Arsitektur
Diagram berikut menunjukkan gateway atau perangkat agregasi terhubung yang terhubung langsung ke Pub/Sub.
Berikut adalah alur peristiwa dalam diagram sebelumnya:
- Anda dapat menggunakan Identity and Access Management API untuk membuat pasangan kunci baru akun layanan. Kunci publik disimpan dalam IAM. Namun, Anda harus download kunci pribadi dengan aman dan menyimpannya di perangkat gateway agar dapat digunakan untuk autentikasi.
- Perangkat agregasi mengumpulkan data dari beberapa perangkat dan sensor jarak jauh lainnya yang terletak di dalam jaringan lokal yang aman. Perangkat jarak jauh berkomunikasi dengan gateway menggunakan protokol edge lokal seperti MODBUS, BACNET, OPC-UA, atau protokol lokal lain.
- Perangkat agregasi mengirimkan data ke Pub/Sub melalui HTTPS atau gRPC. Panggilan API ini ditandatangani menggunakan kunci pribadi akun layanan yang ditahan di perangkat agregasi.
Pertimbangan dan pilihan arsitektur
Karena Pub/Sub adalah layanan streaming data tanpa server, Anda dapat menggunakannya untuk membuat sistem dua arah yang terdiri dari produser dan konsumen peristiwa (dikenal sebagai penerbit dan pelanggan). Dalam beberapa skenario perangkat yang terhubung, Anda hanya memerlukan layanan publikasi dan berlangganan yang skalabel untuk membuat arsitektur data yang efektif. Bagian berikut menjelaskan pertimbangan dan pemilihan yang perlu Anda buat saat menerapkan perangkat ke arsitektur Pub/Sub di Google Cloud.
Endpoint penyerapan
Pub/Sub menyediakan library klien bawaan dalam beberapa bahasa yang menerapkan API REST dan gRPC. Layanan ini mendukung dua protokol penyerapan pesan: REST (HTTP) dan gRPC. Agar perangkat terhubung dapat mengirim dan menerima data melalui Pub/Sub, perangkat harus dapat berinteraksi dengan salah satu endpoint tersebut.
Banyak aplikasi software dengan dukungan bawaan untuk REST API, sehingga penghubungan dengan Pub/Sub REST API sering menjadi solusi termudah. Namun, dalam beberapa kasus penggunaan, gRPC dapat menjadi alternatif yang lebih efisien dan lebih cepat. Karena menggunakan buffering protokol berserial untuk payload pesan, bukan JSON, XML, atau format berbasis teks lainnya, gRPC lebih cocok untuk aplikasi bandwidth rendah yang biasa ditemukan pada kasus penggunaan perangkat terhubung. Koneksi gRPC API juga lebih cepat daripada REST untuk transmisi data, dan gRPC mendukung komunikasi dua arah secara bersamaan. Sebuah studi menemukan bahwa gRPC mampu bekerjatujuh kali lebih cepat daripada REST. Oleh karena itu, untuk skenario dengan banyak perangkat yang terhubung, gRPC menjadi opsi yang lebih baik jika konektor gRPC tersedia atau dapat diterapkan untuk aplikasi perangkat yang terhubung.
Autentikasi perangkat dan pengelolaan kredensial
Pub/Sub mendukung sejumlah metode autentikasi untuk akses dari luar Google Cloud.
Jika arsitektur Anda menyertakan penyedia identitas eksternal seperti Active Directory atau cluster Kubernetes lokal, Anda dapat menggunakan federasi identitas workload untuk mengelola akses ke Pub/Sub. Pendekatan ini memungkinkan Anda membuat token akses jangka pendek untuk perangkat yang terhubung. Anda juga dapat memberi peran IAM ke perangkat terhubung, tanpa overhead pengelolaan dan keamanan saat menggunakan kunci akun layanan.
Apabila penyedia identitas eksternal tidak tersedia, kunci akun layanan adalah satu-satunya opsi untuk autentikasi. Kunci akun layanan dapat menjadi risiko keamanan jika tidak dikelola dengan benar. Jadi, sebaiknya ikuti praktik terbaik keamanan untuk men-deploy kunci akun layanan ke perangkat yang terhubung. Untuk mempelajari lebih lanjut, lihat Praktik terbaik untuk mengelola kunci akun layanan. Akun layanan juga merupakan resource terbatas dan setiap project cloud memiliki kuota akun layanan yang dikelola pengguna terbatas. Maka, pendekatan ini hanya opsi untuk deployment dengan sedikit perangkat yang perlu dihubungkan.
Aplikasi backend
Setelah data diserap ke dalam topik Pub/Sub, data tersebut akan tersedia untuk semua aplikasi dengan kredensial dan hak istimewa akses sesuai yang berjalan di Google Cloud Tidak ada konektor tambahan yang diperlukan selain Pub/Sub API di aplikasi Anda. Pesan dapat disediakan untuk beberapa aplikasi di seluruh infrastruktur backend Anda untuk pemrosesan atau laporan paralel, serta penyimpanan arsip dan analisis lainnya.
Kasus penggunaan
Bagian berikut menjelaskan contoh skenario saat koneksi langsung dari perangkat ke Pub/Sub sangat cocok untuk kasus penggunaan perangkat terhubung.
Penyerapan data massal dari histori data lokal
Perangkat ke koneksi Pub/Sub paling cocok untuk aplikasi dengan sedikit endpoint yang mengirimkan data dalam volume besar. Historis data operasional adalah contoh tepat dari sistem lokal dengan banyak data tersimpan yang perlu dikirim ke Google Cloud. Untuk kasus penggunaan ini, beberapa jumlah endpoint harus diautentikasi, biasanya satu hingga beberapa perangkat terhubung, yang berada dalam parameter standar untuk autentikasi akun layanan. Sistem ini juga biasanya memiliki arsitektur modular, yang memungkinkan Anda menerapkan koneksi Pub/Sub API yang perlu dikomunikasikan dengan Google Cloud.
Agregasi data gateway lokal untuk factory
Agregasi data sensor pabrik di gateway lokal adalah kasus penggunaan lain yang cocok untuk koneksi Pub/Sub langsung. Dalam hal ini, sistem agregasi dan pengelolaan data lokal di-deploy pada perangkat gateway di factory. Sistem ini biasanya merupakan produk software yang terhubung ke berbagai sensor dan komputer lokal. Produk ini mengumpulkan data dan sering mengubahnya menjadi representasi standar sebelum meneruskannya ke aplikasi cloud.
Banyak perangkat dapat dihubungkan di skenario ini. Namun, perangkat-perangkat tersebut biasanya hanya terhubung ke gateway lokal dan dikelola oleh software pada perangkat tersebut, sehingga tidak diperlukan aplikasi pengelolaan berbasis cloud. Tidak seperti pada arsitektur broker MQTT, dalam kasus penggunaan ini, gateway berperan aktif dalam menggabungkan dan mengubah data.
Ketika terhubung ke Google Cloud, gateway melakukan autentikasi dengan Pub/Sub melalui kunci akun layanan. Kunci tersebut mengirimkan data yang telah dikumpulkan dan diubah ke aplikasi cloud untuk dilakukan proses lebih lanjut. Jumlah gateway yang terhubung juga biasanya berkisar di puluhan hingga ratusan perangkat, yang berada dalam rentang standar untuk autentikasi akun layanan.
Langkah berikutnya
- Lihat Praktik terbaik untuk mengelola kunci akun layanan.
- Baca ringkasan penggabungan identitas untuk workload eksternal.
- Pelajari lebih lanjut mengenai Pub/Sub
- Pelajari arsitektur referensi, diagram, dan praktik terbaik untuk Google Cloud. Lihat Cloud Architecture Center kami.
- Untuk arsitektur referensi, diagram, dan praktik terbaik lainnya, jelajahi Pusat Arsitektur Cloud.