Pengantar

Latensi RPC pada Odin 1.0 sering terjadi saat antrean layanan backend bertumpuk di tengah lintasan RPC. Artikel ini langsung menguraikan gejala utama, cara mengamati log dan metrik, lalu memaparkan akar penyebab konfigurasi dan backpressure yang identik dengan pengumuman Odin 1.0. Dengan pendekatan studi kasus, pembaca mendapatkan langkah perbaikan yang bisa diterapkan tanpa menunggu pembaruan versi baru.

Gejala dan Observasi

Perbaikan perlu dimulai dari gejala konkret agar tidak hanya menebak. Pada kasus ini, tim melaporkan waktu respon RPC melonjak dua kali lipat saat beban spike, dan request gagal setelah timeout di gateway.

Log dan Tracing

  • Log Odin gateway: tercatat banyak entri "upstream response timeout" disertai request_id.
  • Distributed tracing: spans RPC antar layanan menunjukkan durasi 800-1200 ms padahal normal 120 ms.
  • Stack trace menunjukkan bottleneck terjadi sebelum handler backend menerima payload, mengindikasikan masalah di layer RPC/transport.

Metrics

  • Latency p95 RPC melonjak, sementara throughput tetap stabil—indikasi tidak karena beban CPU tapi antrean.
  • Jumlah koneksi aktif ke Odin RPC dispatcher meningkat signifikan tanpa penurunan, menandakan tidak ada drain.
  • Queue length pada gateway naik dari near-zero ke nilai berkurang drastis saat puncak, menunjukkan backpressure tidak bekerja.

Analisis Root Cause

Setelah observasi, akar masalah menunjukkan dua aspek utama yang dipengaruhi Odin 1.0.

Konfigurasi RPC dan Gateway

Gateway default menetapkan timeout 3 detik, padahal handler backend membutuhkan 5 detik karena operasi kompleks. Ketika timeout habis, gateway menutup koneksi namun backend tetap memproses request, menyebabkan backlog baru. Lokasi konfig: gateway/rpc-config.yaml dan odindispatcher/rpc_server.go.

Pendekatan yang tepat ialah mensinkronkan deadline RPC dengan timeout upstream. Periksa setting rpc_client_deadline di kedua sisi agar tidak saling memutus sebelum selesai.

Backpressure dan Pool Connection

Dispatcher Odin menggunakan pool goroutine tetap. Saat antrean masuk, dispatcher tidak mengatur queue size, sehingga semua goroutine menunggu balasan, membuat CPU sibuk menangani context cancel tanpa melepaskan slot. Solusi: batasi concurrency dan aktifkan token bucket.

Penjelasan: tanpa backpressure, dispatcher terus menerima request baru padahal sumber daya pekerja masih sibuk. Menambahkan semaphore sekaligus memblokir read meski TCP masih terbuka menghindari antrean menumpuk di kernel.

Langkah Perbaikan

Perbaikan dilakukan dengan dua kategori: koreksi konfigurasi RPC dan penanganan antrean.

Perbarui Timeout dan Retry

Sinkronkan timeout agar tidak memutus RPC sebelum selesai. Contoh konfigurasi:

rpc_timeout: 6s
rpc_retry_policy:
  max_attempts: 2
  per_try_timeout: 2s

Dengan timeout 6 detik, backend yang membutuhkan waktu 5 detik tidak diputus. Per_try_timeout menjaga bahwa retry tidak memicu tambahan beban ketika backend masih memproses request sebelumnya.

Implementasi Backpressure

Tambahkan token bucket sebelum request diarahkan ke handler. Contoh pola:

semp := make(chan struct{}, 32)

go func(req RPCRequest) {
  semp <- struct{}{}
  defer func() { <-semp }()
  process(req)
}(req)

Token bucket menghindari overload dengan membatasi simultan handler. Jika antrean penuh, gateway langsung mengembalikan 503 dengan header Retry-After, sehingga caller tahu untuk merendahkan kecepatan.

Mitigasi dan Pencegahan Regresi

Setelah patch, lakukan beberapa mitigasi tambahan agar latensi tidak kembali.

  • Gunakan chaos testing ringan untuk memicu lonjakan latency dan pastikan throttle token masih bekerja.
  • Tambahkan alert untuk metrics latency p95 dan retry rate; jika retry naik, berarti timeout masih belum sinkron.
  • Automated tests mengeksekusi RPC dengan simulasi latensi 1-2 detik di dependency, memastikan gateway tidak memutus secara prematur.

Catatan: hindari menurunkan timeout terlalu agresif karena akan meningkatkan retry yang juga memberi tekanan ke backend.

Verifikasi Perbaikan

Verifikasi dilakukan lewat pengujian end-to-end dan observabilitas.

  1. Jalankan skenario beban dengan wrk atau locust agar memicu latency 5 detik. Perhatikan bahwa gateway tanggap dan tidak timeout.
  2. Pastikan tracer mencatat span latency di bawah 7 detik tanpa banyak retries.
  3. Amati metric o_rpc_queue_wait_duration_seconds—nilai harus konsisten rendah saat fitur backpressure jalan.
  4. Lakukan rollback cepat jika alert latency muncul, karena perubahan ini berisiko memengaruhi throughput.

Kesimpulannya, debugging latensi RPC Odin 1.0 efektif bila fokus pada observasi log/metrics, penyelarasan timeout, dan penanganan backpressure. Dengan mitigasi dan verifikasi, regresi dapat dicegah sehingga layanan tetap responsif saat beban tinggi.