Belajar Cloud Computing - Cloud Load Balancing & Auto-Scaling

#Pendahuluan

Di episode 5 kita membangun VPC dengan subnet di beberapa AZ, lalu di episode 6 kita mengisinya dengan VM. Namun satu VM yang menangani semua traffic adalah titik rawan: jika ia mati, aplikasi ikut mati. Episode 8 ini menjawab dua pertanyaan besar arsitektur cloud: bagaimana membagikan beban ke banyak mesin, dan bagaimana jumlah mesin itu menyesuaikan diri dengan beban.

Kita akan mulai dari konsep high availability dan no single point of failure, lalu membandingkan load balancer L4 dan L7, memetakan layanan masing-masing provider, dan menutup dengan auto-scaling lengkap contoh CLI AWS.

#Konsep: High Availability, Fault Tolerance, dan No Single Point of Failure

Sebelum menyentuh tooling, pahami tiga istilah yang menentukan desain arsitektur:

• High availability (HA): layanan tetap tersedia meski satu komponen gagal. Mungkin ada penurunan kecil, tapi pengguna tetap bisa memakai aplikasi.
• Fault tolerance: sistem terus berjalan tanpa degradasi berarti meski terjadi kegagalan komponen.
• No single point of failure (no SPOF): tidak ada satu komponen yang bila mati akan meruntuhkan seluruh sistem.

Prinsip dasar mencapai ketiganya adalah redundansi lintas AZ. Karena AZ adalah gedung data center yang terpisah fisiknya, menempatkan mesin di minimal dua AZ berarti jika listrik atau jaringan satu gedung padam, gedung lain tetap melayani. Inilah alasan kenapa di episode 5 kita selalu menempatkan subnet di beberapa AZ, bukan satu.

#L4 vs L7: Dua Level Load Balancer

Load balancer adalah "pintu masuk tunggal" yang menerima traffic lalu mendistribusikannya ke banyak server. Namun ia bisa bekerja pada dua lapisan yang berbeda:

• L4 (transport layer) bekerja pada level TCP/UDP. Ia hanya melihat alamat IP dan port tujuan, lalu meneruskan paket ke server belakang. Cepat dan ringan karena tidak perlu membaca isi paket — cocok untuk protokol non-HTTP dan kebutuhan latensi terendah.
• L7 (application layer) membaca isi HTTP. Ia bisa melakukan routing berdasarkan path (/api ke service A, /assets ke service B), membaca header dan cookies, memutus koneksi TLS, serta melakukan health check berbasis HTTP.

#Komparasi Layanan Load Balancer Big 3

Konsep sama, nama berbeda. Peta lengkapnya:

Yang patut diperhatikan: karena load balancer adalah pintu masuk tunggal, ia sendiri sebaiknya direplikasi. Di cloud, load balancer biasanya dijalankan sebagai layanan terkelola yang redundan secara internal oleh provider — kalian tidak perlu membangun HA untuk load balancer itu sendiri, hanya memastikan konfigurasinya menyebar ke beberapa AZ.

#Auto-Scaling: Kapasitas yang Mengikuti Beban

Redundansi menangani kegagalan, tapi belum menangani lonjakan. Auto-scaling memecahkan masalah itu: jumlah mesin menyesuaikan beban secara otomatis.

• AWS menyebutnya Auto Scaling Group (ASG), GCP Managed Instance Group (MIG), Azure Virtual Machine Scale Set (VMSS).
• Konfigurasi intinya tiga angka: minimum (paling sedikit yang selalu jalan), maximum (batas atas), dan desired (target saat ini).
• Pemicu scale-out/scale-in bisa berupa metrik: CPU utilization, penggunaan RAM, jumlah request, atau panjang antrian. Bisa juga berbasis jadwal — misalnya menaikkan kapasitas sebelum jam sibuk atau flash sale yang bisa diprediksi.

Bayangkan restoran yang menambah koki saat jam makan siang dan melepasnya saat sepi — dengan tiga aturan sederhana: minimal dua koki selalu ada, maksimal sepuluh koki, dan tambah satu koki jika antrian pembeli di atas batas tertentu. Itulah persis cara kerja auto-scaling.

#Praktik dengan AWS CLI

Langkah pertama adalah membuat launch template — cetakan konfigurasi untuk setiap instance baru. Perintah aws ec2 create-launch-template menyimpan cetakan itu di cloud:

aws ec2 create-launch-template \
  --launch-template-name web-template \
  --launch-template-data '{
    "ImageId": "ami-0abcdef1234567890",
    "InstanceType": "t3.medium",
    "KeyName": "lab-key",
    "SecurityGroupIds": ["sg-0abc123"]
  }'

Lalu bentuk Auto Scaling Group yang memakai template tersebut dan menyebar ke beberapa subnet di AZ berbeda — dilakukan lewat aws autoscaling create-auto-scaling-group:

aws autoscaling create-auto-scaling-group \
  --auto-scaling-group-name web-asg \
  --launch-template "LaunchTemplateName=web-template" \
  --min-size 2 --max-size 10 --desired-capacity 3 \
  --vpc-zone-identifier "subnet-0aaa,subnet-0bbb" \
  --health-check-type ELB

Terakhir, pasang kebijakan scaling berbasis target: biarkan cloud menjaga rata-rata CPU di sekitar 60 persen, menambah atau mengurangi instance otomatis:

aws autoscaling put-scaling-policy \
  --auto-scaling-group-name web-asg \
  --policy-name cpu-target \
  --policy-type TargetTrackingScaling \
  --target-tracking-configuration '{
    "PredefinedMetricSpecification": { "PredefinedMetricType": "ASGAverageCPUUtilization" },
    "TargetValue": 60
  }'

Jika target dirasa terlalu agresif atau terlalu longgar, cukup ubah satu angka:

{
  "PredefinedMetricType": "ASGAverageCPUUtilization",
  "TargetValue": 60, # [!code --]
  "TargetValue": 75 # [!code ++]
}

#Penutup

Pada episode 8 ini, kita telah merancang arsitektur yang tangguh: high availability lewat redundansi lintas AZ, tidak ada single point of failure, load balancer L4 dan L7 yang membagi traffic dengan cerdas, serta auto-scaling yang menyesuaikan jumlah mesin dengan beban. Kalian juga sudah melihat contoh nyata membuat launch template, Auto Scaling Group, dan kebijakan scaling lewat AWS CLI.

Kunci yang harus dibawa pulang:

• Sebar ke beberapa AZ — redundansi adalah fondasi HA, bukan fitur tambahan.
• L4 untuk kecepatan dan protokol non-HTTP, L7 untuk routing berbasis aplikasi.
• Auto-scaling butuh tiga angka (min, max, desired) dan metrik yang tepat — plus health check yang benar-benar mencerminkan kesehatan aplikasi.

Aplikasi kalian sekarang sudah bisa tumbuh dan bertahan. Namun database yang mengikutinya belum: men-scalable aplikasi tanpa database yang andal sama saja menambah pintu masuk tanpa memperkuat gudang. Episode 9 berikutnya membahas Relational Managed Databases (RDBMS) — managed versus self-hosted, high availability multi-AZ dengan failover otomatis, hingga SQL terdistribusi cloud-native seperti Aurora dan Spanner.