GPU iş yüklerinde otomatik ölçeklendirme sorunu, Kubernetes'in karar verememesi değil, kararın çok geç ulaşması olabilir. Adobe'dan Ramkumar Nagaraj ve Bingi Narasimha Karthik, kritik bir üretim hizmetinin, Horizontal Pod Autoscaler ölçeklendirmeyi başlatmış olmasına rağmen, bir talep dalgası nedeniyle kullanıcı hata oranlarının %15–20'ye yükseldiği bir olayı anlatıyor. Bunun nedeni, yüzlerce konteynerin beklemede kalması ve yeni GPU düğümlerinin hazır hale gelmesinin uzun sürmesiydi.
Yazarların belgelediği zaman çizelgesinde talep dalgası saat 06:00'da geldi, HPA göstergeleri 06:05'te eşiği aştı ve konteynerlerin zamanlaması 06:15'te başladı. Ancak ilk GPU düğümlerinin hazırlanması ancak 06:45'te tamamlandı; yani artış dalgası sona erdikten sonra. GPU düğümlerinin hazırlanması; aygıt yazılımının yüklenmesi, sürücülerin yapılandırılması ve CUDA'nın hazırlanması nedeniyle genellikle CPU tabanlı hizmetlerin hazırlanma süresinin üç ila beş katını alır.
Talebe Tepkiden Talebe Hazırlığa
Ekip, Kubernetes içinde her 60 saniyede bir çalışan, önceki ölçümlerin bir saatini okuyarak on dakika sonraki talebi öngören bir denetleyici çalıştırmayı önerdi. Amaç kusursuz öngörü değil, düğümlerin ve konteynerlerin ihtiyaç anında hazır olabilmesi için kapasite hazırlığını dalga gelmeden yeterince önce başlatmaktır.
Tasarımda Prometheus'un topladığı CPU ve bellek kullanımı, yanıt süresi, istek oranı ve GPU kullanımı gibi verilerden yararlanıldı. Ekip, her durumda teorik olarak en iyi seçenek olduğu için değil, makaleye göre kısa süreli artışlar, toparlanma dönemleri ve anormal sabit değerler içeren veri örüntülerine yanıt olarak iki katmanlı, sırasıyla 64 ve 32 birimden oluşan Bi-LSTM modelini seçmeden önce ARIMA, üstel düzeltme, Prophet kütüphanesi ve LSTM modellerini test etti.
Model haftalık olarak yeniden eğitiliyor; dağıtılan model ise TensorFlow Lite kullanılarak Go ile yazılmış bir denetleyici ikili dosyası içinde yalnızca çıkarım modunda çalışıyor. Böylece tasarım harici bir makine öğrenimi platformuna veya model sunum katmanına ihtiyaç duymuyor.
Ölçeklendirmeyi Düzenleyen Üç Katman
Tasarım, birbiriyle bağlantılı üç işleve dayanıyor: öngörü, hazırlık ve soğurma. Model talebi öngörüyor, ardından denetleyici kopya sayısını kademeli olarak artırıyor; önceden hazırlanmış kapasite ise gerçek dalganın karşılanması için alan sağlıyor.
Öngörü her sürprizle başa çıkamadığı için ekip, buna paralel çalışan bir ani artış dedektörü ekledi. Bu bileşen, hareketli standart sapmaya dayalı uyarlanabilir bir eşik kullanarak gerçek talebi öngörülerle karşılaştırıyor. Talep, belirlenen güven düzeyini karşılayan bir farkla öngörüyü aşarsa dedektör ölçeklendirme hızını artırıyor. Yazarlar bu bileşeni ikinci bir öngörü modeli değil, çıkarımsal bir güvenlik ağı olarak tanımlıyor.
Kademeli ölçeklendirici artışı dakikada 20 konteynerle sınırlıyor. Amaç, zamanlayıcı ve etcd üzerinde baskı oluşturabilecek, görüntü çekme, konteyner çalıştırma, başlatma konteynerlerini hazırlama ve yan birimleri enjekte etme işlemlerinde yığılmaya yol açabilecek büyük bir zamanlama dalgasını önlemek. Hedeflenen kullanım da %100 yerine %70 olarak belirlendi; böylece artışları karşılamak ve model zaman zaman hatalı olduğunda hatanın bir dizi arızaya dönüşmesini önlemek için pay bırakılıyor.
Testler Neyi Kanıtladı?
Ekip sistemi önce, öngörülerin gerçek bir ölçeklendirme uygulanmadan kaydedildiği gölge modunda çalıştırdı ve 500 saatten fazla veri topladı. Sonuçlar, on dakika sonraki talep öngörüsü gerçek talebin ±%10 aralığında olduğunda %85 doğruluk gösterdi. Artış dedektörü on dalganın dokuzunu yakaladı ve iki yanlış alarm verdi; kademeli ölçeklendirici testlerinde ise zincirleme arıza veya ölçeklendirme salınımı görülmedi.
Sistem ayrıca HPA v2 ile çakışma olmadan birlikte çalıştı. Kontrollü bir geliştirme ortamında bir hafta süren doğrulama sırasında 23 testin 23'ünü geçti. İlk olaya neden olan artış örüntülerinin simülasyonunda sistem dalgayı yaklaşık 11 dakika önceden tespit edebildi.
Bu Yaklaşım Ne Zaman Uygundur?
Öngörülü ölçeklendirmenin değeri, düğümlerin hazırlanmasının iki veya üç dakikadan uzun sürdüğü ve günlük, haftalık örüntüler ya da bilinen etkinlikler gibi talebin kısmen öngörülebilir olduğu durumlarda ortaya çıkar. Ayrıca en az bir haftalık Prometheus ölçümleriyle birlikte iyi izleme verilerine ihtiyaç duyar. Buna karşılık düğümler 30 saniye içinde hazırlanıyorsa, talep tamamen rastgeleyse veya ekibin önceliği her şeyden önce maliyeti düşürmekse fikir daha az anlamlı hale gelir; sıcak düğümleri çalışır durumda tutmak yedek kapasite maliyeti ödemek anlamına gelir.
Editoryal değerlendirme: Buradaki pratik değişiklik HPA'nın yerine başka bir şey koymak değil, normalde talep ortaya çıktıktan sonra tepki veren bir sisteme öngörü süresi eklemektir. Bunun önemi özellikle GPU iş yüklerinde görülür; altyapının konteynerleri çalıştırmadan önce onlarca dakikaya ihtiyaç duyduğu durumlarda ölçeklendirme kararının hızı tek başına yeterli olmaz. Ancak sunulan kanıt hâlâ kontrollü bir doğrulamadan elde edilmiş durumda; farklı üretim ortamlarında geniş kapsamlı, bağımsız bir ölçüm değil.
Ekibin deneyimi de önemli kısıtlamalara işaret ediyor: İyi ayarlanmış bir ARIMA modeli daha basit bir mimariyle benzer bir sonuç verebilir ve talep örüntüleri değiştiğinde model birkaç gün içinde güncelliğini yitirebilir. Ayrıca belirli sayıda kopyanın neden öngörüldüğünü açıklamak zor olmaya devam etti; en uygun veri hacmi, yeniden eğitim sıklığı ve çıkarımsal artış dedektörünün emsalsiz olayları yakalama kapasitesiyle ilgili sorular da henüz kesinleşmedi.
Bu nedenle makale, bir hafta boyunca ölçüm toplamaya, basit bir model eğitmeye, modeli gölge modunda çalıştırmaya ve ölçeklendirmeyi etkinleştirmeden önce doğruluğu ölçmeye başlamayı öneriyor. Üretime geçerken kopyalar için bir üst sınır uygulanmalı, açık bir devre dışı bırakma prosedürü sağlanmalı ve tercihen tam kapsamı açmadan önce sınırlı bir ölçeklendirme aşamasından geçilmeli. Yazarların tekrarladığı sonuç pratik: Modelin karmaşıklığı başlı başına bir avantaj değildir; daha basit çözüm başarılı oluyorsa onu çalıştırmak daha iyidir.