Serverless (Sunucusuz Mimari) Nedir?
Kısa tanım
Serverless (sunucusuz mimari), uygulama kodunun sunucu kurma, yamalama ve kapasite planlama işleri tamamen bulut sağlayıcısına bırakılarak çalıştırıldığı bulut modelidir. Kod genellikle bir HTTP isteği, kuyruğa düşen mesaj veya zamanlayıcı gibi olaylarla tetiklenen kısa ömürlü fonksiyonlar hâlinde yazılır. Sağlayıcı talebe göre otomatik ölçekler; ücret sabit sunucu kirası yerine istek sayısı ve çalışma süresine göre alınır.
Diğer adları: Sunucusuz Mimari, Sunucusuz Bilişim, Serverless Computing, FaaS, Function as a Service
Sunucusuz, ama sunucusuz değil
Adı yanıltıcıdır: kod yine sunucularda çalışır. Değişen, o sunuculardan kimin sorumlu olduğudur. İşletim sistemi güncellemeleri, kapasite planlaması, trafiğe göre yeni makine açıp kapatmak sağlayıcının işidir; geliştirici yalnızca fonksiyonu ve onu tetikleyecek olayı tanımlar. Bu modelin en bilinen biçimi FaaS'tır (Function as a Service): AWS Lambda, Google Cloud Run functions veya Azure Functions gibi servisler. Kimlik doğrulama, veritabanı ve dosya depolama gibi hazır servislerin kullanıldığı tarafa ise genellikle BaaS (Backend as a Service) denir.
Serverless mimari doğası gereği olay güdümlüdür: bir HTTP isteği, depolama alanına yüklenen bir dosya, kuyruğa düşen bir mesaj ya da her gece aynı saatte çalışan bir zamanlayıcı fonksiyonu tetikler.
Fonksiyonun yaşam döngüsü ve cold start
Bir fonksiyon ilk kez çağrıldığında sağlayıcı ona bir çalışma ortamı hazırlar: kodu indirir, çalışma zamanını başlatır ve handler dışındaki başlatma kodunu çalıştırır. Bu hazırlığın kullanıcıya yansıyan gecikmesine cold start denir. İş bittikten sonra ortam bir süre dondurulmuş hâlde bekletilir; aynı fonksiyona yeni bir istek gelirse hazır ortam yeniden kullanılır (warm start).
AWS'nin Lambda dokümantasyonuna göre cold start'lar çağrıların genellikle yüzde 1'inden azında görülür ve süreleri 100 milisaniyenin altından 1 saniyenin üstüne kadar değişebilir. Düşük trafikli fonksiyonlar bu gecikmeyi daha sık yaşar. Etkisini azaltmak için bağımlılıkları küçük tutmak, ağır kütüphaneleri yalnızca gerektiğinde yüklemek ve gecikmenin kritik olduğu yerlerde önceden ısıtılmış örnekler (AWS'de provisioned concurrency) kullanmak işe yarar.
Limitler tasarımı belirler
Serverless fonksiyonlar kısa süreli ve durumsuz (stateless) işler için tasarlanmıştır. AWS Lambda örneğinde varsayılan sınırlar şöyledir:
| Sınır | AWS Lambda değeri |
|---|---|
| Tek çağrının azami süresi | 900 saniye (15 dakika) |
| Bellek | 128 MB ile 10.240 MB arası; işlemci gücü bellekle orantılı artar |
| Senkron istek/yanıt boyutu | Her biri için 6 MB |
/tmp disk alanı | 512 MB ile 10.240 MB arası, geçici |
Pratik sonuçları şunlardır: Uzun süren video işleme veya büyük veri aktarımları parçalara bölünmeli ya da başka bir servise taşınmalıdır. Bir çağrıdan diğerine bellekte ya da diskte veri saklanacağı varsayılmamalıdır. Veritabanı bağlantıları özel dikkat ister: trafik arttığında yüzlerce fonksiyon örneği aynı anda bağlantı açabilir, bu yüzden paylaşılan bir bağlantı havuzu ya da HTTP tabanlı veri erişimi gerekir.
Maliyet modeli: kullandıkça öde
Lambda gibi FaaS servislerinde ücret iki kalemden oluşur: istek sayısı ve çalışma süresi. Süre, ayrılan bellekle çarpılarak GB-saniye cinsinden ölçülür ve milisaniye hassasiyetinde yuvarlanır. 512 MB bellekle 200 milisaniye çalışan bir fonksiyon, her çağrıda 0,1 GB-saniye tüketir; ayda bir milyon çağrı 100.000 GB-saniye eder. AWS'nin ücretsiz katmanı ayda bir milyon istek ve 400.000 GB-saniye içerir.
Bu model düzensiz ve seyrek trafikte çok avantajlıdır: kimse kullanmadığında fatura sıfıra yaklaşır. Gün boyu sabit ve yüksek yük taşıyan bir serviste ise aynı iş, sabit ücretli bir VPS veya container platformunda daha ucuza gelebilir. Karar vermeden önce beklenen çağrı sayısı ve ortalama süreyle basit bir hesap yapmak gerekir.
Ne zaman uygun, ne zaman değil?
- Uygun: Webhook alıcıları, form işleme, görsel küçültme gibi olay tetikli işler; zamanlanmış görevler; trafiği tahmin edilemeyen veya ani sıçramalar yaşayan API'ler; prototipler.
- Zorlayıcı: Uzun süreli bağlantılar (WebSocket gibi) gerektiren sistemler; sürekli yüksek yük altındaki servisler; düşük ve kararlı gecikmenin kritik olduğu uç noktalar; sağlayıcıya özgü servislere derinden bağlanmanın kabul edilemeyeceği projeler.