Kapasite planlaması ve yük artışı

Kısa Özet

1. Talep tahmini (temel eğilim + mevsimsellik + olaylar).

2. Yük modeli (Internet için açık model).

3. Boşluk ve hatalı bütçe.

4. Ölçekleme (ufuk/dikey/otomatik) + sınırlayıcılar (hız sınırı/geri basınç).

5. Finans: $/1000 RPS, $/ms p95, senaryoya göre TCO.

Şartlar ve Metrikler

İşlem Hacmi: RPS/QPS/CPS - gerçek işlem hacmi.
Gecikme süresi p95/p99: Kullanıcı yolları için hedef SLO'lar.
Doygunluk: CPU/bellek/IO/FD/bağlantılar/kuyruklar yükleniyor.
Hata oranı: 5xx/timeout/429, dönem için hatalı bütçe.
Boşluk: En yoğun trafikte serbest güç payı (%30 ≥ önerilir).
Burst: Kısa süreli başak (saniye/dakika), Spike: N × keskin yükselişi.

Temel modeller ve formüller

Little Yasası (sıralı sistemler için)

L = λ W

L, sistemdeki ortalama istek sayısı, λ ortalama giriş oranı (RPS), W, sistemdeki ortalama süredir. Kuyruk derinliğini tahmin etmek için kullanışlıdır.

Yük faktörü (ρ)

ρ = λ / μ

μ - servis hızı (%100 CPU'da RPS). ρ - 1 olduğunda, gecikme doğrusal olmayan bir şekilde artar - çalışma noktasını ρ ≤ 0 tutun. 6–0. 75.

Güvenlik faktörü/marjı

Capacity_required = Peak_load (1 + Headroom) Degradation_factor

Degradation_factor N hatası, önbellek bozulması, bir PoP/bölge kaybı (örneğin, 1. 2).

Talep tahmini

1. Geçmiş: Gün/hafta profilleri, mevsimsellik, olaylarla korelasyon (maçlar/akışlar/ödemeler).
2. Olaylar: Senaryo katsayıları (normal gün × 1, turnuva × 2. 3, son × 3. 5).
3. Dalgalanmaların kaynakları: pazarlama kampanyaları, sürümler, bot anomalileri.
4. Tahmin birimleri: Rotalara göre RPS (giriş, lobi, katalog, ödemeler), CPS TLS, QPS DB, IOPS disk, çıkış Gbps.
5. Güven: İki senaryo tutun - muhafazakar ve agresif.

Yükleme simülasyonu

Açık model (Poisson benzeri varış): Genel API'ler/web için makul - boyutlandırma için kullanın.
Kapalı model (VU + think-time): iç diziler için uygundur; birleştirin.
Rota karışımları: uç noktalar başına ağırlık kesirleri; Sadece "sıcak'değil, aynı zamanda" pahalı "(kayıt, depozito) içerir.
Unutmayın: retras, kuyruklar, iş ortağı sınırları (PSP, üçüncü taraf API'ler).

Emniyet marjı tasarımı

Headroom hedefi: Zirveye ≥ %30 (İnternet için); Ödeme çekirdeği ve kritik yollar için - %40-50.
N + 1/N + 2: SLO'yu ihlal etmeden 1-2 örnek/bölgenin başarısızlığına dayanır.
Çok bölgeli: Her bölge toplam zirvenin ≥ %60'ını çeker (bir komşunun kaybından kurtulmak için).
Degrade modu: ikincil işlevleri devre dışı bırakın, yükü azaltın, önbellek/bıçak yanıtlarını etkinleştirin.

Katmanlara Göre Boyutlandırma

Ağ/Kenar

Önde CPS/RPS, TLS-el sıkışma p95, % resumption≥70, çıkış Gbps.
Anycast/Geo-routing, CDN/WAF limitleri (önceden kabul edin).
Kenar boşluğu: link/aplink ≥ tepe × 1. 3, H3 için marj UDP/443 ile SYN birikimi.

Dengeleyiciler/Proxy'ler

Örneğin RPS, açık bağlantılar, kuyruklar, CPU/IRQ.
Keepalive ve bağlantı havuzu - arka uçlara bağlantıları azaltın.
Stok: ρ ≤ 0. 7, rota başına sınırlayıcı по CPS/RPS.

Uygulamalar

Platoda çekirdek başına hedef performans (RPS/çekirdek).
Havuzlar (iş parçacığı/DB/HTTP) - sınırlara girmeyin.
Stok: CPU'ya kadar otomatik ölçekleme %60-70 ve gecikme tetiği (p95).

Önbellekler

Hit-ratio, hotset hacmi, tahliye, kopya.
Rezerv: hafıza ≥ 1. 2 × hotset, ağ boşluğu ≥ %30.

Veritabanları

QPS/TPM, p95 istekleri, kilitler, arabellek önbelleği, WAL/çoğaltma gecikmesi.
IOPS ve gecikme sürücüleri p95'in anahtarıdır.
Marj: CPU çalışma noktası %50-65, replica lag <target; Charding planı ve okuma-kopyaları.

Diskler/Depolama

IOPS (4k/64k), verim, fsync maliyeti.
Stok: IOPS ≥ zirve × 1. 5, hedef penceresinde gecikme p95; Günlük/veri için ayrı havuzlar.

GPU/ML (çevrimiçi çıkarım varsa)

Samples/s, latency, VRAM headroom, batching.
Marj: "testere" yükü altında parti parametreleri, sıcak havuz GPU.

Otomatik ölçekleme

HPA/KEDA: CPU metrikleri + özel (p95 gecikme, RPS, kuyruk).
Sıcak havuzlar: Olaylardan önce önceden ısıtılmış örnekler.
Adım ölçekleme: "testere" olmamak için bekleme süresine sahip adımlar.
Reaksiyon süresi: T_scale nişan alın ≤ ön katman için 1-2 dakika; DB için - önceden.

Sınırlayıcılar ve geri basınç

IP/ASN/cihaz/rota по oran sınırı; ortak kotaları.
TTL ile kuyruklar, ret "kibar" (429/gri-vol aracılığıyla) zaman aşımları önce.
Idempotence: ödemeler için anahtarlar; bütçe + jitter ile retrays.
Çökme isteği/SWR: Sıçrama sırasında orijini uyandırmayın.

Hızlı hesaplama örneği

Verilen: 35k RPS API tepe tahmini, p95 ≤ 250 ms, ortalama servis süresi 60 % CPU'da örnek başına 8 ms, μ≈125 RPS/çekirdek, örnek başına 8 çekirdek, 1000 RPS/örnek ~.
Adım 1 (stok yok): 35 örnek.
Adım 2 (boşluk %30): 35 × 1. 3 = 46.
Adım 3 (bir AZ'nin başarısızlığı, + %20): 46 × 1. 2 ≈ 55.
Adım 4 (yuvarlama + sıcak rezerv %10): 61 örnek.
Kontrol: ρ ≈ 35k/( 61k) ≈ 0. 57 - Yeşil bölgede.

Finansal Model (FinOps)

$/1000 RPS katman (kenar, proxy, uygulama, DB).
$/ms p95 (kuyruk azaltma maliyeti).
TCO senaryoları: talep üzerine vs rezerve vs spot (kesinti riski ile).
Kapasite planı: üç aylık hesap/küme limitleri, bulut kotaları, PSP/CDN limitleri.

Arızalar ve DR için hazır

Multi-AZ/bölge: Her kol yükün %60'ını ≈.
Yük devretme planı: Anycast, GSLB anahtarlama, TTL ≤ 60-120 s çekin.
Kritik bağımlılıklar: PSP/banka limitleri, ikincil sağlayıcı.
Periyodik egzersizler: PoP/BG/önbellek kapalı oyun günü.

Gözlemlenebilirlik ve erken doygunluk sinyalleri

P95/p99 büyümesi ve sabit girişli kuyruklar.
Hit-ratio önbellek düşüşü, origin çıkış büyümesi.
Geri gönderimler/ECN CE artışı, TLS devam düşüşü.
Büyüme 429/zaman aşımı ve yeniden deneme oranı.
Veritabanları için - çatışma büyümesi, kontrol noktası zamanı, WAL fsync.

Operasyonel Uygulamalar

Aylık kapasite incelemesi: fact vs plan.
Olaylar için pencereleri değiştirin: çekirdekleri ve sınırları dondurun.
Prewarm (CDN/DNS/TLS/pools) zirveden 10-30 dakika önce.
Sürüm oluşturmayı sınırla: Git'te kur-limit/havuz yapılandırmalarını düzelt.

iGaming/fintech'e özel

Turnuvalar/maçlar: spike + plato profilleri, botlar için gri rotalar, ayrı kayıt/depozito limitleri.
Ödemeler/PSP: sağlayıcı/yöntem kotaları, geri dönüş yolları, çıkış IP havuzları, SLA Time-to-Wallet.
İçerik sağlayıcıları: stüdyoya göre dağıtım, sıcak önbellekler, parça havuzları.
Antifraud/AML: Kurallar/puanlama sınırı, zirvede ışık kurallarına bozunma.

Uygulama kontrol listesi

• Zirve tahmini (baz/sezon/olaylar), iki senaryo.
• SLO/yanlış bütçe ve hedef boşluk ≥ %30.
• Katmanlara göre boyutlandırma (edge/proxy/app/cache/DB/IO/network).
• Oran-limit, kuyruk, idempotency, yeniden deneme-bütçe.
• HPA/KEDA + sıcak havuzlar; Etkinlikten önce promosyon planı.
• Çoklu AZ/bölge, yük devretme oyun kitapları, TTL ve GSLB.
• Bulut/PSP/CDN kotaları tutarlı ve belgelenmiştir.
• Gözlemlenebilirlik: kapasite panoları, erken doygunluk sinyalleri.
• DR egzersizleri ve düzenli kapasite incelemesi.

Yaygın hatalar

Atıklar/sivri olmadan ortalama RPS için plan yapın.
ρ≈0. 9 "kağıt üzerinde" - gecikme en ufak bir gürültüde patlar.
Harici servis sınırları göz ardı ediliyor (PSP/CDN/DB kümesi).
Hiçbir bozunma modu yoktur ve geri basınç basamakları başarısız olur.
Ön ısıtma olmadan otomatik ölçek - tepe "sonra" yönetir.
Tüm katmanlar için tek boşluk - darboğaz taşınır.

Mini oyun kitapları

Zirve olayından önce (T-30 dk)

1. MinReplicas/hedef HPA'yı artırın, sıcak havuzu etkinleştirin.
2. CDN/DNS/TLS/bağlantılarını ısıtın, önbellekleri ısıtın.
3. PSP havuzu limitlerini ve kotalarını kararlaştırıldığı gibi yükseltin.
4. Gri rotaları/bot filtrelerini, dar ağır uç noktaları açın.

Kısmi bölge kaybı

1. GSLB - komşu bölge, TTL 60-120 s.
2. Bozma modunu etkinleştirin (önbellek/basitleştirilmiş ödeme).
3. PSP/çıkış-IP sınırlarını yeniden dağıtın.
4. Durum iletişimi, p95/hata kontrolü.

Geri çekilmelerde dalgalanma

1. Yeniden deneme bütçesini azaltın, backoff + jitter özelliğini etkinleştirin.
2. GET üzerinde istek daraltma/SWR'yi etkinleştirin.
3. "Gürültülü" ASN'ler için hız sınırını geçici olarak sıkılaştırın.

Sonuç

Kapasite planlaması talep tahmini + mühendislik modeli + güvenlik marjı + operasyonel kollardır. SLO ve tavan aralığını resmileştirin, dış sınırları göz önünde bulundurun, ölçeklendirmeyi ve bozulmayı otomatikleştirin, "milisaniye başına maliyeti" ölçün ve düzenli kapasite incelemeleri yapın. O zaman yükteki artış bir riske değil, yönetilebilir bir iş metriğine dönüşecektir.