SPOF Tersembunyi di Fleet IoT: Gateway, Broker, SIM

SPOF Tersembunyi di Fleet IoT: Gateway, Broker, SIM

Dashboard fleet klien bisa hijau di semua perangkat, padahal satu kali reboot router cukup untuk memadamkan semuanya. Pola itu selalu saya temukan saat mengaudit deployment IoT: tidak ada yang memetakan apa saja yang ada di antara perangkat dan dashboard-nya. Padahal di situlah SPOF sebenarnya berada — single point of failure, satu titik yang kalau mati, semuanya ikut mati.

Peta SPOF yang jarang terlihat

Kebanyakan tim menguji sensornya habis-habisan — daya tahan baterai, drift kalibrasi, rating enclosure. Tapi mereka tidak pernah menanyakan hal yang sama untuk infrastruktur yang dilalui setiap pembacaan: satu MQTT broker (server pusat tempat semua perangkat setor dan mengambil pesan), satu gateway lokasi, satu SIM atau uplink ISP, satu sumber NTP, satu OTA server.

Di hari normal, kelimanya tidak kelihatan. Tapi satu saja gagal, seluruh fleet ikut padam. Dashboard yang cuma memantau perangkat menunjukkan 200 titik hijau sampai broker-nya mati, lalu berubah jadi 200 titik abu-abu yang tidak menjelaskan apa-apa.

Broker sebagai SPOF: clustering vs. bridged failover

Satu instance Mosquitto yang menangani seluruh fleet adalah SPOF yang paling sering saya temui — wajar, karena paling gampang dipasang. Begitu VM-nya reboot untuk patch kernel, semua perangkat antre mengirim pesan ke socket yang tidak merespons.

Clustering mendistribusikan broker itu sendiri. EMQX membagi node jadi peran Core (menangani write, direplikasi lewat layer Mria/RLOG) dan Replicant (read-only, menangani sesi client dan routing). Kalau satu atau lebih node offline, cluster-nya tetap berjalan. HiveMQ mengambil pendekatan masterless: setiap node setara, dan kalau satu node lepas, node yang tersisa menyerap trafiknya. Kompleksitas clustering 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 (default-nya), alamat pertama jadi koneksi utama dan alamat lain dicoba berurutan kalau yang utama gagal.

Ini bukan pembagian beban — broker cuma diberi jalur cadangan ke standby yang sudah terdokumentasi. Jangan pilih clustering karena terdengar lebih benar lalu tetap menjalankannya sebagai satu node; hasilnya tetap satu broker, cuma lebih ribet.

Gateway lokasi sebagai SPOF: buffer dulu, watchdog kedua

Gateway menerjemahkan Modbus, BACnet, atau serial jadi MQTT lalu meneruskannya ke broker. Saat koneksi WAN-nya putus sesaat — dan di lokasi industrial itu pasti terjadi — gateway tanpa buffer membuang semua pembacaan selama jeda itu. Baru ketahuan saat audit menemukan lubang datanya.

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 default, mengantre telemetri secara lokal dengan time-to-live yang bisa dikonfigurasi sampai koneksi kembali.

Polanya berlaku di platform apa pun: buffer-nya 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. Tapi ini tidak menolong kalau proses gateway-nya sendiri yang hang gara-gara library yang deadlock.

Untuk itulah watchdog ada: proses terpisah yang lebih sederhana, menunggu heartbeat pada interval tetap, dan me-restart paksa gateway kalau heartbeat-nya tidak muncul. Buffering menangani kegagalan jaringan; watchdog menangani kegagalan software.

Kapan cold-standby gateway sudah cukup

Tidak semua lokasi butuh gateway active-active. Kalau Anda menjalankan satu lokasi, downtime beberapa menit masih bisa ditoleransi, dan gateway-nya hardware komoditas yang murah, solusi malas yang tetap benar adalah unit kedua yang identik. Unit itu nganggur di rak dalam keadaan mati, lengkap dengan prosedur penggantian yang terdokumentasi: konfigurasi sama, kabel berlabel, runbook 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 cold-chain, tempat sepuluh menit berarti stok rusak. Tidak untuk lokasi retail yang sudah ditolong buffering lokal.

Uplink sebagai SPOF: kenapa SIM satu operator gagal bareng operatornya

Modem dual-SIM atau multi-operator adalah saran standar, tapi itu cuma melindungi dari gangguan radio di satu operator, bukan kegagalan di lapisan atasnya. Laporan FCC soal outage AT&T Februari 2024 menemukan satu network element yang salah konfigurasi.

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

Outage Rogers Communications di Kanada tahun 2022 punya penyebab serupa di lapisan berbeda: perubahan maintenance menghapus routing filter. Rogers menjalankan trafik wireless dan wireline lewat satu IP core yang sama, jadi kegagalannya ikut memadamkan terminal debit dan seperempat lampu lalu lintas Toronto. Ini bukan masalah menara radio yang bisa diselesaikan slot SIM kedua.

Persis di sinilah celah 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 mobile core yang sama, sehingga kegagalan core bisa menjatuhkan semua profil sekaligus. Redundansi uplink yang sungguhan untuk fleet 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 clock yang drift menggagalkan validasi sertifikat TLS, atau korelasi log lintas lokasi berantakan karena timestamp-nya tidak lagi sepakat soal urutan. Best practice NTP sudah ada sebelum IoT: pasang tiga atau lebih sumber Stratum 1, jangan pernah dua. Kalau servernya cuma dua dan keduanya berselisih, tidak ada cara tahu mana yang melenceng; dengan tiga, outlier-nya ketahuan dan bisa dikeluarkan.

Satu OTA server adalah SPOF yang jarang dianggarkan, karena baru terasa penting di hari terburuk: mendorong patch ke 500 perangkat saat endpoint update-nya justru sedang down.

Fleet yang tidak bisa mengirim telemetri keluar saat gangguan juga tidak bisa menerima patch masuk. Solusinya sama seperti NTP — endpoint yang di-mirror, bukan satu origin box saja — plus staged rollout supaya update yang bermasalah tidak langsung menghantam seluruh fleet sekaligus.

Kerangka keputusan: samakan redundansi dengan konsekuensi

Redundansi makan uang dan menambah kompleksitas, jadi pasang di titik yang kegagalannya benar-benar mahal. 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 buffer; untuk taruhan sekecil itu, clustering penuh cuma membayar risiko yang tidak ada.

Fleet cold-chain, atau apa pun yang memberi input ke pipeline alarm, butuh clustering dan uplink dual-SIM multi-core sejak hari pertama, karena celah yang tidak terdeteksi di sana berarti stok rusak, bukan cuma lubang di dashboard. Ini disiplin yang sama dengan single point of failure di sistem bisnis secara umum — fleet IoT cuma menyembunyikan lebih banyak titiknya. Begitu salah satu dari lima lapisan ini cuma punya satu jalur, dashboard yang hijau diam-diam berhenti jadi bukti fleet yang sehat.

Checklist penutup

• Broker: di-cluster, atau bridged dengan alamat failover yang terdokumentasi
• Gateway: buffering store-and-forward plus watchdog terpisah
• Gateway cadangan: cold spare dan runbook penggantian, disesuaikan dengan ongkos downtime sesungguhnya
• Uplink: SIM multi-operator atau multi-core, atau jalur fisik kedua
• NTP: tiga atau lebih sumber independen
• OTA: endpoint pengiriman redundan plus staged rollout

Kalau pemetaan seteliti ini perlu diterapkan ke deployment Anda, persis itulah audit yang kami jalankan sebagai bagian dari engagement pengembangan backend IoT.