Praktik terbaik bagi penyebaran perangkat IoT berskala besar

Menskalakan solusi IoT ke jutaan perangkat bisa menjadi tantangan. Solusi skala besar sering kali perlu dirancang sesuai dengan batas layanan dan langganan. Saat pelanggan menggunakan Azure IoT Device Provisioning Service, mereka menggunakannya dalam kombinasi dengan layanan dan komponen platform Azure IoT lainnya, seperti IoT Hub dan SDK perangkat Azure IoT. Artikel ini menjelaskan praktik terbaik, pola, dan kode sampel yang dapat Anda masukkan dalam desain Anda untuk memanfaatkan layanan ini dan memungkinkan penyebaran Anda untuk memperluas skala. Dengan mengikuti pola dan praktik ini mulai dari fase desain proyek, Anda dapat memaksimalkan performa perangkat IoT Anda.

Memprovisikan perangkat baru

Penyediaan pertama kali adalah proses onboarding perangkat untuk pertama kali sebagai bagian dari solusi IoT ini. Saat bekerja dengan penyebaran skala besar, penting untuk menjadwalkan proses provisi untuk menghindari situasi kelebihan beban yang disebabkan oleh semua perangkat yang mencoba terhubung pada saat yang sama.

Menggunakan jadwal penyediaan yang bertahap

Untuk penyebaran perangkat dalam skala jutaan, mendaftarkan semua perangkat sekaligus dapat mengakibatkan instans DPS kewalahan karena pembatasan (kode 429, Too Many Requestsrespons HTTP ) dan kegagalan untuk mendaftarkan perangkat Anda. Untuk mencegah pembatasan tersebut, gunakan jadwal pendaftaran yang bertahap untuk perangkat. Konfigurasikan ukuran batch pendaftaran perangkat Anda sesuai dengan kuota dan batas DPS. Misalnya, jika tingkat pendaftaran adalah 200 perangkat per menit, ukuran batch untuk onboarding akan menjadi 200 perangkat setiap batch.

Operasi Ulang

Jika kesalahan sementara terjadi karena layanan sibuk, logika coba lagi memungkinkan perangkat berhasil terhubung ke cloud IoT. Namun, sejumlah besar percobaan ulang dapat lebih menurunkan layanan sibuk yang berjalan mendekati atau pada kapasitasnya. Seperti halnya layanan Azure apa pun, Anda harus menerapkan mekanisme coba lagi cerdas dengan backoff eksponensial. Informasi lebih lanjut tentang pola coba lagi yang berbeda dapat ditemukan dalam pola desain coba lagi dan penanganan kesalahan sementara.

Daripada langsung mencoba kembali penerapan ketika dibatasi, sebaiknya tunggu hingga waktu yang ditentukan di header retry-after. Jika tidak ada header coba lagi yang tersedia dari layanan, algoritma ini dapat membantu mencapai pengalaman onboarding perangkat yang lebih lancar:

min_retry_delay_msec = 1000
max_retry_delay_msec = (1.0 / <load>) * <T> * 1000
max_random_jitter_msec = max_retry_delay_msec

Dengan logika ini, perangkat menunda koneksi ulang untuk jumlah waktu acak, antara min_retry_delay_msec dan max_retry_delay_msec. Penundaan percobaan kembali maksimum dihitung dengan variabel berikut:

  • <load> adalah faktor yang dapat dikonfigurasi dengan nilai > 0, yang menunjukkan bahwa beban bekerja pada rata-rata waktu muat dikalikan dengan jumlah koneksi per detik
  • <T> adalah waktu minimum absolut untuk melakukan cold boot perangkat (dihitung di T = N / cps mana N adalah jumlah total perangkat dan cps merupakan batas layanan untuk jumlah koneksi per detik).

Untuk informasi selengkapnya tentang pengaturan ulang waktu operasi, lihat Pengaturan Ulang Waktu.

Menyambungkan ulang vs konfigurasi ulang perangkat

Koneksi ulang adalah proses di mana perangkat perlu terhubung kembali ke hub IoT setelah berhasil terhubung sebelumnya melalui DPS dan terputus karena beberapa alasan. Provisi ulang adalah proses di mana perangkat perlu disediakan ke hub IoT baru. Misalnya, perangkat perlu diprovisikan ulang karena sedang dipindahkan ke hub di wilayah yang berbeda, dipindahkan dari pengembangan ke hub pengujian, atau perlu diinisialisasi ulang di hub yang dialokasikan sebelumnya.

Mungkin ada banyak alasan yang mengakibatkan kebutuhan perangkat untuk terhubung kembali ke hub IoT, seperti:

  • Perangkat di-boot ulang karena pemadaman listrik, hilangnya konektivitas jaringan, relokasi geografis, pembaruan firmware, reset pabrik, atau rotasi kunci sertifikat.
  • Instans IoT Hub untuk sementara tidak tersedia karena pemadaman IoT Hub yang tidak terencana.

Anda tidak perlu melalui proses provisi setiap kali perangkat di-boot ulang. Sebagian besar perangkat yang diprovisikan ulang akhirnya terhubung ke hub IoT yang sama. Sebagai gantinya, perangkat harus mencoba menyambungkan ke hub IoT-nya secara langsung menggunakan informasi yang di-cache dari koneksi yang berhasil sebelumnya.

Saat Anda mempertimbangkan untuk menyediakan ulang perangkat, tetapkan perangkat ke hub IoT yang berbeda dengan menggunakan kebijakan alokasi kustom.

Perangkat yang dapat menyimpan string koneksi

Perangkat yang memiliki kemampuan untuk menyimpan string koneksi mereka setelah provisi awal harus melakukannya dan mencoba terhubung kembali langsung ke IoT Hub setelah boot ulang. Pola ini mengurangi latensi dalam berhasil menyambungkan ke hub IoT yang sesuai. Ada dua kemungkinan kasus di sini:

  • Hub IoT yang digunakan untuk menghubungkan pada reboot perangkat adalah sama dengan hub IoT yang terhubung sebelumnya.

    String koneksi yang diambil dari cache akan berfungsi dengan baik dan perangkat dapat terhubung kembali ke titik akhir yang sama. Tidak perlu memulai dari awal untuk proses penyediaan.

  • Hub IoT untuk terhubung pada reboot perangkat berbeda dari hub IoT yang terhubung sebelumnya.

    String koneksi yang disimpan dalam memori tidak akurat. Mencoba menyambungkan ke titik akhir yang sama gagal sehingga mekanisme coba lagi untuk koneksi hub IoT dipicu. Setelah ambang batas untuk kegagalan koneksi hub IoT tercapai, mekanisme coba lagi secara otomatis memicu awal baru untuk proses provisi.

Perangkat yang tidak dapat menyimpan string koneksi

Beberapa perangkat tidak memiliki ruang atau memori yang cukup besar untuk mengakomodasi caching string koneksi dari koneksi hub IoT yang berhasil dilakukan sebelumnya. Perangkat ini perlu memprovisi ulang melalui DPS setelah reboot. Gunakan API pendaftaran DPS untuk mendaftar ulang. Perlu diingat bahwa jumlah pendaftaran ulang per menit terbatas berdasarkan batas pendaftaran perangkat DPS.

Sampel provisi ulang

Contoh kode pada bagian ini menunjukkan sebuah kelas untuk membaca dan menulis dari cache perangkat, diikuti dengan kode yang mencoba menyambungkan kembali perangkat ke hub IoT jika string koneksi ditemukan, dan jika tidak, mencoba melakukan provisi ulang melalui DPS.

using Newtonsoft.Json;
using System;
using System.Collections.Generic;
using System.IO;
using System.Linq;
using System.Text;

namespace ProvisioningCache
{
  public class ProvisioningDetailsFileStorage : IProvisioningDetailCache
  {
    private string dataDirectory = null;

    public ProvisioningDetailsFileStorage()
    {
      dataDirectory = Environment.GetEnvironmentVariable("ProvisioningDetailsDataDirectory");
    }

    public ProvisioningResponse GetProvisioningDetailResponseFromCache(string registrationId)
    {
      try
        {
          var provisioningResponseFile = File.ReadAllText(Path.Combine(dataDirectory, registrationId));

          ProvisioningResponse response = JsonConvert.DeserializeObject<ProvisioningResponse>(provisioningResponseFile);

          return response;
        }
      catch (Exception ex)
      {
        return null;
      }
    }

    public void SetProvisioningDetailResponse(string registrationId, ProvisioningResponse provisioningDetails)
    {
      var provisioningDetailsJson = JsonConvert.SerializeObject(provisioningDetails);

      File.WriteAllText(Path.Combine(dataDirectory, registrationId), provisioningDetailsJson);
    }
  }
}

Anda dapat menggunakan kode yang mirip dengan yang berikut ini untuk menentukan cara melanjutkan menyambungkan kembali perangkat setelah menentukan apakah ada info koneksi di cache:

IProvisioningDetailCache provisioningDetailCache = new ProvisioningDetailsFileStorage();

var provisioningDetails = provisioningDetailCache.GetProvisioningDetailResponseFromCache(registrationId);

// If no info is available in cache, go through DPS for provisioning
if(provisioningDetails == null)
{
  logger.LogInformation($"Initializing the device provisioning client...");
  using var transport = new ProvisioningTransportHandlerAmqp();
  ProvisioningDeviceClient provClient = ProvisioningDeviceClient.Create(dpsEndpoint, dpsScopeId, security, transport);
  logger.LogInformation($"Initialized for registration Id {security.GetRegistrationID()}.");
  logger.LogInformation("Registering with the device provisioning service... ");

  // This method will attempt to retry in case of a transient fault
  DeviceRegistrationResult result = await registerDevice(provClient);
  provisioningDetails = new ProvisioningResponse() { iotHubHostName = result.AssignedHub, deviceId = result.DeviceId };
  provisioningDetailCache.SetProvisioningDetailResponse(registrationId, provisioningDetails);
}

// If there was IoT Hub info from previous provisioning in the cache, try connecting to the IoT hub directly
// If trying to connect to the IoT hub returns status 429, make sure to retry operation honoring
//   the retry-after header
// If trying to connect to the IoT hub returns a 500-series server error, have an exponential backoff with
//   at least 5 seconds of wait-time
// For all response codes 429 and 5xx, reprovision through DPS
// Ideally, you should also support a method to manually trigger provisioning on demand
if (provisioningDetails != null)
{
  logger.LogInformation($"Device {provisioningDetails.deviceId} registered to {provisioningDetails.iotHubHostName}.");
  logger.LogInformation("Creating TPM authentication for IoT Hub...");
  IAuthenticationMethod auth = new DeviceAuthenticationWithTpm(provisioningDetails.deviceId, security);
  logger.LogInformation($"Testing the provisioned device with IoT Hub...");
  DeviceClient iotClient = DeviceClient.Create(provisioningDetails.iotHubHostName, auth, TransportType.Amqp);
  logger.LogInformation($"Registering the Method Call back for Reprovisioning...");
  await iotClient.SetMethodHandlerAsync("Reprovision",reprovisionDirectMethodCallback, iotClient);

  // Now you should start a thread into this method and do your business while the DeviceClient is still connected
  await startBackgroundWork(iotClient);
  logger.LogInformation("Wait until closed...");

  // Wait until the app unloads or is cancelled
  var cts = new CancellationTokenSource();
  AssemblyLoadContext.Default.Unloading += (ctx) => cts.Cancel();
  Console.CancelKeyPress += (sender, cpe) => cts.Cancel();

  await WhenCancelled(cts.Token);
  await iotClient.CloseAsync();
  Console.WriteLine("Finished.");
}

Pertimbangan konektivitas IoT Hub

Setiap hub IoT tunggal dibatasi hingga 1 juta perangkat ditambah modul. Jika Anda berencana untuk memiliki lebih dari satu juta perangkat, batasi jumlah perangkat hingga 1 juta per hub dan tambahkan hub sesuai kebutuhan saat meningkatkan skala penyebaran Anda. Untuk informasi selengkapnya, lihat kuota dan pembatasan IoT Hub. Jika Anda memiliki rencana untuk lebih dari satu juta perangkat dan Anda perlu mendukungnya di wilayah tertentu (seperti di wilayah Uni Eropa untuk persyaratan residensi data), Anda dapat menghubungi kami untuk memastikan bahwa wilayah yang Anda sebarkan memiliki kapasitas untuk mendukung skala Anda saat ini dan di masa mendatang.

Saat perangkat terhubung ke IoT Hub melalui DPS, perangkat harus menggunakan logika berikut sebagai respons terhadap kode kesalahan saat menyambungkan:

  • Saat menerima salah satu dari 500 rangkaian respons kesalahan server, coba lagi koneksi menggunakan kredensial cache atau hasil panggilan API Pencarian Status Pendaftaran Perangkat.
  • Saat menerima 401, Unauthorized atau 403, Forbidden atau 404, Not Found, lakukan pendaftaran ulang penuh dengan memanggil API pendaftaran DPS.

Perangkat harus mampu merespons perintah pengaturan ulang yang dimulai pengguna kapan saja.

Jika perangkat terputus dari IoT Hub, mereka mencoba terhubung kembali langsung ke hub IoT yang sama selama 15-30 menit sebelum mencoba kembali ke DPS untuk merealokasi ke hub IoT baru. Dalam skenario ini, jika hub mengalami gangguan dan hub IoT tidak dihapus dari pendaftaran DPS, perangkat mencoba terhubung kembali ke hub yang sama yang sedang tidak tersedia. Proses ini menyebabkan kegagalan penyediaan untuk terhubung ke hub dan menyebabkan efek kegagalan yang semakin bertambah secara eksponensial. Pastikan hub IoT tidak dihapus dari lingkungan Anda dan tersedia.

Memantau perangkat

Bagian penting dari penyebaran keseluruhan adalah memantau solusi secara menyeluruh untuk memastikan bahwa sistem berkinerja dengan tepat. Ada beberapa cara untuk memantau kesehatan layanan untuk penyebaran skala besar perangkat IoT. Pola berikut terbukti efektif dalam memantau layanan:

  • Buat aplikasi untuk mengkueri setiap grup pendaftaran pada instans DPS, mendapatkan total perangkat yang terdaftar ke grup tersebut, lalu mengagregasi angka dari berbagai grup pendaftaran. Jumlah ini memberikan jumlah pasti perangkat yang saat ini terdaftar melalui DPS dan dapat digunakan untuk memantau status layanan.
  • Pantau pendaftaran perangkat selama periode tertentu. Misalnya, pantau tingkat pendaftaran untuk instans DPS selama lima hari sebelumnya. Pendekatan ini hanya memberikan perkiraan angka dan juga dibatasi untuk periode waktu.

Langkah berikutnya

  • Last updated on