İki autoscaler hikâyesi: dışarıdan izlemek ile içeriden akıl yürütmek
A Tale of Two Flink Autoscalers · Netflix Technology Blog
Netflix 2017'den beri Apache Flink ile akış işliyor ve 2026 itibarıyla birden fazla AWS bölgesinde 30.000'den fazla Flink işi çalıştırıyor. Çoğu elle değil, yönetilen platformları Data Mesh tarafından üretiliyor; daha küçük ama büyüyen bir kısmı kişiselleştirme, reklam ve canlı yayın gibi alanlarda ekiplerin kendi yazdığı işler. Yükleri günlük döngülerle, lansmanlarla ve bölgesel yük devirleriyle dalgalanıyor.
Zirveye göre kaynak ayırmak israf, ortalamaya göre ayırmak ani yükte gecikme. Üstelik ölçekleme bedava değil: varsayılan olarak savepoint almak, işi düzgünce durdurmak ve yeni boyutta yeniden başlatmak demek; büyük durumlu işlerde bu dakikalar sürüyor.
İlk autoscaler (yaklaşık 2019) bir akış işi gibi kurulmuştu: Mantis üzerinde, Atlas telemetri platformundan küme düzeyinde metrikleri (CPU, ağ, Kafka gecikmesi, giriş hızı) tüketiyordu. Ama dışarıdan izlemenin tavanı vardı: tüm kümeyi kaba konteyner metrikleriyle değerlendiriyor ve tek bir düğmeyi (toplam TaskManager sayısı) çevirdiği için işteki bütün operatörler birlikte ölçekleniyordu. Daha kötüsü, bir iş tamamen meşgul olup bunun hiçbiri CPU kullanımına yansımayabiliyordu.
İkinci autoscaler, topluluğun Apache Flink Autoscaler'ı, içeriden akıl yürütüyor. Anahtar fikir her operatörün gerçek işleme hızını (TPR) tahmin etmek: tamamen meşgul olsa sürdürebileceği verim. Flink, her alt görev için saniyenin ne kadarının gerçek iş yaparak geçtiğini, geri basınç ve boşta bekleme süresinden ayrı raporluyor. Netflix şimdi ikisini birlikte işletiyor ve adım adım açık kaynak olana yakınsıyor.
Öne çıkanlar
- Dışarıdan metrik (CPU) ile içeriden metrik (meşgul oranı) aynı şeyi söylemeyebilir; yanlış sinyal yanlış ölçekleme demek.
- Tek düğmeli ölçekleme (toplam TaskManager) her operatörü aynı oranda büyütür; darboğaz operatörü ayrı ölçeklemek daha verimli.
- Ölçeklemenin kendisinin maliyeti var (savepoint, durdur, yeniden başlat); bu yüzden gereksiz ölçekleme de pahalı.
- Kendi yazdığın altyapıyı sürdürmenin gizli fiyatı, hazır çözüm olgunlaştığında ortaya çıkıyor.
Neden önemli?
Otomatik ölçekleme kararı, beslendiği metrik kadar iyidir. Bu yazı, “CPU %40, demek ki rahatız” varsayımının ne zaman yalan söylediğini gösteriyor: iş doluyken CPU boş görünebilir. Doğru metrik, sistemin gerçekte neyi beklediğini ölçen metriktir.
Sende karşılığı
Kendi servislerinde de kuyruğa bağlı bir tüketici çalıştırırsan aynı tuzak var: CPU'ya göre ölçekleme yapma, kuyruk gecikmesine (consumer lag) göre yap. Spring Boot tüketicin CPU'da %20 görünürken kuyruk büyüyorsa, iş bir dış çağrıyı bekliyordur. İkinci ders “build vs buy” için: bu gazetenin fetch.py içindeki RSS ayrıştırıcısı gibi küçük şeyleri kendin yazmak sorun değil; ama olgun bir kütüphane varsa onu benimseme zamanını bilmek de beceridir.
Sözlük
- autoscaler otomatik ölçekleyici
- Yüke göre kaynak miktarını insan müdahalesi olmadan artıran ya da azaltan bileşen.
- backpressure geri basınç
- Aşağı akıştaki bir bileşen yetişemediğinde, yukarıdaki üreticinin yavaşlatılması.
- savepoint kayıt noktası
- Flink işinin durumunun tutarlı bir anlık görüntüsü; durdurup yeniden başlatırken veri kaybını önler.
- true processing rate (TPR) gerçek işleme hızı
- Bir operatörün tamamen meşgul olsa sürdürebileceği teorik verim.