Memigrasikan lingkungan dari IoT Core

Last reviewed 2023-02-01 UTC

Google telahmengumumkan penghentian IoT Core. Dokumen ini dimaksudkan untuk membantu Anda mendesain dan menerapkan rencana migrasi dari lingkungan berbasis IoT Core ke lingkungan baru yang tidak bergantung pada IoT Core untuk hal berikut:

  • Autentikasi perangkat Edge
  • Pengelolaan perangkat edge
  • Komunikasi antara perangkat edge Anda dan Google Cloud

Dokumen ini juga memberikan panduan jika Anda mengevaluasi peluang untuk bermigrasi setelah IoT Core tidak digunakan lagi dan ingin mempelajari seperti apa migrasinya.

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:

Workload yang akan dimigrasikan

Dokumen ini mengasumsikan bahwa beban kerja yang ingin Anda migrasikan dari IoT Core memiliki bagian berikut:

  • Bagian yang berjalan di perangkat edge (di-deploy di tepi lingkungan Anda, dan di samping data yang ingin diproses)
  • Backend yang berjalan di Google Cloud

Diagram berikut menunjukkan arsitektur beban kerja umum yang menggunakan IoT Core. Dalam arsitektur ini, Cloud IoT mengintegrasikan perangkat edge yang memiliki backend yang berjalan di Google Cloud.

Alur peristiwa dari perangkat edge ke Cloud IoT (dirangkum dalam teks berikut).

Diagram sebelumnya dapat dirangkum sebagai berikut:

Untuk merencanakan migrasi secara efektif, sebaiknya lakukan penilaian untuk mendapatkan pemahaman penuh tentang arsitektur lingkungan sumber. Dalam hal ini, lingkungan sumber mengacu pada lingkungan berbasis IoT Core Anda saat ini.

Dokumen ini mengasumsikan bahwa Anda dapat mengupdate konfigurasi dan komponen software yang berjalan di perangkat edge untuk migrasi. Dalam beberapa kasus, pendekatan ini mungkin tidak valid, berlaku. Misalnya, perangkat edge atau proses deployment Anda mungkin tidak mendukung kasus penggunaan ini. Dalam hal ini, sebaiknya Anda berencana menghentikan perangkat edge yang tidak mendukung update. Untuk informasi selengkapnya tentang merancang dan menerapkan proses penyediaan dan konfigurasi otomatis untuk perangkat edge, lihat Praktik terbaik untuk menyediakan dan mengonfigurasi sistem dan server edge dan bare metal secara otomatis.

Mendesain migrasi

Untuk memigrasikan lingkungan berbasis IoT Core, sebaiknya ikuti framework migrasi yang dijelaskan dalam Migrasi ke Google Cloud.

Diagram berikut menjelaskan jalur perjalanan migrasi Anda:

Jalur migrasi dengan empat fase.

Seperti yang ditunjukkan dalam diagram sebelumnya, perjalanan ini memiliki empat fase:

  1. Evaluasi: Pada fase ini, Anda menilai lingkungan sumber, menilai beban kerja, dan perangkat edge yang ingin Anda migrasikan dari Cloud IoT Core.
  2. Merencanakan: Pada fase ini, Anda membuat infrastruktur dasar di Google Cloud, seperti menyediakan hierarki resource dan menyiapkan akses jaringan.
  3. Men-deploy: Pada fase ini, Anda men-deploy solusi baru untuk digunakan, bukan IoT Core, dan memigrasikan perangkat edge ke solusi baru.
  4. Optimalkan: Pada fase ini, Anda mengoptimalkan lingkungan target. Dalam hal ini, lingkungan target mengacu pada lingkungan tujuan migrasi yang tidak didasarkan pada IoT Core.

Menilai lingkungan sumber dan workload

Pada fase penilaian, Anda mengumpulkan informasi tentang lingkungan sumber, perangkat edge, dan penggunaan IoT Core di organisasi Anda. Informasi ini membantu Anda merancang rencana migrasi dan memastikan Anda memiliki resource yang diperlukan untuk migrasi dan lingkungan target.

Pada tahap penilaian, Anda dapat melakukan hal-hal berikut:

  1. Build inventaris perangkat edge yang telah Anda daftarkan ke Cloud IoT Core.
  2. Bangun inventaris workload backend yang terintegrasi dengan Cloud IoT Core.
  3. Kategorikan perangkat edge dan beban kerja backend Anda.
  4. Bereksperimen dan merancang bukti konsep.
  5. Hitung total biaya kepemilikan.
  6. Desain arsitektur lingkungan target.
  7. Pilih perangkat edge dan beban kerja backend untuk dimigrasikan terlebih dahulu.

Pada akhir fase penilaian, Anda memiliki dua inventaris: inventaris untuk perangkat edge dan inventaris untuk beban kerja backend.

Untuk menghindari inkonsistensi, sebaiknya jeda deployment perangkat edge dan beban kerja backend baru sebelum Anda membuat inventaris ini. Sebaiknya jangan men-deploy perangkat edge dan workload latar belakang baru setelah membuat inventaris.

Membuat inventaris perangkat edge Anda

Untuk menentukan cakupan migrasi dan mendesain rencana migrasi, Anda perlu mengetahui jumlah perangkat edge yang ada di lingkungan sumber. Anda juga harus memahami cara perangkat berinteraksi dengan IoT Core, dan apakah Anda dapat mengategorikannya berdasarkan karakteristik umum, perilaku, tujuan, atau dependensi.

Setiap perangkat edge yang Anda daftarkan ke IoT Core adalah milik registry IoT Core. Langkah pertama untuk mem-build inventaris perangkat edge adalah membuat daftar registry IoT Core yang Anda buat. Anda kemudian mengumpulkan informasi tentang perangkat edge yang terdaftar di setiap registry.

Untuk mem-build inventaris perangkat edge Anda, pertimbangkan informasi berikut untuk setiap perangkat edge, dan cara perangkat terintegrasi dengan IoT Core:

  • ID: Kumpulkan informasi berikut tentang ID IoT Core perangkat edge:

    • ID yang ditentukan pengguna
    • ID yang ditentukan server dan tidak dapat diedit yang dihasilkan secara otomatis IoT Core saat Anda mendaftarkan perangkat edge ke IoT Core
    • Nama resource yang secara unik mengidentifikasi perangkat edge menggunakan ID registry IoT Core tempat Anda mendaftarkan perangkat edge

  • Status deployment: Menilai status deployment perangkat edge saat ini. Misalnya, perangkat edge mungkin berada dalam salah satu status berikut:

    • Belum diproduksi, atau saat ini sedang diproduksi
    • Siap di-deploy, tetapi belum terdaftar ke IoT Core
    • Sudah di-deploy di situs tujuannya, dan terdaftar di IoT Core

  • Jenis perangkat IoT Core: Menilai jenis perangkat IoT Core. Setiap perangkat edge yang Anda daftarkan ke IoT Core dapat bertindak dengan salah satu dari dua cara. Platform ini dapat berupa klien yang terhubung langsung ke IoT Core. Atau, dapat berupa gateway untuk klien yang tidak dapat atau tidak ingin Anda hubungkan ke IoT Core secara langsung.

  • Protokol komunikasi: IoT Core mendukung dua protokol untuk berkomunikasi dengan perangkat edge: HTTP dan MQTT. Tentukan protokol yang digunakan perangkat edge Anda untuk berkomunikasi dengan IoT Core. Untuk protokol MQTT, Anda juga harus menentukan kualitas layanan yang diandalkan oleh perangkat edge dan workload backend Anda.

  • Kredensial: IoT Core mengautentikasi perangkat edge menggunakan pasangan kunci dan token berumur pendek yang dibuat menggunakan pasangan kunci tersebut. Opsi ini dapat memverifikasi tanda tangan bagian publik pasangan kunci menggunakan metode verifikasi berbasis sertifikat. Menilai cara autentikasi perangkat edge dikonfigurasi. Periksa apakah Anda menggunakan mekanisme verifikasi berbasis sertifikat untuk registry IoT Core tempat perangkat tersebut berada.

  • Metadata perangkat: Di IoT Core, Anda dapat menentukan metadata untuk setiap perangkat edge dalam bentuk key-value pair. Misalnya, Anda dapat menentukan thumbprint hardware, nomor seri, informasi produsen, atau atribut lain yang relevan untuk perangkat edge. Anda dapat menentukan metadata saat menambahkan perangkat edge ke registry IoT Core, atau mengedit perangkat edge yang sudah ada dalam registry. Metadata tidak pernah dikirim ke atau dari perangkat edge melalui IoT Core. Kumpulkan informasi tentang metadata yang Anda tentukan untuk perangkat edge.

  • Status perangkat: Di IoT Core, setiap perangkat edge dapat melaporkan informasi tentang statusnya sebagai data terstruktur atau tidak terstruktur arbitrer. Misalnya, perangkat edge mungkin melaporkan versi firmware yang sedang berjalan. Atau, data mungkin melaporkan informasi tentang kondisinya, sesuai dengan metrik tertentu. IoT Core memublikasikan informasi yang diterima tentang status perangkat sebagai pesan dalam topik Pub/Sub yang Anda konfigurasi. Periksa cara perangkat edge Anda melaporkan informasi tentang statusnya, dan ke topik Pub/Sub mana IoT Core memublikasikan pesan tersebut. Tentukan komponen arsitektur mana yang mengandalkan informasi tentang status perangkat edge.

  • Peristiwa telemetri: Setiap perangkat edge yang Anda tambahkan ke registry IoT Core dapat mengirim peristiwa telemetri sebagai data terstruktur atau tidak terstruktur arbitrer ke IoT Core. IoT Core memublikasikan peristiwa telemetri yang diterima sebagai pesan dalam topik Pub/Sub yang Anda konfigurasikan. Nilai cara perangkat edge Anda melaporkan peristiwa telemetri, dan ke topik Pub/Sub mana IoT Core memublikasikan pesan tersebut. Tentukan komponen arsitektur mana yang mengandalkan peristiwa telemetri yang dilaporkan oleh perangkat edge.

  • Konfigurasi perangkat: Di IoT Core, Anda dapat menentukan konfigurasi perangkat edge sebagai data terstruktur atau tidak terstruktur arbitrer. IoT Core juga memungkinkan Anda menentukan pembaruan konfigurasi perangkat sebagai versi baru dari konfigurasi tersebut yang kemudian akan dikirim ke perangkat edge. Evaluasi apakah perangkat edge menerima konfigurasi dari Cloud IoT Core, dan kumpulkan informasi tentang semua versi konfigurasi yang Anda tentukan.

  • Perintah: Di IoT Core, perangkat edge dapat menerima perintah dari IoT Core, lalu bereaksi sesuai dengan perintah tersebut. Evaluasi apakah perangkat edge Anda mendukung reaksi terhadap perintah yang berasal dari IoT Core.

  • Update software dan konfigurasi: Selama migrasi, Anda mungkin perlu mengupdate komponen software yang berjalan di perangkat edge, atau konfigurasi komponen tersebut. Nilai mekanisme update yang didukung perangkat edge Anda. Tentukan apakah perangkat juga mendukung mekanisme rollback untuk mengembalikannya ke status kerja yang diketahui jika ada masalah dan masalah selama update tersebut.

  • Periode nonaktif: Selama migrasi, beban kerja backend atau bagian lain di lingkungan sumber mungkin tidak tersedia. Periksa apakah perangkat edge Anda mendukung periode nonaktif, mekanisme penggantiannya, dan cara perangkat pulih setelah periode nonaktif.

Membuat inventaris workload backend yang terintegrasi dengan IoT Core

Setelah membuat inventaris perangkat edge, Anda mengumpulkan informasi tentang beban kerja backend di lingkungan sumber yang terintegrasi dengan Cloud IoT Core. Beban kerja backend dapat diintegrasikan dengan IoT Core dengan cara berikut:

  • Dengan mengirimkan perintah ke perangkat edge, dan memperbarui konfigurasi perangkat edge menggunakan IoT Core.
  • Dengan berlangganan topik Pub/Sub, yang menjadi tujuan IoT Core memublikasikan pesan tentang peristiwa telemetri perangkat edge dan status perangkat.
  • Dengan mengintegrasikan IoT Core API secara langsung, atau menggunakan alat penyediaan infrastruktur. Misalnya, Anda mungkin menggunakan Terraform untuk menyediakan registri dan perangkat IoT Core.

Untuk mem-build inventaris beban kerja backend yang terintegrasi dengan Cloud IoT Core, pertimbangkan hal berikut untuk setiap beban kerja backend:

  • Konfigurasi perintah dan perangkat: Menilai apakah beban kerja backend mengirimkan perintah ke perangkat edge, dan apakah konfigurasi perangkat diperbarui. Kedua tindakan ini memerlukan integrasi dengan IoT Core API.
  • Peristiwa telemetri dan status perangkat: Menilai apakah beban kerja backend berlangganan topik Pub/Sub tempat IoT Core memublikasikan pesan tentang peristiwa telemetri dan status perangkat.

  • Integrasi dengan IoT Core API lainnya: Menilai apakah beban kerja backend berinteraksi dengan IoT Core API lainnya, selain yang digunakan untuk mengirim perintah dan memperbarui konfigurasi perangkat. Misalnya, beban kerja backend Anda mungkin mengandalkan IoT Core API untuk melakukan hal berikut:

    • Membuat registry IoT Core dan memperbarui konfigurasinya.
    • Buat perangkat IoT Core dan perbarui konfigurasinya.
    • Mengumpulkan informasi tentang registry dan perangkat IoT Core.
    • Gunakan metrik logging IoT Core dan log aktivitas perangkat.

Mengategorikan perangkat edge dan workload backend Anda

Setelah membuat inventaris perangkat edge dan beban kerja backend, Anda perlu mengategorikan item di setiap inventaris berdasarkan karakteristiknya. Kategorisasi ini membantu Anda membuat draf rencana migrasi dan memilih perangkat edge dan beban kerja backend yang akan dimigrasikan terlebih dahulu.

Untuk mengategorikan perangkat edge, sebaiknya lakukan kategorisasi berdasarkan jenis interaksi yang dapat terjadi antara perangkat edge dan beban kerja backend. Pertimbangkan jenis interaksi berikut:

  • Saat perangkat edge mengirimkan data ke beban kerja backend menggunakan peristiwa telemetri atau informasi tentang status perangkat.
  • Saat beban kerja backend mengirimkan perintah ke perangkat edge menggunakan perintah atau update konfigurasi perangkat.

Untuk setiap jenis interaksi sebelumnya, jenis pesan yang dipertukarkan selama interaksi semacam itu berbeda. Namun, pesan tersebut memiliki tujuan yang serupa. Beberapa perangkat mengirim data dari perangkat edge ke beban kerja backend, seperti peristiwa telemetri dan informasi tentang status perangkat. Beberapa perangkat mengirim perintah dari beban kerja backend ke perangkat edge, seperti perintah dan update konfigurasi perangkat.

Berdasarkan jenis interaksi yang diusulkan, kami merekomendasikan kategori berikut untuk perangkat edge Anda:

  • Khusus transmisi: Perangkat edge yang mengirim peristiwa telemetri atau informasi tentang status perangkat, tetapi tidak menerima perintah atau update konfigurasi perangkat dari beban kerja backend.
  • Hanya terima: Perangkat edge yang tidak mengirim peristiwa telemetri atau informasi tentang status perangkat, tetapi menerima perintah atau update konfigurasi perangkat dari beban kerja backend.
  • Menerima dan mengirim: Perangkat edge yang mengirim peristiwa dan informasi telemetri tentang status perangkat, serta menerima perintah atau update konfigurasi perangkat dari beban kerja backend.

Untuk mengategorikan beban kerja backend, Anda dapat mengikuti pendekatan yang serupa dengan yang Anda ikuti untuk mengategorikan perangkat edge. Berdasarkan jenis interaksi yang diusulkan, kami merekomendasikan kategori berikut untuk beban kerja backend Anda:

  • Hanya terima: Beban kerja backend yang menerima peristiwa telemetri atau informasi tentang status perangkat dari perangkat edge, tetapi tidak mengirimkan perintah atau pembaruan konfigurasi perangkat.
  • Khusus kirim: Beban kerja backend yang tidak menerima peristiwa telemetri atau informasi tentang status perangkat, tetapi mengirim perintah atau perubahan konfigurasi perangkat.
  • Kirim dan terima: Beban kerja backend yang menerima peristiwa telemetri atau informasi tentang status perangkat dari perangkat edge, dan mengirim perintah atau update konfigurasi perangkat.

Menyelesaikan penilaian

Setelah membuat inventaris, Anda harus menyelesaikan bagian-bagian fase penilaian berikut:

Setelah menyelesaikan aktivitas tersebut, lanjutkan membaca dokumen ini.

Mendesain arsitektur lingkungan target

Setelah menyelesaikan kegiatan penilaian sebelumnya, Anda merancang arsitektur untuk lingkungan target.

Dokumen ini berfokus pada migrasi lingkungan sumber ke lingkungan target. Namun, memigrasikan lingkungan dari IoT Core juga merupakan peluang bagi Anda untuk merencanakan fitur dan update baru. Saat mendesain arsitektur lingkungan target, pikirkan tentang keterbatasan yang mungkin Anda alami di lingkungan sumber. Pertimbangkan cara Anda mengonfigurasi lingkungan target untuk menghindari pembatasan tersebut. Anda juga dapat mempertimbangkan setiap potensi fitur baru yang mungkin diperlukan di lingkungan target.

Berdasarkan cara Anda mengategorikan perangkat edge dan beban kerja backend, Anda mungkin melihat kasus penggunaan IoT Core pelengkap berikut yang muncul dari penilaian lingkungan sumber:

  • Penyerapan data yang berasal dari perangkat edge ke backend yang berjalan di Google Cloud.
  • Menjalankan workload backend pengelolaan perangkat edge di Google Cloud.

Untuk mengurangi kompleksitas migrasi, sebaiknya Anda berfokus pada kasus penggunaan yang muncul dari penilaian lingkungan sumber. Misalnya, jika Anda menyerap data yang berasal dari perangkat edge, tetapi tidak menggunakan fitur pengelolaan perangkat IoT Core apa pun, sebaiknya Anda berfokus untuk mendesain lingkungan target. Pendekatan ini memungkinkan Anda mendukung kasus penggunaan penyerapan data saja, tanpa perlu mempertimbangkan kasus penggunaan pengelolaan perangkat.

Desain lingkungan target dapat bervariasi bergantung pada kasus penggunaan Cloud IoT Core ini yang Anda implementasikan di lingkungan sumber, dan cara menerapkannya di lingkungan target. Anda harus mempertimbangkan faktor-faktor berikut:

  • Jika menerapkan kedua kasus penggunaan di lingkungan sumber, Anda dapat mendesain lingkungan target untuk mengimplementasikan kedua kasus penggunaan tersebut dengan satu solusi. Anda juga dapat menerapkan dua kasus penggunaan tersebut secara terpisah menggunakan solusi yang berbeda.
  • Jika hanya menerapkan salah satu dari dua kasus penggunaan di lingkungan sumber, Anda dapat mendesain lingkungan target untuk menerapkan kasus penggunaan tersebut dengan satu solusi.

Diagram berikut menunjukkan serangkaian contoh pertanyaan yang perlu dipertimbangkan saat Anda memutuskan cara mendesain arsitektur lingkungan target.

Contoh pertanyaan, yang dinyatakan dalam teks berikut.

Diagram sebelumnya dapat dirangkum sebagai berikut:

  • Apakah Anda perlu menyerap data dari perangkat edge dan mengelola perangkat edge?

    • Jika ya, lanjutkan ke pertanyaan berikutnya.
    • Jika tidak, lanjutkan ke pertanyaan kasus penggunaan pengelolaan perangkat edge.

  • Apakah Anda memerlukan solusi tunggal untuk menerapkan kasus penggunaan penyerapan data dan pengelolaan perangkat edge?

    • Jika ya, deploy solusi untuk penyerapan data dan pengelolaan perangkat edge di Google Cloud.
    • Jika tidak, deploy solusi pengelolaan perangkat edge di Google Cloud, lalu lanjutkan ke pertanyaan evaluasi kasus penggunaan penyerapan data.

  • Apakah Anda perlu mengelola perangkat edge?

    • Jika ya, deploy solusi pengelolaan perangkat edge di Google Cloud, lalu lanjutkan ke pertanyaan evaluasi kasus penggunaan penyerapan data.
    • Jika tidak, lanjutkan ke pertanyaan evaluasi kasus penggunaan penyerapan data.

  • Apakah Anda perlu menyerap data yang berasal dari perangkat edge?

    • Jika ya, lanjutkan ke pertanyaan berikutnya.
    • Jika tidak, berarti Anda telah menyelesaikan migrasi atau tidak perlu memigrasikan lingkungan sumber. Pada kedua kasus tersebut, Anda dapat menghentikan lingkungan sumber.

  • Apa protokol komunikasi yang diutamakan?

    • Jika MQTT, deploy broker MQTT di Google Cloud.
    • Jika HTTP atau gRPC, serap data yang berasal dari perangkat edge menggunakan Pub/Sub.
    • Jika tidak, evaluasi solusi penyerapan data yang kompatibel dengan protokol komunikasi pilihan Anda.

Saat mendesain arsitektur lingkungan target, pertimbangkan hal berikut:

  • Mengelola setiap komponen arsitektur memerlukan pengetahuan dan upaya. Sebaiknya Anda mengevaluasi jumlah resource tambahan yang perlu memperhitungkan lingkungan target.
  • Menyediakan banyak perangkat edge akan menimbulkan tantangan keamanan, skalabilitas, dan operasional. Untuk informasi selengkapnya tentang penyediaan perangkat edge, lihat Praktik terbaik untuk menyediakan dan mengonfigurasi sistem serta server edge dan bare metal secara otomatis.
  • Dengan menggunakan Pub/Sub untuk menyerap data dari perangkat edge, Anda tidak dapat mengelola dan menskalakan platform pesan terdistribusi. Jika Anda menggunakan Pub/Sub untuk menyerap data yang berasal dari perangkat edge, pertimbangkan kuota dan batas Pub/Sub, terutama jika Anda perlu menyerap data dari banyak perangkat singkat ini.

  • Untuk mengautentikasi perangkat edge Anda terhadap lingkungan target dan mengelola identitasnya, sebaiknya Anda menilai metode autentikasi dan kredensial mana yang menyimpan lingkungan target tersebut. Pertimbangkan perbandingannya dengan aplikasi yang Anda gunakan dengan IoT Core di lingkungan sumber.

    Setelah mengumpulkan informasi ini, sebaiknya ikuti panduan dalam Panduan keamanan backend IoT untuk merancang dan mengimplementasikan mekanisme pengelolaan identitas dan autentikasi bagi Anda perangkat edge.

Pilih perangkat edge dan workload backend yang akan dimigrasikan terlebih dahulu

Setelah mendesain arsitektur lingkungan target, Anda menentukan hal berikut:

  1. Kategori perangkat edge dan beban kerja backend yang akan dimigrasikan terlebih dahulu.
  2. Batch migrasi (grup item yang akan dimigrasikan dari lingkungan sumber ke lingkungan target).

Tentukan kategori perangkat edge yang akan dimigrasikan terlebih dahulu

Kategori perangkat edge dan beban kerja backend mungkin menawarkan tantangan dan kesulitan yang berbeda untuk bermigrasi. Salah satu contohnya adalah migrasi perangkat edge khusus transmisi, yang mungkin lebih mudah daripada memigrasikan perangkat penerima dan transmisi edge.

Untuk mengembangkan pemahaman yang lebih mendalam tentang cara memilih kategori perangkat edge dan beban kerja backend yang akan dimigrasikan terlebih dahulu, lihat Memilih aplikasi yang akan dimigrasikan terlebih dahulu.

Bagian ini merangkum pertimbangan yang harus Anda buat untuk setiap kategori perangkat edge saat memutuskan mana yang akan dimigrasikan terlebih dahulu.

Hanya mengirimkan perangkat edge

Perangkat edge ini mengirim peristiwa telemetri dan informasi tentang status perangkat menggunakan MQTT atau HTTP.

Jika perangkat menggunakan MQTT, Anda mungkin hanya perlu memperbarui konfigurasinya untuk terhubung ke dan melakukan autentikasi terhadap broker MQTT di lingkungan target Anda. Anda dapat terus memublikasikan peristiwa telemetri dan informasi tentang status perangkat melalui broker MQTT di lingkungan target. Dalam beberapa kasus, Anda mungkin tidak memiliki broker MQTT di lingkungan target, dan perlu bermigrasi ke jenis lingkungan target yang berbeda, seperti solusi pihak ketiga. Dalam hal ini, Anda perlu menilai kemampuan dan antarmuka integrasi yang disediakan oleh solusi tersebut. Selanjutnya, Anda dapat mendesain dan menerapkan rencana migrasi yang sesuai.

Jika perangkat menggunakan HTTP, Anda mungkin perlu memperbarui konfigurasinya untuk terhubung dan mengautentikasi terhadap lingkungan target. Anda mungkin juga perlu memfaktorkan ulang semantik cara perangkat berkomunikasi untuk memperhitungkan perbedaan lingkungan target jika dibandingkan dengan menggunakan IoT Core API. Misalnya, jika Anda menggunakan Pub/Sub di lingkungan target, Anda dapat bermigrasi dari menggunakan IoT Core API untuk memublikasikan pesan ke topik Pub/Sub menjadi menggunakan Pub/Sub API untuk tujuan yang sama. Dalam beberapa kasus, Anda mungkin tidak menggunakan Pub/Sub di lingkungan target. Oleh karena itu, Anda perlu bermigrasi ke jenis lingkungan target yang berbeda, seperti solusi pihak ketiga. Dalam hal ini, Anda harus menilai kemampuan dan antarmuka integrasi yang disediakan oleh solusi pihak ketiga untuk merancang dan menerapkan rencana migrasi yang sesuai.

Hanya menerima perangkat edge

Perangkat edge ini menerima perintah menggunakan MQTT dan update konfigurasi menggunakan MQTT atau HTTP. IoT Core tidak mendukung penggunaan HTTP untuk mengirim perintah.

Jika perangkat menerima perintah dan update konfigurasi menggunakan MQTT, pertimbangan yang serupa dengan kategori perangkat edge sebelumnya akan berlaku. Untuk memigrasikan kategori perangkat edge ini, Anda perlu memperbarui konfigurasi perangkat edge untuk dihubungkan dan melakukan autentikasi terhadap broker MQTT di lingkungan target Anda. Anda akan terus berlangganan topik MQTT tempat IoT Core memublikasikan perintah dan pembaruan konfigurasi perangkat. Dalam beberapa kasus, Anda mungkin tidak memiliki broker MQTT di lingkungan target, dan perlu bermigrasi ke jenis lingkungan target yang berbeda, seperti solusi pihak ketiga. Dalam hal ini, Anda perlu menilai kemampuan dan antarmuka integrasi yang disediakan oleh solusi tersebut untuk mendesain dan mengimplementasikan rencana migrasi yang sesuai.

Jika perangkat menerima update konfigurasi menggunakan HTTP, pertimbangan serupa seperti yang berlaku untuk kategori perangkat edge sebelumnya. Untuk memigrasikan kategori perangkat edge ini, Anda mungkin perlu memperbarui konfigurasinya agar dapat terhubung dan melakukan autentikasi terhadap lingkungan target. Untuk menerima update konfigurasi, Anda mungkin juga perlu memfaktorkan ulang semantik komunikasi untuk memperhitungkan perbedaan di lingkungan target, dibandingkan dengan menggunakan IoT Core API. Misalnya, jika bermigrasi ke berbagai jenis lingkungan target, seperti solusi pihak ketiga, Anda harus menilai kemampuan dan antarmuka integrasi yang disediakan oleh solusi tersebut untuk desain dan menerapkan rencana migrasi yang sesuai.

Menerima dan mengirimkan perangkat edge

Perangkat edge ini mungkin paling sulit dimigrasikan karena merupakan konsumen data yang berasal dari beban kerja backend, dan produser data yang diterima perangkat edge. Pertimbangan untuk memigrasikan kategori perangkat edge yang dibahas di atas keduanya berlaku dalam kasus ini, sehingga Anda perlu perhatian khusus untuk menangani migrasi kategori beban kerja backend ini.

Setelah memilih kategori perangkat edge yang akan dimigrasikan terlebih dahulu, Anda memilih kategori beban kerja backend yang akan dimigrasikan terlebih dahulu.

Workload backend penerimaan saja

Beban kerja backend ini dipisahkan dari perangkat edge yang menghasilkan peristiwa telemetri atau informasi tentang status perangkat, sehingga, karena alasan berikut, dapat dimigrasikan secara relatif mudah:

  • Beban kerja backend berlangganan topik Pub/Sub. Karena alasan ini, perangkat tidak perlu mengetahui produsen informasi tersebut untuk menggunakannya. Anda mungkin tidak perlu mengupdate konfigurasi atau software yang berjalan di perangkat edge.
  • Beban kerja backend tidak mengirimkan perintah atau pembaruan konfigurasi perangkat ke perangkat edge. Oleh karena itu, Anda tidak perlu mempertimbangkan kasus penggunaan ini selama migrasi beban kerja backend ini.
  • Anda dapat menyimpan topik Pub/Sub yang ada untuk memublikasikan atau menggunakan pesan. Dalam kasus semacam itu, beban kerja backend Anda dapat terus berlangganan topik Pub/Sub yang ada jika lingkungan target Anda terus meneruskan peristiwa telemetri dan informasi tentang status perangkat ke topik Pub/Sub tersebut.

Workload backend pengiriman saja

Beban kerja backend ini memerlukan penilaian komprehensif untuk memahami cara interaksi dengan perangkat edge saat mengirimkan perintah dan pembaruan konfigurasi perangkat, serta cara memigrasikannya ke lingkungan target. Misalnya, jika Anda bermigrasi ke lingkungan target dengan broker MQTT, beban kerja backend tersebut dapat bermigrasi dari menggunakan IoT Core API untuk mengirim perintah atau pembaruan konfigurasi perangkat untuk memublikasikan pesan melalui MQTT. Dalam beberapa kasus, Anda mungkin tidak perlu mengupdate software atau konfigurasi di perangkat edge. Misalnya, jika beban kerja backend memublikasikan perintah dan pembaruan konfigurasi dalam format yang sama dan ke topik MQTT yang sama tempat IoT Core memublikasikan pesan tentang perintah dan pembaruan konfigurasi perangkat di lingkungan sumber Anda. Jika bermigrasi ke jenis lingkungan target yang berbeda, seperti solusi pihak ketiga, Anda harus menilai kemampuan dan antarmuka integrasi yang disediakan oleh solusi tersebut untuk merancang dan mengimplementasikan solusi yang sesuai rencana migrasi.

Mengirim dan menerima workload backend

Beban kerja backend ini mungkin paling sulit untuk dimigrasikan karena keduanya merupakan konsumen data yang berasal dari perangkat edge, dan produsen data yang diterima perangkat edge. Pertimbangan untuk memigrasikan kategori beban kerja backend yang dibahas di atas keduanya berlaku dalam kasus ini, sehingga Anda memerlukan perhatian khusus untuk menangani migrasi kategori beban kerja backend ini.

Menentukan batch migrasi

Untuk mengurangi risiko dan kompleksitas migrasi sejumlah besar item dalam satu batch, Anda perlu membagi item untuk dimigrasikan di setiap kategori dalam batch migrasi. Untuk merencanakan batch migrasi, Anda dapat melakukan hal berikut:

  1. Desain batch migrasi dengan mengelompokkan item homogen: Untuk mengelompokkan item yang akan dimigrasikan dalam batch, sebaiknya pilih serangkaian kriteria agar item dalam batch migrasi memiliki karakteristik umum yang sama. Misalnya, Anda dapat mengelompokkan perangkat edge dalam batch sesuai dengan hal berikut:

    • Region deployment
    • Registry IoT Core tempat perangkat didaftarkan
    • Jika ada kumpulan metadata perangkat IoT Core yang bermakna
    • Status deployment perangkat

  2. Tentukan ukuran setiap batch migrasi: Untuk setiap kategori item yang akan dimigrasikan, sebaiknya rencanakan batch migrasi pertama dalam kategori tersebut agar berukuran relatif kecil. Anda meningkatkan ukuran batch saat mendapatkan pengalaman dan momentum selama migrasi.

  3. Menilai apakah batch migrasi Anda memerlukan strategi ad-hoc: Bergantung pada cara Anda mengelompokkan item untuk dimigrasikan dalam batch migrasi, strategi migrasi yang akan diterapkan untuk batch migrasi tertentu mungkin bergantung pada karakteristik item dalam batch tersebut. Misalnya, untuk memigrasikan perangkat edge yang dikelompokkan berdasarkan status deployment, Anda harus mempertimbangkan hal berikut:

    • Jika perangkat belum diproduksi, atau saat ini sedang diproduksi, Anda dapat meminta produsen untuk mengupdate konfigurasi dan software untuk memigrasikannya ke lingkungan target.
    • Jika perangkat siap di-deploy, tetapi belum terdaftar ke IoT Core, Anda dapat menginstruksikan deployer untuk menarik kembali perangkat edge tersebut. Selanjutnya, Anda dapat mengupdate konfigurasi dan software untuk memigrasikannya ke lingkungan target.
    • Jika perangkat Anda sudah di-deploy di lokasi tujuannya, dan terdaftar ke IoT Core, Anda dapat memperbarui konfigurasi dan software untuk memigrasikannya ke lingkungan target, baik dari jarak jauh maupun di lokasi.

Merencanakan dan mem-build fondasi Anda

Dalam fase perencanaan dan pembuatan, Anda akan menyediakan dan mengonfigurasi infrastruktur dan layanan cloud yang mendukung workload Anda di Google Cloud sebagai berikut:

  1. Mem-build hierarki resource.
  2. Mengonfigurasikan Identity and Access Management
  3. Menyiapkan penagihan.
  4. Menyiapkan konektivitas jaringan.
  5. Memperketat keamanan Anda.
  6. Menyiapkan pemantauan dan pemberitahuan.

Untuk panduan tentang cara membangun infrastruktur dan layanan cloud yang mendukung beban kerja Anda dan dependensinya, lihat Migrasi ke Google Cloud: Membangun fondasi Anda. Ikuti panduan ini untuk membangun fondasi bagi lingkungan Anda. Kemudian, Anda dapat melanjutkan aktivitas yang dijelaskan di bagian berikutnya dalam dokumen ini.

Memigrasikan perangkat edge dan workload backend

Setelah membangun fondasi untuk lingkungan target, Anda harus melakukan hal berikut untuk memigrasikan perangkat edge dan beban kerja backend ke lingkungan target.

  1. Sediakan dan konfigurasi resource untuk menerapkan arsitektur lingkungan target: Sebagai langkah pertama dalam proses migrasi, Anda perlu membuat dan menyiapkan infrastruktur platform baru.
  2. Migrasikan perangkat edge dan beban kerja backend ke lingkungan target: Setelah Anda memverifikasi bahwa lingkungan target sudah siap, migrasikan beban kerja backend dan perangkat edge ke lingkungan target. Bergantung pada arsitektur lingkungan target Anda dan kasus penggunaan Anda, mungkin ada pendekatan yang berbeda untuk melakukan migrasi. Dokumen ini membahas strategi migrasi dua langkah yang memungkinkan lingkungan sumber dan target Anda untuk berdampingan selama jangka waktu tertentu. Dengan pendekatan ini, Anda dapat melakukan roll back ke lingkungan sumber jika terjadi kegagalan selama migrasi.
  3. Menghentikan lingkungan sumber: Setelah memastikan bahwa lingkungan target sudah beroperasi sepenuhnya, Anda akan menghentikan lingkungan sumber.

Menyediakan dan mengonfigurasi resource untuk arsitektur lingkungan target

Pada fase ini, Anda akan menyediakan dan mengonfigurasi lingkungan target. Seperti yang dijelaskan dalam Mendesain arsitektur lingkungan target, arsitektur lingkungan target dapat dirangkum sebagai berikut:

  • Broker MQTT yang berjalan di Google Cloud: Anda menjalankan broker MQTT di Google Cloud dan meneruskan peristiwa telemetri serta informasi tentang status perangkat dari broker MQTT ke beban kerja backend. Workload backend Anda memublikasikan perintah dan kontrol ke topik MQTT.
  • Pub/Sub: Perangkat edge Anda memublikasikan peristiwa telemetri dan informasi tentang status perangkat ke Pub/Sub dan menerima perintah dari Pub/Sub.
  • Platform pengelolaan perangkat dan penyerapan data pihak ketiga: Anda menyiapkan solusi pihak ketiga untuk peristiwa telemetri dan informasi tentang penyerapan status perangkat dan pengelolaan perangkat.

Untuk mengetahui informasi selengkapnya tentang setiap arsitektur, lihat arsitektur perangkat yang terhubung di Google Cloud.

Memigrasikan perangkat edge dan workload backend ke lingkungan target

Setelah menyediakan dan mengonfigurasi resource di lingkungan target, Anda akan memigrasikan perangkat edge dan beban kerja backend ke lingkungan target. Di bagian ini, Anda akan memigrasikan perangkat edge dan beban kerja backend dari lingkungan sumber ke lingkungan target. Lingkungan sumber dan target berdampingan sampai Anda menonaktifkan lingkungan sumber.

Untuk mengurangi periode nonaktif, proses migrasi memiliki fase berikut:

  1. Memantau lingkungan sumber dan target.
  2. Memigrasikan informasi metadata perangkat edge dari lingkungan sumber ke lingkungan target. Hal ini termasuk kredensial perangkat, konfigurasi perangkat, dan status perangkat.
  3. Memperbarui perangkat edge agar terhubung ke lingkungan sumber dan target.
  4. Memigrasikan workload backend dari lingkungan sumber ke lingkungan target.
  5. Memperbarui perangkat edge agar terhubung ke lingkungan sumber saja.

Sebaiknya pantau lingkungan sumber dan target selama setiap fase migrasi, dan pastikan Anda memverifikasi hasil setiap fase sebelum berpindah ke fase berikutnya.

Selain memantau lingkungan, Anda mungkin ingin memperkenalkan pengujian black-box untuk memverifikasi apakah lingkungan berfungsi seperti yang diharapkan. Contoh pengujian tersebut adalah kasus penggunaan saat beban kerja backend Anda mengirimkan notifikasi email ke operator saat mendeteksi peristiwa tertentu, seperti suhu di atas 50 derajat celsius. Anda dapat membuat kasus pengujian yang memiliki data telemetri untuk suhu di atas 50 derajat celsius dan menguji apakah beban kerja backend mengirimkan email ke operator.

Memantau lingkungan sumber dan target

Untuk memantau lingkungan sumber dan target, sebaiknya Anda mempertimbangkan metrik berikut:

  • Jumlah perangkat aktif: Jumlah perangkat yang baru-baru ini mengirim data ke IoT Core.
  • Jumlah error komunikasi perangkat: Jumlah error yang dialami beban kerja backend saat berkomunikasi dengan perangkat edge, yang dikelompokkan berdasarkan jenis error, dalam periode tertentu. Metrik ini berguna untuk memahami apakah beban kerja backend mengalami masalah saat berkomunikasi dengan perangkat edge.
  • Jumlah operasi perangkat: Jumlah operasi yang dilakukan oleh perangkat edge, seperti permintaan koneksi atau pemutusan koneksi, publikasi pesan, yang dikelompokkan berdasarkan jenis operasi, dalam periode tertentu. Metrik ini membantu Anda memahami apakah perangkat edge berjalan seperti yang diharapkan. Misalnya, jika nilai Jumlah error perangkat dan jumlah operasi Perangkat meningkat, lingkungan mungkin mengalami masalah saat mengirimkan pesan ke perangkat edge.
  • Jumlah byte yang diterima: Jumlah byte yang diterima dari perangkat edge dalam periode tertentu. Metrik ini membantu Anda memikirkan statistik traffic masuk jaringan.
  • Jumlah byte terkirim: Jumlah delta jumlah byte yang dikirim ke perangkat edge. Metrik ini membantu Anda memikirkan statistik traffic keluar jaringan.
  • Throughput pesan: Jumlah pesan yang diproses oleh beban kerja backend dalam periode tertentu. Metrik ini membantu Anda memahami apakah lingkungan diskalakan sesuai dengan volume traffic antara perangkat edge dan beban kerja backend. Misalnya, jika jumlah perangkat aktif dan jumlah operasi perangkat meningkat, tetapi throughput pesan tidak terlalu berubah, sebaiknya periksa apakah beban kerja backend memiliki resource yang cukup untuk menangani peningkatan pesan.
  • Latensi pengiriman pesan: Jumlah waktu yang berlalu setelah perangkat edge memublikasikan pesan dan sebelum beban kerja backend menerimanya untuk diproses. Misalnya, jika nilai latensi naik, sebaiknya periksa apakah ada masalah yang memperlambat pengiriman pesan.
  • Pesan yang tidak terkirim: Jumlah pesan yang tidak dapat dikirim ke perangkat edge dan beban kerja backend. Kegagalan mengirimkan pesan kepada konsumen dapat berarti bahwa perangkat edge atau beban kerja backend mungkin tidak merespons.
  • Penggunaan kuota resource cloud: Pantau penggunaan kuota resource cloud untuk memastikan lingkungan memiliki resource yang cukup untuk diskalakan.
Memantau lingkungan sumber

Cloud Monitoring otomatis mengumpulkan metrics dari IoT Core dan Pub/Sub. Misalnya, IoT Core menampilkan metrik device/active_devices, device/error_count, dan device/operation_count. Data ini membantu Anda memahami jumlah perangkat edge yang terhubung ke lingkungan sumber, dan jumlah perangkat edge yang mengalami error saat berkomunikasi dengan IoT Core. Metrik device/received_bytes_count dan metrik device/sent_bytes_count membantu Anda memantau penggunaan bandwidth jaringan.

Untuk memantau status dan kondisi pengiriman pesan, Anda menggunakan Monitoring Query Language untuk mengukur skor kondisi latensi pengiriman untuk langganan, throughput pesan, dan pesan yang tidak terkirim.

Memantau lingkungan target

Anda memantau lingkungan target untuk memahami apakah migrasi berhasil. Bergantung pada arsitektur lingkungan target, broker MQTT atau platform IoT pihak ketiga mungkin memberikan metrik berikut:

  • Broker MQTT: Jika lingkungan target didasarkan pada broker MQTT, broker dapat memberikan metrik tentang perangkat edge dan pengiriman pesan. Untuk memantau byte yang dikirim dan diterima, lihat metrik yang disediakan oleh Cloud Load Balancing. Jika broker MQTT berjalan di cluster GKE, Anda dapat mengonfigurasi Cloud Monitoring untuk menentukan metrik yang akan dikirim ke Monitoring. Jika broker MQTT berjalan di instance Compute Engine, Anda dapat menggunakan dasbor default atau menginstal Agen Operasional untuk mengumpulkan telemetri mendetail dari instance Cloud Monitoring.

  • Pub/Sub: Jika lingkungan target didasarkan pada Pub/Sub, Anda harus menggunakan topik dan langganan Pub/Sub. Misalnya, Anda dapat menggunakan Bahasa Kueri Monitoring untuk melakukan kueri guna mengambil skor kondisi latensi pengiriman untuk langganan, throughput pesan, dan pesan yang tidak terkirim.

  • Platform IoT: Jika lingkungan target didasarkan pada platform IoT, platform tersebut mungkin menyediakan informasi tentang perangkat edge dan pengiriman pesan. Jika platform IoT pihak ketiga berjalan di cluster GKE, Anda dapat mengonfigurasi Logging dan Monitoring untuk mengonfigurasi metrik mana yang dikirim ke Cloud Monitoring. Jika platform IoT pihak ketiga berjalan di instance Cloud Monitoring, Anda dapat menggunakan dasbor default atau menginstal Agen Operasional untuk mengumpulkan telemetri mendetail dari instance Cloud Monitoring.

Memigrasikan informasi metadata perangkat edge dari lingkungan sumber ke lingkungan target

Untuk bermigrasi ke platform IoT baru, Anda perlu memigrasikan informasi metadata perangkat edge ke lingkungan target. Untuk memigrasikan metadata perangkat edge, pertimbangkan kategori metadata berikut:

  • Kredensial perangkat: IoT Core mengautentikasi perangkat edge menggunakan pasangan kunci dan token yang memiliki masa aktif singkat. Ikuti langkah-langkah yang diperlukan terkait lingkungan target untuk mendaftarkan perangkat ke lingkungan target dan membuat kredensial perangkat di lingkungan target sesuai dengan mekanisme autentikasinya.

  • Konfigurasi perangkat: Mungkin lingkungan target Anda adalah platform IoT pihak ketiga yang menyediakan layanan konfigurasi perangkat, dan kasus penggunaan Anda mengharuskan perangkat edge dikonfigurasi dengan status terbaru yang diinginkan. Dalam hal ini, Anda perlu memigrasikan konfigurasi perangkat ke lingkungan target. Selama migrasi, pastikan konfigurasi perangkat sinkron antara lingkungan sumber dan lingkungan target. Jika lingkungan target Anda didasarkan pada broker MQTT atau Pub/Sub dan tidak menyediakan cara untuk mengelola konfigurasi perangkat, Anda dapat menyimpan konfigurasi perangkat di bucket Cloud Storage selama istilah arsip.

  • Informasi tentang status perangkat: Pastikan bahwa perangkat edge memperbarui statusnya saat pertama kali terhubung ke lingkungan target, sehingga lingkungan target memiliki informasi terbaru tentang status perangkat.

Setelah Anda menyelesaikan langkah ini, verifikasi apakah informasi dan kredensial perangkat yang diperlukan telah dikonfigurasi dengan benar serta bahwa perangkat edge dapat terhubung dan melakukan autentikasi terhadap lingkungan target.

Mengupdate perangkat edge agar terhubung baik ke lingkungan sumber dan target

Saat mencapai tahap ini, lingkungan target Anda siap menerima koneksi dari perangkat edge. Anda dapat mengupdate perangkat edge untuk menghubungkannya ke sumber dan lingkungan target agar dapat mengirim peristiwa telemetri dan informasi tentang status perangkat. Saat mengupdate perangkat edge, pendekatan yang harus Anda lakukan bergantung pada kategori perangkat edge.

Untuk perangkat edge yang memang mengirim peristiwa telemetri atau informasi tentang status perangkat, tetapi tidak menerima perintah atau pembaruan konfigurasi perangkat dari beban kerja backend, Anda perlu berikut ini:

  1. Update perangkat edge agar mengirim peristiwa telemetri dan informasi tentang status perangkat ke sumber dan lingkungan target.
  2. Pastikan lingkungan target menerima peristiwa telemetri dan informasi tentang status perangkat dengan benar.

Sebaliknya, untuk perangkat edge yang tidak mengirim peristiwa atau informasi telemetri tentang status perangkat, tetapi memang menerima perintah atau update konfigurasi dari beban kerja backend, Anda lakukan hal berikut:

  1. Update perangkat edge untuk menerima perintah dan update konfigurasi dari lingkungan target.
  2. Pastikan perangkat edge Anda melaporkan hasil eksekusi perintah atau update konfigurasi ke lingkungan target.
  3. Kirim perintah dan pembaruan konfigurasi dari lingkungan target ke perangkat edge.
  4. Pastikan eksekusi perintah dan pembaruan konfigurasi berhasil.

Untuk perangkat edge yang mengirim peristiwa telemetri dan informasi tentang status perangkat dan juga menerima update perintah atau konfigurasi dari beban kerja backend, Anda perlu melakukan hal berikut:

  1. Update perangkat edge agar mengirim peristiwa telemetri dan informasi tentang status perangkat ke sumber dan lingkungan target.
  2. Pastikan lingkungan target menerima peristiwa telemetri dan informasi tentang status perangkat dengan benar.
  3. Update kode perangkat edge untuk menerima pembaruan perintah dan konfigurasi dari lingkungan target.
  4. Pastikan perangkat edge Anda melaporkan hasil eksekusi perintah atau update konfigurasi ke lingkungan target.
  5. Kirim perintah dan pembaruan konfigurasi dari lingkungan target ke perangkat edge.
  6. Pastikan eksekusi perintah dan pembaruan konfigurasi berhasil.

Setelah menjalankan langkah-langkah ini untuk kasus penggunaan Anda, semua kategori perangkat edge melakukan hal berikut:

  • Menghubungkan ke lingkungan sumber dan target.
  • Mengirim peristiwa dan informasi telemetri tentang status perangkat ke lingkungan sumber dan target.
  • Terima perintah dan pembaruan konfigurasi dari lingkungan sumber hanya karena Anda belum memigrasikan beban kerja backend.

Sebaiknya hindari skenario saat beban kerja backend memproses pesan yang sama dengan yang dikirim perangkat edge ke lingkungan sumber dan lingkungan target. Sebaiknya konfigurasikan periode retensi pesan di lingkungan target seminimal mungkin. Pendekatan ini memungkinkan Anda memverifikasi bahwa lingkungan target berfungsi seperti yang diharapkan. Dengan alat ini, Anda juga dapat memeriksa apakah pesan di lingkungan target akan habis masa berlakunya sebelum memigrasikan beban kerja backend. Anda dapat menyesuaikan konfigurasi retensi pesan di lingkungan target setelah langkah migrasi berikutnya.

Jika perangkat edge tidak dapat terhubung ke lingkungan sumber dan target secara bersamaan karena alasan teknis atau peraturan, Anda harus mengonfigurasi perangkat edge untuk memutuskan koneksi dari lingkungan sumber terlebih dahulu. Setelah itu, Anda hanya dapat terhubung ke lingkungan target. Dalam kasus ini, beban kerja backend yang masih terhubung ke lingkungan sumber akan berhenti menerima peristiwa telemetri dan informasi tentang status perangkat dari perangkat edge. Perangkat tidak dapat lagi mengirimkan perintah dan pembaruan konfigurasi ke perangkat edge.

Sebaiknya Anda juga menyediakan dan mengonfigurasi mekanisme penyimpanan buffer. Pendekatan ini membantu Anda menghindari kehilangan data saat perangkat mengirimkan peristiwa telemetri dan informasi tentang status perangkat ke lingkungan target saat beban kerja backend masih terhubung ke lingkungan sumber. Selanjutnya, beban kerja backend dapat menggunakan informasi ini ketika terhubung ke lingkungan target. Misalnya, Anda dapat mengonfigurasi retensi pesan di lingkungan target, berdasarkan broker MQTT, Pub/Sub, atau pada platform IoT. Dengan pendekatan ini, Anda dapat menyimpan pesan yang tidak dikonfirmasi tersedia saat yang diperlukan bagi Anda untuk menyelesaikan fase migrasi berikutnya, seperti yang dijelaskan di bagian berikut.

Memigrasikan beban kerja backend dari lingkungan sumber ke lingkungan target

Anda memigrasikan beban kerja backend ke lingkungan target. Bergantung pada arsitektur lingkungan target, Anda harus mengambil pendekatan yang berbeda untuk memigrasikan beban kerja.

MQTT Broker di Google Cloud: Jika lingkungan target Anda didasarkan pada broker MQTT, faktor-faktor berikut memandu pendekatan migrasi Anda:

  • Untuk workload backend yang memang menerima peristiwa telemetri atau informasi tentang status perangkat dari perangkat edge, tetapi tidak mengirim perintah atau pembaruan konfigurasi perangkat: Konfigurasikan backend untuk berlangganan topik MQTT guna menerima peristiwa telemetri dan informasi tentang status perangkat yang berasal dari perangkat edge.
  • Sebaliknya, untuk beban kerja backend yang tidak menerima peristiwa telemetri atau informasi tentang status perangkat, tetapi harus mengirim perintah atau pembaruan konfigurasi perangkat: Konfigurasikan backend Anda workload untuk memublikasikan pesan guna mengirim perintah dan update konfigurasi ke topik MQTT untuk update perintah dan konfigurasi di lingkungan target.
  • Untuk workload backend yang menerima peristiwa telemetri atau informasi tentang status perangkat dari perangkat edge dan mengirimkan perintah atau pembaruan konfigurasi perangkat: Konfigurasi workload backend Anda untuk berlangganan topik MQTT menerima telemetri, lalu konfigurasikan workload backend untuk memublikasikan pesan guna mengirim perintah dan update konfigurasi ke topik MQTT.

Pub/Sub: Jika lingkungan target Anda didasarkan pada Pub/Sub, faktor berikut memandu pendekatan migrasi Anda:

  • Untuk workload backend yang menerima peristiwa telemetri atau informasi tentang status perangkat dari perangkat edge, tetapi tidak mengirim perintah atau pembaruan konfigurasi perangkat: Buat baru Langganan Pub/Sub di lingkungan target, dan update workload backend Anda untuk menggunakan langganan yang baru dibuat.
  • Sebaliknya, untuk workload backend yang tidak menerima peristiwa telemetri atau informasi tentang status perangkat, tetapi selalu mengirimkan perintah atau update konfigurasi perangkat: Create Pub/Buat sub topik dan konfigurasikan workload backend Anda untuk memublikasikan pesan guna mengirim perintah dan pembaruan konfigurasi ke topik Pub/Sub.
  • Untuk workload backend yang menerima peristiwa telemetri atau informasi tentang status perangkat dari perangkat edge dan mengirimkan perintah atau pembaruan konfigurasi perangkat: Konfigurasikan workload backend Anda untuk berlangganan Pub/Sub topik untuk menerima peristiwa telemetri dan informasi tentang status perangkat. Kemudian, konfigurasikan workload backend Anda untuk memublikasikan pesan guna mengirim perintah dan pembaruan konfigurasi ke topik Pub/Sub.

Platform IoT pihak ketiga: Jika lingkungan target Anda didasarkan pada platform IoT pihak ketiga, Anda harus mengikuti petunjuk platform IoT pihak ketiga untuk menyiapkan integrasi antara beban kerja backend dan platform IoT. Kemudian, verifikasi bahwa beban kerja backend dapat menerima peristiwa telemetri dan informasi tentang status perangkat yang berasal dari perangkat edge. Anda juga memeriksa apakah beban kerja backend dapat memublikasikan pesan untuk mengirim perintah atau pembaruan konfigurasi perangkat ke perangkat edge.

Untuk memverifikasi bahwa perangkat edge dan beban kerja backend berfungsi seperti yang diharapkan, sebaiknya lakukan hal berikut:

  • Pastikan beban kerja backend menerima peristiwa telemetri dan informasi tentang status perangkat serta bereaksi dengan benar. Misalnya, jika beban kerja backend Anda menghasilkan dasbor yang hampir real time untuk memantau data telemetri tertentu, pastikan dasbor tersebut telah diperbarui dengan periode data terbaru.
  • Pastikan beban kerja backend mengirimkan perintah dan pembaruan konfigurasi ke perangkat edge seperti yang diharapkan. Pastikan perangkat edge juga bereaksi seperti yang Anda harapkan.
  • Verifikasi apakah perangkat edge melaporkan peristiwa telemetri dan informasi tentang status perangkat ke lingkungan target.

Pada tahap ini, beban kerja backend melakukan hal berikut:

  • Menghubungkan ke lingkungan target.
  • Menerima peristiwa dan informasi telemetri tentang status perangkat dari perangkat edge dari lingkungan target.
  • Mengirim perintah dan update konfigurasi ke perangkat edge dari lingkungan target.

Sekarang Anda dapat memperbarui konfigurasi retensi pesan lingkungan target yang ditetapkan ke nilai minimum saat Anda menghubungkan perangkat edge ke lingkungan sumber dan target , dan tetapkan sesuai dengan kebutuhan Anda.

Saat Anda memperbarui konfigurasi beban kerja backend untuk menerima peristiwa telemetri dan informasi tentang status perangkat dari lingkungan target, beban kerja backend mungkin memerlukan waktu untuk menerapkan konfigurasi yang diperbarui ini. Selama fase sementara, beban kerja backend tidak dapat menggunakan peristiwa telemetri dan informasi tentang status perangkat yang dikirim perangkat edge. Jika kasus penggunaan Anda memerlukan integritas data lengkap, Anda mungkin perlu mengonfigurasi periode retensi pesan di lingkungan target sebelum memperbarui konfigurasi beban kerja backend. Pendekatan ini memastikan bahwa masa berlaku pesan tidak berakhir sebelum beban kerja backend dapat menerapkan konfigurasi baru dan memakai pesan tersebut.

Mengupdate perangkat edge agar hanya terhubung ke lingkungan target

Pada tahap ini, Anda telah berhasil memigrasikan perangkat edge ke lingkungan target, tetapi perangkat tersebut juga masih menggunakan lingkungan sumber. Untuk menyelesaikan langkah migrasi, update perangkat edge Anda agar terhubung ke lingkungan target hanya dengan menghapus koneksi ke dan integrasi dengan IoT Core. Setelah update ini selesai, perangkat edge Anda hanya terhubung ke lingkungan target.

Penghapusan lingkungan sumber

Setelah memigrasikan perangkat edge dan beban kerja backend ke lingkungan target, dan memvalidasi lingkungan target, Anda akan menonaktifkan lingkungan sumber.

Untuk menonaktifkan lingkungan sumber, Anda melakukan hal berikut:

  1. Hapus langganan Pub/Sub yang berlangganan topik IoT Core.
  2. Menghapus topik Pub/Sub yang tidak digunakan. Jika Anda menggunakan kembali topik Pub/Sub, pastikan Anda tidak menghapus topik yang dibuat oleh IoT Core. Anda dapat menemukan topik Pub/Sub yang digunakan oleh IoT Core menggunakan konsol IoT Core.
  3. Hapus registry dan perangkat IoT Core.

Mengoptimalkan lingkungan Anda setelah migrasi

Pengoptimalan adalah fase terakhir dari migrasi Anda. Pada fase ini, Anda membuat lingkungan lebih efisien daripada sebelumnya. Pada fase ini, Anda menjalankan beberapa iterasi dari loop berulang hingga lingkungan Anda memenuhi persyaratan pengoptimalan. Langkah-langkah dari loop berulang ini adalah sebagai berikut:

  1. Menilai lingkungan, tim, dan loop pengoptimalan Anda saat ini.
  2. Menetapkan persyaratan dan sasaran pengoptimalan Anda.
  3. Mengoptimalkan lingkungan dan tim Anda.
  4. Menyesuaikan loop pengoptimalan.

Bagian berikut bergantung pada Migrasi ke Google Cloud: Mengoptimalkan lingkungan Anda.

Menilai lingkungan target, tim, dan loop pengoptimalan

Jika penilaian pertama yang Anda lakukan berfokus pada lingkungan sumber, fase penilaian ini ditujukan untuk fase pengoptimalan. Untuk mengetahui informasi selengkapnya tentang cara menilai lingkungan target, tim, dan loop pengoptimalan, lihat Mengukur lingkungan, tim, dan loop pengoptimalan.

Menetapkan persyaratan pengoptimalan

Tinjau persyaratan pengoptimalan berikut yang mungkin perlu Anda buat untuk lingkungan target Anda:

  • Menyiapkan penskalaan otomatis: Gunakan layanan Google Cloud seperti Managed Instance Group atau Google Kubernetes Engine untuk secara otomatis menskalakan solusi IoT dan workload backend Anda secara otomatis secara horizontal atau vertikal saat beban meningkat. Pendekatan ini membantu memastikan pendaftaran perangkat dan penyimpanan data telemetri Anda dapat menangani volume data yang lebih besar saat men-deploy perangkat yang besar. Karena Spanner adalah database transaksional yang terdistribusi, sangat tersedia, dan skalabel, cocok untuk menyimpan data telemetri dan informasi pendaftaran perangkat.
  • Meningkatkan mekanisme logging dan pemantauan: Optimalkan dan integrasikan mekanisme logging dan pemantauan Anda untuk membentuk solusi terpusat. Anda mungkin juga ingin meningkatkan metrik pemantauan tertentu untuk membantu memahami cara perangkat edge berinteraksi dengan solusi IoT Anda. Anda juga harus mencatat dan menghubungkan aktivitas seperti peristiwa menghubungkan, memutuskan peristiwa, dan peristiwa telemetri. Sebaiknya Anda juga memantau error sistem dan aplikasi. Jika memungkinkan, siapkan pemberitahuan saat terjadi kegagalan kritis tertentu di tingkat sistem.
  • Lindungi workload Anda dengan menggunakan layanan keamanan Google Cloud: Security Command Center adalah layanan pelaporan ancaman dan kerentanan terpusat yang dapat Anda gunakan untuk membantu memperkuat postur keamanan Anda dengan mengevaluasi keamanan dan permukaan serangan data Anda. Fitur ini menyediakan inventaris dan penemuan aset, serta dapat membantu Anda mengidentifikasi kesalahan konfigurasi, kerentanan, dan ancaman. Security Command Center juga membantu Anda memitigasi dan memulihkan risiko. Untuk mempelajari cara mengamankan beban kerja yang berjalan di Google Kubernetes Engine (GKE), lihat ringkasan keamanan Google Kubernetes Engine untuk memahami cara mengamankan beban kerja GKE Anda.

Selesaikan pengoptimalan

Setelah mengisi daftar persyaratan pengoptimalan, Anda akan menyelesaikan fase pengoptimalan. Untuk mempelajari cara melakukannya, lihat Migrasi ke Google Cloud: Mengoptimalkan lingkungan Anda.

Langkah selanjutnya