Kapasite planlaması

1) Kapasite planlamasının ne olduğu ve neden gerekli olduğu

Kapasite planlama, minimum maliyetle hedef SLO'lara ulaşmak için gereken kaynakların sistematik olarak değerlendirilmesi ve güvence altına alınması sürecidir. Sadece CPU/bellek hakkında değil, aynı zamanda ağ bant genişliği, depolama, veritabanları/önbellekler, kuyruklar/olay yolu, harici sağlayıcılar (ödemeler/CCM/sahtekarlık önleme) ve insan kaynakları (çağrı üzerine, destek) hakkında da konuşuyoruz.

• Zirvelerde ve bozulmalarda bile SLO/SLA gerçekleştirin.
• TCO ve sermaye aşırı provizyonunu en aza indirin.
• Kaynakların tükenmesinden kaynaklanan olay riskini azaltın (doygunluk - p99/hata).
• Yayınların ve kampanyaların (pazarlama, turnuvalar, en iyi maçlar) öngörülebilirliğini sağlayın.

2) Gerçeğin girdileri ve kaynakları

Gözlemlenebilirlik: RPS/bitiştirme, p50/p95/p99, hata oranı, doygunluk (CPU, mem, disk IOPS, ağ pps/mbps), kuyruk uzunlukları, hız sınırları.
İş etkinlikleri: kampanya takvimleri, mevsimsellik (akşamları/hafta sonları/mega etkinlikler), bölgeler/yargı bölgeleri.
Teknik borç/özellikler: sürümlerin yol haritası, mimari değişiklikler (örneğin, şifreleme, yeni kayıt).
Sağlayıcılar: Kotalar ve ödeme/CUS/posta/dolandırıcılıkla mücadele hizmetlerinin çıktıları.
Geçmişin olayları: darboğaz nerede (veritabanı, önbellek, L7 dengeleyici, veri yolu, CDN, disk).

3) Temel kavramlar ve formüller

Headroom - kapasite marjı: 'headroom = (max _ stable _ RPS − actual _ RPS )/max _ stable _ RPS'.
Hedef %20-40 zirvede (kritik akışlar için).
Doygunluk - kullanılan kaynağın mevcut kaynağa oranı (CPU %, bellek/GC, bağlantılar, dosya tanımlayıcıları, IOPS, kuyruk derinliği).
Verim stabil - p99 ve hata oranının uzun süre SLO gerçekleştirme hızı (bir kerelik bir patlama değil).
Kapasite Birimi (CU) - servis için normalleştirilmiş güç birimi (örneğin, pod vCPU = 1, RAM = 2 GiB başına X RPS).
Sistem sınırı bozulma olmadan maks: 'N _ pods × CU'. Paylaşılan bağımlılıkları (DB/cache/bus) dikkate almak önemlidir.

4) Talep Modeli: Tahmin

İstatistiksel seriler: haftalık/günlük mevsimsellik, tatiller, spor finalleri, bölgesel zirveler.
Kohortlar: ülkeye, ödeme sağlayıcılarına, cihazlara, VIP segmentlerine göre.
Olay deltaları: kampanyaların/pooches/releases/SEO'nun etkisi.
"What if" (senaryo planlama): + %50 19: 00-22: 00'de trafiğe; Sağlayıcı A'nın düşmesi - B'ye yeniden dağıtım (gecikmeye + %30).
Gerçek zamanlı ayarlamalar: Ana metriklere göre şimdi yayınlama (oturumların yeniden canlandırılması, maç kuyruğu, sepetler).

5) Tedarik modeli: zincirin "kırıldığı" yer

Sorgu konveyörü: Kenar/CDN ^ L7 dengeleyici ^ uygulama ^ önbellek ^ DB ^ harici API ^ dönüş/lastik ^ işleyiciler/ETL.

• Kapasite (CU/instance), ölçeklenebilirlik (horizon/vertex), limitler (bağlantılar, pps, IOPS), gecikmeler.
• Arıza politikaları (hız limiti, devre kesici, bozulma).
• SLO'lar yereldir ve e2e-SLO katkılarıdır.

6) Hata marjı ve bütçe

Boşluk alanını hata bütçesine bağlıyoruz: daha az bütçe - daha fazla stok.
Kritik akışlar için (ödeme/doğrulama) - yukarıda boşluk, ikincil akışlar için - aşağıda.
Soğuk/sıcak rezervler: pik/kazada aktive olur.

7) Ölçeklendirme: Taktikler

HPA (yük metriklerine göre): RPS, gecikme, kuyruk uzunluğu, kullanıcı SLI'ları (CPU %'den daha iyi).
VPA: podam kaynaklarının düzeltilmesi (stateful ve p99 GC ile dikkatli).
KEDA/adaptörler: harici kaynaklara göre ölçeklendirme (Kafka gecikmesi, Redis liste uzunluğu, CloudQueue derinliği).
Sıcak havuzlar/ısınma: Soğuk bir başlangıcı önlemek için önceden yükseltilmiş örnekler.
"Load-as-Code" yaklaşımı: Autoscale/limit/timeout/retray politikaları yeniden düzenlenir ve gözden geçirilir.

8) Kuyruklar, geri basınç ve kuyruk kontrolü

Amaç, p99'un çığ benzeri büyümesini önlemektir.
Eşzamanlılığı ve kuyruk boyutunu sınırlıyoruz, zaman pencereleri ve idempotence giriyoruz.
Hedging/Retry-budget: Kullanıcının ve sistemin toplam zaman bütçesini sınırlar.
Zarif bozulma: aşırı yükleme sırasında ikincil özellikleri devre dışı bırakma.

9) DB, önbellekler ve depolama

DB: bağlantı sınırı, günlük kaydı/FSync, indeksler, sorgu planı, replika gecikmesi, kısayol tuşları/tablolar, işlemler için maksimum TPS.
Keshi: segmente göre isabet oranı, serbest bırakma/engellilik sırasında "kayıp fırtınası", anahtar dağılımı.
Depolama: IOPS/throughput, gecikmeler, sıkıştırma, TTL, eski partilerin/anlık görüntülerin temizlenmesi.
Geçiş şeması: genişlet> göç et> durma kilitleri olmadan sözleşme.

10) Olay akışları ve ETL'ler

Kafka/bus: parti işlem hacmi, gecikme, ISR, sıkıştırma, üretici/tüketici sınırları.

ETL/partiler: başlangıç pencereleri, çalışma zamanı bütçeleri, gaz I/O

Idempotence ve kritik akış için tam olarak bir kez benzeri (ödemeler/bakiyeler).

11) Ağ ve çevre

L4/L7 dengeleyiciler: bağlantı sınırları, syn backlog, TLS aktarımı, oturum yeniden kullanımı.
CDN/Edge: bant genişliği, başlangıç yükünü azaltmak için önbellek politikası.
Ağ içi limitler: VPC/alt ağda pps/mbps, çıkış-maliyet (FinOps).

12) Çok bölgeli, DR ve yargı alanları

Stratejiler: Aktif-aktif (GSLB/Anycast), aktif-pasif (sıcak/sıcak/soğuk DR).
Bölgelere göre N + 1: SLO çekirdek akışlarını korurken AZ/bölge kaybını sürdürün.
Yasal yerelleştirme: Trafik/verilerin ülkelere göre bölünmesi, farklı sınırlar ve SLO'ların sağlayıcılara bölünmesi.
DR testleri: Gerçek yük aktarımı ile normal oyun günleri.

13) Dış sağlayıcılar: kotalar ve rotalar

Ödemeler/KYC/dolandırıcılıkla mücadele/posta/SMS: TPS, patlama kotaları, günlük limitler.
Çoklu sağlayıcı: gecikme/başarı ile yönlendirme, sağlayıcı başına SLO, auto-feiler.
SLA sözleşmeleri: e2e-SLO uyumluluğu, yükseltme kanalları, durum web kitapları.

14) FinOps: Maliyet ve Verimlilik

TCO: hesaplama + depolama + ağ çıkışı + lisanslar/sağlayıcılar + görev.
Birim Ekonomisi: 1k isteklerinin maliyeti/1 depozito işlemi/1 KYC.
En iyileştirme: sağ boyutlandırma, spot/önek indirimleri, önbellek hitrate, log/trace dedup, soğuk depolama düzeyleri.
Zamanında yük transferi: "Gece" pencerelerinde ve ucuz bölgelerde kritik olmayan partiler.

15) Gösterge panoları ve raporlama (minimum set)

• Mevcut yük ve bağlantılar arasında sabit verim.
• Servis ve bölgeye göre headroom; 24/72 saat tahmini.
• FinOps KPI: $/1k istekleri, $/depozito.

• Üst darboğazlar (p99, doygunluk, gecikme), DR marjı.

• Sağlayıcı başarısı/gecikmesi ve sınırları; Güzergahlarda trafik paylaşımı.

• Yükseltme/endeks/optimizasyon planı, beklenen tasarruf/kapasite artışı.

16) Süreçler ve roller

RACI: Platform (infra/clusters/balancers), Veritabanı/Veri (indeksler, replikasyonlar), Servis komutları (profilleme/önbellek), SRE (SLO, uyarılar), Sec/Uyumluluk (kripto/loglar), Finans (bütçe).
Ritim: haftalık kapasite incelemesi (yol haritası, tahmin, riskler), aylık FinOps raporları, üç aylık DR testleri.
Değişim Yönetimi: Büyük kampanyalar/sürümler kapasite kapısına gider (aşağıdaki kontrol listesi).

17) Kapasite-kapı

• Tepe yük tahmini ve "+ x % acil kuyruk".
• Çekirdek akışlar için mevcut boşluk (ödemeler/ACC/oturum açma).
• Kotalar sağlayıcılara teyit edilmiştir; Alternatif yollar aktif.
• HPA/KEDA eşikleri ve sıcak havuz yapılandırılmıştır.
• Kuyruklar/sınırlar ve bozulma kontrol edildi (oyun kitapları hazır).
• Kanarya paylaşımları ve otomatik geri alma etkinleştirildi.
• Gösterge panoları/uyarılar (yanma oranı, doygunluk, p99) kontrol edildi.
• DR planı ve eskalasyon temasları önemlidir.

18) Anti-desenler

"CPU <%70 - her şey yolunda": bağımlılık sınırlarını göz ardı etme (DB bağlantıları, IOPS, kuyruklar).
Bağlantı başına metrikler olmadan merkezi'kara kutu "- sınırın nerede olduğunu anlamak imkansızdır.
Önbellek stratejisi eksikliği - serbest bırakma öldürme kökenini özlüyor.
Bütçesiz yeniden ödeme limiti sabit kodu bir istek fırtınasıdır.
"Bir ödeme sağlayıcısı", zirvede bir başarısızlık noktasıdır.
Sıcak rezervleri görmezden gelmek, olayların bir nedeni olarak soğuk bir başlangıçtır.
Periyodik DR testleri yok - plan gerektiğinde çalışmıyor.

19) Mini maliyet tahminleri (örnek)

Hizmet X: pod başına kararlı 350 RPS (vCPU = 1, RAM = 2 GiB). Hedef 5,000 RPS, boşluk %25.
Gerekli güç = '5000/0. 75 = 6667 RPS '.
Podov = 'ceil (6667/350) = 20'. Artı sıcak havuz %15 - 3 daha fazla bakla.
DB: 12k TPS limiti, 9k TPS cari kredi, 10 tepe tahmini. 5k TPS - stok 1. 5k (%14). 8'e düşürmek için indeksler/sharding/replicas veya önbelleğe alma gerektirir. 5k.

Sağlayıcı A (KYC): kota 120 rps, tepe 95 rps, kampanya + 40 % - 133 rps> kotalar - yönlendirme 70 % A/30 % B

20) Kapasite planlama uygulama şablonu

1. E2e yolunu ve darboğazlarını açıklayın.
2. CU'ya girin ve her katmanın sürekli verimliliğini ölçün.
3. Tüm bağlantılarda doygunluk ve p99 metriklerini yapılandırın.
4. Etkinlik/kampanya/yayın takvimi oluşturun.
5. Kohort tahmini ve what-if senaryoları oluşturun.
6. Başlık başına iş parçacığı ve bölge başına pin (hata bütçesine bağlanır).
7. HPA/VPA/KEDA + sıcak havuzları, limitleri/retrays/kuyrukları ayarlayın.
8. Sağlayıcı kotalarını kontrol edin, çoklu rotaları etkinleştirin.
9. Panoları ve haftalık ritim kapasitesini toplayın-gözden geçirin.
10. Üç aylık - DR egzersizleri ve model revizyonu.

21) Alt satır

Kapasite planlama, yönetilebilir bir tahmin, mimari kısıtlama ve maliyet paketidir, "CPU ekleyin'değil. E2e yolunun her bir katmanı ölçülen bir kapasiteye sahip olduğunda ve boşluk ve bozulma stratejileri SLO ve hata bütçesi ile ilişkilendirildiğinde, en yüksek yükler, kampanyalar ve kazalar sürpriz olmaktan çıkar. Bu yaklaşım, olay riskini azaltır, iş metriklerini stabilize eder ve maliyetleri optimize eder.