AWS Lambda Web Functions, adapter olmadan Node.js HTTP sunucuları çalıştırıyor

Ne oldu

AWS, sıradan bir Node.js HTTP sunucusunu platform üzerinde doğrudan çalıştıran, adapter kütüphaneleri ve event başına handler gerektirmeyen yeni bir serverless compute biçimi olan Lambda Web Functions'ı duyurdu. dev.to'daki bir analize göre uygulama, Lambda'nın AWS_LAMBDA_HTTP_ENDPOINT değişkeni üzerinden sağladığı host ve port'u dinliyor — yerelde node index.js ile çalıştıracağınız kodun aynısı — HTTPS endpoint'ini, TLS'i ve ölçeklendirmeyi ise AWS üstleniyor.

Bu özellik, klasik Lambda'nın tam anlamıyla bir alternatifi değil. Event odaklı işler — SQS mesajları, S3 event'leri, stream'ler — hâlâ geleneksel event-handler modeline ait. Web Functions boşta kaldığında sıfıra kadar ölçekleniyor ve şu anda desteklenen tek runtime Node.js.

Gerçekte ne değişiyor

Demo'larda gösterilen şeylerin çoğu — REST, streaming, webhook — zaten başka yollarla mümkündü; değişen şey fonksiyonun biçimi. Parse edilmiş bir JSON event'i alan bir handler yazmak yerine, bir port üzerinde normal bir HTTP sunucusu yazıyorsunuz. Lambda ham HTTP/1.1 trafiğini — method, path, query string, body ve neredeyse tüm header'lar — iletiyor; böylece Express, Fastify veya Hono standart bir request ve response görüyor, ancak parsing ve validasyon sizin göreviniz. Desteklenen fiiller GET, HEAD, POST, PUT, PATCH, OPTIONS ve DELETE; HTTP/1.0 505 ile reddediliyor ve Lambda lambda-web-request-id gibi context header'ları ekliyor.

Daha büyük değişiklik eşzamanlılıkta. Geleneksel bir Event Function ortamı aynı anda tek bir isteği işlerken, bir Web Function ortamı herhangi bir Node sunucusu gibi aynı anda pek çok isteğe hizmet veriyor. Zamanının çoğunu bir veritabanını, harici bir API'yi veya bir LLM'i beklemekle geçiren iş yüklerinde, her istek kendi ortamını işgal etmek yerine pek çok istek tek bir süreci paylaşabiliyor.

Ortam artık istekler arasında dondurulmuyor da; dev.to yazısı bunun global state, yeniden kullanılabilir bağlantılar ve arka plan görevlerini mümkün kıldığına dikkat çekiyor.

Ayarlanabilir parametreler

Davranışı üç parametre yönetiyor. maxConcurrencyPerEnvironment 1 ile 128 arasında değişiyor ve bir revision üzerinde ayarlanıyor; etkili üst sınır daha düşük olabilir ama asla daha yüksek olamaz ve değeri değiştirmek yeni bir revision gerektirir. maxEnvironments, endpoint üzerinde bölge başına ortam sayısını sınırlar. rateLimit, bölge başına saniyede kabul edilen istekleri belirler; 1.000'e kadar 100'ün, üzerinde ise 1.000'in katları şeklinde ayarlanır. Fazla trafik 429 alır, ölçeklendirme tükendiğinde gelen trafik de öyle; istekler ise başlatılmakta olan bir ortamın arkasında kuyruğa girer. Eşzamanlılık ayarının aksine maxEnvironments ve rateLimit, aws lambda-web update-web-function-endpoint ile yeniden dağıtım yapmadan anında değiştirilebilir.

Güvenlik ve faturalandırma

Her endpoint, kimlik doğrulama modundan bağımsız olarak internetten erişilebilir. IamAuth ile Lambda, SigV4 imzasını doğrular ve iletimden önce Authorization header'ını çıkarır. ApplicationManaged ile Lambda hiçbir şeyi doğrulamaz: URL'yi bilmek uygulamaya erişmek için yeterlidir, dolayısıyla kimlik doğrulama uygulamanın içinde olmalıdır. dev.to yazısı ayrıca bazı header'lara güvenilemeyeceği konusunda uyarıyor: X-Forwarded-Host doğrulanmadan geliyor ve gerçek istemci adresi X-Forwarded-For'daki son değer.

Faturalandırma, ortam var olduğu sürece aktif CPU ve belleği kapsar, duvar saati zamanını değil. Yavaş bir veritabanını bekleyen bir istek az CPU harcar, dolayısıyla bekleme neredeyse faturalandırılmaz.

Nereye uymuyor

Yazar, Web Functions'ın yanlış araç olduğu birkaç durumu sıralıyor: basit ve düşük hacimli request/response işleri klasik bir function URL olarak daha kolay; kuyruklar ve stream'ler event fonksiyonu alanı olarak kalıyor; istekler 900 saniyeyle sınırlı, bu yüzden daha uzun işler bölünmeli; WebSockets ve HTTP/2 desteklenmiyor, çünkü kalıcı çift yönlü bağlantılar ortama açık tutulmuyor; ve çok adımlı iş akışları, kontrol noktaları, retry'lar ve compute tüketmeyen bekleme durumlarıyla durable function'lara daha iyi uyuyor. Sunulan pratik kural şu: iş yükü eşzamanlı trafiği işleyen bir HTTP sunucusu değilse, Web Functions muhtemelen uygun değil.

API Gateway işini koruyor

Bir Web Function kendi HTTPS endpoint'iyle geliyor ve bu çoğu zaman dahili API'ler için yeterli, ancak API Gateway'i eskimiş yapmıyor. Yazıda alıntılanan rehber, özel bir domain, WAF incelemesi, caching veya merkezi edge kontrolleri gerektiğinde önüne CloudFront veya API Gateway koymayı öneriyor. API Gateway ayrıca bir Web Function'ın sahip olmadığı özellikleri elinde tutuyor: istemci başına API anahtarları, kullanım planları, JWT ve Cognito authorizer'ları ve tüketici başına kotalar. Bir Web Function'ın rate limit'i endpoint ve bölge başına geçerlidir, tüketici başına değil.

Neden önemli

Adapter katmanının kaldırılması, Lambda'yı sıradan web uygulamaları için — yalnızca event yapıştırıcısı değil — makul bir yurt haline getiriyor. Mevcut framework kodu büyük ölçüde değiştirilmeden serverless'a taşınabiliyor ve ortam başına eşzamanlılığın CPU tabanlı faturalandırmayla birleşimi, I/O yoğun ve LLM destekli iş yüklerini ortam başına tek istek modelinden çok daha ekonomik hale getiriyor. Kısıtlamalar — herkese açık endpoint'ler, tek bir runtime, WebSockets yokluğu — gerçek, ancak bir sunucu çalıştırmak ile bir fonksiyon yazmak arasındaki sınır belirgin biçimde inceldi.