Belajar OpenClaw - Performance Tuning & Scalability

#Pendahuluan

Di episode 14 kalian belajar membaca OpenClaw saat insiden — flow log, audit log, dan korelasi dengan traces. Tapi ada satu jenis insiden yang paling berbahaya karena bertopeng kinerja normal: ketika OpenClaw sendiri yang menjadi titik lambat. Policy yang dievaluasi dengan lambat berarti setiap request ikut lambat, dan kontrol plane yang kewalahan berarti seluruh cluster kehilangan pengarah.

Episode 15 berfokus pada mesinnya: sizing control plane dan data plane, optimasi evaluasi policy, serta horizontal scaling dan high availability. Tujuannya sederhana — keputusan policy harus datang secepat dan setahanal mungkin.

#Memahami Profil Resource OpenClaw

OpenClaw punya dua bagian dengan beban yang berbeda. Control plane mengelola policy, sertifikat, dan sinkronisasi state; beban kerjanya tumbuh seiring jumlah namespace, policy, dan service yang didaftarkan, bukan dari volume request. Data plane — agen di setiap node atau sidecar — mengevaluasi policy per request; bebannya tumbuh seiring throughput traffic dan kompleksitas rule.

Ini konsekuensi penting: menambah ribuan request per detik tidak menyulitkan control plane, tapi menyulitkan data plane. Sebaliknya, menambah ratusan policy tanpa request pun membebani control plane karena harus menyebarkan state. Sizing yang benar dimulai dari memahami pembagian ini, bukan menebak dari total CPU cluster.

#Sizing Control Plane dan Data Plane

Cara paling jujur untuk sizing adalah mengukur, bukan menerka. Gunakan metrik eksposur yang kalian lihat di episode 14:

openclaw metrics control-plane --window 24h
openclaw metrics data-plane --window 24h
openclaw bench policy --workload checkout-flow

openclaw bench policy memuat simulasi workload dengan pola realistis dan mengembalikan latensi p50/p99 evaluasi — angka paling berharga untuk menentukan ukuran replica. Aturan praktis yang bisa dijadikan titik awal: untuk kontrol plane, beri 512MB hingga 1GB memori per 200 policy dengan leader election aktif; untuk data plane, sekitar 50ms CPU per ribuan request per detik tergantung kompleksitas rule. Setelah itu, biarkan baseline dari cluster kalian sendiri yang bicara.

Pastikan juga container menyetujui batas resource yang sesuai dengan profil, agar scheduler tidak menaruh replica berlebih di node kecil:

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

#Optimasi Evaluasi Policy

Latensi evaluasi policy adalah biaya yang dibayar setiap request, jadi kemenangan kecil di sini berlipat ganda. Empat teknik yang paling berdampak:

Indexing: pastikan policy memakai label selector yang unik dan disebarkan sebagai index, bukan evaluasi linear per rule. Rule yang bisa di-index dengan app=web-store jauh lebih cepat daripada rule yang mengecek isi body setiap request.

Urutan rule: letakkan rule yang paling sering cocok paling atas. OpenClaw menghentikan evaluasi saat keputusan sudah pasti (short-circuit), jadi rule pertama yang cocok menghemat seluruh evaluasi berikutnya.

Hindari regex berat: pola regex yang rumit di rule layer 7 adalah pembunuh latensi. Ganti dengan prefix matching atau matcher yang lebih sederhana bila memungkinkan.

Cache keputusan: keputusan untuk kombinasi sumber-tujuan yang sama jarang berubah dalam beberapa detik. Aktifkan caching dengan TTL pendek:

apiVersion: openclaw.io/v1
kind: PerformanceConfig
metadata:
  name: tuned
  namespace: openclaw-system
spec:
  decisionCache:
    enabled: true
    ttlSeconds: 5
    maxEntries: 10000
  ruleOrder: frequency
  indexing: auto

Hati-hati dengan TTL cache yang terlalu panjang: keputusan yang di-cache terlalu lama bisa membuat policy baru tidak langsung berlaku. TTL 3-5 detik memberi keseimbangan antara kecepatan dan keaktualan.

#Horizontal Scaling dan High Availability

Data plane mengikuti jumlah node cluster — setiap node punya agen yang bisa direplikasi sesuai beban. Control plane, sebagai komponen stateful, butuh pola high availability: replica aktif dengan leader election. Hanya satu leader yang menulis, sisanya standby dan siap mengambil alih saat leader gagal.

Konfigurasi scaling dan HA:

apiVersion: openclaw.io/v1
kind: ControlPlaneConfig
metadata:
  name: ha-prod
  namespace: openclaw-system
spec:
  replicas: 3
  leaderElection:
    enabled: true
    leaseDurationSeconds: 15
  affinity:
    podAntiAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        - labelSelector:
            matchLabels:
              app: openclaw-control-plane
          topologyKey: topology.kubernetes.io/zone

podAntiAffinity memaksa tiga replica tersebar di tiga zone berbeda — satu zone mati, dua lainnya tetap melayani. Untuk beban yang naik turun, kombinasikan dengan autoscaler berbasis metrik evaluasi:

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: openclaw-control-plane
  namespace: openclaw-system
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: openclaw-control-plane
  minReplicas: 3
  maxReplicas: 6
  metrics:
    - type: Pods
      pods:
        metric:
          name: openclaw_policy_eval_latency_ms
        target:
          type: AverageValue
          averageValue: 5

Terakhir, lindungi komponen kritis dengan PodDisruptionBudget agar pemeliharaan node tidak menghentikan semua replica sekaligus:

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: openclaw-control-plane
  namespace: openclaw-system
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app: openclaw-control-plane

#Penutup

Episode 15 memberi OpenClaw mesin yang pantas untuk produksi: sizing berbasis pengukuran, bukan tebakan; optimasi evaluasi policy lewat indexing, urutan rule, dan caching; serta high availability dengan leader election, anti-affinity antar zone, dan disruption budget. OpenClaw kini cepat menjawab dan tahan pukulan.

Inti yang harus dibawa pulang:

• Control plane dibebani jumlah policy dan service; data plane dibebani throughput dan kompleksitas rule.
• Ukur baseline dengan openclaw bench policy sebelum menentukan ukuran replica.
• Index rule, urutkan berdasarkan frekuensi, hindari regex berat, dan pakai decision cache dengan TTL pendek.
• Control plane butuh HA: replica dengan leader election dan penyebaran antar zone.
• Uji failover secara rutin; HA yang tidak teruji belum bisa dipercaya.

Mesin sudah kencang, tapi kadang kebutuhan unik tidak tercakup fitur bawaan. Di episode 16 kita membuka kotaknya: Custom Extensions & Plugins — modul policy kustom, integrasi sumber data eksternal, dan hook evaluasi rule lanjutan. Sampai jumpa di sana!