90. Studi Kasus: Simulasi Load Testing gRPC

Dewasa ini, layanan dengan protokol gRPC semakin popular digunakan di berbagai perusahaan teknologi karena efisiensinya dalam membangun komunikasi antar layanan (microservices). gRPC yang berbasis HTTP/2 menawarkan performa dan protokol serialization yang sangat efisien (Protocol Buffers), sehingga cocok untuk sistem berskala besar. Namun, sebelum mengimplementasikan gRPC pada production, memahami bagaimana performa layanan tersebut ketika mendapat beban yang masif adalah langkah wajib. Di artikel kali ini, saya akan membahas studi kasus simulasi load testing pada layanan gRPC lengkap dengan contoh kode, simulasi, hingga analisis hasilnya.

Mengapa Perlu Load Testing pada gRPC?

Load testing bertujuan untuk mensimulasikan traffic dalam jumlah besar ke sistem agar kita dapat mengidentifikasi bottleneck, mengevaluasi throughput, response time, serta memvalidasi skenario error handling. Ada beberapa alasan kita tidak bisa serta-merta mengasumsikan performa gRPC selalu “super cepat”:

• gRPC tetap membutuhkan resource network dan sistem, bisa saja terjadi bottleneck di deserialization, database, maupun concurrency.
• Pengujian dengan beban rendah tidak merepresentasikan skenario sesungguhnya pada production.
• Ada resource limit, misal memory, pool, ataupun CPU usage.

Karena itu, simulasi load testing menjadi kunci dalam kesiapan deployment production layanan gRPC.

Studi Kasus: Layanan User Service Sederhana

Misal kita memiliki sebuah User Service yang expose gRPC endpoint untuk operasi GetUser. Berikut contoh protokol buffer dan implementasi server sederhananya:

user.proto

syntax = "proto3";

package user;

service UserService {
  rpc GetUser (GetUserRequest) returns (GetUserResponse);
}

message GetUserRequest {
  string user_id = 1;
}

message GetUserResponse {
  string user_id = 1;
  string name = 2;
  string email = 3;
}

Implementasi Sederhana (Go)

type userServer struct{
  user.UnimplementedUserServiceServer
}

func (s *userServer) GetUser(ctx context.Context, req *user.GetUserRequest) (*user.GetUserResponse, error) {
  // Simulasi pembacaan data
  return &user.GetUserResponse{
    UserId: req.GetUserId(),
    Name: "Jane Doe",
    Email: "janedoe@example.com",
  }, nil
}

Pada contoh ini, GetUser hanya mengembalikan data sederhana — namun cukup untuk menguji performa request-response gRPC.

Menentukan Parameter Load Testing

Sebelum melakukan load testing, tentukan parameter berikut:

• Jumlah concurrent user: Berapa banyak request simultan yang akan disimulasikan? (misal 200, 500)
• RPS (Request per Second): Seberapa tinggi rate request yang ingin dicapai?
• Durasi test: Seberapa lama simulasi dilakukan (misal 1 menit, 5 menit)?
• Threshold: SLA/SLI response time yang diharapkan (misal 95% request < 200ms).

Tools untuk Load Testing gRPC

Beberapa tools open source untuk load testing gRPC antara lain:

• ghz (link) — CLI tool yang powerful dan mudah dipakai.
• k6 dengan gRPC extension.
• Locust dengan plugin, atau custom script.

Dalam studi kasus ini, kita gunakan ghz, karena:

• Mudah digunakan sebagai CLI
• Support berbagai output report
• Bisa dikustom script dan mempunyai integrasi CI/CD

Simulasi Load Testing dengan ghz

Instalasi (pada CLI)

go install github.com/bojand/ghz/cmd/ghz@latest

Menjalankan Simulasi

Misal service berjalan di localhost:50051, perintah berikut akan menjalankan load test:

ghz --insecure \
    --proto user.proto \
    --call user.UserService.GetUser \
    -d '{"user_id": "123"}' \
    -c 200 -n 10000 \
    localhost:50051

• -c 200 menunjukan 200 concurrent connections.
• -n 10000 menunjukan total 10.000 request akan dikirim.

Contoh Output & Analisis

Simulasi berjalan ±1 menit, dan berikut hasilnya:

Hasil di atas mengindikasikan service mampu melayani 350 RPS dengan latency mayoritas <100ms.

Visualisasi dengan Diagram Alur (mermaid)

Mari kita lihat alur proses load testing secara diagram.

sequenceDiagram
    participant Client as ghz
    participant Proxy as Load Balancer
    participant Service as gRPC User Service

    Client->>Proxy: Kirim request GetUser (200 concurrent)
    Proxy->>Service: Forward ke gRPC instance (balancing)
    Service->>Proxy: Kembalikan response
    Proxy->>Client: Terima response (dan log latency)

Studi Eksperimen: Menambah Beban

Sekarang, mari tingkatkan concurrent ke 500 dan request 20.000 kali:

ghz --insecure \
    --proto user.proto \
    --call user.UserService.GetUser \
    -d '{"user_id": "123"}' \
    -c 500 -n 20000 \
    localhost:50051

Output sample

Terlihat pada concurrency lebih tinggi, terjadi peningkatan error, response time naik cukup signifikan, dan beberapa request gagal karena timeout/resource limit.

Bottleneck dan Optimasi

Melalui hasil di atas, beberapa pertanyaan kritis dapat diajukan:

• Mengapa terjadi error pada concurrency tinggi?
  Jawaban umum: Kemungkinan thread pool habis, garbage collection, limitasi memory, atau resource lain.
• Bagaimana mengatasinya?
  • Scaling horizontal: deploy service secara distributed.
  • Optimasi resource limit: perbesar thread pool, tuning GC/runtime.
  • Cek & optimize dependency downstream, misal ke database.

Monitoring & Reporting

Agar hasil load testing bermanfaat, wajib dicatat dan divisualisasikan. ghz mendukung export ke JSON/HTML, sehingga bisa dibuat grafik berikut.

{
  "summary": {
    "total": 20000,
    "average": 110,
    "q95": 240,
    "errors": 87,
    "rps": 450
  }
}

Cocokan hasil load test dengan dashboard grafana/prometheus di production untuk validasi hasil.

Tips Praktek Saat Simulasi Load Test

1. Jalankan di environment terpisah
   Agar tidak mengganggu traffic user sebenarnya.
2. Replikasi topology production
   Simulasikan komponen nyata: reverse proxy, load balancer, service discovery.
3. Perhitungkan efek lain
   Misalnya keamanan jaringan, rate limit, serta alat observabilitas.
4. Automasi sebagai bagian CI/CD
   Load test rutin (misal pada nightly build) untuk regression service.

Kesimpulan

Load testing pada gRPC service bukanlah sekedar formalitas, namun langkah krusial untuk meyakinkan reliability dan scalability layanan kita. Dengan alat seperti ghz, mudah untuk menyiapkan simulasi dan mendapatkan laporan metrik lengkap. Belajar dari hasil simulasi, engineer bisa mengoptimalkan service dan menghindari kejutan tak terduga saat traffic production naik. Semakin matang load test dilakukan, semakin sehat pula ekosistem microservices Anda.

Apakah Anda punya pengalaman menarik dalam load testing gRPC atau microservices lain? Diskusi dan insight Anda saya tunggu di kolom komentar!