Kurumsal bulut mimarisinde kapasite planlama çoğu zaman iki kötü uç arasında sıkışır: ya gereğinden fazla rezerv alınır ve maliyet şişer ya da ortalama kullanım rakamlarına fazla güvenilip kritik anda performans daralması yaşanır. Oysa kapasiteyi anlamlı yöneten soru CPU ortalaması değil, hizmet hedefinin hangi yük davranışını garanti etmesi gerektiğidir. SLO tabanlı kapasite rezervasyonu tam bu ayrımı görünür kılar.
Ortalama kullanım neden yanıltıcıdır?
Çünkü kurumsal sistemlerde yük eşit dağılmaz. ERP entegrasyonları gün sonu yığılabilir, self-service platform akşam pipeline patlaması yaşayabilir, güvenlik taramaları belirli pencerelerde ani dalga üretebilir. Ortalama kullanım grafiği sakin görünürken kuyruk gecikmesi veya hata oranı kritik eşikleri sessizce aşabilir.
Bu yüzden kapasite kararını sadece yüzde kullanım üzerinden almak, maliyet optimizasyonu gibi görünse de gerçekte riskin görünmez şekilde taşınmasıdır.
SLO kapasite rezervasyonuna nasıl bağlanır?
SLO, sistemin ne kadar hızlı ve güvenilir davranması gerektiğini söyler. Kapasite rezervasyonu ise bu hedefi taşıyacak güvenlik payını belirler. İkisini birlikte düşündüğünüzde şu çerçeve oluşur:
- İzin verilen gecikme ve hata bütçesi tanımlanır.
- Bu hedefleri bozan yük paternleri çıkarılır.
- Yüksek etkili pikler için rezerv kapasite sınıfı ayrılır.
- Düşük öncelikli iş yükleri geri bastırma veya sıraya alma ile yönetilir.
Yani rezerv kapasite, “boşta duran pahalı kaynak” olmaktan çıkar; hizmet vaadini koruyan operasyonel tampon hâline gelir.
Mimari olarak hangi katmanlarda uygulanır?
Kurumsal bulutta SLO tabanlı rezervasyon tek bir servis ayarı değildir. Genellikle üç katmanda kurulur:
- Hesaplama katmanı: node pool, autoscaling sınırı, reserved instance veya committed use planı
- Veri katmanı: bağlantı havuzu, IOPS tavanı, replika stratejisi
- Ağ ve kenar katmanı: egress kapasitesi, load balancer eşikleri, rate limit politikası
Bu katmanlardan biri ihmal edildiğinde kapasite sorunu başka yüzeyde tekrar ortaya çıkar. Örneğin uygulama katmanında autoscaling çalışırken veri tabanı bağlantı tavanı sabit kalıyorsa, görünürde kapasite artar ama kullanıcı deneyimi bozulur.
FinOps ile operasyon aynı masada nasıl buluşur?
Burada kritik nokta, maliyet optimizasyonunu sadece “daha az kaynak tüket” söyleminden çıkarmaktır. Daha doğru yaklaşım şudur:
- Hangi kapasite rezervi SLO’yu koruyor?
- Hangi rezerv yalnızca varsayım rahatlığı sağlıyor?
- Hangi yük ertelenebilir veya farklı zaman penceresine kaydırılabilir?
Bu sorular sayesinde FinOps ekibi maliyet azaltırken kör kesinti riski yaratmaz, platform ekibi de her ek güvenlik payını savunmak zorunda kalmaz. Dil ortaklaşır.
Pratikte işe yarayan karar modeli
Benzer yapılarda şu karar matrisi verimli çalışır:
- Kritik müşteri akışı: yüksek rezerv, agresif gözlem, düşük tolerans
- İç operasyon servisi: orta rezerv, kontrollü kuyruklama
- Batch veya raporlama: düşük rezerv, planlı geri basınç
- Geçici deney ortamı: minimum rezerv, sert kota
Bu sınıflandırma, kapasiteyi iş etkisiyle hizalar. Böylece her sistem için aynı tartışmayı baştan yapmak gerekmez.
Başarı nasıl ölçülür?
Sadece maliyet düşüşü başarı sayılmamalı. Bence şu üç sinyal birlikte izlenmeli:
- Pik trafik anlarında SLO ihlali sıklığı
- Kapasite artış taleplerinin tahmin doğruluğu
- Atıl rezerv ile kesinti önleme etkisi arasındaki oran
Eğer kapasite planı bu sinyalleri birlikte iyileştiriyorsa mimari işe yarıyor demektir.
Sonuç
Kurumsal bulutta SLO tabanlı kapasite rezervasyonu, klasik kapasite planlamayı hizmet odaklı hâle getirir. Kaynağın ne kadar kullanıldığı kadar, neyin garanti edildiği de görünür olur. Sonuçta daha pahalı değil, daha bilinçli bir kapasite modeli kurulur; bu da hem bulut maliyetini hem kurumsal güveni daha yönetilebilir kılar.