Mengelola koneksi ulang perangkat untuk membuat aplikasi tangguh

Artikel
10/17/2024

Artikel ini menyediakan panduan tingkat tinggi untuk membantu Anda merancang aplikasi tangguh dengan menambahkan strategi koneksi ulang perangkat. Ini menjelaskan mengapa perangkat terputus dan perlu terhubung kembali. Dan menjelaskan strategi khusus yang dapat digunakan pengembang untuk menyambungkan kembali perangkat yang telah terputus.

Apa yang menyebabkan pemutusan sambungan

Berikut ini adalah alasan paling umum bahwa perangkat terputus dari IoT Hub:

Token SAS kedaluwarsa atau sertifikat X.509. Token SAS perangkat atau sertifikat autentikasi X.509 kedaluwarsa.
Gangguan jaringan. Koneksi perangkat ke jaringan terganggu.
Gangguan layanan. Layanan Azure IoT Hub mengalami kesalahan atau sementara tidak tersedia.
Konfigurasi ulang layanan. Setelah Anda mengonfigurasi ulang pengaturan layanan IoT Hub, hal ini dapat menyebabkan perangkat memerlukan provisi ulang atau koneksi ulang.

Mengapa Anda memerlukan strategi koneksi ulang

Penting untuk memiliki strategi untuk menyambungkan kembali perangkat seperti yang dijelaskan di bagian berikut. Tanpa strategi koneksi ulang, Anda dapat melihat efek negatif pada performa, ketersediaan, dan biaya solusi Anda.

Upaya koneksi ulang massal dapat menyebabkan DDoS

Sejumlah besar upaya koneksi per detik dapat menyebabkan kondisi yang mirip dengan serangan penolakan layanan terdistribusi (DDoS). Skenario ini relevan untuk armada besar perangkat yang berjumlah jutaan. Masalah ini dapat meluas di luar penyewa yang memiliki armada, dan memengaruhi seluruh unit skala. DDoS dapat mendorong peningkatan biaya besar untuk sumber daya Azure IoT Hub Anda, karena kebutuhan untuk meluaskan skala. DDoS juga dapat merusak performa solusi Anda karena kelaparan sumber daya. Dalam kasus yang lebih buruk, DDoS dapat menyebabkan gangguan layanan.

Kegagalan hub atau konfigurasi ulang dapat memutuskan sambungan banyak perangkat

Setelah hub IoT mengalami kegagalan, atau setelah Anda mengonfigurasi ulang pengaturan layanan di hub IoT, perangkat mungkin terputus. Untuk failover yang tepat, perangkat yang terputus memerlukan provisi ulang. Untuk mempelajari selengkapnya tentang opsi failover, lihat Ketersediaan tinggi dan pemulihan bencana IoT Hub.

Provisi ulang banyak perangkat dapat meningkatkan biaya

Setelah perangkat terputus dari IoT Hub, solusi optimalnya adalah menyambungkan kembali perangkat daripada menyediakannya kembali. Jika Anda menggunakan IoT Hub dengan DPS, DPS memiliki biaya per provisi. Jika Anda memprovisikan ulang banyak perangkat di DPS, itu akan meningkatkan biaya solusi IoT Anda. Untuk mempelajari selengkapnya tentang biaya provisi DPS, lihat Harga DPS IoT Hub.

Desain untuk ketahanan

Perangkat IoT sering mengandalkan koneksi jaringan yang tidak berkelanjutan atau tidak stabil (misalnya, GSM atau satelit). Kesalahan dapat terjadi saat perangkat berinteraksi dengan layanan berbasis cloud karena ketersediaan layanan yang terputus-putus dan tingkat infrastruktur atau kesalahan sementara. Aplikasi yang berjalan pada perangkat harus mengelola mekanisme koneksi, koneksi ulang, dan logika coba lagi untuk mengirim dan menerima pesan. Selain itu, persyaratan strategi coba ulang sangat bergantung pada skenario, konteks, dan kemampuan IoT perangkat.

SDK perangkat Azure IoT Hub bertujuan untuk menyederhanakan koneksi dan komunikasi dari cloud-to-device dan device-to-cloud. SDK ini menyediakan cara yang andal untuk terhubung ke Azure IoT Hub dan serangkaian opsi lengkap untuk mengirim dan menerima pesan. Pengembang juga dapat memodifikasi implementasi yang ada untuk menyesuaikan strategi coba lagi yang lebih baik untuk skenario tertentu.

Fitur SDK relevan yang mendukung konektivitas dan pesan yang andal tersedia di SDK perangkat IoT Hub berikut. Untuk informasi selengkapnya, lihat dokumentasi API atau SDK tertentu:

Bagian berikut menjelaskan fitur SDK yang mendukung konektivitas.

Koneksi dan coba lagi

Bagian ini memberikan ringkasan tentang pola koneksi ulang dan percobaan kembali yang tersedia saat mengelola koneksi. Hal ini merinci panduan implementasi untuk menggunakan kebijakan coba lagi yang berbeda di aplikasi perangkat Anda dan mencantumkan API yang relevan dari SDK perangkat.

Pola kesalahan

Kegagalan koneksi dapat terjadi di berbagai tingkatan:

Kesalahan jaringan: soket terputus dan kesalahan resolusi nama
Kesalahan tingkat protokol untuk transport HTTP, AMQP, dan MQTT: tautan terlepas atau sesi kedaluwarsa
Kesalahan tingkat aplikasi yang disebabkan oleh kesalahan lokal: kredensial atau perilaku layanan yang tidak valid (misalnya, melebihi kuota atau pembatasan)

SDK perangkat mendeteksi kesalahan pada ketiga level. Namun, SDK perangkat tidak mendeteksi dan menangani kesalahan terkait OS dan kesalahan perangkat keras. Desain SDK didasarkan pada Panduan Penanganan Kesalahan Sementara dari Azure Architecture Center.

Mencoba lagi pola

Langkah-langkah berikut menjelaskan proses coba lagi ketika koneksi terdeteksi:

SDK mendeteksi kesalahan tersebut dan kesalahan lain yang terkait dalam jaringan, protokol, atau aplikasi.
SDK menggunakan filter kesalahan untuk menentukan jenis kesalahan dan memutuskan apakah coba lagi diperlukan.
Jika SDK mengidentifikasi kesalahan yang tidak dapat dipulihkan, operasi seperti koneksi, pengiriman, dan penerimaan akan dihentikan. SDK memberi tahu pengguna. Contoh kesalahan yang tidak dapat dipulihkan termasuk kesalahan autentikasi dan kesalahan titik akhir yang buruk.
Jika SDK mengidentifikasi kesalahan yang dapat dipulihkan, SDK akan mencoba lagi sesuai dengan kebijakan coba lagi yang ditentukan hingga batas waktu yang ditentukan berlalu. SDK menggunakan back-off Eksponensial dengan kebijakan coba lagi jitter secara default.
Saat batas waktu yang ditentukan berakhir, SDK berhenti mencoba menghubungkan atau mengirim. Hal ini memberi tahu pengguna.
SDK memungkinkan pengguna untuk melampirkan panggilan balik untuk menerima perubahan status koneksi.

SDK biasanya menyediakan tiga kebijakan coba lagi:

Back-off eksponensial dengan jitter: Kebijakan coba lagi default ini cenderung agresif di awal dan melambat seiring waktu hingga mencapai penundaan maksimum. Desainnya didasarkan pada Panduan coba lagi dari Azure Architecture Center.
Coba ulang khusus: Untuk beberapa bahasa SDK, Anda dapat merancang kebijakan coba lagi khusus yang lebih cocok untuk skenario Anda dan kemudian memasukkannya ke dalam RetryPolicy. Percobaan ulang kustom tidak tersedia di C SDK, dan saat ini tidak didukung pada Python SDK. Python SDK terhubung kembali sesuai kebutuhan.
Tidak ada coba lagi: Anda dapat mengatur kebijakan coba lagi ke "tidak ada coba lagi", yang menonaktifkan logika coba lagi. SDK mencoba untuk terhubung sekali dan mengirim pesan sekali, dengan asumsi koneksi telah dibuat. Kebijakan ini biasanya digunakan dalam skenario dengan bandwidth atau pertimbangan biaya. Jika Anda memilih opsi ini, pesan yang gagal terkirim akan hilang dan tidak dapat dipulihkan.

API Coba lagi

SDK	Metode SetRetryPolicy	Implementasi Kebijakan	Panduan implementasi
C	IOTHUB_CLIENT_RESULT IoTHubDeviceClient_SetRetryPolicy	Lihat: IOTHUB_CLIENT_RETRY_POLICY	Implementasi C
Java	SetRetryPolicy	Default: Kelas ExponentialBackoffWithJitter Kustom: menerapkan antarmuka RetryPolicy Tidak dapat dicoba lagi: kelas NoRetry	Implementasi Java
.NET	DeviceClient.SetRetryPolicy	Default: kelas ExponentialBackoff Custom: implementasi tampilan IRetryPolicy Tidak dapat dicoba lagi: kelas NoRetry	Implementasi C#
Simpul	setRetryPolicy	Default: Kelas ExponentialBackoffWithJitter Kustom: mengimplementasi tampilan RetryPolicy Tidak dapat dicoba lagi: kelas NoRetry	Implementasi node
Python	Saat ini tidak didukung	Saat ini tidak didukung	Percobaan ulang koneksi bawaan: Koneksi yang terputus dicoba kembali dengan interval 10 detik tetap secara default. Fungsionalitas ini dapat dinonaktifkan jika diinginkan, dan interval dapat dikonfigurasi.

Alur koneksi ulang hub

Jika Anda menggunakan IoT Hub hanya tanpa DPS, gunakan strategi koneksi ulang berikut.

Saat perangkat gagal tersambung ke IoT Hub, atau terputus dari IoT Hub:

Gunakan back-off eksponensial dengan fungsi penundaan jitter.
Sambungkan kembali ke IoT Hub.

Diagram berikut ini meringkas alur koneksi ulang:

Diagram alur koneksi ulang perangkat untuk IoT Hub.

Hub dengan alur koneksi ulang DPS

Jika Anda menggunakan IoT Hub dengan DPS, gunakan strategi koneksi ulang berikut.

Saat perangkat gagal tersambung ke IoT Hub, atau terputus dari IoT Hub, sambungkan kembali berdasarkan kasus berikut:

Skenario koneksi ulang	Strategi koneksi ulang
Untuk kesalahan yang memungkinkan percobaan ulang koneksi (kode respons HTTP 500)	Gunakan back-off eksponensial dengan fungsi penundaan jitter. Sambungkan kembali ke IoT Hub.
Untuk kesalahan yang menunjukkan percobaan ulang dimungkinkan, tetapi koneksi ulang telah gagal 10 kali berturut-turut	Provisi ulang perangkat ke DPS.
Untuk kesalahan yang tidak mengizinkan percobaan ulang koneksi (respons HTTP 401, Tidak Sah atau 403, Terlarang atau 404, Tidak Ditemukan)	Provisi ulang perangkat ke DPS.