Belajar MCP - Proxy, Gateway & Fleet

#Pendahuluan

Di episode 15 kalian memasang observability pada satu server. Sekarang bayangkan kalian mengoperasikan sepuluh server MCP: satu untuk git, satu untuk database, satu untuk slack, dan seterusnya. Setiap server punya URL, token, dan konfigurasi keamanannya sendiri. Memberikan akses langsung ke sepuluh endpoint kepada setiap agent adalah mimpi buruk operasional. Episode 16 ini memperkenalkan lapisan yang merapikannya: MCP gateway plus manajemen fleet.

Roadmap episode ini: alasan membangun gateway, implementasi gateway dengan routing, unified auth di satu titik, lalu manajemen fleet — versioning server, rolling deployment, dan health/readiness checks.

#Mengapa Butuh MCP Gateway

Seiring bertambahnya server, masalah yang muncul bertambah cepat dari sekadar "banyak URL". Setiap agent yang ingin memakai lima tool server harus dikonfigurasi dengan lima endpoint, lima kredensial, dan lima kebijakan. Belum lagi kalian harus memutasi kredensial, memindahkan server, atau menambah instance saat beban naik — semua itu menyebar ke setiap konfigurasi klien.

Gateway memecahkan ini dengan pola satu pintu: agent hanya tahu satu endpoint, dan gateway yang tahu cara merutekan ke server yang tepat di belakangnya. Manfaat yang langsung terasa:

Satu titik konfigurasi — agent tidak perlu tahu detail internal topologi.
Unified auth — otentikasi dan otorisasi dilakukan sekali, bukan di tiap server.
Routing yang bisa diubah — memindahkan traffic antar instance, versi, atau region tanpa mengubah klien.

Dalam arsitektur stateless 2026-07-28, gateway bahkan makin sederhana: karena setiap request membawa identitas dan capability-nya sendiri, gateway tidak perlu mempertahankan session affinity (episode 3 dan 9) dan bisa merutekan per-request secara bebas.

#Membangun MCP Gateway

Sebuah gateway pada dasarnya adalah server Streamable HTTP (episode 13) yang menerima request JSON-RPC, memutuskan server tujuan, dan meneruskan. Keputusan routing didasarkan pada method yang dipanggil: tools/call membawa nama tool, resources/read membawa URI, dan prompts/get membawa nama prompt — semua ini cukup untuk memetakan ke server yang tepat.

Konfigurasi routing sederhana:

gateway.yaml - peta tool dan resource ke server

servers:
  git:
    url: http://git-mcp.internal:8080/mcp
    routes:
      tools: ["git_status", "git_commit", "git_push"]
  db:
    url: http://db-mcp.internal:8080/mcp
    routes:
      resources: ["postgres://*", "mysql://*"]
  slack:
    url: http://slack-mcp.internal:8080/mcp
    routes:
      tools: ["slack_send"]
      prompts: ["standup_report"]

Implementasi intinya di TypeScript tidak jauh dari handler HTTP biasa: terima POST, baca method, cocokkan dengan tabel route, lalu teruskan body JSON-RPC ke server tujuan dan kirim balik response-nya. Kunci yang sering luput adalah timeout dan error mapping — kalau server tujuan lambat atau error, gateway harus menerjemahkannya ke kode error JSON-RPC yang standar, bukan membiarkan timeout membingungkan agent.

#Unified Auth

Dengan gateway, autentikasi berhenti menjadi urusan tiap server. Semua request masuk diverifikasi di satu tempat dengan satu kebijakan: OAuth 2.1 dari episode 10 untuk klien eksternal, API key atau mTLS untuk layanan internal. Server di belakang gateway bisa memakai credential service yang berbeda — atau bahkan tanpa autentikasi sama sekali — karena tidak pernah terekspos langsung ke luar.

Yang perlu dijaga: jangan pernah meneruskan credential klien ke server backend secara mentah. Gateway adalah batas kepercayaan. Pola yang benar:

Gateway memverifikasi identitas klien (token, scope).
Gateway memetakan identitas itu ke izin (tool mana yang boleh dipanggil).
Gateway meneruskan request ke backend dengan credential layanannya sendiri, bukan token klien.
Response kembali lewat gateway, dan gateway mencatat audit log pemanggilan.

Dengan cara ini, revoke akses satu klien cukup di satu tempat, dan kalian mendapat catatan siapa memanggil tool apa — modal untuk audit dan deteksi penyalahgunaan dari episode 14.

#Fleet Management & Versioning

Di belakang gateway, kalian mengoperasikan fleet server. Setiap server MCP harus diperlakukan seperti aplikasi produksi: punya versi, pipeline rilis, dan strategi upgrade. Dua konsep yang wajib ada:

Versioning — setiap rilis diberi versi semantik dan, bila memungkinkan, dipublikasikan sebagai artefak Docker dengan tag yang tidak bisa diubah (SHA image, seperti yang dipakai pipeline release di repo ini). Gateway tahu versi mana yang aktif untuk route mana.
Environment terpisah — staging dan production adalah fleet yang berbeda, terisolasi oleh jaringan dan kredensial. Rilis lewat staging dulu sebelum menyentuh production.

Versioning juga penting karena MCP berevolusi cepat (episode 17 membahas compatibility antar era spec). Mengetahui versi server dan versi SDK yang dipakainya memungkinkan kalian merencanakan upgrade sebelum versi tersebut dihentikan.

#Rolling Deployment & Health/Readiness

Bagian paling menegangkan dari operasional fleet adalah mengganti versi tanpa downtime. Rolling deployment mengganti instance sedikit demi sedikit: naikkan instance baru dengan versi baru, tunggu healthy, turunkan yang lama. Selama proses, gateway hanya mengarahkan traffic ke instance yang sehat.

Deployment di Kubernetes dengan strategi rolling:

deployment.yaml - rolling update dengan health check

apiVersion: apps/v1
kind: Deployment
metadata:
  name: db-mcp
spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1
      maxSurge: 1
  template:
    spec:
      containers:
        - name: mcp
          image: registry.internal/db-mcp:sha-9f2c71a
          ports:
            - containerPort: 8080
          readinessProbe:
            httpGet:
              path: /healthz
              port: 8080
            initialDelaySeconds: 5

Perhatikan readiness probe: Kubernetes tidak akan mengirim traffic ke pod sebelum /healthz menjawab 200. Inilah yang membedakan dua konsep:

Health check — server hidup dan tidak sedang crash; jika gagal, pod di-restart.
Readiness check — server siap menerima traffic; jika gagal, traffic ditahan sementara (misalnya saat startup atau saat dependensi belum siap).

Gateway juga memeriksa health backend secara berkala dan menandai server yang tidak sehat sebagai unavailable — memotongnya dari routing tanpa menunggu request pertama gagal.

Info

Uji readiness probe dengan benar: buat endpoint yang benar-benar memeriksa dependensi (koneksi database, koneksi ke identity provider), bukan sekadar return 200. Readiness yang palsu adalah penyebab klasik error flaky di tengah rolling deployment — pod terlihat sehat tapi langsung gagal ketika menerima traffic nyata.

#Penutup

Episode 16 mengubah kumpulan server MCP yang berantakan menjadi satu arsitektur terkelola: gateway sebagai satu pintu masuk dengan routing berbasis method dan unified auth, diikuti fleet management dengan versioning semantik, rolling deployment, serta health dan readiness checks yang menjaga trafik hanya menuju instance yang benar-benar siap.

Inti yang harus dibawa pulang:

Gateway menyembunyikan topologi: agent hanya melihat satu endpoint, routing dilakukan per-request di belakang layar.
Unified auth di satu titik — verifikasi klien di gateway, jangan meneruskan token klien ke backend; catat audit log.
Fleet butuh versioning — setiap server punya versi semantik dan artefak yang bisa dirilis, dengan staging terpisah dari production.
Rolling deployment mengganti instance bertahap, dengan gateway dan orchestrator hanya mengarahkan traffic ke instance sehat.
Health vs readiness berbeda: health untuk restart, readiness untuk menentukan layak menerima traffic.

Episode 17 berikutnya kita menutup fase operasional dengan topik yang sering dilupakan sampai terlambat: Versioning & Compatibility (Modern vs Legacy) — negosiasi versi antara dua era spec, implementasi dual-era, dan kebijakan deprecation dengan removal clock. Sampai jumpa!