Belajar Traefik - Services & Load Balancing

#Pendahuluan

Setelah router memutuskan ke mana request pergi, service menentukan tujuan akhirnya. Episode 7 membedah seluruh mekanisme service dan load balancing Traefik: berbagai tipe service, cara mendefinisikan beberapa server, pembagian beban, health check, sticky session, hingga mirroring untuk pengujian.

Load balancing adalah alasan Traefik sering dipilih sebagai pintu gerbang microservices. Kemampuannya mengelola beberapa instance backend secara transparan — ditambah health check yang menjaga kualitas — membuat skala horizontal menjadi hal yang mudah. Mari kita kuasai dari sisi paling dasar.

#Tipe-Tipe Service

#Lima Keluarga Service

• HTTP service: melayani request HTTP/HTTPS, tipe yang paling umum dipakai.
• TCP service: meneruskan koneksi TCP mentah — berguna untuk database, SSH, dan protokol non-HTTP.
• UDP service: meneruskan datagram UDP, misalnya untuk DNS atau game server.
• Weighted service: menggabungkan beberapa service dengan pembagian persentase — basis untuk canary dan blue-green.
• Mirroring service: menyalin trafik ke service lain untuk shadowing tanpa mengganggu produksi.

Episode 7 fokus pada HTTP service; TCP dan UDP dibahas khusus di episode 18, sementara weighted dan mirroring kita kupas di bagian akhir episode ini.

#Load Balancer Dasar

#Server List dan Round Robin

Secara default Traefik melakukan round robin: setiap request diteruskan ke server berikutnya secara bergiliran. Dalam Docker, server list dibuat otomatis dari container yang di-scale. Dalam file provider, kalian mendefinisikan server secara manual:

http:
  services:
    web-svc:
      loadBalancer:
        servers:
          - url: "http://10.0.0.11:80"
          - url: "http://10.0.0.12:80"
        passHostHeader: true

passHostHeader: true adalah default yang meneruskan header Host asli ke backend — penting karena banyak aplikasi memutuskan virtual host berdasarkan header ini. Nilai false untuk passHostHeader akan membuat backend melihat host Traefik, bukan host asli pengunjung.

#Health Checks

#Menjaga Kualitas Backend

Tanpa health check, Traefik meneruskan request ke backend yang mungkin sudah mati, menghasilkan 502. Health check memperbaiki ini: Traefik memeriksa backend secara berkala dan mengeluarkan yang sakit dari rotasi:

http:
  services:
    api-svc:
      loadBalancer:
        servers:
          - url: "http://10.0.0.21:3000"
          - url: "http://10.0.0.22:3000"
        healthCheck:
          path: "/health"
          interval: "15s"
          timeout: "3s"
          healthyStatuses:
            - 200
          followRedirects: true

Pengaturan di atas memeriksa /health setiap 15 detik dengan batas waktu 3 detik. Backend yang tidak mengembalikan 200 akan dikeluarkan sementara dari rotasi. Traefik juga mengelola koneksi secara pasif: jika backend gagal merespons request nyata, dia ikut ditandai tidak sehat. Health check adalah lapisan pertahanan pertama kualitas layanan kalian.

#Algoritma Load Balancing

#Round Robin dan Weighted

Algoritma default Traefik adalah round robin. Untuk mengendalikan proporsi trafik, gunakan weighted service yang menggabungkan service-service dengan bobot:

http:
  services:
    app-canary:
      weighted:
        services:
          - name: app-stable
            weight: 9
          - name: app-v2
            weight: 1

Kombinasi di atas mengirim 90 persen trafik ke app-stable dan 10 persen ke app-v2. Pola ini adalah dasar canary deployment: menaikkan bobot app-v2 bertahap sambil memantau error rate, sampai akhirnya versi baru menerima semua trafik dan versi lama dihapus. Masing-masing service tetap memakai round robin internalnya sendiri.

#Sticky Sessions

#Konsistensi dalam Sesi

Beberapa aplikasi menyimpan state di session — jika request kedua jatuh ke server lain, session hilang. Sticky session menyelesaikan ini dengan menulis cookie yang menandai server tujuan:

http:
  services:
    app-svc:
      loadBalancer:
        servers:
          - url: "http://10.0.0.31:80"
          - url: "http://10.0.0.32:80"
        sticky:
          cookie:
            name: "session-affinity"
            secure: true
            httpOnly: true

Cookie bernama session-affinity ditulis pada response pertama; request berikutnya dari klien yang sama akan selalu diarahkan ke server yang sama. Atribut secure: true membuat cookie hanya dikirim lewat HTTPS, dan httpOnly: true mencegah JavaScript membaca cookie — kombinasi yang direkomendasikan untuk production.

#Service Mirroring

#Traffic Shadowing

Mirroring service menyalin request ke service tambahan tanpa memengaruhi response utama. Response asli tetap diambil dari service utama; salinan dikirim secara paralel hanya untuk observasi:

http:
  services:
    app-mirror:
      mirroring:
        service: app-prod
        maxBodySize: 1048576
        mirrors:
          - name: app-staging
            percent: 100

Pola ini sangat berguna untuk menguji versi baru: kirim semua trafik produksi ke versi staging untuk diamati, tanpa mengubah apa pun yang diterima pengguna. Gunakan percent untuk mengontrol berapa persen request yang di-mirror. Service app-mirror inilah yang dirujuk router, bukan service aslinya.

#Penutup

Inti yang harus dibawa pulang:

• Tipe service: HTTP, TCP, UDP, weighted, dan mirroring.
• Load balancer memakai round robin secara default; passHostHeader meneruskan host asli.
• Health check menjaga hanya backend sehat yang menerima trafik.
• Weighted service adalah dasar canary deployment.
• Sticky session memakai cookie, tapi desain stateless tetap lebih baik.
• Mirroring menyalin trafik untuk shadowing tanpa memengaruhi pengguna.

Di episode 8 selanjutnya kita akan membahas middleware fundamentals — konsep request chain dan response chain, urutan eksekusi, cara men-chaining beberapa middleware, tipe middleware HTTP dan TCP, serta pola umum autentikasi, security headers, dan modifikasi request. Ini membuka gerbang fase ketiga series.