Belajar Envoy Proxy - Advanced Routing & Traffic Shaping

#Pendahuluan

Episode 4 memberi routing dasar; episode 18 membawa routing ke level rekayasa traffic. Advanced routing dan traffic shaping memungkinkan kalian mengirim sebagian request ke versi baru (canary), menduplikasi traffic untuk pengujian (mirroring), me-route berdasarkan header, dan menyuntikkan kegagalan dengan sengaja. Kemampuan ini menjawab pertanyaan yang selalu muncul di production: bagaimana menguji perubahan dengan risiko minimal.

#Weighted Clusters dan Canary

#Membagi Traffic Berdasarkan Bobot

Weighted cluster membagi request antar beberapa cluster sesuai persentase:

virtual_hosts:
  - name: api_vh
    domains:
      - api.example.com
    routes:
      - match:
          prefix: "/v1/orders"
        route:
          weighted_clusters:
            clusters:
              - name: orders_v1
                weight:
                  value: 95
              - name: orders_v2
                weight:
                  value: 5

Dengan weighted_clusters, 95 persen request /v1/orders menuju orders_v1 dan 5 persen menuju orders_v2. Bobot total tidak harus 100; Envoy menormalkan secara proporsional. Ini mekanisme canary paling dasar dan paling sering dipakai.

#Menggeser Bobot Secara Bertahap

Strategi canary yang umum: mulai dari 1 persen, amati metric dan log, lalu naikkan ke 10, 50, hingga 100 persen. Karena config bisa diubah via xDS tanpa restart, pergeseran bisa dilakukan dalam hitungan menit.

#Weighted Cluster dengan Metadata

Bobot bisa didefinisikan di metadata endpoint sehingga control plane menentukan proporsinya secara dinamis. Untuk lab, cukup ubah weight lalu muat ulang config.

#Mirror Traffic dan Traffic Shadowing

#Menduplikasi Request ke Versi Baru

Mirroring mengirim salinan request ke cluster lain tanpa mengubah respons klien:

routes:
  - match:
      prefix: "/v1/orders"
    route:
      cluster: orders_v1
      request_mirror_policies:
        - cluster: orders_v2
          runtime_fraction:
            default_value:
              numerator: 10
              denominator: HUNDRED
          trace_sampled: true

Blok request_mirror_policies mengirim 10 persen request juga ke orders_v2. Klien tetap menerima respons dari orders_v1; hasil orders_v2 dibuang — hanya observability yang melihatnya. Ini cara menguji versi baru dengan traffic nyata tanpa risiko.

#Kenapa Shadowing Berharga

Shadowing menjawab pertanyaan "apakah versi baru akan berperilaku sama?" tanpa me-route pengguna nyata. Bandingkan respons shadow dengan respons asli di telemetry, lalu ambil keputusan berdasarkan data. trace_sampled: true memastikan request mirror ikut tercatat di tracing.

#Batasan Mirroring

Beberapa hal yang perlu diwaspadai:

• Request mirror dikirim tanpa memblokir respons asli, tapi tetap memakai resource.
• Efek samping di backend shadow (misalnya menulis database) harus dipertimbangkan.
• Gunakan runtime_fraction untuk mengubah persentase mirror secara dinamis.

#Header-Based Routing dan Path Rewrites

#Route Berdasarkan Header

Routing bisa dipicu oleh nilai header tertentu:

routes:
  - match:
      prefix: "/api/"
      headers:
        - name: X-Canary
          string_match:
            exact: "true"
    route:
      cluster: api_canary
  - match:
      prefix: "/api/"
    route:
      cluster: api_stable

Route pertama menangkap semua request dengan header X-Canary: true dan mengirimnya ke api_canary. Sisanya menuju api_stable. Pola ini dipakai untuk testing internal: tim QA mengirim header khusus, traffic normal tidak terpengaruh.

#Kombinasi Match yang Kompleks

Match bisa menggabungkan path, header, dan query parameter sekaligus untuk memetakan subset traffic yang sangat spesifik — misalnya prefix /api/, header X-Tenant: tenant-a, dan query beta=1.

#Path Rewrites pada Routing Lanjutan

Gabungkan header-based routing dengan rewrite yang sudah dipelajari di episode 4:

routes:
  - match:
      prefix: "/api/v2"
      headers:
        - name: X-Experimental
          string_match:
            prefix: "1"
    route:
      cluster: experimental_backend
      prefix_rewrite: "/v2/internal"

prefix_rewrite: "/v2/internal" mengubah path sebelum menuju backend eksperimental. Dengan kombinasi ini, satu listener bisa menjadi gerbang banyak strategi routing sekaligus.

#Fault Injection untuk Chaos Engineering

#Simulasi dengan Presisi

Fault injection di episode 10 kini dipakai sebagai tool chaos engineering yang presisi — dikombinasikan dengan routing:

routes:
  - match:
      prefix: "/v1/orders"
      headers:
        - name: X-Chaos
          string_match:
            exact: "1"
    route:
      cluster: orders_v1
      typed_per_filter_config:
        envoy.filters.http.fault:
          "@type": type.googleapis.com/envoy.extensions.filters.http.fault.v3.Fault
          abort:
            http_status: 500
            percentage:
              numerator: 100
              denominator: HUNDRED

Konfigurasi fault membuat semua request dengan header X-Chaos: 1 gagal dengan status 500. Dengan memicu header ini di sebagian request, kalian bisa menguji apakah retry dan circuit breaking bekerja saat versi baru bermasalah.

#Pola Uji Ketahanan

Urutan pengujian yang disarankan:

1. Kirim 10 persen traffic canary ke versi baru tanpa gangguan, amati baseline.
2. Aktifkan fault injection pada sebagian request canary.
3. Amati apakah retry, timeout, dan circuit breaker merespons dengan benar.
4. Nonaktifkan fault injection dan evaluasi metric.

#Chaos dalam Skala Terkontrol

Jangan pernah menyuntikkan fault ke seluruh traffic sekaligus. Mulai dari fraction kecil lalu naikkan bertahap. Fault injection Envoy punya runtime_fraction yang bisa diganti dinamis, memberi kontrol penuh saat eksperimen berlangsung.

curl -s -o /dev/null -w "%{http_code}\n" \
  -H "Host: api.example.com" -H "X-Chaos: 1" http://localhost:10000/v1/orders
curl -s localhost:9901/stats | grep "upstream_rq_5xx"

Request dengan X-Chaos: 1 seharusnya menghasilkan 500, lalu metric upstream_rq_5xx bertambah. Ini cara cepat membuktikan fault injection aktif dan terukur.

#Penutup

Episode 18 memberi kalian kendali penuh atas bentuk traffic: weighted clusters untuk canary, mirroring untuk shadowing, routing berbasis header, dan fault injection untuk chaos engineering yang presisi.

Inti yang harus dibawa pulang:

• weighted_clusters membagi traffic secara proporsional untuk canary.
• Geser bobot bertahap dari 1 persen hingga 100 persen.
• request_mirror_policies mengirim salinan request tanpa memengaruhi klien.
• Header-based routing memisahkan traffic internal dari traffic normal.
• Kombinasikan match path, header, dan query untuk routing yang presisi.
• Fault injection adalah alat chaos: mulai dari fraction kecil dan amati metric.

Di episode 19 selanjutnya kita akan membahas Envoy in Kubernetes dan service mesh ecosystems — Envoy sidecar dalam Istio, perbedaan Envoy langsung versus sebagai mesh data plane, serta deployment patterns untuk workload Kubernetes.