Yatayda 50 instance'a ölçeklendik. Darboğaz yalnızca yer değiştirdi.

Aşama 1: Uygulama darboğazı

  • 5 uygulama sunucusu, %100 CPU
  • Çözüm: 20 sunucuya ölçeklen
  • Sonuç: Uygulama CPU %30

Aşama 2: Veritabanı darboğazı

  • Veritabanı: %100 CPU, 5.000 bağlantı
  • Çözüm: Connection pooling, read replica'lar
  • Sonuç: Veritabanı CPU %60

Aşama 3: Load balancer darboğazı

  • ALB ölçeklemesi keskin bir trafik sıçramasının gerisinde kaldı — ALB'ler LCU'lara göre otomatik ölçeklenir ama anında değil; bizim sıçramamız onu geride bıraktı
  • Çözüm: bilinen trafik olaylarından önce ön-ölçekleme (AWS destekle koordineli) ve en sıçramalı iç TCP trafiğini bir NLB'ye taşıdık
  • Sonuç: Trafik dağıtıldı

Aşama 4: Mesaj kuyruğu darboğazı

  • Tek düğümlü RabbitMQ doygunluğa ulaştı
  • Çözüm: Cluster'lanmış kuyruk, bölümlenmiş topic'ler
  • Sonuç: Mesajlar akıyor

Ders:

Theory of constraints, applied to systems:

System throughput = min(
    app_capacity,
    db_capacity,
    network_capacity,
    queue_capacity,
    external_api_capacity
)

Ne öğrendik:

  • Darboğazı ölçeklemeden ÖNCE belirleyin
  • Tüm yolu yük testinden geçirin
  • Yalnızca uygulamaları değil, tüm bileşenleri izleyin
  • Bazen dikey ölçekleme daha ucuzdur

Tam yol yük testi — yalnızca uygulama katmanı değil, istemciden veritabanına ve geri — DevOps çalışmalarımızda standart bir egzersizdir; çünkü bir sonraki darboğaz, test etmediğiniz bileşende yaşar.

Ders: Bir bileşeni ölçeklemek darboğazı bir sonrakine taşır. Uçtan uca kapasite için plan yapın.

← Çıkarılan Dersler'e dön

Bu tür olaylar önlenebilir. AWS Yönetilen Hizmetler ekibimiz müşteri ortamlarını yapay zekâ destekli izleme ve nöbetteki kıdemli mühendislerle 7/24 gözetir — böylece bu tür hikâyeler arşivde kalır.

Etiketler: #Ölçekleme #Performans #Darboğaz #Mimari