Serverless Mimari ve AWS Lambda: Nerede İşe Yarar, Nerede Yaramaz
Serverless mimari, sunucu yönetimini sağlayıcıya devretme fikri üzerine kuruludur. AWS Lambda özelinde bu, kodunuzun yalnızca bir olay (HTTP isteği, kuyruk mesajı, dosya yüklemesi, zamanlanmış tetikleyici) geldiğinde çalıştığı ve yalnızca çalıştığı süre için faturalandırıldığı bir modeldir. Bu rehber, orta seviye geliştiricilerin Lambda'yı bilinçli biçimde tercih edip etmeyeceğine karar vermesine yardımcı olmayı amaçlar.
Bu yazı belirli bir çalışma zamanı sürümüne bağlı değildir; burada ele alınan kavramlar (soğuk başlangıç, eşzamanlılık, IAM, idempotency) Lambda'nın genel çalışma modeline aittir. Sürüm numarası belirtilmediği sürece örneklerde sürüme özgü ayrıntılara girilmemiştir.
Önkoşullar
- Temel AWS kavramları: IAM rolleri, CloudWatch Logs, bir olay kaynağı (API Gateway, SQS, S3 vb.)
- En az bir dilde fonksiyon yazma deneyimi (örnekler Python ve Node.js üzerinden anlatılır)
- Dağıtım için AWS CLI veya bir IaC aracı (SAM, CDK, Terraform) hakkında temel bilgi
Serverless'ın Gerçek Avantajları
Yönetilecek sunucu yok. İşletim sistemi yamaları, ölçeklendirme kararları ve kapasite planlaması sağlayıcıya aittir.
Talep ile ölçeklenme. Trafik arttığında platform eşzamanlı örnek (concurrent execution) sayısını otomatik artırır. Boşta bekleyen bir sunucu için ödeme yapmazsınız.
Olay odaklı tasarıma doğal uyum. SQS, S3, DynamoDB Streams, EventBridge gibi servislerle entegrasyon, ayrık (decoupled) sistemler kurmayı kolaylaştırır.
Küçük birimler. Her fonksiyon tek bir işi yapar; bu da bağımsız dağıtım ve test kolaylığı sağlar.
Gerçek Dezavantajlar
Soğuk başlangıç (cold start). Yeni bir örnek ayağa kalkarken çalışma zamanının başlatılması gecikme yaratır. Bu gecikme; çalışma zamanına, paket boyutuna ve bağımlılık sayısına göre değişir. Gecikmeye duyarlı, kullanıcıya dönük senkron uç noktalarda bu belirgin biçimde hissedilebilir.
Yürütme süresi sınırı. Lambda fonksiyonları sınırlı bir azami çalışma süresine sahiptir. Uzun süren toplu işler (batch) bu modele uygun değildir; bu tür işler için konteyner veya uzun soluklu işlemci servisleri daha uygundur.
Durum (state) tutulmaz. Her çağrı bağımsızdır. Fonksiyon örnekleri yeniden kullanılabilir ama buna güvenilmemelidir. Kalıcı durum için harici bir depo (S3, DynamoDB, ilişkisel veritabanı) gerekir.
Eşzamanlılık ve maliyet kontrolü. Ani trafik artışları eşzamanlılığı yükseltir; hem aşağı havuzdaki servisleri (örneğin bir veritabanı bağlantı havuzunu) zorlayabilir hem de maliyeti artırabilir. Eşzamanlılık sınırları ve rezerve eşzamanlılık (reserved concurrency) burada devreye girer.
Yerel test ve hata ayıklama zorluğu. Bulut ortamına özgü olay kaynakları ve IAM davranışı yerelde birebir taklit edilemez.
Satıcıya bağımlılık. Olay kaynakları, IAM ve dağıtım araçları sağlayıcıya özgüdür; taşıma maliyeti yüksektir.
Mimari Karar: Ne Zaman Lambda, Ne Zaman Değil
Lambda'yı tercih etmek mantıklı olduğunda:
- Kısa süren, olayla tetiklenen işler (webhook işleme, görsel dönüştürme, bildirim gönderme)
- Trafiği düzensiz veya patlamalı olan iş yükleri
- Ayrık servisler arasında tutkal (glue) mantığı
- Zamanlanmış görevler
Lambda'dan kaçınmanın daha doğru olduğu durumlar:
- Uzun süren, kesintisiz hesaplama gerektiren işler
- Sürekli yüksek trafik alan ve sabit maliyetin daha ekonomik olduğu servisler
- Düşük gecikme garantisi kritik olan senkron uç noktalar (burada ısıtılmış örnekler veya konteyner tabanlı çözümler değerlendirilmelidir)
- Durum tutan, uzun ömürlü bağlantı gerektiren protokoller
Uygulama Adımları
1. Fonksiyonu olay odaklı tasarla
Her fonksiyonu tek bir sorumluluğa indir. Girdi olarak olay nesnesini (event) al, çıktıyı açıkça döndür. Aşağıdaki örnek, SQS'ten gelen bir partiyi işleyen basit bir Python fonksiyonudur:
import json
import logging
logger = logging.getLogger()
logger.setLevel(logging.INFO)
def lambda_handler(event, context):
for record in event.get("Records", []):
try:
body = json.loads(record["body"])
process(body)
except Exception:
logger.exception("Kayıt işlenemedi: %s", record.get("messageId"))
raise
return {"statusCode": 200}
def process(payload):
# İş mantığı burada
logger.info("İşlendi: %s", payload.get("id"))
Beklenen davranış: Partideki her kayıt işlenir; hata durumunda istisna yukarı fırlatılır ve SQS mesajı yeniden denenmek üzere kuyrukta kalır (kuyruğun yeniden deneme ve ölü mektup kuyruğu yapılandırmasına bağlı olarak).
2. Idempotency'yi baştan tasarla
Olay kaynakları aynı mesajı birden fazla kez teslim edebilir. İşlemin yan etkisi varsa (ödeme, e-posta, kayıt oluşturma) idempotency anahtarı kullan. Örneğin DynamoDB'de koşullu yazma ile aynı messageId'nin ikinci kez işlenmesini engelleyebilirsin. Bu, "en az bir kez" (at-least-once) teslim modelinin doğal sonucudur.
3. Eşzamanlılığı sınırla
Aşağı havuzdaki bir veritabanını korumak için fonksiyonun eşzamanlılığını sınırla. Rezerve eşzamanlılık, bir fonksiyonun aynı anda kaç örnek çalıştırabileceğini üst sınırlar; bu hem maliyet hem de bağımlılık koruması sağlar.
4. IAM rolünü en az yetkiyle ver
Her fonksiyona yalnızca ihtiyaç duyduğu kaynaklara erişim tanıyan ayrı bir rol ver. Geniş joker (*) izinlerden kaçın. Fonksiyonun okuduğu/yazdığı belirli kaynakları (belirli S3 öneki, belirli DynamoDB tablosu) izin politikasında açıkça belirt.
5. Yapılandırmayı ve sırları koddan ayır
Ortam değişkenlerini yapılandırma için kullan; hassas değerler (API anahtarları, veritabanı parolaları) için AWS Secrets Manager veya Systems Manager Parameter Store tercih et. Sırları doğrudan ortam değişkenine gömmekten kaçın; bunlar loglara veya hata çıktılarına sızabilir.
6. Gözlemlenebilirliği kur
CloudWatch Logs'a yapılandırılmış (structured) log yaz. Her isteği bir korelasyon kimliğiyle etiketle ki dağıtık izleme (X-Ray veya OpenTelemetry) ile zinciri takip edebilesin. Sessizce yutulan istisnalar, üretimde en zor ayıklanan hataların başında gelir.
7. Paketi küçük tut
Bağımlılık sayısı ve paket boyutu soğuk başlangıcı doğrudan etkiler. Kullanılmayan kütüphaneleri ayıkla; ağır bağımlılıkları gerekiyorsa katman (layer) veya konteyner imajı ile yönet. Bu, gecikmeyi azaltmanın yanı sıra dağıtım süresini de kısaltır.
Yaygın Hatalar
- Fonksiyonu uzun ömürlü bir uygulama gibi yazmak. Global değişkende durum biriktirmek, örnek yeniden kullanımına güvenmek kırılganlık yaratır.
- Veritabanı bağlantısını her çağrıda açmak. Bağlantı kurulumu pahalıdır; bağlantı havuzlama veya bir proxy katmanı değerlendirilmelidir.
- Zaman aşımını ayarlamamak. Varsayılan değer, takılı kalan bir çağrının gereğinden uzun süre ücretlendirilmesine yol açar. Gerçekçi bir üst sınır belirle.
- Sonsuz yeniden deneme döngüsü. Ölü mektup kuyruğu (DLQ) tanımlamadan bırakmak, zehirli (poison) mesajların sürekli yeniden işlenmesine neden olur.
- Geniş IAM izinleri. Her fonksiyona yönetici benzeri izin vermek, bir güvenlik açığının etki alanını büyütür.
- Sırları loglara yazmak. Hata ayıklama sırasında tüm olay nesnesini loglamak, hassas verileri kalıcı hale getirebilir.
Güvenlik Etkileri
- En az yetki ilkesi IAM'de pazarlık konusu değildir; her fonksiyon kendi rolüne sahip olmalı.
- Girdi doğrulama olay kaynağına güvenilse bile yapılmalıdır; olay içeriği dışarıdan gelebilir.
- Sır yönetimi Secrets Manager veya Parameter Store üzerinden yapılmalı, koda veya ortam değişkenine gömülmemelidir.
- Bağımlılık güvenliği ciddiye alınmalıdır; kullanılan kütüphanelerin bilinen açıkları Lambda paketine taşınır.
- Log hijyeni sağlanmalı; hassas alanlar maskelenmeli veya loglanmamalıdır.
Sonuç
Serverless mimari bir hedef değil, bir araçtır. AWS Lambda; olay odaklı, kısa süren ve düzensiz trafikli iş yüklerinde güçlü bir seçenektir. Buna karşılık soğuk başlangıç, durum tutmama, eşzamanlılık yönetimi ve satıcıya bağımlılık gibi sınırları vardır. Doğru karar, iş yükününüzün bu sınırlarla ne kadar uyumlu olduğunu dürüstçe değerlendirmekten geçer. Idempotency, en az yetkili IAM, sınırlı eşzamanlılık ve yapılandırılmış loglama; hangi kararı verirseniz verin üretimde sizi ayakta tutacak temel pratiklerdir.
