Vercel, sıcak Turborepo cache isabetlerinden sonra elastic build makinelerinin küçültülmesi sorununu düzeltti

Ne yaşandı

Vercel blog'undaki bir changelog kaydına göre Vercel, bir build'in daha küçük bir makineye geçirilip geçirilemeyeceğine karar verirken elastic build makinelerini artık Turborepo cache isabetlerini dikkate alacak şekilde güncelledi. Bu düzeltme, sıcak cache'li bir build'in — yani önbelleğe alınmış görev çıktılarının çoğunu yeniden kullanan bir build'in — çok az CPU ve belleğe ihtiyaç duyuyor gibi görünmesi ve boyutlandırma mantığının bunun üzerine o build pipeline'a atanan makineyi küçültmesiyle ortaya çıkan bir hata modunu ele alıyor. Soğuk bir cache ile çalışan sonraki bir build ise her görevi sıfırdan, işi bitirecek kaynaklardan yoksun donanımda yürütmek zorunda kalıyordu.

Bu değişiklikle birlikte, cache isabetlerinden yararlanan bir çalışma artık daha küçük bir makinenin yeterli olduğuna dair kanıt olarak sayılmıyor. Vercel, ayarlamannın elastic build makinelerini kullanan her build'e otomatik olarak uygulandığını, herhangi bir yapılandırma değişikliği veya opt-in gerektirmediğini belirtiyor ve ayrıntılar için okuyucuları build dokümantasyonuna yönlendiriyor.

Boyutlandırma döngüsü nasıl ters gitti

Vercel'in JavaScript ve TypeScript monorepo'ları için build sistemi olan Turborepo, build, test ve lint gibi görevlerin çıktılarını, bunları üreten girdilere göre anahtarlayarak önbelleğe alır. Önceki çalışmadan bu yana ilgili hiçbir şey değişmediğinde görevler neredeyse anında cache'ten geri yüklenir ve çok az compute tüketir. Bir girdi değiştiğinde ise — bir kaynak düzenlemesi, bir bağımlılık güncellemesi, bir ortam değişkeni — cache kaydı geçersizleşir ve görevin gerçekten yürütülmesi gerekir.

Elastic build makineleri, compute'u build'lerin gerçekten kullandığı şeye göre doğru boyutlandırmayı amaçlar. Bu, kullanım işin gerçek maliyetini yansıttığında iyi çalışır; ancak sıcak bir cache bu maliyeti geçici olarak bastırır. Boyutlandırma mantığı fiilen temsili bir ölçüm yerine en iyi senaryo ölçümüne göre optimizasyon yapıyor ve ardından yalnızca cache'in bir dahaki sefere soğuk olduğu durumda görünür hale gelen bir küçültmeyi kalıcı hale getiriyordu.

Kullanıcıların ne yapması gerekiyor

Hiçbir şey. Vercel'e göre düzeltilmiş davranış elastic build makinelerindeki tüm build'ler için otomatik olarak sunuldu; dolayısıyla elastic boyutlandırmayı zaten kullanan ekipler bunu ayarlarını göç etmeden veya Turborepo yapılandırmalarına dokunmadan elde ediyor. Hızlı ve cache yoğun bir dizi çalışmadan sonra — özellikle de cache'i boşaltan bağımlılık güncellemeleri veya diğer geniş kapsamlı girdi değişiklikleri çevresinde — build'lerinin zorlandığını fark eden ekipler, bu durumlarda artık makinelerin küçüldüğünü görmemeli.

Neden önemli

Cache'ler CI'ı daha hızlı ve daha ucuz hale getirmek içindir, daha az güvenilir hale getirmek için değil. Bu bug, her biri tasarlandığı gibi davranan iki optimizasyon katmanı arasındaki bir etkileşimdi: Turborepo ölçülen kaynak kullanımını azalttı ve elastic boyutlandırma bu azalmaya tepki verdi. Birlikte, en iyi senaryodaki bir çalışmayı, çok sonra ve onu tetikleyen değişiklikten çok uzakta ortaya çıkan bir kaynak açığına dönüştürdüler.

Aynı zamanda kullanım temelli autoscaling için genel bir tuzaknın da iyi bir örneği. Cache'leme nedeniyle düşürülen telemetri, alttaki işin gerçek maliyetini tanımlamaz ve buna dayanan kapasite kararları sonuçta hedefin altında kalır. Vercel üzerinde CI çalıştıran monorepo ekipleri için bu düzeltme, elastic boyutlandırmanın sağlaması amaçlanan maliyet tasarrufunu korurken kafa karıştırıcı ve gecikmeli build hatalarının bir sınıfını ortadan kaldırıyor.