Bir API Gateway REST API'si, başlatma sırasında DynamoDB tablosundan büyük bir veri kümesini yükleyen bir Lambda işlevini çağırıyor ve bu da 8-10 saniyelik cold start'lara neden oluyor. DynamoDB tablosu DAX kullanıyor. Uygulama aralıklı olarak uzun yanıt süreleri yaşıyor ve trafiği büyük ölçüde değişiyor (öğle vakti normalin 10 katı bir artış ve gün sonuna doğru normalin %10'una düşüş). DevOps mühendisi, günün her saatinde Lambda gecikmesini azaltmalıdır. Hangi çözüm gereksinimi karşılar?

Bu çözüm, Lambda soğuk başlatma sorununu doğrudan ele alır ve değişken trafik desenlerine uyum sağlar. Provisioned concurrency, Lambda işlevlerinin her zaman başlatılmaya hazır olmasını sağlayarak soğuk başlatmaları ortadan kaldırır. Application Auto Scaling ile birleştirildiğinde, bu, işlevin trafik taleplerine göre otomatik olarak ölçeklenmesini sağlar. Minimum 1 örnek, her zaman en az bir işlevin hazır olmasını garanti ederken, maksimum 100 örnek, yoğun trafik dönemlerinde yeterli kapasite sağlar. Diğer seçenekler: İlk yanlış seçenek, DAX'ı silmeyi öneriyor. DAX, DynamoDB'nin gecikmesini azaltmak için tasarlanmış bir önbellek hizmetidir ve silinmesi performansı kötüleştirir. Ayrıca, 1 provisioned concurrency, değişken trafik için yeterli değildir. İkinci yanlış seçenek olan reserved concurrency'yi 0 olarak ayarlamak, Lambda işlevinin hiç çalıştırılamayacağı anlamına gelir ve bu da hizmetin tamamen kullanılamamasına yol açar. Üçüncü yanlış seçenek, reserved concurrency'yi ayarlamayı ve API Gateway'de Application Auto Scaling'i yapılandırmayı öneriyor. Reserved concurrency, bir işlev için ayrılan eşzamanlı yürütme sayısını sınırlar, ancak soğuk başlatmaları önlemez. Ayrıca, API Gateway'deki Application Auto Scaling, Lambda işlevinin kendisinin soğuk başlatma sorununu çözmez.