AWS Serverless TypeScript Projelerini Yapılandırma: Eksiksiz Rehber
AWS Lambda, API Gateway ve TypeScript ile production-ready serverless projeleri oluşturmak için en iyi uygulamalar. Gerçek dünya örnekleri, maliyet optimizasyonu ve performans ipuçları.
EC2 instance'ları üzerinde geleneksel bir Express.js API çalıştırıyordum. Sabit maliyetler, öngörülebilir ölçeklendirme, 99.9% uptime. Hayat güzeldi. Sonra en büyük müşterimiz ayda bir kez, 10 dakika içinde 50.000 webhook işlemesi gerektiren bir özellik istedi.
Aylık 10 dakikalık bir yoğunluk için EC2 instance'larını 7/24 çalışır durumda tutmak israf gibiydi. İşte o zaman AWS Lambda'ya dalış yaptım. Production Lambda fonksiyonları oluşturmak, her serverless hatasını yapmak ve AWS faturalarında çok fazla para harcamaktan öğrendiklerimi paylaşıyorum. Bu rehber, maliyet sürprizlerinden kaçınmak ve performansı optimize etmek için somut adımlar sunuyor. CDK stack örnekleri, DynamoDB single-table design ve cold start optimizasyonları dahil—hepsi gerçek production sistemlerinden uyarlanmış. Lambda concurrency limitleri ve throttling'i baştan planlamak, webhook burst'lerinde beklenmedik hataları önler. İlk günden kapsamlı monitoring kurmak, incident sırasında gerçekten işe yarayacak tek şey.
Neden Sonunda Serverless'ı Benimsedim (Yıllarca Direniş Sonrası)
Eskiden serverless'ı "ekstra adımlarla vendor lock-in" olarak nitelendiren biriyim. Kubernetes cluster'ları yönetmek ve JVM garbage collector'larını ince ayar yapmak geçmişinden geldiğim için, Lambda kontrolü bırakmak gibi geliyordu. Ancak üç olay fikrimi değiştirdi:
Beklenmedik Trafik Artışı (Haziran 2022)
Express API'miz gece 2'de Hacker News'te yer aldı. Trafik 100 istek/dk'dan 5.000 istek/dk'ya çıktı. Auto-scaling grubumuz yeni instance'lar başlatmak için 8 dakika aldı. O zamana kadar ciddi ödeme işleme hataları yaşamıştık ve Redis cache'imiz aşırı yüklenmişti.
Lambda anında ölçeklenirdi. Bu olay otomatik ölçeklendirmenin değerini vurguladı.
Webhook İşleme Zorluğu (Ağustos 2022)
Bir müşteri 10.000+ event'in patlamalar halinde gelebileceği Stripe webhook'larını işlemeye ihtiyaç duyuyordu. EC2 ile iki kötü seçeneğimiz vardı:
- Tepe yük için fazla provision (pahalı)
- Queue kullan ve webhook timeout riski al (güvenilmez)
Lambda'nın otomatik concurrency ölçeklendirmesi bunu zarif bir şekilde çözdü. Her webhook kendi fonksiyon instance'ını aldı. Queue yok, timeout yok, fazla provisioning yok.
Compute Kullanım Analizi (Ekim 2022)
Gerçek compute kullanımımızı analiz ettiğimizde, API sunucularımızın zamanın %87'sinde boşta olduğunu, ancak %100 kapasite için ödeme yaptığımızı gördük. Kullanılmayan kaynaklar için aylık maliyetler önemli ölçüde birikiyor.
Lambda'nın milisaniye başına ödeme modeli bu verimsizliği doğrudan çözdü. Idle sürelerde ödeme yapmıyorsun; sadece gerçek execution süresince faturalandırılıyorsun. Bu özellikle düzensiz trafik pattern'leri olan API'ler için önemli.
Production'da Gerçekten İşe Yarayan Stack
Birden fazla yaklaşımı denedikten sonra, işte karar verdiğimiz:
Gerçeği Ele Alan Lambda Handler
İşte production incident'lerden öğrenilen tüm error handling ve optimizasyonlarla birlikte production Lambda handler'ımız:
Gerçek Sorunlarda Uyarı Veren Monitoring Kurulumu
Çok fazla gereksiz alarmdan sonra production monitoring kurulumumuz:
TreatMissingData.NOT_BREACHING: Lambda hiç invoke edilmezse (ör. gece) alarm tetiklenmez – false positive yok. Çok fazla alarm gereksiz notification yorgunluğuna yol açar; sadece aksiyon gerektiren metrikleri izleyin.
Maliyet Optimizasyon Dersleri
1. Memory vs Duration Trade-off
2. Connection Reuse
3. Bundle Size Optimizasyonu
Production'da Öğrenilen Dersler
1. CloudWatch Logs Maliyeti
CloudWatch Logs faturamız ayda 400a ulaştı. Çözüm:
2. Cold Start Optimizasyonu
3. DynamoDB Maliyet Optimizasyonu
Hatalardan Öğrenenler
1. DynamoDB Scan Hatası
2. Memory Leak in Lambda
3. 15 Dakikalık Timeout Keşfi
Lambda max 15 dakika. Uzun Step Functions veya batch job'lar için chunk'lama veya Fargate. Bizim job 22 dakika sürüyordu; 5'er dakikalık chunk'lara böldük.
Production Verisinden Performans Çıkarımları
18 aylık production süreci boyunca detaylı monitoring ile elde ettiğimiz veriler:
Cold Start Analizi
- Ortalama cold start: 850ms
- P95 cold start: 1,200ms
- Bundle size etkisi: 10MB bundle = +400ms cold start
- Memory etkisi: 1024MB vs 512MB = -200ms cold start
Maliyet Dağılımı (Aylık)
- Lambda execution: $89/ay (8M invocation)
- API Gateway: $28/ay (8M request)
- DynamoDB: $67/ay (pay-per-request)
- CloudWatch logs: $12/ay
- Toplam: 800/ay ile karşılaştırıldığında)
Güvenilirlik Metrikleri
- Uptime: %99.97 (EC2'de %99.9'a karşı)
- Error rate: %0.02 (çoğunlukla client hataları)
- P95 response time: 180ms
Serverless Ne Zaman Kullanılmamalı
Serverless her zaman cevap değil. Uzun süreli process'ler, websocket ağırlıklı uygulamalar ve cold start hassas senaryolar için container'lar daha uygun. Serverless'e geçmeden önce workload karakteristiğini iyi anla.
Container'da kaldığım durumlar:
- Uzun süren süreçler – Video encoding, büyük batch joblar
- Websocket ağırlıklı uygulamalar – Gerçek zamanlı oyun, chat
- Legacy uygulamalar – Karmaşık deployment gereksinimleri
- Stateful workload'lar – In-memory cache, session'lar
- Cold start hassas – Sub-100ms yanıt gereksinimleri
Kırılmayan Deployment Pipeline'ı
CodePipeline ile zero-downtime deployment. Synth: npm ci, build, test, cdk synth. Test ve Prod stage'leri. Integration testleri post-step. Prod için ManualApproval, smoke testleri.
Sonuç
TypeScript ile AWS Lambda, ekibimizin özellik geliştirme sürecini dönüştürdü. Haftalık deployment'lardan günlük deployment'lara geçtik. AWS maliyetlerimiz önemli ölçüde düştü. Uptime'ımız %99.97'ye yükseldi.
En büyük kazanım? Azaltılmış operasyonel yük. Daha az sunucu çökmesi acil çağrısı, minimal kapasite planlaması ve işletim sistemi yaması yok.
Serverless öğrenme eğrisi diktir, ancak üretkenlik kazanımları ölçülebilir. Küçük başlayın, ilk günden kapsamlı monitoring uygulayın ve öğrenme sürecinde hatalar yapmayı bekleyin. CDK ile infrastructure as code kullanmak, manuel konsol işlemlerinden çok daha güvenli ve tekrarlanabilir.
Başlamaya hazır mısınız? Basit bir CRUD API ile başlayın, ilk günden düzgün monitoring ekleyin ve platformun özelliklerini öğrenirken kademeli olarak oluşturun.