Ölçeklenebilirlik eksenleri

Ölçeklenebilirlik yalnizca daha fazla sunucu eklemek degildir. Sistem farklı eksenlerde buyur: trafik, veri, ekip, islevsellik. Her eksen farklı mimari baskı üretir. Tek boyutlu düşünce, ya erken optimizasyon ya da gec kalmis felaket refactor üretir. Bu makale ölçeklenebilirlik eksenlerini ve her birinin tasarım kararlarini inceler.

Uc temel eksen

Pratik siniflandirma:

• Yatay ölçeklendirme (scale out): Daha fazla instance; stateless servisler.
• Dikey ölçeklendirme (scale up): Daha güçlü makine; tek node kapasitesi.
• Fonksiyonel ölçeklendirme: Sistemi alt servislere veya modullere ayirma.

Bunlara ek olarak veri ölçeklendirme ve organizasyon ölçeklendirme (Conway Yasasi) ayri dusunulmelidir.

Yatay ölçeklendirme

Stateless web ve API katmanları yatay olceklendirmeye uygundur. Load balancer trafigi instance'lara dagitir. Gereksinimler:

1. Session state dis storeda (Redis) veya sticky session bilincli kullanım.
2. Idempotent işlemler ve uygun retry semantigi.
3. Health check ve otomatik kayıt silme.

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: order-api
spec:
  minReplicas: 2
  maxReplicas: 20
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70

HPA CPU veya custom metrik (kuyruk derinligi) ile olceklendirir.

Stateless tasarım maliyeti

State dışarı tasindiginda ag gecikmesi ve tutarlılık sorulari dogar. Her stateless karar trade-off icerir.

Dikey ölçeklendirme

Veritabanı ve bazı legacy bilesenler oncelikle dikey olceklendirilir. Daha büyük CPU, RAM ve IOPS. Basit ve hızlı çözüm; tavan vardir. Tek node limitine yaklasildiginda sharding veya read replica gerekir.

Dikey ölçeklendirme downtime gerektirebilir; cloud provider live resize sunabilir ama risk degerlendirmesi sart.

Fonksiyonel ölçeklendirme

Sistem işlevsel olarak parcalanir: siparis servisi, odeme servisi, envanter servisi. Moduler monolit ile baslanip ihtiyaç halinde mikroservise gecilebilir. Fonksiyonel ölçeklendirme ekip bagimsizligini artirir ama dagitik sistem karmasikligini getirir.

Conway Yasasi: mimari yapı organizasyon iletisimi yansitir. Yanlış sınırlar ekip catismasini kodda tekrarlar.

Veri ölçeklendirme

Veri buyudugunde:

• Read replica: Okuma yukunu dagitir; eventual consistency.
• Sharding: Veriyi tenant veya key araligina gore bol.
• Archive: Soguk veriyi ucuz depolamaya tasir.
• Cache: Sık okunan veriyi bellekte tutar.

Veri ölçeklendirme en zor eksendir; geri donusu pahali kararlar burada alinir.

CAP ve PACELC

Dagitik sistemlerde tutarlılık ve erisilebilirlik arasinda seçim yapilir. CAP: partition durumunda CP mi AP mi. PACELC: normal calismada latency vs consistency. Ölçeklendirme stratejisi bu secimleri aciklastirmalidir.

Odeme mutabakati CP egilimli; ürün katalog cache AP egilimli olabilir.

Ölçeklendirme tetikleyicileri

Ne zaman olceklendirmeli:

1. p95 latency SLO ihlali.
2. CPU veya bellek sürekli esik uzerinde.
3. Kuyruk tüketim hizi üretim hizini geride birakiyor.
4. Veritabanı bağlantı havuzu tukeniyor.

Reaktif ölçeklendirme metrik tabanli olmali; takvim degil.

Anti-patternler

• Premature microservices: düşük trafikte operasyon yuku.
• Shared database antipattern: fonksiyonel ölçeklendirme sahte.
• Infinite vertical scale: maliyet ve limit.
• Cache as database: veri kaybi riski.

Maliyet ölçeklendirme

FinOps perspektifi: ölçeklendirme bulut faturasini artirir. Autoscaling max limit, spot instance ve reserved capacity planlanir. Ölçeklenebilirlik ve maliyet birlikte dashboardda izlenir.

Test ve kapasite planlama

Load test staging ortaminda production benzeri profille çalışır. Breaking point belirlenir; HPA esikleri buna gore ayarlanir. Chaos engineering ile instance kaybi senaryosu dogrulanir.

Özet

Ölçeklenebilirlik cok eksenlidir. Yatay, dikey ve fonksiyonel stratejiler birlikte dusunulmeli. Veri ölçeklendirme kritik sinirdir. Metrik tabanli karar, açık CAP trade-off ve maliyet bilinci sürdürülebilir buyume sağlar.

Global ölçeklendirme

Cok bolgeli deployment latency dusurur; veri yerellik mevzuati gerektirir. Active-active veya active-passive topoloji seçimi tutarlılık gereksinimine baglidir. CDN statik içerik icin yatay olceklendirmenin edge varyantidir.

Ekip ölçeklendirme

Kod olceklendirmesi ekip olceklendirmesi ile uyumlu olmali. Two-pizza team ve bounded context sınırları fonksiyonel olceklendirmeyi destekler.

Gozlemlenebilirlik

Ölçeklendirme kararlari metrik gerektirir: RPS, queue lag, DB connections, error rate. Golden signals olmadan ölçeklendirme tahmindir.

Little Yasasi

Little Yasasi: gecikme = kuyruk uzunlugu x işlem suresi. Ölçeklendirme kuyrugu kisaltmadan veya işlem suresini dusurmeden latency dusmez. Profiling ile dar bogaz bulunur.

Connection pool ölçeklendirme

Instance sayisi arttikca DB bağlantı havuzu baskisi artar. PgBouncer veya RDS proxy gibi katmanlar zorunlu hale gelir. Pool boyutu ölçeklendirme planinin parcasidir.

Serverless ölçeklendirme

Function as a Service aninda yatay ölçeklendirme sunar; cold start ve vendor limit dikkate alinir. Event driven yük profiline uygundur.