Yük Dengeleme — Trafik Artınca Kapıya Kim Bakar?

Bir banka şubesinde tek gişe açıksa kuyruk kapıya kadar uzar. Yeni gişeler açılınca kapıda biri durup müşterileri boş gişelere yönlendirmeye başlar.

Bir sunucu yetmeyince

Daha güçlü bir makineye geçmek dikey ölçeklemedir: basittir ama bir tavanı vardır ve o makine düşünce her şey durur. Yatay ölçekleme?Terimin tanımını açyatay ölçeklemeKapasiteyi, aynı servisin daha çok kopyasını çalıştırarak artırmak. Tek makineyi büyütmeye dikey ölçekleme denir.Sözlükte gör → ise aynı servisin kopyalarını çalıştırır.

Kopyaların önünde bir load balancer?Terimin tanımını açload balancerBir servisin kopyalarının önünde durup gelen istekleri aralarında dağıtan bileşen. Sağlıksız kopyaya trafik göndermemek için onları düzenli olarak kontrol eder.Sözlükte gör → durur. Her isteği kopyalardan birine yollar ve sağlıksız olanı rotasyondan çıkarır.

Tek bir şart var: kopyalar birbirinin yerine geçebilmeli. Oturum bir instance’ın belleğindeyse kullanıcı her istekte başka bir dünyaya düşer; bunu oturum ve stateless ölçekleme dersinde ayrıntılı göreceksin.

Sırayla mı, en boşa mı?

En basit algoritma round-robin: A, B, C, sonra yine A. Instance’lar eşitken çok iyi çalışır.

Least-connections?Terimin tanımını açleast-connectionsHer yeni isteği o an en az açık isteği olan kopyaya veren dağıtım algoritması. Yavaşlayan kopyayı kendiliğinden daha az kullanır.Sözlükte gör → hıza bakmaz, işe bakar: kimde az iş varsa ona verir. Instance’ların güçleri farklıysa ağırlıklı round-robin de kullanılır; güçlü olana daha çok pay düşer.

Kim ayakta, kim hazır?

Yük dengeleyici instance’lara düzenli olarak sorar: health check. Cevap vermeyen ya da hata dönen instance birkaç denemeden sonra rotasyondan çıkar. Bir de pasif kontrol vardır: gerçek isteklerde üst üste hata alan instance bir süre dinlenmeye alınır.

Doğru soru, yaşayıp yaşamadığı değil, trafik almaya hazır olup olmadığıdır. Açılışta cache ısıtan bir instance yaşar ama hazır değildir; yük dengeleyici readiness?Terimin tanımını açreadiness probeKubernetes'in "bu pod şu an trafik almaya hazır mı?" sorusu. Düşerse pod yeniden başlatılmaz, yalnızca load balancer'dan çıkarılır.Sözlükte gör → kontrolüne bakar. Kapanırken de önce readiness düşer ki elindeki istekler bitsin; graceful shutdown dersindeki gibi.

Yük dengeleyiciler iki katmanda çalışır. L4 bağlantıyı IP ve port’a göre dağıtır, içeriği okumaz. L7 HTTP isteğini okur; yola, başlığa ya da cookie’ye göre yönlendirebilir.

Kendin gör

Üç instance, her tur dört istek. Sağlıklı bir instance tur başına iki istek bitirir. B’ye ne olacağını ve yük dengeleyicinin nasıl davranacağını sen seçiyorsun.

1. Varsayılanı oynat. Round-robin, B yavaş. Health check açık ama B testten geçiyor; B’nin kuyruğu uzuyor.
2. Algoritmayı least-connections yap. Aynı yavaş B, ama uzun bekleyen istek yok.
3. “B çöktü” seç, health check’i kapat. Round-robin’de her üç istekten biri kayboluyor.
4. Şimdi least-connections’a geç. Çöken B en boş görünüyor ve trafiğin çoğunu yutuyor. Health check’i aç ve farkı gör.

Tuzaklar

Dış bağımlılığı soran health check. Readiness bütün instance’ların paylaştığı bir dış servise bakarsa, o servis yavaşlayınca hepsi birden “hazır değilim” der. Yük dengeleyici hepsini çıkarır ve bir yavaşlık tam kesintiye döner.

POST’u tekrar denemek. Zaman aşımına düşen istek başka bir instance’a tekrar gönderilirse havale iki kez yapılabilir. Otomatik tekrar idempotent isteklerle sınırlanır; gerisini idempotency key korur.

Arkadakiler çarpılır. Her yeni instance kendi bağlantı havuzunu açar: on instance ve yirmişer bağlantı, veritabanına iki yüz bağlantı demektir. Instance eklemeden önce arkadaki kaynağın bunu kaldırıp kaldırmadığına bakılır.

1
upstream payments {
2
    least_conn;
3
    # Passive check: three failures within 10s take an instance out for 10s.
4
    server app-1:8080 max_fails=3 fail_timeout=10s;
5
    server app-2:8080 max_fails=3 fail_timeout=10s;
6
    server app-3:8080 max_fails=3 fail_timeout=10s;
7
}
8

9
server {
10
    listen 443 ssl;
11

12
    location /api/ {
13
        proxy_pass http://payments;
14
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
15
        proxy_connect_timeout 1s;
16
        proxy_read_timeout 5s;
17
        # Retry on connection errors only; a POST already sent is never sent again (nginx default).
18
        proxy_next_upstream error;
19
    }
20
}

1
server:
2
  shutdown: graceful
3

4
spring:
5
  lifecycle:
6
    timeout-per-shutdown-phase: 20s
7
  datasource:
8
    hikari:
9
      # 3 replicas x 10 = 30 connections to the database. Recheck before adding replicas.
10
      maximum-pool-size: 10
11

12
management:
13
  endpoint:
14
    health:
15
      probes:
16
        enabled: true
17
      group:
18
        readiness:
19
          # Only this instance's own state. Shared external services stay out of it.
20
          include: readinessState

1
apiVersion: apps/v1
2
kind: Deployment
3
metadata:
4
  name: payments
5
spec:
6
  replicas: 3
7
  selector:
8
    matchLabels:
9
      app: payments
10
  template:
11
    metadata:
12
      labels:
13
        app: payments
14
    spec:
15
      containers:
16
        - name: payments
17
          image: bank/payments:1.8.0
18
          ports:
19
            - containerPort: 8080
20
          readinessProbe:
21
            httpGet:
22
              path: /actuator/health/readiness
23
              port: 8080
24
            periodSeconds: 5
25
            failureThreshold: 2
26
          livenessProbe:
27
            httpGet:
28
              path: /actuator/health/liveness
29
              port: 8080
30
            periodSeconds: 10
31
            failureThreshold: 3

Kendini sına

Önce hızlı bir ısınma: puan yok, kayıt yok. Sonra asıl sorular.