AWS SOCI lazy loading, Lambda Managed Instances'ta container başlatma sürelerini yüzde 70'e kadar düşürüyor

AWS, 28 Ekim 2026'da duyurduğu ve fonksiyon başlatma sürelerini yüzde 70'e kadar kısaltabileceğini söylediği bir özellik olarak Lambda Managed Instances'ta container imajları için lazy loading desteği ekledi. dev.to'da yayımlanan uygulamalı bir rehber, mekanizmanın nasıl çalıştığını ve en az o kadar faydalı bir şekilde nerelerde kusurlu olduğunu anlatıyor.

Lazy loading nasıl çalışıyor

Özellik, Apache-2.0 lisanslı açık kaynak bir AWS projesi olan SOCI, kısaltması Seekable OCI'nin üzerine inşa ediliyor. SOCI imajınızı değiştirmiyor. Bunun yerine, her dosya için hangi katmanda ve hangi offset'te bulunduğunu kaydeden bir yardımcı index üretiyor. Bu index mevcut olduğunda Lambda, bir execution environment başlatılmadan önce imajın tamamını indirip açmak yerine, dosyaları ECR'den gerektiği anda tek tek alıyor.

Operasyonel olarak, imajı ve SOCI indexini ECR'ye özel bir tag altında birlikte push ediyorsunuz. Bu tag, tam olarak iki giriş içeren bir image index'e işaret ediyor: sıradan image manifest ve SOCI indexi. dev.to makalesine göre, fonksiyonu o tag'e yönlendirdiğinizde Lambda, sürümü yayımladığınızda lazy loading'i ek yapılandırma gerektirmeden otomatik olarak etkinleştiriyor.

Ancak format gereksinimleri katı. Lambda yalnızca tam olarak iki girişli bir image index içindeki SOCI index v2'yi kabul ediyor ve yalnızca tek mimarili imajları destekliyor. Indexi oluşturmak için SOCI snapshotter gerekiyor; bu, genellikle nerdctl üzerinden kullanılan bir containerd eklentisi ve makaleye göre containerd yüklü bir Linux makinesi istiyor.

Ne zaman kâr sağlıyor

Container imajları, yaklaşık 250 MB'lık ZIP paketi sınırını aşan Lambda yüklerini taşımak için yaygın bir yol: makine öğrenmesi kütüphaneleri, modeller, PDF araçları, komple runtime'lar. Bu imajlar rutin olarak birkaç gigabayta ulaşıyor. Managed Instances'ta imajın tamamı her yeni instance'da indirilip açılması gerekiyor; bu yalnızca yayımlanma anında değil, yük arttıkça capacity provider instance'lar eklediğinde de geçerli.

Bu verilerin büyük kısmı hiç okunmuyor. dev.to örneği tam olarak bu kalıbı esas alıyor: imajında Almanca, İngilizce, Fransızca ve İspanyolca dil modellerini taşıyan bir kitap önerme servisi, oysa her çağrı bunlardan yalnızca birine dokunuyor. Lazy loading, her fonksiyonun içeriğin yalnızca bir dilimine ihtiyaç duyduğu büyük imajlarda en çok kâr sağlıyor.

Init aşaması uyarısı

Başlatma kodunuzun okuduğu dosyalar initialization sırasında getiriliyor. Handler içinde ilk kez dokunulan her şey ise çağrının kendisi sırasında çekiliyor ve bu da isteği buna bağlı olarak yavaşlatıyor. Makale, AWS dokümantasyonuna dayanarak, Lambda'nın imajın kalanını arka planda hiç indirmediğini belirtiyor. Bu da temel kurala götürüyor: her kütüphaneyi import edin ve init aşamasında her dosyayı açın, böylece çağırma süreleri tutarlı kalır.

Managed Instances'ın yeri

SOCI lazy loading yalnızca Lambda Managed Instances için geçerli; bu execution modelinde fonksiyonlar, paylaşımlı Lambda filosundaki Firecracker microVM'lerde değil, kendi hesabınızdaki EC2 Nitro instance'larında container'lar olarak çalışıyor. Bir capacity provider; VPC'yi, subnet'leri, security group'ları, mimariyi, izin verilen instance türlerini ve bir vCPU üst sınırını tanımlıyor. Bir sürüm yayımlamak, Lambda'nın instance'ları başlatmasına yol açıyor; varsayılan olarak Availability Zone'lara yayılmış üç instance ve ayrıca sürüm aktif sayılmadan önce üç execution environment.

dev.to karşılaştırmasına göre ödünleşimler standart Lambda'dan birkaç açıdan farklı: environment'lar aynı anda tek değil birkaç eşzamanlı çağrıya hizmet veriyor, faturalandırma EC2 fiyatının yüzde 15 yönetim ücreti eklenmiş hali ve instance'lar sıfıra kadar ölçeklenmiyor; bu da ani yükselişli iş yüklerinden çok istikrarlı, öngörülebilir trafiğe uyuyor. Node.js için initialization her worker thread başına bir kez çalışıyor, dolayısıyla bellekte tutulan büyük bir model thread başına çoğaltılıyor ve aynı thread'de eşzamanlı istekler tarafından paylaşılan state yalnızca okunur olarak ele alınmalı.

Neden önemli

Büyük container imajlarındaki cold-start maliyeti, ağır kütüphanelere ve modellere bağımlı Lambda iş yükleri üzerinde süregelen bir vergi olageldi. Bir fonksiyonun imajı hâlâ akarken başlatılması — AWS yüzde 70'e kadar daha hızlı başlatma iddiasında — bu vergiyi doğrudan azaltıyor ve en çok, aksi halde birçok instance'ın aynı çok gigabaytlık imajı eşzamanlı çekeceği ölçeklenme anlarında önemli. Ancak sınırlar gerçek: fayda yalnızca Managed Instances için geçerli, farklı fiyatlandırma ve ölçekleme semantiğine sahip kapasite ödemeli bir model; ayrıca katı iki girişli image index formatı ve init aşaması disiplini, bunu bir düğme gibi açacağınız değil, tasarlayacağınız bir optimizasyon haline getiriyor. Halihazırda yüksek ve öngörülebilir Lambda container iş yükleri çalıştıran ekipler en çok kazananlar olacak.