Serverless tarafında en sinir bozucu şey ne biliyor musunuz? Uygulama çalışıyor gibi görünür, ama ilk istek gelir. Sistem bir anda ağırlaşır. En çok da Java, Hibernate ve veritabanı üçlüsü yan yana gelince bu his iyice belirginleşiyor. Geçen ay Maslak’taki bir ekip toplantısında tam da bunu tartışıyorduk — herkes “warm start” güzel de, ilk temas neden hâlâ bu kadar yavaş diye söyleniyordu. Kimse net bir cevap veremedi açıkçası (evet, doğru duydunuz)
İşin aslı şu: AWS Lambda SnapStart bu noktada bayağı işe yarıyor. Ama sadece açıp beklemek yetmiyor. Uygulamayı snapshot alınmadan önce biraz “hazırlamak” gerekiyor — yani sistemi uykuya yatırmadan önce kahvesini vermek gibi, hani tam o metaforu seviyorum bu iş için. Bu yazıda Aurora DSQL isteklerini önceden ısıtma fikrini konuşacağız. Amaç daha hızlı başlangıç, daha az sürpriz.
SnapStart tek başına yetmiyor, işin püf noktası priming
AWS Lambda SnapStart’ın olayı basit aslında. Fonksiyonun bir anlık görüntüsünü alıyor ve sonraki çağrılarda o hazır hali kullanıyor. JVM ayağa kalksın, sınıflar yüklensin, framework’ler toparlansın… bunların çoğu ilk anda yaşanıp sonra tekrar kullanılabiliyor; bu kısmı seviyorum. Ama küçük bir detay var — her şeyi snapshot’a bırakmak bazen yeterli olmuyor. Yetmiyor işte.
Bir şey dikkatimi çekti: Ben bunu 2023 sonbaharında İzmir’de bir fintech projesinde test etmiştim. Uygulama kağıt üstünde fena değildi ama ilk API çağrısında JDBC bağlantısı açılırken gecikme göze batıyordu; o an “tamam, bir şeyler eksik” dedim içimden. SnapStart sonrası tablo düzelmişti, evet… fakat veritabanı tarafını hiç dokunmadan bıraktığımız için ilk gerçek sorgu yine küçük bir takılma yaratıyordu. Tam burada priming devreye giriyor.
Doğrusu, Priming dediğimiz şey, snapshot alınmadan önce uygulamaya “bir deneme turu” attırmak. Mesela veritabanı bağlantısını kurmak, bazı sınıfları yüklemek, cache’i hafifçe doldurmak… Böylece Lambda restore olduğunda elinizde daha hazır bir ortam oluyor; sıfırdan başlamak yerine yarı yoldan devam ediyorsunuz gibi bir his veriyor. Bu yaklaşım özellikle düşük gecikme isteyen API uçlarında fark yaratıyor. Ciddi fark.
SnapStart güzel bir temel veriyor; priming ise o temelin üstüne gerçekten kullanılabilir bir sistem kurmanı sağlıyor. Aradaki fark bazen birkaç yüz milisaniye değil, resmen kullanıcı deneyimi.
Aurora DSQL isteğini neden özellikle öne çekiyoruz?
Araya gireyim: Veritabanı tarafı serverless mimarilerde hep biraz nazlı davranır. Çünkü uygulamanız hızlı olsa bile veriye erişim yavaşsa bütün kazanç eriyip gider — bunu defalarca yaşadım, defalarca. Aurora DSQL özelinde de benzer mantık geçerli; ilk bağlantı ya da ilk sorgu çoğu zaman ikinci ve üçüncü sorgudan farklı hissedilir.
Geçen sene Berlin’de katıldığım küçük bir AWS buluşmasında biri çok iyi özetlemişti: “CPU hızlı olabilir ama ağ tarafı sabah trafiği gibi.” Haksız sayılmazdı. Lambda’nın kendi başlangıcını hızlandırdınız diyelim… ama veritabanı isteği hâlâ soğuksa kullanıcı onu hissediyor. Ve kullanıcı hissedince şikayet ediyor. Ve şikayet gelince siz o Slack mesajını sabah 9’da okuyorsunuz. Neyse, konuya dönelim.
Şunu fark ettim: Bu yüzden örnek uygulamada yapılan şey oldukça mantıklı: snapshot alınmadan hemen önce basit bir getProductById(0) çağrısı ile veri yolu hafifçe yoklanıyor. Buradaki hedef gerçek kullanıcı trafiğini simüle etmek değil; bağlantı havuzunu ve ilgili kod yolunu uyandırmak.
| Kısım | SnapStart’siz | Sadece SnapStart | SnapStart + Priming |
|---|---|---|---|
| JVM açılışı | Yavaş | Bayağı hızlı | Bayağı hızlı |
| İlk DB erişimi | Sert vuruyor | Daha iyi ama hâlâ dalgalı olabilir | Daha stabil görünüyor |
| Kod karmaşıklığı | Düşük-orta | Düşük-orta | Bir tık artıyor |
| Kazanım alanı | Sınırlı | Ciddi iyileşme | Daha ince ayarlı iyileşme |
Kod tarafında ne değişiyor?
Hikaye çok dramatik değil aslında. Yeni bir handler ekleniyor ve bu handler CRaC benzeri yaşam döngüsü kancalarını kullanarak snapshot öncesi ve sonrası davranışı yönetiyor. En hayati bölüm beforeCheckpoint() — orada veritabanına küçük bir istek atılıyor ve sistemin önemli parçaları önceden hazırlanıyor. Bu kadar. Butterfly CSS: 2026’da Dikkat Çeken Hafif Bir Seçenek yazımızda bu konuya da değinmiştik. Bu konuyla ilgili PDF Dünyasında Bir Nefes: Ücretsiz ve Limitsiz Araçlar yazımıza da göz atmanızı tavsiye ederim.
public class GetProductByIdWithDSQLPrimingHandler
implements RequestHandler<APIGatewayProxyRequestEvent, APIGatewayProxyResponseEvent>, Resource {
private static final ObjectMapper objectMapper = new ObjectMapper();
private static final ProductDao productDao = new ProductDao();
public GetProductByIdWithDSQLPrimingHandler() {
Core.getGlobalContext().register(this);
}
@Override
public void beforeCheckpoint(Context<? extends Resource> context) throws Exception {
productDao.getProductById(0);
}
@Override
public void afterRestore(Context<? extends Resource> context) throws Exception {
// Restore sonrası ekstra işlem yok
}
}Lafı gevelemeden söyleyeyim: bu kod satırları çok gösterişli değil ama etkisi var. Hele ki Hikari connection pool kullanan yapılarda küçük test istekleri bazen büyük fark yaratıyor — şaşırdım açıkçası ilk deneyimde, bu kadar basit bir şeyin bu kadar işe yarayacağını beklemiyordum. İlginç, değil mi? Tabii burada sihir yok; yanlış yapılandırılmış pool ayarlarını tek başına kurtarmıyor.
Aslında, Bir de şu var: Hibernate kullanan uygulamalarda başlangıç maliyeti zaten yüksek olabiliyor. O yüzden yalnızca framework seçimi değil, çalışma anındaki davranış da önemli hale geliyor. Ben bunu geçen yıl Ankara’daki iç eğitimde anlatırken şöyle demiştim — “Framework’ü kurdunuz diye iş bitmiyor, asıl mesele onu hangi anda uyandırdığınız.” Birkaç kişi gülmüştü (kendi tecrübem). Sonra ölçümlerde aynı noktaya geldik zaten (buna dikkat edin) One Model Provider Is a Toy Nowadays: Agent Dünyasının Asıl Meselesi yazımızda bu konuya da değinmiştik.
Neden dummy ID ile sorgu atılıyor?
Bazen insanlar buna takılıyor. “Gerçek veri yerine niye 0?” diye soruyorlar. Çünkü amaç doğru kaydı döndürmek değil, sorgu hattını çalıştırmak — bağlantının kurulması, sürücünün konuşması, havuzun tepki vermesi… bunlar önemli olan kısım. Kayıt dönüp dönmemesi burada ikinci planda kalıyor.
Ve işler burada ilginçleşiyor. Daha fazla bilgi için WhatsApp’ın Kullanıcı Adı Hamlesi: Numara Dönemi Bitiyor mu? yazımıza bakabilirsiniz.
Tüm istekleri mi priming yapmalı?
Hayır. İşte orada fren yapmak lazım. Her şeyi önden çalıştırırsanız snapshot şişebilir ya da başlangıçta gereksiz yük oluşabilir; bunu da test ettik, pek iyi gitmedi. Küçük startup için hafif priming gayet yeterli olurken, enterprise tarafta daha kontrollü. Ölçülü gitmek daha mantıklı olabiliyor.
Küçük ekipler için başka, kurumsal yapılar için başka okuma lazım mı?
Evet. Bence lazım. Küçük bir startup’taysanız hedefiniz genelde hızlı doğrulama olur; yani birkaç hayati endpoint’i hızlandırıp kullanıcıyı bekletmemek yeterli. Böyle durumlarda SnapStart + hafif priming baya iş görür, gözle görülür fark hissedilir. Bu konuyla ilgili Kiro CLI ve ArgoCD MCP: Terminalden GitOps Yönetimi yazımıza da göz atmanızı tavsiye ederim.
Bakın, Kurumsal tarafta ise tablo değişir. SLA baskısı vardır, gözlemleme araçları vardır, güvenlik incelemeleri vardır… her şey büyür de büyür, anlayacağınız (kendi tecrübem). Orada sadece latency’ye bakmazsınız; restore tutarlılığına, bağlantı havuzu davranışına ve deploy akışına da bakarsınız. Bir şeyi atlarsanız gece yarısı uyandırıyorlar sizi.
Size bir şey söyleyeyim, Açık konuşayım — ben kurumsal projelerde en çok şuna takıldım: ekipler performans kazanımı görünce hemen her yere aynı optimizasyonu yaymak istiyorlar. Halbuki bazı servislerde ekstra karmaşıklık getirdiği için geri tepebilir. Kağıt üstünde süper görünen çözümün pratikte biraz — kendi adıma konuşayım — ham kaldığı çok oldu benim için. Çok.
Ve işler burada ilginçleşiyor.
- Küçük ekipte odak: düşük gecikmeli birkaç ana uç nokta
- Maliyet odağı varsa: gereksiz warm-up çağrılarını azaltma
- Büyük organizasyonda odak: ölçümleme, geri dönüş planı ve tutarlılık
- Migrasyon aşamasında odak: önce tek servisle test etme
Pratikte ne beklemeli?
Sihirli değnek beklemeyin derim ben. SnapStart + priming kombinasyonu iyi çalışır ama ölçüm şarttır; aksi halde sadece “iyi hissettiren” iyileştirmelerle kalırsınız ki bu da mühendislikte pek tatmin etmiyor, en azından beni etmiyor. Mantıklı değil mi? Sayı görmek istiyorum ben.
Editör masasındayken böyle performans yazılarında hep aynı soruyu sorarım: Kullanıcı gerçekten ne kadar fark ediyor? Eğer cevap ekranın açılması ya da ilk API cevabının hissedilir biçimde hızlanmasıysa mesele tamamdır. Ama arka planda iki kat fazla bakım yükü getiriyorsa orada durup düşünmek gerekir. Durulur. Hesap yapılır.
Neyse uzatmayayım… Bu yaklaşımın bence en güçlü yani kontrollü olmasıdır. Önce Lambda’yı hazır hale getiriyorsunuz, sonra database yolunu hafifçe dürtüyorsunuz ve gerisini ölçerek ilerliyorsunuz. En sağlıklı yöntem bu bence.
Nerede hayal kırıklığı yaşayabilirsiniz?
Eğer büyük çoğunluk problemi yalnızca cold start sanıyorsanız biraz hayal kırıklığı yaşayabilirsiniz. Çünkü bazen asıl sorun ağ gecikmesi ya da kötü tasarlanmış veri erişim katmanıdır. Yani çözüm güzel, işe yarıyor — ama herkese eşit derecede mucize sunmuyor. Dürüst olmak gerekirse böyle söylemek lazım.
Sıkça Sorulan Sorular
AWS Lambda SnapStart nedir?
AWS Lambda SnapStart, Java gibi dillerde fonksiyonun hazır halinin snapshot’ını alıp sonraki çalışmalarda bunu yeniden kullanmaya yarar. Böylece cold start süresi ciddi biçimde düşebilir.
Priming neden gerekiyor?
Çünkü Snapshot almak tek başına her şeyi çözmez. Veritabanı bağlantısı veya bazı ağır kod yolları önceden çalıştırılırsa restore sonrası ilk istek daha akıcı olur.
Aurora DSQL ile SnapStart birlikte kullanılabilir mi?
Evet, kullanılabilir. Buradaki kritik nokta veri erişim katmanını snapshot öncesinde dikkatlice hazırlamak ve gereksiz işleri sisteme yüklememektir.
Hibernate kullanan uygulamalarda fayda görülür mü?
Evet, hatta çoğu zaman fark daha belirgin olur. Çünkü Hibernate başlangıçta nispeten ağır davranabilir ve SnapStart bunun etkisini azaltmada işe yarar.
Kaynakar İleri Okuma”>
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
