Easel'ın bulgusuna göre AWS Lambda Web Functions son istekten sonra belleği 7 dakikaya kadar faturalandırmaya devam ediyor

Çok sayıda web uygulaması barındıran bir platform olan Easel, servisin execution environment'larının son istekten sonra yaklaşık beş ile yedi dakika boyunca canlı kalıp belleği faturalandırmaya devam ettiğini ölçtükten sonra AWS Lambda Web Functions'ı bıraktı. Hacker News ana sayfasına kadar yükselen şirket blog yazısına göre bu keşif Easel'ı kendi işlettiği sunuculara taşıdı ve ilk benchmark'lar bu kurulumun aynı zamanda daha hızlı olduğunu gösteriyor.

Trafiğin durmasından çok sonra faturalanan bellek

AWS, Lambda Web Functions'ı Ekim ayında duyurdu ve Easel hevesli bir ilk testçi oldu: yerel HTTP yönetimi, istek eşzamanlılığı ve yalnızca aktif kullanım sırasında ölçümlenen CPU, şirketin geleneksel Lambda üzerinde aylarca çözmeye çalıştığı sorunlara tıpatıp uyuyordu. İlk denemeler umut vericiydi; 300 eşzamanlı istek hatasız karşılandı ve yeni bir fonksiyon trafiği dokuz saniyenin altında sunmaya başladı.

Sorun faturalandırmanın kuyruğundaydı. Web Functions CPU'yu yalnızca kullanım sırasında ölçüyor, ama bellek bir execution environment'ın ömrü boyunca ücretlendiriliyor. AWS bu modeli belgeliyor; Easel'ı şaşırtan ise environment'ların ne kadar uzun süre beklemesiydi. 26 Ekim'de us-east-1 bölgesindeki altı temsili environment'ta, boşta geçen süreler son tamamlanan istekten sonra 313 ile 411 saniye arasında değişti; süreçler boyunca aktifti ve boşta bekleme penceresini kısaltacak bir ayar yoktu.

Çarpan çarpıcı. Easel'a göre 200 ms'lik bir isteği 345 saniyelik sessizlik izlediğinde, ölçülen bellek süresi isteğin süresinin kabaca 1.700 katı oluyor. CloudWatch ve AWS Cost Explorer ile çapraz kontrol edildiğinde, uygulama yalnızca 160–210 MB civarında bellek kullansa da, bellek yayınlanan liste fiyatlarıyla hesaplanan compute ve istek maliyetlerinin yaklaşık %88'ini oluşturuyordu. Deneyin tamamı liste fiyatlarıyla yaklaşık iki sent tuttu — tek başına önemsiz, ama Easel öngörülemeyen trafiğe sahip binlerce uygulamayı destekliyor; bazıları günde yalnızca birkaç istek alıyor, dolayısıyla environment başına boşta bekleme ücretleri bu ölçekte birikiyor.

Desteklenen bir çözüm yok

Easel, environment'ları 10 saniyelik hareketsizlikten sonra kendisi kapatmayı denedi. Bu, ölçülen environment süresini yaklaşık 20 kat azalttı, ancak AWS kasıtlı her kapatmayı bir runtime hatası olarak kaydetti ve şirket bunun üretime bağımlanacak kadar riskli olduğunu düşündü.

Kendi işletilen compute'a geçiş

Bunun yerine Easel artık uygulama yürütmesini kendi işlettiği host'larda çalıştırıyor ve taşan trafik için sıradan Lambda'yı tutuyor. Her boşta bekleyen environment için AWS'ye ödeme yapmak yerine, tek bir makinedeki kapasite pek çok uygulama arasında paylaşılabiliyor. İlk kendi işletilen compute host'u 2 Kasım'da US East'te yayına girdi ve Easel'ın kendi web sitesi dahil uygulamalara hizmet veriyor.

El yapımı kurulum benchmark'larda daha hızlı çıktı

Easel aynı Next.js 16 uygulamasını her iki platforma da dağıttı ve 11–12 Kasım'da Virginia, Ashburn'deki bir istemciden benchmark yaptı. Platform başına rota başına kabaca 100 isteğe dayanan sonuçlarda, medyan sıcak istek süreleri dört iş yükünün tamamında kendi host'unda 1,5–3 kat daha hızlıydı — sunucu tarafı render için 2,1 kat ve akışın ilk parçası için 2,0 kat. 20.000 zincirli SHA-256 işleminden oluşan CPU yoğun bir test, Easel'ın host'unda 29,2 ms, Web Functions'ta ise 43,8 ms sürdü.

Soğuk başlangıçlar da aynı örüntüyü izledi. 12 dakikalık boşluğun ardından yeni environment'lar Easel'de ilk baytları 216–250 ms'de sunarken Web Functions'ta bu süre 810–854 ms'ydi; yaklaşık 3,5 kat daha hızlı, ancak bu karşılaştırma yalnızca iki eşleştirilmiş denemeye dayanıyor. Beş dakikalık bir aradan sonra Web Functions environment'ını çoktan sonlandırmıştı ve yanıt vermesi 908 ms gerekirken, Easel duraklatılmış bir environment'ı 14 ms'de devam ettirdi.

Easel sayıların şunu not edilmesi gerektiğini vurguluyor: tek bölge, küçük bir uygulama, yalnızca iki soğuk başlangıç örneği, henüz sürekli verimlilik testi yok ve iki platform farklı donanımda çalıştığı için sonuçlar makinelere değil dağıtımlar arası karşılaştırmayı yansıtıyor.

Neden önemli

Serverless maliyetleri genellikle istek başına fiyatlar ve GB-saniye başına ücretlerle değerlendirilir, ama bu öykü platform davranışının — trafiğin durmasından sonra bir environment'ın ne kadar yaşadığının — faturayı domine edebildiğini ve bunun kullanıcıların çevirebileceği bir düğme olmadığını gösteriyor. Patlamalı ya da nadiren ziyaret edilen iş yükleri için, environment başına istek sonrası dakikalarca süren bellek faturalandırması isteklerin kendi maliyetini gölgede bırakabilir; Easel'ın %88'lik bellek payı bunun somut örneği. Bu davranış AWS tarafından belgelendiği için ders gizli bir ücretten çok, belgelenen mekanikler ile ölçülen ekonomi arasındaki uçurum hakkında. Ayrıca birinci taraf bir managed servisinin otomatik olarak en hızlı seçenek olmadığının da bir hatırlatıcısı — kendi stack'ini ayarlayan küçük bir operatör bu ilk testlerde gecikmede AWS'yi geçti. Pek çok küçük, düzensiz kullanılan fonksiyon çalıştıran ekipler, liste fiyatlarının trafik biçimlerine birebir uyduğunu varsaymadan önce environment ömrünü ölçmeli.