Yük Altında Yazılım Tasarımı İlkeleri

Ölçeklenebilirlik ne zaman tasarlanır?

Trafik geldiğinde değil, mimari kurulurken. Yüksek trafik altında ayakta kalan sistemlerin ortak özelliği egzotik teknolojiler değil, az sayıda ilkenin baştan ve tavizsiz uygulanmasıdır: durumu doğru yere koymak, yatay ölçeklenebilir kalmak, veriyi bölünebilir tasarlamak ve koordinasyonu en aza indirmek. Bu yazı o ilkeleri, kampanya günü çöken sistemlerden çıkan derslerle birlikte derler.

İlke 1: Durum (state), en pahalı mimari karardır

Bir servisin ölçeklenebilirliği, taşıdığı durumla ters orantılıdır. Uygulama düğümünde tutulan oturum, yerel bellekteki 'geçici' liste, diske yazılan dosya — her biri o düğümü biricikleştirir ve yük dengeleyiciyi yapışkan oturuma (sticky session) mahkûm eder. Kural: uygulama katmanı durumsuz kalır; oturum ve geçici durum paylaşımlı depoya (Redis vb.), kalıcı durum veritabanına, dosyalar nesne depolamaya gider. Durumsuz düğüm; çoğaltılabilir, öldürülebilir ve otomatik ölçeklenebilir düğümdür — modern altyapının tüm otomasyonu bu varsayıma yaslanır.

İlke 2: Yatay ölçekleme varsayılan, dikey ölçekleme istisnadır

Boyut	Dikey (daha büyük makine)	Yatay (daha çok makine)
Üst sınır	Donanımın fiziksel tavanı	Mimari doğruysa pratikte çok yüksek
Maliyet eğrisi	Üst segmentte hızla pahalılaşır	Doğrusala yakın; talebe göre in-çık
Dayanıklılık	Tek makine = tek hata noktası	Düğüm kaybı emilebilir
Ön koşul	Yok — her kod dikey büyür	Durumsuzluk + bölünebilir veri

Dikey ölçekleme geçerli bir araçtır — özellikle veritabanı için ilk hamledir; ama tavanı ve tek-nokta riski bellidir. Uygulama katmanında hedef her zaman 'N kopya çalışabilir' özelliğini korumaktır: tekil zamanlayıcılar (tek düğümde koşması gereken cron), yerel kilitler ve 'sıradaki numarayı bellekte üret' gibi desenler bu özelliği sessizce öldürür — dağıtık kilit/lider seçimi veya işin veritabanı/kuyruk üzerinden koordine edilmesiyle değiştirilmelidir.

İlke 3: Veri, bölünebilir tasarlanır

Uygulama katmanı kolay çoğalır; darboğaz veri katmanında birikir. Erken alınacak iki karar sonrayı belirler: partisyon anahtarı — veriye hangi eksenden erişiliyor (müşteri, sipariş, kiracı)? Tablolar bu anahtar etrafında tasarlanırsa yarın okuma kopyaları, önbellek bölmeleri ve gerekirse sharding doğal gelir; anahtar kesitli sorgular (cross-partition) ise en pahalı işlem olarak istisnalaşır. İkincisi sıcak nokta yönetimi: tek bir sayaç satırı, ardışık artan kimlikle tek bloğa yığılan yazmalar veya 'herkesin güncellediği' tek kayıt, ölçek büyüdükçe kilitlenme üretir — sayaç parçalama (sharded counter), ID üretiminde dağınıklık ve yazma yayma desenleri baştan düşünülür.

İlke 4: Koordinasyon, gizli hız sınırıdır

İki düğümün anlaşmak zorunda olduğu her nokta — dağıtık kilit, senkron çapraz servis çağrısı zinciri, 'hepsi bitince cevap ver' birleşimleri — sistemin o noktadaki en yavaş üyeye kilitlenmesidir. Ölçeklenebilir tasarımın sessiz ilkesi koordinasyondan kaçınmaktır: mümkün olan her yerde iş, bağımsız işlenebilir parçalara bölünür; kesin sıra yerine idempotent işleme, senkron zincir yerine olay/kuyruk, küresel kilit yerine partisyon içi yerel işlem tercih edilir. Amdahl'ın yasasının mimari karşılığı budur: paralelleşemeyen küçük bir bölüm bile toplam ölçeklenmeyi sınırlar.

Kapasite matematiği: kaç düğüm, hangi eşik?

Ölçek planı slogan değil aritmetiktir. Basit ama işleyen model: hedef zirve RPS (geçmiş zirve × büyüme × kampanya çarpanı) ÷ tek düğümün güvenli RPS'i (yük testinde p99 hedefini koruduğu seviyenin ~%60-70'i) = gereken düğüm sayısı; üzerine N+1 yedeklik. Aynı hesap veritabanı bağlantıları, kuyruk tüketici sayısı ve önbellek belleği için tekrarlanır. Bu matematiğin ön koşulu ölçümdür: tek düğüm kapasitesi tahminle değil, üretim benzeri yük testiyle bulunur — ve her büyük sürümde yeniden doğrulanır.

İş etkisi: ölçeklenebilirlik, satın alınan değil korunan bir özelliktir

Bulut size sınırsız makine satar; mimariniz kullanamıyorsa fatura büyür, kapasite büyümez. Bu ilkelerle kurulan sistemin ticari karşılığı somuttur: kampanya trafiği makine ekleyerek karşılanır (panik mühendisliğiyle değil), altyapı maliyeti talebe göre iner-çıkar ve 'şu kadar trafiği taşır mısınız?' sorusuna yük testi raporuyla cevap verilir. Kurumsal satışta bu rapor, referans kadar güçlüdür.

Sık sorulan sorular

Baştan mikroservis mi kurmalıyım?

Hayır — bu ilkelerin hepsi modüler monolitte de uygulanır. Ölçeklenebilirlik servis sayısından değil; durumsuzluk, veri tasarımı ve koordinasyon disiplininden gelir.

Sticky session kullanmak her zaman yanlış mı?

Geçiş dönemi aracı olarak kabul edilebilir; kalıcı mimari olarak düğüm kaybında oturum kaybı ve dengesiz yük demektir. Hedef, oturumun paylaşımlı depoya taşınmasıdır.

Otomatik ölçekleme (autoscaling) her şeyi çözer mi?

Autoscaling, durumsuz ve hızlı açılan düğüm varsayımına yaslanır; ayrıca ani sıçramalarda açılış gecikmesi vardır. Kampanya gibi bilinen zirvelerde ön-ölçekleme (pre-scaling) planlanır.

Ne zaman sharding'e geçmeliyim?

Okuma kopyaları + önbellek + sorgu optimizasyonu tükenmeden değil. Sharding operasyon karmaşıklığı satın alır; partisyon anahtarını baştan doğru seçmişseniz bu geçiş de dilimlenebilir olur.

Yük altında tasarım kontrol listesi

Uygulama katmanı durumsuz; oturum ve dosyalar paylaşımlı katmanda
Her servis N kopya çalışabiliyor; tekil zamanlayıcılar koordine edilmiş
Partisyon anahtarı tanımlı; çapraz-partisyon sorgular istisna
Sıcak nokta analizi yapıldı; sayaç/ID desenleri gözden geçirildi
Senkron çağrı zincirleri haritalandı; koordinasyon noktaları azaltıldı
Tek düğüm kapasitesi yük testiyle ölçüldü; kapasite modeli yazılı
Bilinen zirveler için ön-ölçekleme planı mevcut

SSH Yazılım, yüksek trafikli sistemlerin mimari değerlendirmesini ve ölçeklenebilirlik dönüşümünü uçtan uca yürütür. Sisteminizin ölçek haritasını birlikte çıkaralım.