Azure VM’lerde Otomatik Aç-Kapa ile Maliyet Düşürmek

Bulut faturasında sürekli açık kalan sanal makineler çoğu zaman kimsenin bakmadığı ama sessizce en çok tüketen kalemdir. Geçtiğimiz günlerde bir müşterinin Azure aboneliğine baktığımda, aylık yanma hızının büyük bölümünü tek bir kaynağın oluşturduğunu gördüm: 7/24 açık kalan bir SQL Server sanal makinesi. Bu örnekte makine bir geliştirme ve test kutusuydu, ama anlatacağım mekanizma sanal makinenin ne işe yaradığına bakmaz; herhangi bir Azure VM’i için aynen çalışır.

Bu yazıda olayı adım adım anlatıyorum: belirti, ölçüm, kurduğum çözüm, aldığım sonuç ve en önemlisi bu çözümü neden geri aldığım. Yöntemin hangi tür VM’ler için uygun olduğunu ayrı bir başlıkta topladım. Sonda bir de karar tablosu var, kendi ortamınız için hangi yaklaşımın doğru olduğuna karar vermenize yardımcı olur.

Bu yalnızca dev/test için değil: hangi Azure VM’lerinde işe yarar?

Otomatik aç-kapa çoğu yazıda dev/test kutularıyla anılır, ama bu bir kısıt değil, sadece en sık örnektir. Zamanlı kapatma ve açma, sanal makinenin üzerinde ne koştuğuna bakmaz. Tek önemli soru şudur: bu VM’in düzenli olarak kimsenin dokunmadığı, öngörülebilir atıl pencereleri var mı? Cevap evet ise yöntem işe yarar.

Öngörülebilir atıl penceresi olan tipik VM’ler:

• Geliştirme, test, QA ve staging makineleri
• Eğitim, demo ve satış öncesi laboratuvar ortamları
• Yalnızca belirli saatlerde koşan toplu iş (batch), ETL ve raporlama sunucuları
• Mesai saatlerinde kullanılan uygulama, jump box ve uzak masaüstü makineleri
• Ara sıra ihtiyaç duyulan analiz, model eğitimi veya GPU makineleri

Buna karşılık 7/24 trafik alan üretim uygulamaları, sürekli veri kabul eden veritabanları ve nöbet saatleri belirsiz olan ekiplerin makineleri bu yönteme uygun değildir. Yani ölçüt “üretim mi, dev/test mi?” değil, “atıl penceresi öngörülebilir mi?” sorusudur. Aşağıdaki vaka bir dev/test SQL Server makinesinde geçiyor, ama tam da bu ölçütü yanlış değerlendirmenin nasıl bir sonuç verdiğini gösteriyor.

Belirti: Faturanın en büyük kalemi sürekli açık bir makine

Bu örnekteki ortam bir geliştirme ve test kutusuydu. Üzerinde SQL Server, geliştirici sürümü koşuyordu, yani lisans açısından da doğru bir kurulumdu. Sorun kurulumda değil, kullanım deseninde idi: makine gece gündüz, hafta sonu dahil açık duruyordu. Compute maliyeti aylık birkaç yüz doları buluyor ve abonelikteki en büyük tek kalem oluşturuyordu.

Bir VM için ödediğiniz faturanın önemli bir kısmı, aslında kimsenin makineye dokunmadığı saatlere gidiyorsa, orada net bir tasarruf fırsatı var demektir. Ama fırsat var demek, otomatik olarak uygulanmalı demek değildir. Önce ölçmek gerekir.

Ölçüm: Gerçekten atıl mı, yoksa öyle mi görünüyor?

Varsayımla değil ölçümle karar vermek gerekiyor. Metrikleri açtığımda tablo netti: CPU çoğu zaman yüzde birkaç seviyesinde geziyor, bellek büyük ölçüde SQL Server’ın kendi tampon havuzuna gidiyordu. Yani makine teknik olarak “boşta” görünüyordu.

Burada bir tuzak var. Düşük CPU, makinenin gereksiz açık olduğunu kanıtlamaz. Yalnızca o an ağır bir iş çalışmadığını gösterir. Bir VM’de asıl soru “CPU yüzde kaç?” değil, “bu makineye ne zaman, kim, hangi düzende erişiyor?” sorusudur. Bu ikinci soruyu erken sormadığım için birazdan anlatacağım hatayı yaptım.

Çözüm mimarisi: Native ve ücretsiz aç-kapa döngüsü

Tasarruf için üçüncü parti bir araca ihtiyaç yok. Azure’un kendi bileşenleriyle, ek bir maliyet doğurmadan tam bir aç-kapa döngüsü kurulabiliyor. Kurduğum yapı üç parçadan oluşuyordu.

1) Zamanlı kapatma (auto-shutdown)

Sanal makinelerin üzerinde, DevTest Labs’ten gelen bir zamanlama motoru var. Portalda “Auto-shutdown” olarak görürsünüz, arka planda Microsoft.DevTestLab/schedules kaynağıdır. Akşam belirli bir saatte makineyi düzgün biçimde (graceful) kapatır. Düzgün kapanma, SQL Server’ın tutarlı kalması için önemlidir: işletim sistemi servisleri sırayla durur, veritabanı zorla kesilmez.

# Kapatma saatini tanımla (saat UTC olarak HHmm; 1700 UTC = 20:00 TR)
az vm auto-shutdown \
  --resource-group RG-DEVTEST \
  --name vm-sql-devtest \
  --time 1700 \
  --email "ekip@ornek.com"

2) Zamanlı açma (Automation Account + runbook)

Kapatmak tek başına yeterli değil, sabah da açılması gerekiyor. Bunun için bir Azure Automation hesabı, sistem tarafından yönetilen bir kimlik (managed identity) ve küçük bir PowerShell runbook kullandım. Yönetilen kimliğe, yalnızca ilgili VM üzerinde Virtual Machine Contributor rolü verdim. Böylece parola veya secret saklamaya gerek kalmıyor.

# Runbook: sabah makineyi başlat
Connect-AzAccount -Identity | Out-Null
Start-AzVM -ResourceGroupName "RG-DEVTEST" -Name "vm-sql-devtest"

Bu runbook’u hafta içi sabahına bağlı bir zamanlamaya (job schedule) bağladım. Hafta sonu açılmıyordu.

3) Bildirim (Action Group + Activity Log Alert)

Makinenin gerçekten açılıp kapandığını görmek için Activity Log üzerinde iki uyarı kurdum: biri başlatma, diğeri durdurma olayında tetikleniyor ve bir Action Group üzerinden e-posta gönderiyordu. Activity Log alert’leri ve e-posta bildirimi ücretsizdir, ek bir maliyet doğurmaz.

Elle mudahale gerektiğinde kullandığım komutlar da basitti:

# Elle başlat / durdur (durdurma faturayı keser: deallocate)
az vm start      -g RG-DEVTEST -n vm-sql-devtest
az vm deallocate -g RG-DEVTEST -n vm-sql-devtest

Önemli ayrım: makineyi işletim sisteminden kapatmak faturayı durdurmaz, çünkü kaynak hala ayrılmış (allocated) kalır. Compute ücretini kesen şey deallocate durumudur. Zamanlı auto-shutdown makineyi deallocate eder, bu yüzden gerçekten tasarruf sağlar.

Sonuç: Compute’un üçte ikisi eridi

Hafta içi 08:00 ile 20:00 arası açık, gece ve hafta sonu kapalı bir döngüde makine haftanın yaklaşık üçte biri kadar açık kalıyor. Compute kaleminde kabaca yüzde 65 düşüş anlamına geliyordu. Kağıt üzerinde temiz bir kazanç, hiçbir ek maliyet yok, veri güvenli. Görünüşte hikaye burada bitmeliydi.

Dönüm noktası: Neden hepsini kaldırdım?

Kısa süre sonra ortam sahibinden düzenli geri bildirimler gelmeye başladı: makine ihtiyaç duyulduğu anda kapalı oluyordu. Sebep basitti ve baştan sormam gereken soruydu. Bu ekibin sabit bir mesai düzeni yoktu. Akşam, gece, hafta sonu, belirsiz saatlerde ortama girip çalışıyorlardı. Onlar için makinenin 7/24 erişilebilir olması, aylık birkaç yüz dolarlık compute tasarrufundan daha değerliydi.

Metrik “atıl” diyordu, ama insan iş akışı “her an lazım” diyordu. İkisi çeliştiğinde kazanan iş akışıdır. Bu yüzden kurduğum yapının tamamını, zamanlı kapatmayı, açma runbook’unu, Automation hesabını ve bildirim uyarılarını temizce kaldırdım. Makine tekrar 7/24 açık düzenine döndü.

Asıl ders: Maliyet optimizasyonu bir metrik egzersizi değil, bir kullanım deseni sorusudur. Zamanlı aç-kapa yalnızca kullanıcının öngörülebilir bir çalışma ritmi olduğunda işe yarar. Ritim düzensizse, tasarruf sürekli bir mağduriyete dönüşür ve eninde sonunda geri alınır. Ölçmeniz gereken tek şey CPU değil, makineye kimin ne zaman dokunduğudur.

Kaldırmadan önce denenebilecek ara çözüm: erteleme bildirimi

Otomasyonu tümden silmeden önce bir orta yol var. Auto-shutdown zamanlaması, makineyi kapatmadan 30 dakika önce e-posta gönderebilir. Bu e-postada kapanmayı 1 veya 2 saat erteleme (snooze) bağlantıları bulunur. Aynı bilgiyi bir webhook adresine de gönderebilir, örneğin bir Logic App veya ekip kanalına düşürüp “bugün geç çalışacağım, ertele” akışı kurabilirsiniz.

Bu, arada bir geç çalışan ama çoğunlukla öngörülebilir bir ekip için ideal çözümdür. Kapanma varsayılan olarak devrededir, isteyen o günlük erteler. Ama benim vakamda ihtiyaç “arada bir” değil, “sürekli ve düzensiz” idi. Bu durumda erteleme bağlantısına her akşam tıklamak da bir yük olur, bu yüzden ara çözüm yerine tam kaldırma doğru karardı.

Hangi ortamda hangi yaklaşım?

Doğru cevap ortamın kullanım desenine göre değişir. Karar için basit bir tablo:

Son satır önemli. Kapatamayacağınız bir makinede maliyeti yine de düşürebilirsiniz. Doğru boyuta indirmek (right-sizing), Reserved Instance veya Savings Plan almak, dev/test fiyatlandırmasından yararlanmak ve zaten lisansınız varsa Azure Hybrid Benefit’i açık tutmak, makineyi hiç kapatmadan ciddi tasarruf sağlar. Kapatma tek yol değildir, çoğu zaman en kırılgan olanıdır.

SQL Server’a özel uyarılar

Bir veritabanı sunucusunu zamanlı kapatmaya alacaksanız birkaç noktaya dikkat edin:

• Düzgün kapanma şart. Zamanlı auto-shutdown işletim sistemini düzgün kapatır, SQL Server servisleri sırayla durur. Zorla kesme (hard reset) alışkanlığı edinmeyin.
• SQL Server Agent job’ları makine kapalıyken çalışmaz. Gece koşan bakım planı, indeks bakımı, yedek veya ETL job’larınız varsa, kapanma penceresiyle çakışmadığından emin olun. Aksi halde sessizce atlanır.
• Yedek ve bakım pencerelerini kapanma saatinin dışına alın. Kapanmadan önce son yedeğin tamamlandığını doğrulayın.
• İlk açılış biraz yavaştır. Tampon havuzu soğuk başladığı için sabah ilk sorgular ısınana kadar daha yavaş gelebilir. Dev/test için sorun değil, ama beklenti yönetimi açısından bilinmeli.

Önemli Çıkarımlar

• Dev/test ortamları bulut faturasının çoğu zaman en büyük ve en görünmez kalemidir. Önce oraya bakın.
• Azure’da tam bir aç-kapa döngüsü native bileşenlerle ve sıfır ek maliyetle kurulabilir: auto-shutdown, Automation runbook, Activity Log alert.
• Compute ücretini kesen şey kapatmak değil, deallocate durumudur. Auto-shutdown bunu yapar.
• Düşük CPU makinenin gereksiz açık olduğunu kanıtlamaz. Kritik metrik “makineye kim ne zaman erişiyor?” sorusudur.
• Zamanlı aç-kapa yalnızca öngörülebilir çalışma ritmi olan ekipler için doğrudur. Ritim düzensizse tasarruf mağduriyete döner.
• Tam kaldırmadan önce erteleme bildirimli auto-shutdown bir orta yoldur, ama “sürekli ve düzensiz” ihtiyaçta bu da yetmez.
• Kapatamadığınız makinede right-sizing, Reserved Instance, Savings Plan ve Azure Hybrid Benefit hala ciddi tasarruf sağlar.
• Bir çözümü geri almak başarısızlık değildir. Yanlış ölçüte optimize etmekte ısrar etmek başarısızlıktır.

Sık Sorulan Sorular

Makineyi işletim sisteminden kapatırsam fatura durur mu?

Hayır. İşletim sisteminden kapatmak makineyi “stopped” durumuna alır ama kaynaklar ayrılmış kalır ve compute ücreti işlemeye devam eder. Faturayı kesmek için makinenin “stopped (deallocated)” durumunda olması gerekir. Portaldan Stop veya az vm deallocate bunu yapar, zamanlı auto-shutdown da makineyi deallocate eder.

Auto-shutdown için ekstra ücret ödüyor muyum?

Hayır. Auto-shutdown zamanlaması, Activity Log alert’leri ve e-posta bildirimleri ücretsizdir. Automation Account’un aylık ücretsiz runbook dakikası çoğu senaryoya fazlasıyla yeter.

Kapanma saatinden önce uyarı alıp erteleyebilir miyim?

Evet. Auto-shutdown, kapanmadan 30 dakika önce e-posta gönderebilir ve bu e-postada kapanmayı 1 veya 2 saat erteleme bağlantıları bulunur. Aynı bilgiyi bir webhook adresine gönderip Logic App gibi bir akışla otomatikleştirebilirsiniz.

Neden Avalonia ya da üçüncü parti bir maliyet aracı kullanmadınız?

Gerek yoktu. Tek bir dev/test makinesi için Azure’un yerleşik bileşenleri hem ücretsiz hem de yeterli. Çok sayıda makineyi merkezden yönetmek gerekseydi Start/Stop VMs v2 çözümüne bakardım.

SQL Server Agent job’larım gece çalışıyor, ne olur?

Makine kapalıyken SQL Server Agent da kapalıdır, bu yüzden o pencereye denk gelen job’lar hiç çalışmaz ve genelde sessizce atlanır. Zamanlı kapatmaya geçmeden önce job takvimini kapanma penceresiyle karşılaştırın.

Tasarruf iyiydi, kaldırmak zorunda mıydınız?

Bu ortam için evet. Ekibin sabit bir çalışma düzeni yoktu ve makinenin her an erişilebilir olması, aylık tasarruftan daha değerliydi. Optimizasyon kullanım desenine uymuyorsa doğru optimizasyon değildir. İleride net bir çalışma ritmi oluşursa aynı yapı birkaç dakikada geri kurulabilir.

Çağlar Özenç · Microsoft SQL MVP
Bu yazı gerçek bir üretim öncesi (dev/test) ortamdaki çalışmadan üretilmiştir. Müşteriye ait tüm isim, adres ve kaynak bilgileri anonimleştirilmiştir.