gRPC melalui proxy dalam arsitektur mikroservis: panduan lengkap untuk pengaturan tunneling HTTP/2

```html

gRPC adalah framework RPC berkinerja tinggi dari Google yang berjalan di atas HTTP/2 dan menjadi standar de facto untuk interaksi antar layanan. Namun, begitu Anda mencoba mengalirkan lalu lintas gRPC melalui proxy, masalah segera muncul: sebagian besar server proxy klasik tidak dapat bekerja dengan HTTP/2 dan koneksi streaming jangka panjang. Dalam artikel ini, kita akan membahas cara mengatur gRPC melalui proxy dengan benar — dari pemilihan arsitektur hingga konfigurasi spesifik Nginx, Envoy, dan HAProxy.

Mengapa gRPC tidak berfungsi dengan baik dengan proxy biasa

Untuk memahami masalah ini, kita perlu memahami bagaimana gRPC bekerja di balik layar. Protokol ini menggunakan HTTP/2 sebagai lapisan transportasi, dan ini sangat berbeda dari REST yang biasa di atas HTTP/1.1. Sebagian besar proxy perusahaan, firewall, dan penyeimbang beban dirancang pada era HTTP/1.1 dan tidak dapat menangani aliran HTTP/2 yang dimultiplex.

Berikut adalah masalah spesifik yang akan Anda hadapi saat mencoba mengalirkan gRPC melalui proxy HTTP klasik:

• Penurunan ke HTTP/1.1. Banyak proxy secara otomatis menurunkan versi protokol. gRPC memerlukan HTTP/2 — tanpa itu, koneksi tidak akan terjalin, dan klien akan menerima kesalahan UNAVAILABLE.
• Putusnya koneksi jangka panjang. gRPC secara aktif menggunakan streaming server dan dua arah. Proxy dengan timeout agresif (terutama AWS ELB Classic, beberapa versi Squid) memutuskan koneksi yang tidak mengirimkan data lebih dari 60 detik.
• Masalah dengan Content-Type. gRPC menggunakan header Content-Type: application/grpc. Proxy yang tidak mengetahui tipe ini dapat menolak permintaan atau melakukan buffering tubuh dengan tidak benar.
• Trailers. gRPC menggunakan trailers HTTP/2 untuk mengirimkan status penyelesaian panggilan. Proxy HTTP/1.1 tidak mendukung trailers — informasi tentang status akan hilang.
• Buffering tubuh. Beberapa proxy melakukan buffering seluruh tubuh respons sebelum mengirimkannya ke klien. Untuk panggilan gRPC yang streaming, ini berarti klien tidak akan menerima pesan apa pun sampai streaming selesai.

Kesimpulan kunci:

Untuk menjalankan gRPC melalui proxy, diperlukan proxy yang mendukung HTTP/2 end-to-end atau mode tunneling khusus. Proxy HTTP klasik tanpa penyesuaian konfigurasi tidak akan cocok.

Tunneling HTTP/2: bagaimana cara kerjanya

Ada dua pendekatan yang berbeda untuk memproxy lalu lintas gRPC, dan penting untuk memahami perbedaan antara keduanya agar dapat memilih solusi yang tepat untuk arsitektur Anda.

Pendekatan 1: HTTP/2 end-to-end (direkomendasikan)

Proxy memahami HTTP/2 dan membangun koneksi HTTP/2 baik dengan klien maupun backend. Ia dapat menganalisis aliran terpisah, menerapkan penyeimbangan di tingkat permintaan, menambahkan header, dan melakukan terminasi TLS. Ini adalah opsi yang paling fungsional — seperti yang dilakukan Envoy, Nginx (mulai versi 1.13.10) dan penyeimbang yang menyadari gRPC di penyedia cloud.

Pendekatan 2: TCP tunneling (CONNECT)

Proxy tidak menganalisis lalu lintas HTTP/2, tetapi hanya membuat tunneling TCP transparan melalui metode CONNECT. Klien membangun koneksi TLS langsung dengan backend melalui tunneling. Proxy hanya melihat aliran byte yang terenkripsi. Metode ini lebih mudah untuk diatur, tetapi menghilangkan kemampuan untuk melakukan penyeimbangan di tingkat permintaan gRPC dan menambahkan header.

Karakteristik	HTTP/2 end-to-end	TCP CONNECT tunneling
Penyeimbangan berdasarkan permintaan	✅ Ya	❌ Tidak (hanya berdasarkan TCP)
Terminasi TLS di proxy	✅ Ya	❌ Tidak
Menambahkan header	✅ Ya	❌ Tidak
Tingkat kesulitan pengaturan	Sedang	Rendah
Dukungan streaming	✅ Lengkap	✅ Lengkap
Observabilitas (metrik)	✅ Detail	❌ Hanya TCP

Mengatur Nginx sebagai proxy gRPC

Nginx mendukung pemproxyan gRPC mulai versi 1.13.10 (Februari 2018). Untuk berfungsi, diperlukan modul ngx_http_grpc_module, yang termasuk dalam build standar. Penting: Nginx mendukung HTTP/2 di sisi klien (frontend), tetapi di sisi backend hanya menggunakan HTTP/2 untuk gRPC — upstream HTTP biasa berfungsi di HTTP/1.1.

Konfigurasi dasar proxy gRPC di Nginx

server {
    listen 443 ssl http2;
    server_name grpc.example.com;

    # Sertifikat TLS
    ssl_certificate     /etc/nginx/ssl/server.crt;
    ssl_certificate_key /etc/nginx/ssl/server.key;

    # Parameter TLS modern
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers HIGH:!aNULL:!MD5;

    location / {
        # Direktif grpc_pass sebagai pengganti proxy_pass
        grpc_pass grpc://grpc_backend;

        # Timeout untuk streaming jangka panjang
        grpc_read_timeout  3600s;
        grpc_send_timeout  3600s;
        grpc_connect_timeout 5s;

        # Mengirimkan IP asli klien
        grpc_set_header X-Real-IP $remote_addr;
        grpc_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}

upstream grpc_backend {
    server backend-1:50051;
    server backend-2:50051;
    server backend-3:50051;

    # Keepalive untuk koneksi HTTP/2
    keepalive 32;
}

Perhatikan beberapa detail yang sangat penting. Pertama, digunakan direktif grpc_pass, bukan proxy_pass — ini adalah modul yang berbeda dengan perilaku yang berbeda. Kedua, timeout grpc_read_timeout dan grpc_send_timeout diatur ke 3600 detik (1 jam) — ini penting untuk streaming server yang dapat berjalan lama tanpa mengirimkan data. Ketiga, keepalive 32 di upstream memungkinkan penggunaan kembali koneksi HTTP/2 dengan backend.

Konfigurasi untuk gRPC tidak terenkripsi (grpc://)

server {
    listen 80 http2;
    server_name grpc-internal.example.com;

    location / {
        grpc_pass grpc://127.0.0.1:50051;

        # Penanganan kesalahan gRPC
        error_page 502 = /error502grpc;
    }

    location = /error502grpc {
        internal;
        default_type application/grpc;
        add_header grpc-status 14;
        add_header content-length 0;
        return 204;
    }
}

Blok error502grpc adalah detail penting: jika backend tidak tersedia, ia mengembalikan status gRPC yang benar UNAVAILABLE (14) alih-alih HTTP 502, yang tidak dapat diproses dengan benar oleh klien gRPC.

Envoy Proxy: pilihan terbaik untuk gRPC dalam mikroservis

Envoy dirancang oleh Lyft khusus untuk arsitektur mikroservis, dan dukungan gRPC di dalamnya diimplementasikan pada tingkat yang sangat mendalam. Ia memahami Protocol Buffers, dapat mentranskode gRPC menjadi REST, mengumpulkan metrik detail untuk setiap metode RPC, dan merupakan dasar untuk solusi service mesh — Istio, AWS App Mesh, dan lainnya. Jika Anda membangun arsitektur mikroservis yang serius, Envoy adalah standar industri.

Konfigurasi dasar Envoy untuk gRPC

static_resources:
  listeners:
  - name: grpc_listener
    address:
      socket_address:
        address: 0.0.0.0
        port_value: 8080
    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: grpc_proxy
          codec_type: HTTP2
          route_config:
            name: grpc_routes
            virtual_hosts:
            - name: grpc_services
              domains: ["*"]
              routes:
              - match:
                  prefix: "/com.example.UserService"
                route:
                  cluster: user_service
                  timeout: 30s
                  retry_policy:
                    retry_on: "reset,connect-failure,retriable-status-codes"
                    num_retries: 3
                    retriable_status_codes: [14]
              - match:
                  prefix: "/com.example.OrderService"
                route:
                  cluster: order_service
                  timeout: 60s
          http_filters:
          - name: envoy.filters.http.grpc_stats
            typed_config:
              "@type": type.googleapis.com/envoy.extensions.filters.http.grpc_stats.v3.FilterConfig
              emit_filter_state: true
          - name: envoy.filters.http.router
            typed_config:
              "@type": type.googleapis.com/envoy.extensions.filters.http.router.v3.Router

  clusters:
  - name: user_service
    connect_timeout: 5s
    type: STRICT_DNS
    lb_policy: ROUND_ROBIN
    http2_protocol_options: {}
    load_assignment:
      cluster_name: user_service
      endpoints:
      - lb_endpoints:
        - endpoint:
            address:
              socket_address:
                address: user-service
                port_value: 50051

Keuntungan utama dari konfigurasi ini: routing berdasarkan layanan gRPC (prefix path sesuai dengan nama lengkap layanan dalam format package.ServiceName), retry otomatis saat status UNAVAILABLE, dan pengumpulan metrik gRPC melalui filter grpc_stats.

Transcoding gRPC-Web di Envoy

Salah satu fitur unggulan Envoy adalah transcoder gRPC-Web yang terintegrasi. Browser tidak mendukung gRPC secara langsung (karena batasan Fetch API pada HTTP/2 trailers), sehingga digunakan protokol gRPC-Web. Envoy dapat secara otomatis mengonversi permintaan gRPC-Web dari browser menjadi gRPC biasa untuk backend:

http_filters:
- name: envoy.filters.http.grpc_web
  typed_config:
    "@type": type.googleapis.com/envoy.extensions.filters.http.grpc_web.v3.GrpcWeb
- name: envoy.filters.http.cors
  typed_config:
    "@type": type.googleapis.com/envoy.extensions.filters.http.cors.v3.CorsPolicy
- name: envoy.filters.http.router
  typed_config:
    "@type": type.googleapis.com/envoy.extensions.filters.http.router.v3.Router

HAProxy dan gRPC: konfigurasi dengan penyeimbangan beban

HAProxy mendukung gRPC mulai versi 1.9.2. Ia bekerja di tingkat TCP atau HTTP/2, dapat menyeimbangkan lalu lintas gRPC dan melakukan health checks. HAProxy adalah pilihan yang baik jika Anda sudah menggunakannya dalam infrastruktur dan ingin menambahkan dukungan gRPC tanpa menambahkan komponen baru.

global
    maxconn 50000
    log stdout format raw local0

defaults
    log global
    timeout connect 5s
    timeout client  3600s
    timeout server  3600s

frontend grpc_frontend
    bind *:443 ssl crt /etc/haproxy/certs/server.pem alpn h2,http/1.1
    mode http
    option http-use-htx
    default_backend grpc_servers

backend grpc_servers
    mode http
    balance leastconn
    option http-use-htx

    # Health check melalui Protokol Pemeriksaan Kesehatan gRPC
    option httpchk GET /grpc.health.v1.Health/Check
    http-check expect status 200

    server grpc1 10.0.0.1:50051 check ssl verify none
    server grpc2 10.0.0.2:50051 check ssl verify none
    server grpc3 10.0.0.3:50051 check ssl verify none

Perhatikan beberapa pengaturan penting. alpn h2,http/1.1 dalam direktif bind menunjukkan bahwa HAProxy menerima koneksi baik HTTP/2 maupun HTTP/1.1 melalui negosiasi TLS ALPN. timeout client 3600s dan timeout server 3600s adalah parameter yang sangat penting untuk streaming gRPC yang jangka panjang. Algoritma leastconn lebih disukai dibandingkan roundrobin untuk gRPC, karena koneksi streaming dapat bertahan lama dan tidak merata dalam membebani backend.

Terminasi TLS dan enkripsi end-to-end untuk gRPC

gRPC secara default mengharuskan penggunaan TLS — ini adalah bagian dari spesifikasi. Dalam praktiknya, dalam arsitektur mikroservis muncul pertanyaan: di mana melakukan terminasi TLS dan bagaimana mengatur enkripsi antara komponen? Ada tiga pola utama.

Pola 1: Terminasi TLS di proxy (Edge TLS)

Proxy menerima lalu lintas terenkripsi dari klien, mendekripsinya, dan mengirimkannya ke backend melalui saluran yang tidak terenkripsi (atau dengan TLS terpisah). Ini adalah pendekatan yang paling umum di jaringan perusahaan. Backend dapat menggunakan grpc.Insecure() untuk menyederhanakan konfigurasi.

Pola 2: Enkripsi end-to-end (mTLS)

Mutual TLS (mTLS) adalah standar untuk service mesh. Setiap layanan memiliki sertifikatnya sendiri, dan pada setiap koneksi kedua belah pihak memverifikasi sertifikat satu sama lain. Ini memastikan otentikasi layanan dan enkripsi lalu lintas di dalam cluster. Inilah cara kerja Istio dengan proxy sidecar Envoy.

# Go: server gRPC dengan mTLS
import (
    "crypto/tls"
    "crypto/x509"
    "google.golang.org/grpc"
    "google.golang.org/grpc/credentials"
)

func createMTLSCredentials() credentials.TransportCredentials {
    cert, _ := tls.LoadX509KeyPair("server.crt", "server.key")
    
    caCert, _ := os.ReadFile("ca.crt")
    caCertPool := x509.NewCertPool()
    caCertPool.AppendCertsFromPEM(caCert)
    
    tlsConfig := &tls.Config{
        Certificates: []tls.Certificate{cert},
        ClientAuth:   tls.RequireAndVerifyClientCert,
        ClientCAs:    caCertPool,
    }
    
    return credentials.NewTLS(tlsConfig)
}

// Membuat server dengan mTLS
creds := createMTLSCredentials()
server := grpc.NewServer(grpc.Creds(creds))

Pola 3: TLS Passthrough

Proxy bekerja di tingkat TCP dan tidak mendekripsi lalu lintas — hanya meneruskan byte terenkripsi ke backend. Ini adalah opsi yang paling sederhana dari sudut pandang proxy, tetapi menghilangkan kemampuan untuk menganalisis lalu lintas gRPC, menambahkan header, atau melakukan penyeimbangan di tingkat permintaan.

Penyeimbangan beban untuk streaming gRPC: fitur dan solusi

Penyeimbangan beban untuk gRPC adalah tugas yang tidak sepele, dan inilah alasannya. Di HTTP/1.1, setiap permintaan adalah koneksi TCP terpisah (atau koneksi dari pool), dan penyeimbang dengan mudah mendistribusikan permintaan ke backend. Di HTTP/2, satu koneksi TCP memmultiplex banyak aliran — jika penyeimbang bekerja di tingkat TCP, semua aliran dari satu koneksi akan masuk ke satu backend.

Untuk gRPC, ini berarti: jika klien telah membangun satu koneksi HTTP/2 dan mengirimkan 100 permintaan RPC melalui koneksi tersebut, dengan penyeimbangan TCP, semua 100 permintaan akan diproses oleh satu instance backend. Backend lainnya akan menganggur. Solusinya adalah penyeimbangan di tingkat aliran HTTP/2 (penyeimbangan L7).

Algoritma penyeimbangan untuk gRPC

Algoritma	Cocok untuk gRPC	Komentar
Round Robin	✅ Ya	Bagus untuk RPC unar dengan waktu pemrosesan yang hampir sama
Least Connection	✅ Pilihan terbaik	Memperhitungkan aliran aktif, mendistribusikan beban secara merata
Random	⚠️ Bersyarat	Bekerja dengan banyak permintaan, tidak merata dengan sedikit
IP Hash	❌ Buruk	Mengikat klien ke satu backend, tidak ada artinya di L7
Pick First (bawaan gRPC)	❌ Tidak untuk produksi	Semua permintaan pergi ke server pertama yang tersedia

Penyeimbangan klien di gRPC

gRPC mendukung penyeimbangan beban klien — klien sendiri memutuskan ke server mana untuk mengirimkan permintaan. Ini memungkinkan untuk menghindari masalah multiplexer TCP. Untuk penemuan layanan, digunakan DNS dengan beberapa catatan A atau resolver khusus (Consul, etcd). Contoh pengaturan penyeimbangan klien di Go:

import (
    "google.golang.org/grpc"
    "google.golang.org/grpc/balancer/roundrobin"
)

// Klien dengan penyeimbangan round-robin melalui DNS
conn, err := grpc.Dial(
    "dns:///grpc-service.internal:50051",
    grpc.WithDefaultServiceConfig(
        `{"loadBalancingConfig": [{"round_robin":{}}]}`
    ),
    grpc.WithTransportCredentials(creds),
)

// Klien dengan least-connection (tersedia di gRPC >= 1.58)
conn, err := grpc.Dial(
    "dns:///grpc-service.internal:50051",
    grpc.WithDefaultServiceConfig(
        `{"loadBalancingConfig": [{"least_request":{}}]}`
    ),
    grpc.WithTransportCredentials(creds),
)

Proxy eksternal untuk gRPC: kapan dan mengapa mereka diperlukan dalam mikroservis

Selain komponen proxy internal (Nginx, Envoy, HAProxy), dalam arsitektur mikroservis terkadang ada kebutuhan untuk menggunakan server proxy eksternal — misalnya, untuk merutekan lalu lintas melalui wilayah tertentu, menghindari batasan jaringan, atau mengisolasi koneksi keluar. Mari kita lihat skenario utama.

Skenario 1: Mikroservis yang terdistribusi secara geografis

Jika mikroservis Anda terletak di berbagai wilayah (misalnya, sebagian di Eropa, sebagian di AS), dan Anda perlu mengontrol melalui alamat IP mana koneksi gRPC dibangun antara wilayah, proxy eksternal dapat membantu mengatur routing yang dapat diprediksi. Untuk tugas semacam itu, proxy pusat data sangat cocok — mereka menyediakan alamat IP yang stabil dan kecepatan koneksi tinggi, yang sangat penting untuk gRPC dengan sensitivitas terhadap latensi.

Skenario 2: Isolasi lalu lintas keluar

Dalam beberapa lingkungan perusahaan, semua lalu lintas keluar harus melewati proxy perusahaan. Untuk klien gRPC yang perlu mengakses layanan gRPC eksternal (misalnya, Google Cloud APIs yang menggunakan gRPC), ini menciptakan kesulitan. Solusinya adalah mengatur tunneling CONNECT melalui proxy perusahaan.

Contoh pengaturan klien gRPC untuk bekerja melalui proxy HTTP CONNECT di Go:

import (
    "net"
    "net/http"
    "golang.org/x/net/proxy"
    "google.golang.org/grpc"
)

// Menggunakan proxy SOCKS5 untuk gRPC
proxyDialer, _ := proxy.SOCKS5(
    "tcp",
    "proxy.example.com:1080",
    &proxy.Auth{User: "user", Password: "pass"},
    proxy.Direct,
)

conn, err := grpc.Dial(
    "grpc-service.example.com:443",
    grpc.WithContextDialer(func(ctx context.Context, addr string) (net.Conn, error) {
        return proxyDialer.Dial("tcp", addr)
    }),
    grpc.WithTransportCredentials(creds),
)

Skenario 3: Pengujian dan pengembangan

Saat mengembangkan mikroservis, seringkali perlu untuk menguji perilaku layanan dari berbagai lingkungan jaringan — memeriksa bagaimana layanan merespons pada latensi tinggi, atau menguji logika yang bergantung pada geo. Untuk tugas semacam itu, proxy residensial sangat berguna, yang memungkinkan untuk mensimulasikan permintaan dari wilayah tertentu dengan IP nyata pengguna rumah.

Kesalahan umum saat mengatur gRPC melalui proxy dan cara mengatasinya

Mari kita bahas masalah yang paling sering dihadapi pengembang saat mengatur gRPC melalui proxy, serta cara konkret untuk menyelesaikannya.

Kesalahan 1: "transport: received the unexpected content-type"

Penyebab: Proxy mengembalikan halaman HTML dengan kesalahan (misalnya, 502 Bad Gateway) alih-alih respons gRPC. Klien gRPC tidak dapat memproses HTML dan mengeluarkan kesalahan ini.
Solusi: Pastikan backend tersedia. Tambahkan penanganan kesalahan gRPC di tingkat proxy (seperti yang ditunjukkan dalam contoh Nginx di atas dengan blok error502grpc).

Kesalahan 2: Koneksi terputus setelah 60-120 detik

Penyebab: Proxy menutup koneksi idle karena timeout. Nilai klasik: AWS ELB — 60 detik, Nginx secara default — 60 detik.
Solusi 1: Tingkatkan timeout di proxy (seperti yang ditunjukkan dalam contoh di atas).
Solusi 2: Atur keepalive di sisi klien gRPC:

import "google.golang.org/grpc/keepalive"

kaParams := keepalive.ClientParameters{
    Time:                30 * time.Second, // Ping setiap 30 detik
    Timeout:             10 * time.Second, // Menunggu respons 10 detik
    PermitWithoutStream: true,             // Ping bahkan tanpa RPC aktif
}

conn, err := grpc.Dial(
    "grpc-service:50051",
    grpc.WithKeepaliveParams(kaParams),
    grpc.WithTransportCredentials(creds),
)

Kesalahan 3: HTTP/2 tidak cocok (ALPN failure)

Penyebab: Proxy atau perangkat jaringan tidak mendukung ALPN (Application-Layer Protocol Negotiation) atau h2 tidak termasuk dalam daftar protokol yang didukung.
Solusi: Pastikan bahwa dalam konfigurasi TLS proxy, protokol h2 secara eksplisit disebutkan: alpn h2,http/1.1 (HAProxy) atau listen 443 ssl http2 (Nginx).

Kesalahan 4: Streaming macet — data tidak datang

Penyebab: Proxy melakukan buffering respons dan hanya mengirimkannya ke klien setelah selesai. Masalah umum untuk proxy yang diatur dengan proxy_buffering on.
Solusi untuk Nginx:

location / {
    grpc_pass grpc://backend;
    
    # Nonaktifkan buffering untuk streaming gRPC
    grpc_buffer_size 0;
    
    # Atau untuk proxy_pass biasa:
    proxy_buffering off;
    proxy_cache off;
}

Daftar periksa diagnosis gRPC melalui proxy

Kesimpulan

Mengatur gRPC melalui proxy memerlukan pemahaman tentang perbedaan kunci antara HTTP/2 dan HTTP/1.1: multiplexer aliran, koneksi jangka panjang, trailers HTTP/2, dan negosiasi ALPN. Proxy HTTP klasik tanpa penyesuaian khusus tidak berfungsi dengan gRPC — diperlukan proxy L7 yang mendukung HTTP/2 (Nginx 1.13.10+, Envoy, HAProxy 1.9.2+), atau tunneling TCP CONNECT.

Untuk lingkungan produksi, disarankan menggunakan Envoy — ia dirancang khusus untuk arsitektur mikroservis, memiliki dukungan bawaan untuk gRPC, dapat mengumpulkan metrik detail untuk setiap metode RPC, dan merupakan dasar dari sebagian besar solusi service mesh. Nginx adalah pilihan yang baik jika Anda sudah menggunakannya sebagai API Gateway dan ingin menambahkan dukungan gRPC tanpa menambahkan komponen baru. HAProxy cocok jika kinerja sangat penting dan Anda sudah familiar dengan konfigurasinya.

Terlepas dari proxy yang dipilih, tiga aturan tetap berlaku: tingkatkan timeout untuk streaming jangka panjang, nonaktifkan buffering respons, dan atur keepalive di klien. Ketiga pengaturan ini menyelesaikan 80% masalah dengan gRPC melalui proxy.

Jika dalam arsitektur Anda layanan gRPC harus berinteraksi melalui jaringan eksternal atau Anda perlu merutekan lalu lintas melalui wilayah tertentu, pertimbangkan untuk menggunakan proxy pusat data — mereka menyediakan alamat IP yang stabil, latensi rendah, dan bandwidth tinggi, yang sangat penting untuk gRPC dengan protokol biner dan sensitivitas terhadap latensi.