Belajar gRPC - HTTP/2, Load Balancing & Connection Management

#Pendahuluan

gRPC tidak bisa dipahami sepenuhnya tanpa memahami HTTP/2. Semua keunggulan gRPC — multiplexing, streaming, efisiensi — lahir dari protokol transport ini. Dan begitu banyak server terlibat, muncul pertanyaan: bagaimana membagi traffic secara adil?

Episode 10 membahas tiga lapisan: karakteristik networking HTTP/2 yang memengaruhi perilaku gRPC, strategi load balancing client-side dari pick_first sampai xDS, dan pengelolaan koneksi — pooling, keepalive, serta manajemen stream — agar koneksi yang kalian bangun di episode 4 tetap sehat di bawah beban.

#Karakteristik Networking HTTP/2

#Multiplexing dan Keterbatasan Stream

Satu koneksi HTTP/2 bisa membawa banyak stream, dan satu stream adalah satu RPC. Keunggulannya: banyak RPC berbagi satu TCP connection tanpa antre. Tapi ada batas: maksimal stream aktif per koneksi biasanya 100 (dikendalikan SETTINGS_MAX_CONCURRENT_STREAMS).

Implikasi praktisnya: untuk ribuan panggilan konkuren, client perlu lebih dari satu koneksi — inilah mengapa gRPC membuka banyak koneksi per channel secara otomatis saat diperlukan.

#HPACK dan Kompresi Header

Header HTTP/2 dikompresi dengan HPACK menggunakan tabel statis dan dinamis. Header berulang seperti content-type: application/grpc dikirim sebagai referensi tabel, bukan string penuh. Inilah alasan overhead per-request gRPC sangat kecil dibanding HTTP/1.1.

#Load Balancing Client-Side

#pick-first

Strategi default: client memilih satu alamat dari daftar hasil resolver dan memakai koneksi itu. Jika gagal, pindah ke alamat berikutnya:

conn, _ := grpc.NewClient(
    "dns:///catalog-svc:50051",
    grpc.WithTransportCredentials(insecure.NewCredentials()),
)

Strategi pick-first cocok ketika load balancing ditangani di level lain — misalnya Kubernetes Service sudah mem-balance antar pod.

#round_robin

Untuk mendistribusikan panggilan secara merata di seluruh instance, aktifkan round_robin melalui service config:

conn, _ := grpc.NewClient(
    "dns:///catalog-svc:50051",
    grpc.WithDefaultServiceConfig(`{"loadBalancingConfig":[
        {"round_robin": {}}
    ]}`),
    grpc.WithTransportCredentials(insecure.NewCredentials()),
)

Dengan {"round_robin": {}} di service config, setiap panggilan diputar ke instance berikutnya secara berurutan. Ini strategi paling sederhana untuk kumpulan server yang homogen.

#xDS dan EDS

Untuk kontrol dinamis, xDS (khususnya EDS/Endpoint Discovery Service) memungkinkan client gRPC menerima daftar endpoint dari control plane seperti Envoy atau Istio, termasuk bobot dan health per endpoint. Detail di episode 18; yang perlu dipahami sekarang: xDS adalah load balancing yang diatur terpusat, bukan dikonfigurasi manual di tiap client.

#Connection Pooling dan Keepalive

#Keepalive untuk Mendeteksi Jalan Buntu

Koneksi yang tampak hidup bisa sebenarnya putus di level TCP. Keepalive mengirim ping secara periodik untuk mendeteksi ini:

conn, _ := grpc.NewClient("localhost:50051",
    grpc.WithTransportCredentials(insecure.NewCredentials()),
    grpc.WithKeepaliveParams(keepalive.ClientParameters{
        Time:                30 * time.Second,
        Timeout:             10 * time.Second,
        PermitWithoutStream: true,
    }),
)

Pengaturan Time: 30 * time.Second mengirim ping tiap 30 detik saat tidak ada aktivitas. PermitWithoutStream: true memungkinkan ping dikirim bahkan tanpa RPC aktif — menjaga koneksi tetap hangat.

#Server Keepalive

Server juga mengonfigurasi kebijakan keepalive agar tidak dikuasai satu client:

s := grpc.NewServer(grpc.KeepaliveParams(keepalive.ServerParameters{
    MaxConnectionIdle: 5 * time.Minute,
    Time:              2 * time.Hour,
    Timeout:           20 * time.Second,
}))

MaxConnectionIdle: 5 * time.Minute menutup koneksi yang menganggur terlalu lama sehingga instance bisa di-scale down. Menyeimbangkan parameter client dan server menghindari koneksi mati yang dibiarkan menggantung.

#Streams Management

#Pengaruh Panjangnya Stream

Streaming RPC yang panjang — seperti watch atau event feed — menahan satu slot stream di koneksi. Jika semua stream habis dipakai stream panjang, RPC unary baru antre. Solusinya: batasi stream panjang per koneksi dan buka channel terpisah untuk workload berbeda, misalnya satu channel untuk stream panjang dan satu untuk unary.

#Backpressure

gRPC menerapkan flow control per stream. Ketika receiver lambat, sender otomatis dibatasi. Jangan menahan Recv terlalu lama saat membaca stream, karena hal itu menciptakan backpressure yang melambatkan seluruh pipeline.

#Penutup

Inti yang harus dibawa pulang:

• HTTP/2 multiplexing membuat banyak RPC berbagi satu koneksi dengan batas stream per koneksi.
• HPACK mengecilkan header berulang sehingga overhead per request sangat kecil.
• pick_first untuk satu alamat; round_robin untuk distribusi merata; xDS untuk kontrol terpusat.
• Keepalive di client dan server menjaga koneksi dari kebuntuan TCP.
• Stream panjang menahan slot; pisahkan channel untuk workload unary dan streaming.
• Flow control HTTP/2 menangani backpressure secara otomatis saat receiver lambat.

Di episode 11 selanjutnya kita membahas TLS, mTLS, dan authentication di gRPC — menyiapkan sertifikat dan TLS pada server dan client, mutual TLS untuk otentikasi dua arah, serta integrasi modern dengan JWT, OAuth2, dan token-based auth lewat metadata. Koneksi yang sehat tanpa enkripsi hanyalah setengah jalan; sekarang waktunya mengamankannya.