Perbandingan Edge Computing dan Arsitektur Terpusat

Edge computing membawa pemrosesan data lebih dekat ke sumbernya untuk mengurangi latency dan konsumsi bandwidth.

Tulisan ini membahas perbedaan utama antara arsitektur terpusat dan edge, keuntungan dan keterbatasannya, tantangan keamanan, contoh kasus industri, serta panduan migrasi praktis. Tujuannya agar kamu bisa menentukan kapan memilih solusi terdistribusi atau tetap di pusat data.

Definisi dan Konsep Dasar Edge Computing untuk IoT

💻 Mulai Belajar Pemrograman

Belajar pemrograman di Dicoding Academy dan mulai perjalanan Anda sebagai developer profesional.

Daftar Sekarang

Edge computing adalah pendekatan komputasi di mana data IoT diproses sedekat mungkin dengan sumbernya. Misalnya langsung di sensor, gateway, atau perangkat lokal, bukan dikirim seluruhnya ke cloud.

Berbeda dengan cloud yang terpusat di pusat data besar, dan fog yang berada di lapisan antara jaringan lokal dan cloud, lapisan edge berada di “ujung” jaringan tempat data lahir. Karena jalur data lebih pendek, pendekatan ini cocok untuk skenario yang tidak boleh terlambat sepersekian detik.

Secara historis, ide ini dapat ditelusuri dari CDN (Content Delivery Network) yang mendistribusikan konten lebih dekat ke pengguna, lalu berkembang menjadi hosting terdistribusi, hingga modern edge yang bisa menjalankan container dan serverless function di banyak lokasi kecil.

Dalam arsitektur IoT, lapisan edge umumnya terdiri dari:

Edge device (sensor, kamera, aktuator)
Edge gateway sebagai penghubung dan agregator
Micro data center kecil di lokasi strategis
Orchestrator terpusat untuk mengatur penempatan workload, pembaruan aplikasi, dan pemantauan ribuan node

Di ekosistem IoT, sensor mengumpulkan data (suhu, getaran, video), lalu sebagian logika dijalankan di perangkat atau gateway untuk memutuskan aksi cepat.

Misalnya, mematikan mesin atau mengunci pintu. Ini mengurangi latency, menghemat bandwidth (hanya data penting yang dikirim ke cloud), dan memungkinkan respons hampir real-time.

Tantangannya: sumber daya perangkat edge terbatas, manajemen konfigurasi dan keamanan lebih kompleks, serta update dan orchestration harus sangat rapi agar tidak memicu kegagalan luas.

Arsitektur Terpusat: Karakteristik dan Keterbatasan

Pada arsitektur terpusat, data dari perangkat IoT dikirim ke data center atau cloud untuk diproses dan disimpan, lalu hasilnya dikembalikan ke lapangan. Pola umum: sensor → message broker di cloud → layanan backend (analitik/integrasi) → perintah balik ke device.

Kelebihan:

Konsolidasi komputasi, penyimpanan, dan keamanan di satu tempat (lebih mudah diaudit)
Skalabilitas relatif mudah (tambah compute/storage)
Operasional dan patching lebih terpusat

Keterbatasan:

End-to-end latency ke cloud publik umumnya sekitar 50 hingga >200 ms (tergantung jarak dan kualitas jaringan)
Cocok untuk analitik batch, backup, ERP, dan data historis besar
Kurang cocok untuk kontrol real-time yang butuh respons di bawah puluhan milidetik

Perbandingan Latency, Bandwidth, dan Pemrosesan

Saat membandingkan terpusat vs edge computing, metrik penting:

Latency
Throughput
Jitter
Konsumsi bandwidth
Kebutuhan komputasi lokal (CPU/GPU) vs pusat

Di edge, latency biasanya lebih rendah (puluhan milidetik) dan jitter lebih stabil, sehingga cocok untuk kontrol real-time. Namun, tiap node perlu sumber daya komputasi dan pengelolaan yang memadai. Di pusat, kapasitas komputasi dan throughput agregat besar, tetapi latency dan variasinya lebih tinggi karena faktor jaringan.

Bentuk dan volume data menentukan strategi:

Data sensor kecil (misalnya suhu tiap 1 detik) relatif ringan → masih masuk akal dikirim terus ke pusat.
Video besar lebih cocok diproses lokal. Contoh: kamera 4K H.265 30 fps ≈ 5–8 Mbps per kamera. Sepuluh kamera berarti puluhan Mbps stabil 24 jam, belum termasuk biaya simpan.

Strategi optimasi yang umum:

Caching hasil inferensi di edge
Filtering agresif (kirim anomali/event saja)
Batch upload saat jam sepi
Compression adaptif
Turunkan frekuensi sampling dan kirim ringkasan statistik

Kesimpulannya, pertanyaan realistis sering bukan “edge atau pusat”, melainkan kombinasi paling efisien (model hybrid).

Keamanan & Privasi pada Sistem Terdistribusi

Pemrosesan yang tersebar memperlebar permukaan serangan karena node berada di banyak lokasi. Risiko datang dari jaringan, akses fisik, dan ketidakseragaman operasi.

Risiko Keamanan Utama

Perangkat bisa dicuri, dibongkar, atau dimodifikasi di lapangan
Lalu lintas data berpotensi disadap atau dimanipulasi
Konfigurasi keamanan bisa tidak seragam (misalnya sebagian gateway sudah mTLS, sebagian belum)

Fondasi Keamanan yang Perlu Diprioritaskan

Enkripsi end-to-end dengan mutual TLS (mTLS)
Hardware root of trust untuk identitas perangkat tepercaya
Secure boot agar perangkat hanya menjalankan firmware valid
Kontrol identitas dan otorisasi ketat (least privilege)

Privasi, Kepatuhan, dan Data Residency

Regulasi (GDPR, data residency, dll.) bisa memaksa desain arsitektur tertentu:

Data mentah sensitif disimpan di lokasi asal/wilayah yang diwajibkan
Data ke pusat dibatasi pada data pseudonim/anonim atau ringkasan/event

Manajemen Kunci & Pembaruan (Lifecycle Security)

Secure element atau HSM untuk penyimpanan kunci (bila memungkinkan)
Key rotation berkala
Wajib code signing untuk firmware
OTA terenkripsi, terautentikasi, dan punya mekanisme rollback aman

Monitoring, Audit, dan Forensik

Distributed logging dengan format konsisten
Sinkronisasi waktu andal (mis. secure NTP)
Log dikirim ke SIEM terpusat + buffer lokal saat jaringan putus

Kasus Penggunaan Nyata dan Contoh Industri

Manufaktur (OT/IIoT)

Target latency: < 5–10 ms, reliabilitas sangat tinggi
Edge cluster di pabrik untuk stream processing, cloud untuk histori dan pelatihan ML
Perlu redundansi dan segmentasi jaringan

Smart city

Lampu lalu lintas adaptif dan analitik kamera
Gateway per persimpangan menjalankan computer vision, pusat menerima metadata
Perlu OTA kuat dan fallback lokal

Healthcare

Alarm cepat + privasi ketat
Deteksi anomali lokal, data ke cloud dalam bentuk pseudonim
Tantangan: pengelolaan kunci dan pembaruan perangkat

Cloud gaming & AR/VR

Target end-to-end latency: < 20 ms
Edge POP dekat pengguna + GPU terdistribusi, control plane tetap terpusat
Tantangan: capacity planning, autoscaling, QoS

Retail

Butuh andal saat jam sibuk, latency ratusan ms cukup
Store node menyimpan cache katalog/harga/model, sinkron periodik
Risiko: konflik data dan model drift → versioning + replikasi terjadwal

Strategi Migrasi dan Kapan Memilih Arsitektur Terdistribusi

Mulai dari checklist:

Target latency end-to-end
Volume data per hari dan biaya transfer/storage
Batas cost per GB
Regulasi dan compliance
SLA uptime dan RTO/RPO

Panduan umum:

Jika butuh respons < puluhan ms dan data mentah besar → proses awal di edge lebih masuk akal
Jika SLA longgar dan data moderat → terpusat biasanya lebih hemat dan sederhana

Langkah migrasi:

Audit workload: pilih kandidat paling sensitif terhadap latency dan biaya jaringan
Rancang hybrid: batas jelas data mana diproses lokal vs dikirim ke cloud
Pilih platform: orkestrasi yang cocok untuk edge, runtime ringan, monitoring terdistribusi
Pilot kecil dengan metrik: latency, error rate, biaya jaringan, beban tim operasi
Siapkan operasi: OTA aman, health check, fallback, graceful degradation
Evaluasi ROI/KPI: penghematan per lokasi, peningkatan SLA, penurunan latency, dampak ke produktivitas tim

Jika indikator membaik dan kompleksitas masih terkendali, lanjutkan migrasi bertahap.

Penutup

Pemilihan arsitektur harus didasarkan pada kebutuhan latency, volume data, biaya, serta keamanan dan kepatuhan. Gunakan pendekatan hybrid bila perlu, mulai dari pilot terukur, lalu skalakan berdasarkan KPI/ROI dan kesiapan operasi. Untuk sistem IoT yang butuh respons cepat dan penghematan bandwidth, edge computing sering menjadi komponen kunci dalam arsitektur modern.