Bali, Indonesia
Insights

Kegagalan Klaster Telemetri Pendingin Retail: Saturasi Disk Writeback dan Serialisasi Ekstrem pada MicroVM

October 13, 2026
0:00
Serangan terkoordinasi yang menargetkan rantai dingin ritel komersial di Eropa baru-baru ini mengungkap kelemahan mendasar dalam arsitektur penanganan telemetri edge terdistribusi. Pelaku memanfaatkan eksploitasi protokol MQTT broker yang terhubung ke puluhan ribu controller lemari pendingin supermarket, lalu menyuntikkan instruksi sinkronisasi masif berupa eksekusi siklus pencairan es otomatis (defrost cycle). Dampak fisik dari manipulasi ini bukan hanya kenaikan suhu makanan beku secara serentak, melainkan runtuhnya infrastruktur pemrosesan kendali di pusat data edge akibat badai konkurensi data serial. Di balik insiden fisik tersebut, infrastruktur backend yang bertugas memvalidasi safety-rules dan status termal kompresor dibangun di atas klaster bare-metal container dan Firecracker microVM. Ketika puluhan ribu kompresor mengirimkan konfirmasi perubahan state secara bersamaan, pipeline data kolaps. Masalah utamanya bukan sekadar throughput jaringan, melainkan degradasi performa I/O kernel Linux akibat saturasi dirty page writeback yang membekukan subsystem serialisasi disk pada layer virtualisasi.
Untuk mengisolasi tiap penyewa (tenant ritel supermarket) dan algoritma kontrol suhu lokal, sistem edge gateway menjalankan Firecracker microVM ringan yang dipadukan dengan unprivileged LXC container. Setiap microVM bertugas membaca pesan state dari message bus, mendekode muatan biner, mencocokkannya dengan batas ambang termal aman, lalu mencatat audit trail ke storage engine lokal (RocksDB berbasis WAL) sebelum meneruskan perintah override ke kompresor fisik. Alur kendali data berjalan sebagai berikut:
TEXT
[ Kompresor & Sensor ] --(MQTT/TLS)--> [ Ingress Gateway (LXC) ]
                                              |
                                     (UNIX Domain Socket)
                                              v
[ Safety State Engine ] <--(virtio-blk)-- [ MicroVM Tenant (Firecracker) ]
        |                                     |
        +------ [ NVMe Writeback Bottleneck ] -+
Ketika anomali injeksi perintah force defrost dikirimkan ke 120.000 titik refrigerator di berbagai wilayah Eropa, pesan konfirmasi status membanjiri ingress broker secara simultan. Setiap unit mengirimkan telemetri status daya pemanas (heating element) dengan frekuensi 100 Hz per unit, melonjak tajam dari batas normal 0.1 Hz. Lonjakan traffic ini menghasilkan gelombang throughput serialisasi data sebesar jutaan record per detik pada host edge.
Pada fase pemrosesan awal di dalam microVM, data biner Protobuf didekodekan oleh daemon pemrosesan. Karakteristik pesan defrost forced state memuat metadata telemetri lengkap, diagnostik sensor evaporator, dan histori beban kompresor. Dekode payload biner berukuran variabel dengan kecepatan tinggi ini langsung memicu heap fragmentation ekstrem pada alokator memori standar. Dalam proses debugging menggunakan perf pada node worker host, terlihat bahwa CPU habis terpakai bukan untuk logika validasi status pendingin, melainkan siklus spinlock alokasi memori dan serialisasi skema disk:
BASH
# Profiling call graph CPU pada thread runner microVM
perf top -p $(pgrep -f 'firecracker.*tenant-coldchain') --sort comm,dso,symbol
Hasil sampling menunjukkan dominasi konsumsi siklus clock pada malloc_consolidate, memcpy_erms, dan sinkronisasi thread saat serialisasi byte stream sebelum penulisan ke disk virtio:
TEXT
Overhead  Shared Object       Symbol
  31.20%  libc.so.6           [.] _int_malloc
  24.45%  coldchain-agent     [.] serde_json::to_writer
  18.12%  [kernel.kallsyms]   [.] copy_user_enhanced_fast_string
  11.30%  [kernel.kallsyms]   [.] balance_dirty_pages
   6.80%  coldchain-agent     [.] rocksdb::DBImpl::Write
Kombinasi overhead JSON/Protobuf parsing dan konkurensi alokasi memori menyebabkan proses ingestion kehilangan efisiensi cache L3. Namun, dampak terburuk terjadi di layer bawah ketika thread ingestion mencoba mengeksekusi write call untuk menjamin persistensi log audit sebelum mengeksekusi instruksi pembatalan siklus pencairan es.
Sistem operasi host Linux dikonfigurasi dengan kapasitas RAM 256 GB per node bare-metal. Pengaturan kernel default mengizinkan page cache menampung data kotor (dirty pages) hingga persentase tertentu sebelum memicu penulisan asinkron ke media penyimpanan NVMe backend. Di bawah beban normal, flusher kernel (flush-bdi) dapat mengalirkan data ke NVMe secara berkala tanpa menghentikan thread aplikasi. Namun, ketika gelombang data masuk melampaui kemampuan transfer agregat virtio-blk microVM, persentase dirty memory di host melompat melampaui vm.dirty_ratio. Ketika ambang batas ini terlampaui, kernel beralih dari mekanisme asinkron ke mekanisme penulisan synchronous yang memblokir proses (synchronous write throttle via balance_dirty_pages_ratelimited). Kondisi ini menciptakan rantai pemblokiran sistemik:
  1. Thread di dalam Firecracker microVM melakukan pemanggilan pwrite64() ke virtual block device (/dev/vda).
  2. Driver backend Firecracker di host mengeluarkan I/O asynchronous melalui io_uring atau epoll-driven AIO ke file backing disk di host filesystem (ext4/XFS).
  3. Host kernel mendeteksi bahwa dirty pages global telah melebihi batas toleransi, sehingga memaksa thread worker Firecracker masuk ke kondisi TASK_UNINTERRUPTIBLE (D-state) untuk menuliskan blok langsung ke NVMe.
  4. Karena thread Firecracker tertahan di kernel host, I/O queue virtio-blk di dalam microVM menjadi jenuh dan kehabisan slot ring buffer (ring buffer starvation).
  5. MicroVM kehabisan buffer untuk memproses pesan baru dari jaringan. Watchdog proses pendeteksi kondisi darurat mengasumsikan kegagalan I/O lokal, lalu mengalami timeout.
Akibat dari rangkaian kebuntuan I/O ini, instruksi abort darurat (safety kill-switch) untuk mematikan elemen pemanas evaporator gagal dieksekusi tepat waktu. Pemanas defrost terus aktif di ribuan unit pendingin hingga sistem proteksi hardware analog internal memutus daya berjam-jam kemudian.
Untuk mengidentifikasi letak kebuntuan I/O selama insiden berlangsung, metrik latensi blok I/O dianalisis menggunakan eBPF tool biolatency. Hasil pengukuran menunjukkan latensi penulisan disk melonjak dari normal 80 mikrosekon menjadi ratusan milisekon, bahkan beberapa request tertahan hingga lebih dari 2 detik.
BASH
# Menjalankan profiling latensi blok I/O secara real-time pada host storage
sudo biolatency-bpfcc -m -T 5
Output distribusi latensi I/O disk saat insiden terjadi:
TEXT
     msecs               : count     distribution
         0 -> 1          : 4210      |***                                     |
         2 -> 3          : 8940      |*******                                 |
         4 -> 7          : 15420     |*************                           |
         8 -> 15         : 38920     |*********************************       |
        16 -> 31         : 46110     |****************************************|
        32 -> 63         : 18450     |****************                        |
        64 -> 127        : 6200      |*****                                   |
       128 -> 255        : 1104      |                                        |
       256 -> 511        : 312       |                                        |
       512 -> 1023       : 88        |                                        |
      1024 -> 2047       : 14        |                                        |
Distribusi latensi di atas memperlihatkan ekor panjang (long-tail latency) hingga lebih dari 1000 milisekon. Pada skala jutaan I/O operations per second (IOPS), penundaan ini menyebabkan kegagalan kaskade (cascading failure) pada seluruh thread microVM yang mengontrol refrigerator. Kondisi antrean writeback kernel dapat dipantau langsung dari /proc/vmstat:
BASH
# Memantau throttling I/O dan dirty pages pada kernel host
watch -n 1 'grep -E "nr_dirty|nr_writeback|nr_dirtied|nr_written" /proc/vmstat'
Ketika insiden mencapai puncak, rasio nr_dirty melampaui jutaan blok, sementara laju penulisan disk fisik melambat karena storage controller mengalami internal garbage collection saturation pada layer flash NAND NVMe akibat pola I/O yang terfragmentasi.
Agar insiden serupa tidak terulang, sejumlah perombakan struktural diterapkan pada layer kernel host, konfigurasi microVM, dan mekanisme persistensi aplikasi.
Secara default, parameter writeback Linux dioptimalkan untuk batch processing umum, bukan untuk pipeline berlatensi rendah dengan konkurensi tinggi. Parameter dirty_background_ratio dan dirty_ratio diganti dengan perhitungan berbasis byte absolut agar flusher thread mulai menulis ke disk jauh sebelum dirty memory menumpuk dalam volume besar. Konfigurasi /etc/sysctl.d/99-storage-latency.conf:
INI
# Mulai background writeback saat dirty memory mencapai 512 MB
vm.dirty_background_bytes = 536870912

# Paksa proses memblokir dan menulis langsung jika dirty memory menyentuh 2 GB
vm.dirty_bytes = 2147483648

# Percepat siklus pengecekan flusher thread (100 = 1 detik)
vm.dirty_writeback_centisecs = 100

# Kurangi usia maksimum halaman dirty di memori sebelum dipaksa flush (500 = 5 detik)
vm.dirty_expire_centisecs = 500

# Kurangi agresivitas reclaim swap untuk mencegah memory latency spike
vm.swappiness = 10
Setelah menerapkan konfigurasi dengan sysctl --system, host tidak lagi menimbun puluhan gigabyte dirty memory, sehingga penulisan ke disk menjadi lebih rata dan teratur (smooth write stream).
File virtual disk yang digunakan oleh Firecracker microVM diubah untuk menggunakan flag O_DIRECT. Dengan flag ini, I/O dari dalam microVM langsung dialirkan ke drive NVMe tanpa melintasi host page cache. Hal ini mengeliminasi masalah double caching (halaman tersimpan di guest page cache dan host page cache sekaligus). Contoh konfigurasi disk block device pada Firecracker manifest:
JSON
{
  "drive_id": "rootfs",
  "path_on_host": "/srv/microvm/disks/tenant-store-42.ext4",
  "is_root_device": true,
  "is_read_only": false,
  "io_engine": "Async",
  "rate_limiter": {
    "bandwidth": {
      "size": 104857600,
      "refill_time": 100
    },
    "ops": {
      "size": 5000,
      "refill_time": 100
    }
  }
}
Selain io_engine Async yang memanfaatkan io_uring pada kernel Linux modern, penerapan rate limiter internal pada Firecracker mencegah satu microVM tenant memonopoli bandwidth disk host saat diserang banjir paket telemetri.
Untuk menjamin bahwa container worker dan Firecracker microVM pemroses sinyal kontrol kritis selalu mendapatkan alokasi I/O yang cukup, diterapkan isolasi berbasis cgroups v2 dengan konfigurasi io.weight dan io.latency:
BASH
# Membuat cgroup khusus untuk runtime microVM pengontrol keselamatan
sudo mkdir -p /sys/fs/cgroup/system.slice/safety-critical.slice

# Menetapkan bobot I/O lebih tinggi untuk critical safety microVM
echo "8:0 800" | sudo tee /sys/fs/cgroup/system.slice/safety-critical.slice/io.weight

# Menetapkan batas proteksi latensi target untuk NVMe device (8:0)
echo "8:0 target=5000" | sudo tee /sys/fs/cgroup/system.slice/safety-critical.slice/io.latency
Dengan konfigurasi ini, jika beban writeback dari tenant lain meningkat, kernel cgroup controller akan secara otomatis membatasi (throttle) I/O milik proses berbobot rendah guna mempertahankan latensi penulisan sub-5ms bagi proses kritis keselamatan.
Aplikasi lokal di dalam microVM dirombak agar tidak melakukan synchronous flush ke disk untuk setiap state perubahan minor. Logika validasi perintah kini dipisahkan dari persistence layer audit:
  1. State kompresor dievaluasi langsung di memori (in-memory state machine).
  2. Validasi keselamatan (safety gate) dieksekusi tanpa menunggu disk fsync.
  3. Log telemetri dialirkan ke WAL RocksDB dengan buffer asinkron, menggunakan direct allocator jemalloc dengan memory arena terisolasi guna menghindari konkurensi alokasi.
RUST
// Cuplikan inisialisasi RocksDB WAL options pada engine microVM
let mut opts = rocksdb::Options::default();
opts.create_if_missing(true);
opts.set_use_direct_io_for_flush_and_compaction(true);
opts.set_manual_wal_flush(true); // Hindari disk flush synchronous per record
opts.set_max_background_jobs(2);
opts.set_write_buffer_size(32 * 1024 * 1024); // 32MB MemTable buffer
Pengujian simulasi injeksi pesan force defrost sebesar 500.000 pesan per detik dijalankan kembali di lingkungan staging bare-metal yang identik. Tabel berikut merangkum metrik performa sistem sebelum dan sesudah tuning arsitektur diimplementasikan:
Metrik EvaluasiKonfigurasi Awal (Default)Konfigurasi Pasca-RemediasiDampak Operasional
Max Host Dirty Memory48.2 GB2.0 GB (dibatasi sysctl)Mencegah pembekuan flusher kernel
p99 Disk Write Latency1.840 ms4.2 msRespons I/O tetap deterministik
virtio-blk Queue Drops64.210 drops/menit0 drops/menitAntrean pesan microVM tidak tersumbat
CPU Time in D-State42.8% per host< 0.5% per hostThread bebas dari pemblokiran writeback
Latensi Eksekusi Safety Override14.200 ms (timeout)12 msPerintah defrost liar langsung dibatalkan
Throughput Serialisasi Disk4.100 IOPS (terfragmentasi)38.500 IOPS (sequential stream)Peningkatan throughput hingga 9.3x
Insiden manipulasi suhu jaringan supermarket ini membuktikan bahwa batas antara ancaman keamanan siber dan ketahanan sistem I/O bare-metal sangat tipis. Penyerang tidak perlu menembus kriptografi enkripsi end-to-end jika mereka dapat merekayasa payload yang memaksa subsystem virtualisasi masuk ke kondisi saturasi I/O writeback. Dalam membangun sistem telemetri berbasis container atau micro-virtualization yang mengontrol infrastruktur fisik kritis, dependensi disk synchronous pada alur validasi in-line harus dihindari secara mutlak. Memisahkan jalur persistensi dari jalur eksekusi aturan keselamatan, membatasi dirty page writeback pada kernel host, serta mengisolasi alokasi I/O menggunakan cgroups v2 dan Direct I/O adalah fondasi mutlak untuk mempertahankan determinisme komputasi edge di bawah tekanan serangan berskala masif.