Insiden OOM Akibat Komputasi Aperiodic Tiling

Penerapan generator diagram geometris baru sering kali membawa beban komputasi tidak terduga ke sistem background worker. Kasus Out-Of-Memory (OOM) kerap terjadi sesaat setelah deployment rilis generator diagram berbasis aperiodic tiling (seperti Penrose tiling P2 atau P3). Masalah utama muncul karena ekspansi rekursif dari aturan inflasi (subdivision) yang mengekspansi jumlah poligon secara eksponensial dalam memori kerja sebelum rasterisasi selesai.

Observasi Metrik: RSS Spikes dan Task Drop Rate

Saat algoritma tiling rekursif menerima parameter tingkat kedalaman (depth level) tanpa batas atas yang aman, alokasi heap melonjak drastis. Indikator berikut menandai kegagalan sistem pada monitoring APM/Prometheus:

  • Resident Set Size (RSS) Spike: RSS container worker melonjak dari kondisi normal baseline (<250 MiB) hingga menyentuh batas memory limit pod (>2 GiB) dalam hitungan milidetik.
  • Task Drop Rate dan Consumer Rebalance: OOM killer kernel Linux (exit code 137) menghentikan pod worker secara paksa. Hal ini memicu hilangnya acknowledgments pada broker pesan (RabbitMQ/Kafka), disusul lonjakan task drop rate dan rebalancing berulang pada consumer group.
  • Queue Lag Bertambah: Kegagalan berulang pada payload yang sama membuat antrean rendering macet dan menumpuk pesan tertunda secara eksponensial.

Prosedur Emergency: Rollback Deployment

Langkah pertama ketika pod worker mati terus-menerus adalah memutus siklus OOMKilled dengan mengembalikan versi deployment ke image stabil sebelumnya via Kubernetes CLI.

# Periksa riwayat deployment worker
kubectl rollout history deployment/diagram-render-worker -n processing

# Eksekusi rollback ke versi sebelumnya
kubectl rollout undo deployment/diagram-render-worker -n processing

# Verifikasi stabilitas pod pasca-rollback
kubectl get pods -n processing -l app=diagram-render-worker -w

Postmortem Singkat dan Akar Masalah

Akar masalah insiden ini berasal dari algoritma dekomposisi segitiga Robinson pada Penrose tiling. Setiap iterasi pembelahan segitiga emas (golden triangle) melipatgandakan jumlah objek simpul dan tepi secara matematis ($O(k^d)$ di mana $d$ adalah kedalaman rekursi). Ketiadaan validasi kedalaman input dari payload API menyebabkan worker mengeksekusi rekursi pada kedalaman di atas 8, menghasilkan jutaan segmen garis yang disimpan dalam heap memory sekaligus.

Isolasi Alokasi Rekursif ke Worker Sandbox

Komputasi geometris berat harus dipisahkan dari thread utama penanganan pesan antrean. Gunakan worker pool terpisah atau child process terisolasi dengan batasan alokasi memori internal.

// diagram_tiler.js - Isolasi proses komputasi rekursif
const { Worker, isMainThread, parentPort, workerData } = require('worker_threads');

const MAX_DEPTH = 6;

function subdividePenrose(triangles, currentDepth, maxDepth) {
  if (currentDepth >= maxDepth) return triangles;
  
  const result = [];
  for (let i = 0; i < triangles.length; i++) {
    const t = triangles[i];
    // Logika dekomposisi segitiga emas di sini
    // pony tail: alokasi flat buffer lebih efisien dibanding object literal
    result.push(...decompose(t));
  }
  return subdividePenrose(result, currentDepth + 1, maxDepth);
}

if (isMainThread) {
  module.exports = function renderTileAsync(tileConfig) {
    return new Promise((resolve, reject) => {
      if (tileConfig.depth > MAX_DEPTH) {
        return reject(new Error(`Input depth ${tileConfig.depth} melebihi batas aman (${MAX_DEPTH})`));
      }

      const worker = new Worker(__filename, {
        workerData: tileConfig,
        resourceLimits: { maxOldGenerationSizeMb: 512 } // Batasi V8 heap sandbox
      });

      worker.on('message', resolve);
      worker.on('error', reject);
      worker.on('exit', (code) => {
        if (code !== 0) reject(new Error(`Worker berhenti dengan exit code ${code}`));
      });
    });
  };
} else {
  const rendered = subdividePenrose(workerData.initialMesh, 0, workerData.depth);
  parentPort.postMessage(rendered);
}

Pencegahan Sistemik

1. Hard Limits pada Orchestrator Container

Pastikan setiap pod mendefinisikan kuota memori eksplisit agar OOM isolation tidak mengganggu node infrastruktur bersama.

resources:
  requests:
    memory: "512Mi"
    cpu: "500m"
  limits:
    memory: "1Gi"
    cpu: "1000m"

2. Circuit Breaker dan Healthcheck Consumer

Tambahkan guard rails sebelum antrean mengonsumsi tugas baru. Jika utilitas memori proses melampaui ambang batas 80%, worker harus menghentikan pengambilan pesan baru (pause consumer) dan me-reject payload bermasalah langsung ke Dead Letter Queue (DLQ).

// Evaluasi beban memori sebelum konsumsi tugas berikutnya
const MEMORY_THRESHOLD = 0.8;

function canProcessNextTask() {
  const mem = process.memoryUsage();
  const heapRatio = mem.heapUsed / mem.heapTotal;
  return heapRatio < MEMORY_THRESHOLD;
}

async function handleTask(channel, msg, payload) {
  if (!canProcessNextTask()) {
    // Circuit breaker aktif: lepas pesan kembali atau jeda consumption
    channel.nack(msg, false, true);
    await sleep(2000);
    return;
  }

  try {
    const result = await renderTileAsync(payload);
    channel.ack(msg);
  } catch (err) {
    // Kirim langsung ke DLQ bila payload terbukti fatal
    channel.reject(msg, false);
  }
}