Ketergantungan pada model AI pihak ketiga (seperti OpenAI, Anthropic, atau Google Gemini) memperkenalkan moda kegagalan baru: kuota token per menit (TPM) dan request per menit (RPM) yang dapat habis seketika. Saat upstream mengembalikan status HTTP 429 Too Many Requests, aplikasi downstream yang memanggil API secara sinkron akan mengalami cascading failure jika sistem tidak memiliki mekanisme isolasi dan pengalihan beban kerja yang deterministik.
Artikel ini membahas prosedur operasional standar penanganan insiden kuota upstream AI: deteksi anomali metrik secara cepat, eksekusi pemulihan darurat tanpa redeploy penuh, penghitungan dampak pada SLA sistem, serta implementasi gateway failover multi-provider.
1. Observasi dan Deteksi Cepat Metrik 429
Langkah pertama dalam penanganan insiden adalah mengisolasi akar penyebab HTTP 429. Provider AI umumnya mengirimkan dua jenis status 429:
- Rate Limit Sementara (Concurrency/TPM/RPM Spike): Kuota periodik terlampaui sementara akibat lonjakan trafik. Header respons biasanya menyertakan
retry-after. - Kuota Saldo Habis (Insufficient Quota): Akun kehabisan kredit penagihan bulanan atau batas kuota absolut terlampaui. Error ini bersifat permanen sampai ada intervensi finansial/administratif.
Deteksi Dini via Prometheus
Jangan mengandalkan laporan pengguna untuk mengetahui limit kuota habis. Pantau metrik layer egress proxy atau HTTP client aplikasi menggunakan aturan alert PromQL berikut:
# Alert: Lonjakan rasio error HTTP 429 pada upstream AI > 5% dalam 2 menit
alert: UpstreamAIRateLimitSpike
expr: |
sum(rate(http_client_requests_seconds_count{status="429", upstream=~"ai-.*"}[2m]))
/
sum(rate(http_client_requests_seconds_count{upstream=~"ai-.*"}[2m])) > 0.05
for: 1m
labels:
severity: critical
annotations:
summary: "Upstream AI provider {{ $labels.upstream }} mengalami lonjakan HTTP 429"
description: "Tingkat kegagalan 429 melebihi 5% selama 1 menit pada cluster {{ $labels.upstream }}. Segera jalankan traffic shifting."Metrik Kritis pada Grafana Dashboard
Siapkan visualisasi pada Grafana yang berfokus pada tiga indikator utama:
- Upstream Status Code Breakdown: Distribusi
200 OKvs429 Too Many Requestsvs5xxper provider. - Client Retry Storms: Volume request retry internal yang dapat memperburuk antrean ketika upstream sedang rate limited.
- Upstream Egress Latency (P95/P99): Mengetahui apakah 429 dikembalikan secara instan (<50ms) atau setelah request tertahan di antrean upstream (>5s).
2. Tanggap Darurat: Canary Rollback dan Traffic Shifting
Saat alert menyala, redeploy penuh aplikasi via CI/CD pipeline memakan waktu 5 hingga 15 menit. Penanganan insiden menuntut perubahan alokasi trafik dalam hitungan detik. Terapkan pemisahan konfigurasi routing dari lifecycle deploy kode.
Mekanisme Runtime Traffic Shifting
Jika deploy versi aplikasi baru (canary release) menyebabkan konsumsi token membengkak akibat prompt baru yang tidak efisien, segera lakukan canary rollback:
- Feature Flags / Dynamic Configuration: Gunakan distributed key-value store (Consul, etcd, atau Redis) untuk mengubah bobot routing model secara runtime.
- Traffic Weight Shifting: Pindahkan beban trafik dari model primer (misal: provider A) ke model fallback (provider B atau model lokal/self-hosted vLLM) secara bertahap (100% primary → 50/50 → 100% fallback).
Penting: Jangan mengirimkan format payload mentah tanpa adaptasi schema. Gunakan unified schema abstraction layer (seperti format standar ChatML) di internal service agar downstream consumers tidak pecah saat dialihkan antar provider.
3. Implementasi Failover Routing Egress Gateway (Envoy Proxy)
Cara paling tangguh mengisolasi upstream eksternal adalah dengan menempatkan Egress Proxy lokal berbasis Envoy. Envoy dapat mengeksekusi active retry, circuit breaking, dan priority failover langsung di network layer tanpa intervensi kode backend.
Berikut konfigurasi envoy.yaml yang mengarahkan trafik utama ke OpenAI, dan langsung mengalihkan request ke backup provider (misal: Anthropic atau secondary endpoint) jika menerima respons 429:
static_resources:
listeners:
- name: ai_egress_listener
address:
socket_address: { address: 0.0.0.0, port_value: 10000 }
filter_chains:
- filters:
- name: envoy.filters.network.http_connection_manager
typed_config:
"@type": type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager
stat_prefix: ai_egress
route_config:
name: ai_route
virtual_hosts:
- name: ai_upstream_vhost
domains: ["*"]
routes:
- match: { prefix: "/v1/chat/completions" }
route:
cluster: primary_ai_provider
timeout: 30s
retry_policy:
retry_on: "retriable-status-codes"
retriable_status_codes: [429, 503]
num_retries: 2
retry_back_off:
base_interval: 0.25s
max_interval: 2s
# Failover otomatis ke cluster secondary jika primary gagal
request_mirror_policies: []
http_filters:
- name: envoy.filters.http.router
typed_config:
"@type": type.googleapis.com/envoy.extensions.filters.http.router.v3.Router
clusters:
- name: primary_ai_provider
connect_timeout: 2s
type: LOGICAL_DNS
dns_lookup_family: V4_ONLY
lb_policy: ROUND_ROBIN
load_assignment:
cluster_name: primary_ai_provider
endpoints:
- priority: 0
lb_endpoints:
- endpoint:
address:
socket_address: { address: api.openai.com, port_value: 443 }
# Backup target dengan Priority 1: hanya menerima trafik jika Priority 0 tidak sehat
- priority: 1
lb_endpoints:
- endpoint:
address:
socket_address: { address: fallback-ai-gateway.internal, port_value: 443 }
transport_socket:
name: envoy.transport_sockets.tls
typed_config:
"@type": type.googleapis.com/envoy.extensions.transport_sockets.tls.v3.UpstreamTlsContext
sni: api.openai.com
outlier_detection:
consecutive_5xx: 3
consecutive_gateway_failure: 3
interval: 10s
base_ejection_time: 30s
max_ejection_percent: 1004. Template Ringkas Incident Postmortem
Setelah status normal tercapai, susun postmortem terstruktur untuk mengevaluasi kegagalan:
A. Kalkulasi Dampak SLA
Hitung persentase konsumsi error budget untuk menentukan apakah insiden ini melanggar service level agreement:
Total Permintaan (Periode Insiden): 120.000
Permintaan Gagal (HTTP 429 / 5xx): 18.000
Availability Aktual = ((120.000 - 18.000) / 120.000) * 100 = 85.0%
Target SLO: 99.9%
Konsumsi Error Budget Bulanan: 150% (SLO breached)B. Timeline Kronologis
- 14:02 WIB: Tim AI merilis prompt v2.1 ke 20% canary traffic; konsumsi token rata-rata meningkat 4x lipat dari proyeksi.
- 14:05 WIB: Kuota TPM upstream habis; alert Prometheus
UpstreamAIRateLimitSpikeaktif. - 14:08 WIB: On-call engineer mengidentifikasi lonjakan 429 dari provider primer.
- 14:11 WIB: Eksekusi traffic shifting manual via dynamic config ke backup provider.
- 14:14 WIB: Error rate kembali di bawah ambang batas 0.1%; insiden dinyatakan mitigasi.
C. Single Point of Failure (SPOF) Analysis
Ketergantungan hardcoded pada satu upstream vendor tanpa pembatas lokal terbukti menyebabkan cascading outage. Kapasitas vendor eksternal berada di luar kendali langsung sistem dan harus diperlakukan sebagai dependensi yang sewaktu-waktu unreliable.
5. Pencegahan Jangka Panjang
Untuk mencegah terulangnya insiden serupa, bangun kontrol preventif pada level arsitektur:
- Local Dynamic Token Budgeting: Terapkan Redis Sliding Window atau Token Bucket di gateway internal. Batasi laju request internal agar berada di angka 80% dari batas kontrak upstream untuk mencegah HTTP 429 mencapai aplikasi.
- Circuit Breaker Adaptif: Putus aliran request ke upstream tertentu secara otomatis ketika error rate 429 melampaui batas ambang dalam interval waktu tertentu (misal: 10 detik berturut-turut).
- Tiering & Graceful Degradation: Saat kuota menipis, turunkan fungsionalitas secara anggun (misal: nonaktifkan fitur AI real-time, masukkan request ke background job queue, atau alihkan ke model open-weights berukuran lebih kecil).
Komentar
0 komentar
Masuk ke akun kamu untuk ikut berkomentar.
Belum ada komentar
Jadilah yang pertama ikut berdiskusi!