Azure SQL Database Serverless ile Maliyet Azaltma

· Mehmet Demir · 4 dk okuma · Azure , SQL , Maliyet Optimizasyonu

Selamlar, bu yazıda Azure SQL Database'in serverless katmanına (compute tier) bir göz atalım. Konu basit gibi duruyor ama uygulamada bir sürü ince ayar var; özellikle 'hangi DB serverless'a taşınmalı, hangisi taşınmamalı' sorusu çoğu ekibin gözünden kaçıyor. Lafı çok uzatmadan başlayayım.

Bir gece nöbetinde dashboard'a baktığımda dev ve staging veritabanlarının neredeyse hiçbir iş yapmadığını ama provisioned olarak full kapasite faturalandığını görünce, 'burada ciddi bir israf var' demiştim. İşte tam bu nokta, serverless'in geldiği yer.

Serverless Tier Nedir?

Azure SQL Database'in vCore satın alma modelindeki General Purpose service tier'i altında iki compute seçeneği var: provisioned ve serverless. Provisioned'da sabit bir vCore sayısı belirliyorsunuz ve database 7/24 açık olsa da olmasa da o kapasite için para ödüyorsunuz. Serverless ise iki şey yapıyor:

  • Otomatik ölçekleme: Min ve max vCore aralığı tanımlıyorsunuz, gerçek CPU talebine göre database bu aralıkta aşağı yukarı gidiyor. Faturalandırma vCore-saniye üzerinden.
  • Otomatik durdurma (auto-pause): Database belirli bir süre (en az 60 dakika) boş kalırsa Azure DB'yi 'pause' ediyor. Pause halindeyken sadece storage için para ödüyorsunuz, compute sıfır.

Yeni bir bağlantı gelir gelmez database otomatik olarak ayağa kalkıyor. Ama uyanma süresi var; buna birazdan döneceğim.

Ne Zaman Kazandırır, Ne Zaman Kaybettirir?

Bence bu en kritik kısım. Çünkü herkes 'serverless = ucuz' diye düşünüp taşıyor, sonra production OLTP database'inde ay sonu faturası iki katına çıkıyor.

Serverless'in parladığı durumlar:

  • Dev ve test veritabanları (mesai dışı tamamen ölü)
  • Sadece iş saatlerinde çalışan iç araçlar
  • POC'lar ve demo ortamları
  • Günde 1-2 saat aktif olan batch işleyen DB'ler
  • Trafiği çok düşük, gecelik uzun boş dönemleri olan küçük production DB'leri

Serverless'in kaybettirdiği durumlar:

  • Steady-state OLTP yükleri (CPU sürekli yüzde 30-40 bandında gezen sistemler)
  • Gerçek zamanlı, düşük gecikme bekleyen API arka uçları
  • 7/24 sürekli yazılan loglama veya telemetri DB'leri
  • Çok sık küçük sorgu alan ama hiçbir zaman tam olarak boş kalmayan sistemler

Pratik bir eşik vereyim: database'iniz günün yüzde 60-70'inden fazla aktifse, provisioned neredeyse her zaman daha ucuz. Aktiflik bunun altındaysa serverless'a geçmek mantıklı.

CLI ile Kurulum

Portal'dan da yapabilirsiniz ama benim tercihim CLI; hem tekrar edilebilir hem de Terraform/Bicep geçişi için temel oluşturuyor. Yeni bir serverless DB açmak için:

az sql db create \
    --resource-group rg-staging \
    --server sql-staging-01 \
    --name app-db \
    --edition GeneralPurpose \
    --compute-model Serverless \
    --family Gen5 \
    --min-capacity 0.5 \
    --capacity 2 \
    --auto-pause-delay 60 \
    --max-size 32GB

Buradaki --min-capacity 0.5 aktif haldeki taban maliyeti minimuma indiriyor. --capacity 2 ise tavan, yani yük patlasa bile 2 vCore'u geçmez. --auto-pause-delay 60 60 dakika hareketsizlikten sonra DB'yi uyutuyor.

Mevcut bir DB'yi serverless'a çevirmek için de update komutu var:

az sql db update \
    --resource-group rg-staging \
    --server sql-staging-01 \
    --name app-db \
    --edition GeneralPurpose \
    --compute-model Serverless \
    --min-capacity 0.5 \
    --capacity 4 \
    --auto-pause-delay 120

Auto-pause istemiyorsanız --auto-pause-delay -1 verin; sadece otomatik ölçekleme avantajını kullanırsınız.

Uyanma Gecikmesi - En Sık Karşılaşılan Tuzak

Burada çoğu ekip yanılıyor. Pause halindeki bir DB'ye bağlantı geldiğinde toparlanması 1-2 dakika sürüyor. Eğer uygulamanızın connection timeout değeri 15 saniyeyse, sabah ilk istek boş yere <TimeoutError> alıyor.

Connection string'inize en az 60 saniye timeout verin:

Server=sql-staging-01.database.windows.net;Database=app-db;Connection Timeout=60;Encrypt=true;

Bir de monitoring sistemleri konusu var. Eğer DB'ye 5 dakikada bir health check ping atan bir sisteminiz varsa, auto-pause hiçbir zaman tetiklenmez ve serverless'in tüm mantığı çöpe gider. Bunu fark etmesi bile bir hafta sürebiliyor; faturayı görünce anlıyorsunuz.

Sık Karşılaşılan Hatalar

  • Tüm production'ı serverless'a taşımak: Provisioned ucuz olduğu yük profilleri var. Önce metrik toplayın, sonra karar verin.
  • Min vCore'u gereksiz yüksek tutmak: 0.5 yerine 1 koymak, taban maliyetinizi iki katına çıkarır. Zorunlu değilse 0.5 bırakın.
  • Auto-pause'u 60 dakikaya çekip sonra her 30 dakikada bir ping atmak: DB hiçbir zaman uyumaz, sadece serverless'in ölçekleme kısmından faydalanırsınız - bu da çoğu zaman provisioned'dan daha pahalıya çıkar.
  • Storage'i unutmak: DB pause olsa bile storage faturası devam eder. 500 GB tutmanıza gerek yoksa küçültün.

Kapanış

Serverless tier, doğru yerde kullanıldığında gerçekten ciddi bir tasarruf aracı. Şahsi kanaatim, dev/test ortamlarının neredeyse hepsi serverless'a taşınmalı; production tarafında ise önce metrikleri okuyup karar vermek lazım. 1-2 dakikalık uyanma gecikmesini tolere edemiyorsanız veya DB'niz zaten sürekli meşgulse, provisioned'da kalmak daha mantıklı. Umarım faydalı olur, bir sonraki yazıda görüşmek üzere.