Belajar WebSocket - Cloud Deployment (AWS, GCP, Azure)

#Pendahuluan

Menjalankan WebSocket di cloud lebih dari sekadar menyewa server: kalian harus memilih layanan, mengatur load balancer agar koneksi panjang tidak putus, dan memastikan scaling bekerja. Setiap provider punya solusi sendiri, termasuk managed service yang menghilangkan beban infrastruktur.

Episode 29 membahas cloud deployment di AWS, GCP, dan Azure: opsi kontainer, konfigurasi load balancing khusus WebSocket, serta managed WebSocket service yang bisa mengurangi biaya operasional.

#AWS

#ECS dan Fargate

Amazon ECS dengan Fargate menjalankan container tanpa mengelola server.

aws ecs create-service \
  --cluster ws-cluster \
  --service-name ws-service \
  --task-definition ws-task \
  --desired-count 2 \
  --load-balancers targetGroupArn=arn:aws:elasticloadbalancing:ap-southeast-1:123456789012:targetgroup/ws-tg/abc

--desired-count 2 menjaga dua task berjalan. Target group dipasang di Application Load Balancer (ALB) yang mengerti WebSocket dan mendukung target-based sticky session.

#ALB untuk WebSocket

ALB secara native mendukung koneksi WebSocket: ia membaca header Upgrade dan mempertahankan koneksi panjang. Konfigurasi kuncinya: target group dengan protocol HTTP/HTTPS, keep-alive timeout di atas durasi koneksi, dan session stickiness berbasis cookie.

#EKS dan CloudFront

Untuk kontrol penuh, EKS (Kubernetes terkelola) membawa semua yang dipelajari di episode 28. CloudFront bisa menayangkan aset statis, sementara WebSocket dilayani langsung dari ALB — CloudFront tidak dirancang untuk meneruskan koneksi WebSocket yang sangat panjang.

#GCP

#Cloud Run

Cloud Run menjalankan container stateless dengan auto-scaling hingga nol.

steps:
  - name: gcr.io/cloud-builders/docker
    args: ["build", "-t", "gcr.io/$PROJECT_ID/ws-server", "."]
  - name: gcr.io/cloud-builders/gcloud
    args:
      - run
      - deploy
      - ws-server
      - --image=gcr.io/$PROJECT_ID/ws-server
      - --region=asia-southeast1
      - --cpu=1
      - --memory=512Mi

Cloud Build membangun image lalu gcloud run deploy meluncurkannya. Cloud Run bisa discale ke nol, tapi koneksi WebSocket aktif mencegah scaling turun di bawah jumlah koneksi — biaya mengikuti koneksi yang benar-benar terpakai.

#Cloud Load Balancing

Google Cloud Load Balancing mendukung WebSocket dan bisa diatur dengan backend yang sama seperti Kubernetes Ingress. GKE (Kubernetes terkelola) adalah pilihan untuk tim yang sudah memakai Kubernetes.

#Azure

#App Service dan AKS

Azure App Service mendukung WebSocket melalui WebSockets setting. AKS (Kubernetes) adalah jalur yang lebih kuat untuk skala besar.

#Azure SignalR Service

Azure SignalR adalah managed WebSocket service yang menangani koneksi dan scaling secara otomatis.

Server SignalR di Node.js

const { Server } = require("@microsoft/signalr");
 
const server = new Server({
  transport: 1,
  url: "https://ws-app.service.signalr.net",
  hubName: "chat",
});

url menunjuk ke SignalR service yang dikelola Azure. Koneksi dipegang oleh layanan ini, bukan server aplikasi — aplikasi hanya memproses event. Untuk tim yang ingin fokus pada logika bisnis tanpa mengelola load balancer dan sticky session, managed service seperti ini menghemat banyak waktu.

#Managed Services

#Perbandingan

Selain Azure SignalR, ada managed WebSocket service lain:

AWS API Gateway  : WebSocket API terkelola, bayar per koneksi dan pesan
Azure SignalR    : integrasi erat ekosistem .NET dan Node.js
Pusher Channels  : pub-sub real-time sebagai service
Ably             : WebSocket dan pub-sub dengan jaminan SLA

Managed service menghapus beban infrastruktur: no load balancer, no sticky session, no scaling. Konsekuensinya, kontrol lebih terbatas, biaya per pesan bisa tinggi untuk volume besar, dan vendor lock-in perlu dipertimbangkan.

#AWS API Gateway WebSocket API

API Gateway menyediakan endpoint WebSocket dengan model integrasi route:

aws apigatewayv2 create-route \
  --api-id <id> \
  --route-key '$connect'

Route $connect dipicu saat klien melakukan handshake, $disconnect saat koneksi ditutup, dan $default untuk pesan umum. Pengiriman pesan kembali ke klien memakai koneksi management API, bukan koneksi langsung ke server aplikasi.

#Pemilihan Provider

Pilih berdasarkan kebutuhan:

• Tim kecil, fokus pada produk: managed service (API Gateway, SignalR).
• Sudah memakai Kubernetes: EKS, GKE, atau AKS sesuai provider.
• Kontrol penuh dan budget terukur: container di ECS, Cloud Run, atau App Service.
• Biaya per pesan tinggi: pertimbangkan self-managed dengan Redis adapter.

#Penutup

Episode 29 memetakan lanskap cloud: container di tiga provider besar, load balancer yang memahami WebSocket, dan managed service yang menghapus beban infrastruktur. Tidak ada jawaban tunggal — pilihan bergantung pada tim dan biaya.

Inti yang harus dibawa pulang:

• ECS Fargate, Cloud Run, dan App Service menjalankan container di cloud.
• ALB dan Cloud Load Balancing mendukung koneksi WebSocket panjang.
• Kubernetes terkelola (EKS, GKE, AKS) membawa episode 28 ke cloud.
• Managed service menghilangkan beban infrastruktur dengan harga tertentu.
• AWS API Gateway menggunakan route seperti $connect dan $disconnect.
• Pilih layanan berdasarkan tim, kontrol, dan pola biaya.

Di episode 30 berikutnya kita membahas CI/CD pipeline: continuous integration dan deployment, GitHub Actions, serta strategi blue-green dan canary.