Cloud Computing ile Kapasite Planlama

Geleneksel veri merkezinde 3–5 yıllık donanım planı yaparken bulut bilişimde elastik kaynaklarla saatlik planlama yapıyoruz. Bu yazıda kapasite planlamanın bulutla nasıl değiştiğini, AWS Auto Scaling, Reserved ve Spot örnekleri ve talep tahmini teknikleri üzerinden anlatıyorum.

Kapasite planlaması, bilgi işlem dünyasının en eski ve en sıkıcı sorunlarından biridir. Kaç sunucu? Ne kadar bellek? Ne kadar disk? Yıllık büyüme oranı nedir? Tüm bu soruların bir 3–5 yıllık zaman ufkunda cevaplanması beklenir. Bulut bilişim, bu disiplinin oyun kurallarını köklü biçimde değiştirdi. Bu yazıda kapasite planlamasının bulutla birlikte nasıl başka bir şeye dönüştüğünü anlatmaya çalışacağım.

Geleneksel Kapasite Planlamasının Mantığı

Klasik bir veri merkezi inşaatında satın alma kararı şuna benzer: ürün yöneticisi pazarlama planını anlatır, finans 3 yıllık bir kullanıcı projeksiyonu hazırlar, IT bu büyümeyi karşılayacak donanım listesini çıkarır, ihale açılır, sunucular tedarik edilir (8–12 hafta), kabin yerleşimi yapılır, kurulum tamamlanır, üretim devreye girer. Tüm süreç 4–6 ay sürebilir ve karar bir kez verildiğinde 3–5 yıl boyunca o donanımla yaşamak zorundasınız.

Bu yaklaşımın iki büyük zaafiyeti var:

  • Yanlış tahminin cezası ağır. Gerçek talep tahminin üzerine çıkarsa kullanıcı deneyimi bozulur, satış kaybedersiniz. Tahminin altında kalırsa donanım atıl durur ve para batar.
  • Statik bir kararla dinamik bir dünyada yaşıyorsunuz. Donanım 5 yıl ortalama ömürle satın alınır ama iş dünyası 5 yılı 5 ayda tüketebiliyor (özellikle internet servislerinde).

Bulutta Kapasite Planlamasının Yeni Mantığı

Bulut bilişim, kaynakları sürekli bir musluk gibi sunar. İhtiyacınız varsa açarsınız, azaldıysa kısarsınız. Bunu mümkün kılan üç temel yetenek var:

  1. Elastik tedarik: Bir EC2 instance’ını dakikalar içinde açıp kapatabilirsiniz. Yıllık değil, saatlik faturalanır.
  2. Otomatik ölçekleme: AWS Auto Scaling (Mayıs 2009’da kullanıma açıldı) gibi servisler ile metriklere bağlı olarak ölçekleme kararını yazılım veriyor.
  3. Pay-per-use: Kullandığınızı ödüyorsunuz. Sermaye yatırımı (CapEx) yerine işletme gideri (OpEx).

Bu üç yeteneğin birleşimi, kapasite planlamasını “büyük tahmin oyunu” olmaktan çıkarıp “talep takibi + politika tasarımı” hâline getiriyor. Tahmin doğruluğunun değil, sistemin reaktifliğinin önemli olduğu bir alana geçiyoruz.

Bulut Kapasite Modelinin Üç Aracı

Otomatik Ölçekleme Grupları (Auto Scaling Groups)

AWS Auto Scaling, CloudWatch metriklerine (CPU yüzdesi, ağ giriş/çıkış, gelen istek sayısı, kuyruk derinliği) dayanarak instance sayısını otomatik artırıp azaltır. Tipik bir politika şöyle olur:

  • 5 dakikalık ortalama CPU > %70 ise +2 instance ekle.
  • 5 dakikalık ortalama CPU < %30 ise -1 instance çıkar.
  • Minimum 2, maksimum 20 instance ile çalış.

Bu yaklaşımın klasik kapasite planlaması karşısındaki en güzel yanı, “Black Friday” gibi anlık trafik artışlarına insan müdahalesi olmadan tepki verebilmesidir.

Reserved, On-Demand, Spot, Üç Farklı Fiyat Modeli

AWS bu noktada güzel bir ürün tasarımı yaptı:

  • On-Demand: Saatlik fiyatla, taahhütsüz. En esnek ama en pahalı.
  • Reserved Instances: 1 ya da 3 yıllık ön ödeme yapıp saatlik fiyatı %40–60 düşürüyorsunuz. Sürekli çalışan baz yük (baseline) için ideal.
  • Spot Instances: Aralık 2009’da kullanıma açıldı. Atıl kapasiteyi açık artırmayla satıyorlar; bazen %80 indirimli fiyatlarda instance alabiliyorsunuz. Karşılığında, AWS sizden geri alabilir; yani fault-tolerant iş yükleri için uygun.

Bulut kapasite planlamasının yeni disiplini, bu üç fiyat modelini doğru oranlarda harmanlamak. Tipik bir öneri:

  • Baz yükün %50’sini Reserved ile karşıla.
  • Günlük dalgalanmaları On-Demand ile karşıla.
  • Batch işler, analiz yükleri ve fault-tolerant servisleri Spot ile çalıştır.

CloudWatch ve Üçüncü Parti Gözlem Araçları

Otomatik ölçeklemenin gerçek anlamda çalışması için sağlam bir gözlem katmanı şart. AWS tarafında CloudWatch temel metrikleri sağlıyor; uygulama tarafı için Nagios, Zabbix, Munin, Cacti gibi açık kaynak araçlar ya da ücretli New Relic, RightScale Dashboard kullanılıyor. RightScale özellikle ilgi çekici: AWS, Rackspace ve diğer sağlayıcılar üzerinden bulut yönetimi yapıyor ve “ServerTemplate” konsepti ile mimari katmanı sürüm kontrolüne sokuyor.

Talep Tahmininin Hâlâ Yeri Var

“Buluta geçtim, artık tahmin yapmama gerek yok” düşüncesi tamamen doğru değil. Talep tahmini hâlâ önemli; sadece amacı değişti. Eski dünyada tahminin amacı kaç sunucu satın alacağımıza karar vermekti; yeni dünyada tahminin amacı ne kadar Reserved Instance taahhüt edeceğimize, hangi maksimum sınırı (ceiling) ayarlayacağımıza, hangi saatlerde scale-up bekleyeceğimize karar vermek.

Yaygın tahmin teknikleri:

  • Zaman serisi analizi: ARIMA, exponential smoothing gibi yöntemlerle geçmiş kullanım verisini geleceğe taşımak.
  • Sezonsallık modellemesi: Günün saati, haftanın günü, ayın günü, yılın ayı seviyesinde tekrarlanan örüntüleri tanımak. E-ticaret tarafında Cuma akşamları ve hafta sonları, B2B SaaS tarafında pazartesi sabahları belirgin pikler oluşturur.
  • Senaryo planlaması: Kampanya, ürün lansmanı, PR olayı gibi noktasal etkilerin etkisini önceden modelleyip kapasiteyi buna göre hazırlamak.

Kapasite Planlama Sürecinde Karşılaşılan Zorluklar

  1. Maliyet kayması: Bulutun esnekliği iki tarafı keskin bir bıçaktır. Kontrol edilmezse aylık fatura beklenmedik şekilde patlayabilir. Bir geliştirme ekibinin unutulan 20 m1.large instance’ı, üç ayda ciddi para eder. Bu yüzden tagging disiplini (her instance’a maliyet merkezi etiketi koymak) ve faturanın günlük takibi şart.
  2. Cold start gecikmesi: Auto Scaling tepki süresi yaklaşık 2–5 dakikadır (instance açılma + uygulama hazırlık süresi). Bu pencerede gelen ani trafik düşüşü kullanıcı tarafında hissedilebilir. Çözüm: önden bir miktar fazla kapasite tutmak (over-provisioning), AMI’leri olabildiğince hazır tutmak (golden image).
  3. Veritabanı katmanı: Web ve uygulama katmanını yatay ölçeklemek görece kolay, ama veritabanı katmanı hâlâ zor. Master-slave replikasyon, sharding, read replica kullanımı için ciddi mühendislik çalışması gerekiyor. Amazon RDS’in (Ekim 2009 GA, Aralık 2010’da Multi-AZ desteği) gelmesi bu yükü biraz hafifletti.
  4. Sağlayıcı kilitlenmesi: Auto Scaling, CloudWatch, RDS gibi servislerin her biri AWS’e bağımlı kalıyorsunuz. Bunun bilincinde olarak mimari seçim yapmak gerekiyor.

Bir Örnek: E-Ticaret Sitesinde Cuma Akşamı

Bir orta ölçekli e-ticaret sitesinin kapasite planı kabaca şöyle kurulabilir:

  • Baz yük (gün ortalaması): 4 m1.large web sunucusu + 2 m1.large worker. Bunları 3 yıllık Reserved alın.
  • Akşam yoğunluğu (18:00–24:00): +2 web instance. Auto Scaling ile, On-Demand olarak.
  • Cuma akşamı / hafta sonu pikleri: +4 web instance. Önden tanımlı bir zaman tabanlı tetikleyici (scheduled scaling) ile.
  • Arka uç analiz işleri: Spot Instance ile, gece çalıştır.

Bu modelin yıllık maliyeti, aynı kapasiteyi 24/7 satın alarak çıkacak maliyetin %40–60’ı civarına iniyor. Üstelik trafiğin beklediğinizin üstüne çıktığı bir gün, sistem otomatik olarak ölçekleniyor.

Türkiye Perspektifi

Bizim piyasamızda kapasite planlaması hâlâ büyük ölçüde geleneksel yöntemlerle yapılıyor; satın alma süreci uzun, ihale yapısı esneklik bırakmıyor. Ama bulut bilişimle birlikte daha küçük ekiplerin AWS Auto Scaling benzeri pratikleri kurabildiğini görüyoruz. Özellikle dijital reklam, mobil oyun, e-ticaret ve medya sektörlerinde Auto Scaling kullanımı önümüzdeki 2 yıl içinde standartlaşacak gibi görünüyor.

Sonuç

Bulut bilişim kapasite planlamasında köklü bir devrim yarattı. Geleneksel yöntemlerde statik olan kaynaklar bulutla birlikte esnek ve dinamik hâle geldi. Bir işletmenin iş yükü ne olursa olsun kaynaklar hızlıca ayarlanabilir; bu hem maliyetleri düşürür hem de performansı optimize eder. Asıl iş, ekibin yeni disipline (gözlem, ölçekleme politikaları, Reserved/Spot harmanı) alışmasında. 2011’in bana göre kritik gündemlerinden biri budur.