SPOF IoT: Satu Titik Gagal, Banyak Perangkat Terputus

Dasbor dapat menampilkan semua perangkat sebagai sehat meski satu mulai ulang router akan memutus koneksinya. Saat meninjau sistem IoT, saya memetakan komponen di antara perangkat dan dasbor. Di jalur ini terdapat titik tunggal kegagalan atau SPOF: komponen tanpa jalur pengganti yang dapat menghentikan banyak perangkat sekaligus.

Peta SPOF yang jarang terlihat

Tim sering menguji baterai, pergeseran kalibrasi, dan ketahanan pelindung sensor. Lakukan pemeriksaan serupa untuk infrastruktur yang dilalui setiap pembacaan: satu MQTT broker (server pusat tempat semua perangkat setor dan mengambil pesan), satu gateway lokasi, satu SIM atau jalur keluar jaringan ISP, satu sumber NTP, satu OTA server.

Di hari normal, kelimanya tidak kelihatan. Dampaknya bergantung pada susunan sistem. Broker dapat menghentikan telemetri, sedangkan gangguan server pembaruan dapat menunda pembaruan tanpa menghentikan pembacaan. Dasbor yang hanya memantau perangkat menunjukkan 200 titik hijau sampai brokernya mati, lalu berubah jadi 200 titik abu-abu yang tidak menjelaskan apa-apa.

Cadangan broker: klaster atau peralihan melalui penghubung

Satu instance Mosquitto yang menangani seluruh kelompok perangkat adalah SPOF yang paling sering saya temui — wajar, karena paling gampang dipasang. Begitu mesin virtualnya mulai ulang untuk perbaikan kernel, semua perangkat antre mengirim pesan ke socket yang tidak merespons.

Clustering mendistribusikan broker itu sendiri. EMQX membagi node jadi peran Core (menangani penulisan, direplikasi lewat layer Mria/RLOG) dan Replicant (hanya-baca, menangani sesi klien dan pengalihan pesan). Kalau satu atau lebih simpul terputus, klasternya tetap berjalan. HiveMQ mengambil pendekatan masterless: setiap node setara, dan kalau satu node lepas, node yang tersisa menyerap trafiknya. Kompleksitas pengelompokan broker baru sepadan kalau satu broker melayani banyak lokasi.

Bridged failover adalah jawaban yang lebih ringan untuk satu lokasi. Konfigurasi bridge Mosquitto menerima beberapa alamat broker dalam satu koneksi. Dengan round_robin false (nilai bawaan), alamat pertama jadi koneksi utama dan alamat lain dicoba berurutan kalau yang utama gagal.

Pola penghubung ini menyediakan jalur cadangan, tanpa membagi beban. Jika memilih klaster, jalankan pada lebih dari satu simpul yang sesuai rancangan. Klaster dengan satu simpul tetap memiliki satu titik kegagalan.

Lindungi penghubung lokasi dengan antrean lokal dan pengawas proses

Gateway menerjemahkan Modbus, BACnet, atau serial jadi MQTT lalu meneruskannya ke broker. Jika koneksi WAN terputus, penghubung tanpa penyangga dapat kehilangan pembacaan selama jeda tersebut. Kehilangan ini mungkin baru diketahui ketika catatan diperiksa.

Solusinya adalah store-and-forward: tulis setiap pembacaan ke penyimpanan persisten lokal, biasanya SQLite, sebelum mencoba mengirimnya. Anggap seperti kotak surat lokal di kantor cabang: kalau kurir pusat belum bisa mengangkut, surat menumpuk di kotak dulu, bukan dibuang. edgeHub Azure IoT Edge melakukan ini secara bawaan, mengantre telemetri secara lokal dengan time-to-live yang bisa dikonfigurasi sampai koneksi kembali.

Polanya berlaku di platform apa pun: penyangganya nyaris kosong saat normal, membesar selama gangguan, dan mengalir keluar dalam batch kronologis begitu koneksi pulih. Pola ini mengubah gangguan WAN dari kehilangan data jadi sekadar penundaan. Penyimpanan lokal tetap tidak mengatasi proses penghubung yang berhenti karena pustaka saling menunggu tanpa akhir.

Untuk itulah pengawas proses ada: proses terpisah yang lebih sederhana, menunggu heartbeat pada interval tetap, dan memulai ulang secara paksa gateway jika sinyal berkala tidak muncul. Buffering menangani kegagalan jaringan; pengawas proses menangani kegagalan perangkat lunak.

Kapan unit penghubung cadangan sudah cukup

Tidak semua lokasi butuh gateway active-active. Kalau Anda menjalankan satu lokasi, downtime beberapa menit masih bisa ditoleransi, dan penghubungnya perangkat keras komoditas yang murah, pilihan sederhana adalah unit kedua yang identik. Unit cadangan disimpan dalam keadaan mati, lengkap dengan prosedur penggantian yang terdokumentasi: konfigurasi sama, kabel berlabel, panduan penanganan yang bisa diikuti teknisi tanpa perlu menelepon Anda.

Active-active memang memangkas menit-menit downtime itu, tapi ongkosnya sinkronisasi konfigurasi dan urusan split-brain yang tidak ada habisnya. Ongkos itu pantas dibayar di lokasi rantai dingin, tempat sepuluh menit berarti stok rusak. Tidak untuk lokasi ritel yang sudah ditolong buffering lokal.

Jalur keluar jaringan sebagai SPOF: kenapa SIM satu operator gagal bareng operatornya

Modem dual-SIM atau multi-operator dapat melindungi dari gangguan radio maupun jaringan inti satu operator jika jalur alternatifnya independen. Keduanya tetap tidak melindungi dari infrastruktur yang dipakai bersama. Laporan FCC soal gangguan AT&T Februari 2024 menemukan satu komponen jaringan yang salah konfigurasi.

Kegagalan itu memadamkan layanan suara dan data 5G secara nasional selama kira-kira 12 jam di semua perangkat AT&T. Gangguan ini memblokir lebih dari 92 juta panggilan, termasuk lebih dari 25.000 upaya menghubungi 911.

Gangguan Rogers Communications di Kanada tahun 2022 punya penyebab serupa di lapisan berbeda: perubahan pemeliharaan menghapus routing filter. Rogers menjalankan trafik seluler dan kabel lewat satu jaringan inti IP yang sama, jadi kegagalannya ikut memadamkan terminal debit dan seperempat lampu lalu lintas Toronto. Ini bukan masalah menara radio. Jalur operator yang independen dapat membantu, sedangkan SIM kedua yang memakai jaringan inti sama tetap ikut terdampak.

Risiko ketergantungan bersama ini juga perlu diperiksa pada kartu SIM multi-IMSI: kartu ini menyimpan beberapa profil operator dan berpindah saat satu jaringan radio tidak terjangkau. Tapi profil-profil itu umumnya tetap lewat satu jaringan inti seluler yang sama, sehingga kegagalan jaringan inti bisa menjatuhkan semua profil sekaligus. Redundansi jalur keluar jaringan yang sungguhan untuk kelompok perangkat yang tidak boleh padam berarti SIM multi-core atau jalur fisik kedua, bukan sekadar nama operator kedua di SIM yang sama.

Pasangan yang sering terlewat: NTP dan OTA

Satu sumber NTP kelihatan tidak berbahaya — sampai pergeseran waktu perangkat menggagalkan validasi sertifikat TLS, atau korelasi log lintas lokasi berantakan karena penanda waktunya tidak lagi sepakat soal urutan. Best practice NTP sudah ada sebelum IoT: gunakan sedikitnya empat sumber waktu yang independen dan beragam bila tersedia. Jika hanya dua server memberikan waktu berbeda, sulit menentukan sumber yang melenceng. Dengan tiga sumber, sistem dapat membandingkan hasil dan menyingkirkan sumber yang menyimpang.

Satu OTA server adalah SPOF yang jarang dianggarkan, karena baru terasa penting di hari terburuk: mendorong perbaikan ke 500 perangkat saat titik akses pembaruannya justru sedang tidak dapat diakses.

Fleet yang tidak bisa mengirim telemetri keluar saat gangguan juga tidak bisa menerima perbaikan masuk. Solusinya sama seperti NTP — titik akses cadangan di samping server utama — plus staged rollout supaya pembaruan yang bermasalah tidak langsung menghantam seluruh kelompok perangkat sekaligus.

Kerangka keputusan: samakan redundansi dengan konsekuensi

Redundansi menambah biaya dan kerumitan. Prioritaskan lapisan yang kegagalannya berdampak besar. Pertanyaannya bukan apakah suatu lapisan bisa gagal, tapi apa yang dikontrol perangkatnya dan berapa kerugian satu jam tanpa kabar darinya. Sensor kelembapan tanah yang lapor tiap jam cukup ditolong broker bridged dan penyangga; klaster penuh belum tentu sepadan dengan dampak gangguannya.

Fleet rantai dingin, atau apa pun yang memberi input ke alur pemrosesan alarm, butuh pengelompokan broker dan jalur keluar jaringan dual-SIM multi-core sejak hari pertama, karena celah yang tidak terdeteksi di sana berarti kerusakan stok, bukan hanya kekosongan data pada dasbor. Ini disiplin yang sama dengan single point of failure di sistem bisnis secara umum — kelompok perangkat IoT memiliki lebih banyak titik yang perlu diperiksa. Dasbor hijau belum membuktikan kesiapan menghadapi gangguan jika salah satu dari lima lapisan hanya memiliki satu jalur.

Daftar periksa tiap lapisan

• Broker: dikelompokkan dalam klaster, atau dihubungkan ke broker cadangan dengan alamat failover yang terdokumentasi
• Gateway: buffering store-and-forward plus pengawas proses terpisah
• Gateway cadangan: unit cadangan dalam keadaan mati dan panduan penanganan penggantian, disesuaikan dengan ongkos downtime sesungguhnya
• Jalur keluar jaringan: SIM multi-operator atau multi-core, atau jalur fisik kedua
• NTP: sedikitnya empat sumber independen dan beragam bila tersedia
• OTA: endpoint pengiriman redundan plus staged rollout

Jika Anda perlu memetakan ketergantungan pada sistem yang sudah terpasang, pekerjaan ini dapat dibahas dalam pengembangan sistem belakang IoT.