Yatay mı Dikey mi Ölçekleme

Trafiğin artmaya başladığında önüne iki yol çıkar: ya mevcut sunucuya daha fazla CPU, RAM ve disk verirsin ya da aynı işi yapan ikinci, üçüncü sunucuyu devreye alırsın. İlkine dikey ölçekleme (scale up), ikincisine yatay ölçekleme (scale out) denir. Kâğıt üzerinde bir tercih meselesi gibi görünür ama gerçekte bu karar mimarinin geri kalanını, maliyet eğrini ve kesinti riskini yıllarca belirler. Yanlış tarafa çok erken sapmak da, çok geç sapmak da pahalıya patlar.

Bu rehberde iki yaklaşımın gerçekte ne anlama geldiğini, nerede duvara tosladıklarını, maliyetlerinin nasıl davrandığını ve en önemlisi hangi sinyaller gördüğünde hangisine geçmen gerektiğini anlatacağım. Ayrıca yatay ölçeklemenin görünmeyen ön koşulunu — uygulamanın durumsuz hâle getirilmesini — ve neredeyse her projede işleri tıkayan veritabanı katmanını da ele alacağım.

Dikey Ölçekleme (Scale Up) Nedir#

Dikey ölçekleme, aynı makineyi güçlendirmektir: 4 vCPU'yu 16'ya çıkarmak, 8 GB RAM'i 64 GB yapmak, SATA SSD'yi NVMe ile değiştirmek. Sanallaştırılmış ortamlarda bu genellikle panelden kaynak artırıp makineyi yeniden başlatmak kadar basittir; fiziksel sunucuda ise donanım değişimi gerekir. Uygulama tarafında hiçbir şey değişmez, kod aynı kalır, mimari aynı kalır. Bu yüzden dikey ölçekleme her zaman en hızlı ve en ucuz ilk hamledir.

Yükün nerede sıkıştığını görmeden kaynak artırmak ise para yakmaktır. Önce hangi kaynağın doyduğunu ölç:

# CPU baskısı mı, I/O beklemesi mi? %wa yüksekse sorun diskte
vmstat 1 5
# Bellek gerçekten dolu mu, yoksa sadece önbellek mi? "available" sütununa bak
free -h
# Disk gecikmesi: %util 90+ ve await yüksekse disk darboğaz
iostat -x 1 3
# En çok belleği kim yiyor
ps -eo pid,comm,%mem,rss --sort=-rss | head -10

free -h çıktısında used yüksek ama available da yüksekse bellek sorunun yoktur; Linux boş belleği disk önbelleği olarak kullanır ve bu sağlıklıdır. Gerçek bellek darlığının işareti si/so sütunlarında sürekli takas (swap) hareketi görmektir. Aynı şekilde CPU kullanımı %90 görünüyorsa ama bunun büyük kısmı %wa ise, CPU eklemek hiçbir şeyi düzeltmez — disk yükseltmen gerekir.

Dikey ölçeklemenin üç somut sınırı vardır. Birincisi fiziksel tavan: her sanallaştırma düğümünün ve her anakartın bir üst sınırı vardır, sonsuza kadar büyütemezsin. İkincisi getiri azalması: tek bir PHP-FPM ya da Node.js süreci belirli bir çekirdek sayısından sonra doğrusal hızlanmaz, kilitlenmeler ve tek iş parçacıklı bölümler devreye girer. Üçüncüsü ve en önemlisi, dikey ölçekleme erişilebilirliği hiç iyileştirmez: 64 GB RAM'li tek sunucu da çöktüğünde site gider, tıpkı 8 GB'lik gibi.

Yatay Ölçekleme (Scale Out) Nedir#

Yatay ölçekleme, aynı işi yapan sunucu sayısını artırmaktır. Önüne bir dağıtım katmanı koyarsın, arkasına iki, dört, on düğüm eklersin. Bu yaklaşımın en büyük kazancı kapasite değil, dayanıklılıktır: bir düğüm çöktüğünde diğerleri trafiği karşılamaya devam eder, bakım için tek tek düğüm çıkarabilirsin, sürüm geçişlerini kesintisiz yapabilirsin. Kapasite artışı ise cabası.

Bunun bedeli karmaşıklıktır. Trafiği dağıtacak bir katmana ihtiyacın olur; bunun nasıl çalıştığını yük dengeleyici nedir yazısında ayrıntılı anlattım. Dosya yüklemeleri artık yerel diske yazılamaz, oturumlar sunucu belleğinde tutulamaz, önbellek her düğümde ayrı ayrı ısınamaz, dağıtım (deploy) işlemi tek makineye git pull atmaktan ibaret olamaz. Yani yatay ölçekleme bir sunucu kararı değil, bir mimari kararıdır.

Maliyet Eğrileri Aynı Davranmaz#

İki yaklaşımın maliyeti çok farklı biçimde büyür ve bunu peşinen bilmek bütçe planını değiştirir. Dikey ölçeklemede fiyat, kaynak arttıkça doğrusaldan hızlı yükselir: 4 vCPU'dan 8'e çıkmak makul bir farkken, 32'den 64'e çıkmak genelde orantısız pahalıdır çünkü artık daha büyük ve daha az bulunan bir anakart sınıfına geçersin. Yatay ölçeklemede ise birim maliyet neredeyse sabittir — dördüncü sunucu, ikinci sunucuyla aynı fiyattır — ama başlangıçta ödediğin sabit bir "mimari vergisi" vardır: dengeleyici düğümleri, ortak depolama, izleme.

Kabaca şöyle düşünebilirsin: küçük ve orta ölçekte dikey daha ucuz, belirli bir eşikten sonra yatay daha ucuz. O eşik her uygulamada farklıdır ama iki ipucu verir kendini: aylık faturanda tek makinenin bedeli iki orta boy makineden pahalı hâle geldiğinde ve bir kesintinin sana kaybettirdiği para ek sunucunun bedelini geçtiğinde. İkinci eşik genelde birincisinden önce gelir. Ne kadarlık bir kesintinin ne anlama geldiğini somutlaştırmak için uptime ve SLA hesaplayıcı aracını kullanabilirsin.

Yatay Ölçeklemenin Ön Koşulu: Durumsuzluk#

Bir uygulamayı yatay ölçekleyemiyorsan, sebep neredeyse her zaman aynıdır: uygulama durum (state) tutuyordur ve bu durum tek bir makinenin diskinde ya da belleğindedir. Yatay ölçeklemeye geçmeden önce şu dört şeyin makine dışına çıkarılması gerekir.

1. Oturumlar. PHP'nin varsayılan files oturum sürücüsü oturumu /var/lib/php/sessions altına yazar; ikinci sunucuya düşen kullanıcı oturumunu kaybeder. Redis ya da Memcached gibi ortak bir depoya taşı.
2. Yüklenen dosyalar. Kullanıcı görselleri, faturalar, ekler yerel diske yazılıyorsa nesne depolama ya da ortak bir dosya sistemi gerekir.
3. Önbellek. Her düğümün kendi yerel önbelleği tutarsız sonuçlar üretir; merkezî bir önbellek katmanı kurulmalıdır.
4. Zamanlanmış görevler. cron girdisi bütün düğümlere kopyalanırsa aynı e-posta üç kez gider. Ya tek bir düğümü görev düğümü ilan et ya da dağıtık bir kilit kullan.

; PHP oturumlarını Redis'e taşı (php.ini)
session.save_handler = redis
session.save_path = "tcp://10.0.0.20:6379?database=1"

Bu değişikliklerin her düğümde birebir aynı uygulanması gerekir; tek bir sunucuda unutulan ayar, sadece o sunucuya düşen kullanıcılarda ortaya çıkan ve teşhisi çok zor olan hatalara yol açar. Yapılandırmayı elle kopyalamak yerine Ansible ile sunucu otomasyonu yaklaşımıyla tanımlamak, düğüm sayısı ikiyi geçtiği anda zorunlu hâle gelir.

Veritabanı Katmanı: Asıl Zorluk Burada#

Web sunucularını yatay ölçeklemek görece kolaydır; veritabanını ölçeklemek ise bambaşka bir konudur ve çoğu projede tıkanma noktası buradadır. Sebebi basit: veritabanı doğası gereği durumludur ve yazma işlemlerinin tutarlı olması gerekir.

Pratikte sırayla denenen yol şudur. Önce dikey: veritabanı sunucusuna daha fazla RAM vermek genelde en yüksek getirili hamledir, çünkü çalışma kümesi belleğe sığdığında disk okuması neredeyse sıfırlanır. Sonra okuma replikaları: bir birincil (primary) sunucuya yazar, bir veya birden fazla replikadan okursun. Okuma ağırlıklı uygulamalarda bu tek başına büyük rahatlama sağlar ama uygulamanın okuma ve yazma bağlantılarını ayırması gerekir. En sonda parçalama (sharding) gelir: veriyi anahtar aralıklarına göre bölmek. Sharding güçlüdür ama sorgu esnekliğini ve raporlamayı ciddi biçimde zorlaştırır; gerçekten gerekmedikçe girme.

-- Replikasyon gecikmesini izlemeden okuma replikasına yönlendirme yapma
SHOW REPLICA STATUS\G
-- Seconds_Behind_Source değeri sürekli 0'ın üstündeyse
-- kullanıcı kendi yazdığı kaydı listede göremez

Bu son nokta gerçek bir üretim tuzağıdır: kullanıcı formu kaydeder, sayfa listeye döner, liste replikadan okunur ve replika henüz güncellenmemiştir; kullanıcı kaydın kaybolduğunu düşünür. Çözüm, yazma sonrası kısa bir süre okumaları birincile yönlendirmek ya da kritik akışları replikadan hiç okumamaktır.

Hangisini Ne Zaman Seçmelisin#

Karar için basit bir kılavuz:

Kaynak ihtiyacının hangi altyapı tipine denk düştüğüne karar verirken bulut sunucu mu VDS mi karşılaştırması işine yarar; sabit ve öngörülebilir yükte VDS, dalgalı yükte esnek kaynaklı bulut sunucu genellikle daha mantıklıdır. Yükün gerçekten tek bir makinenin sınırlarını zorlayıp zorlamadığını anlamak içinse dedicated sunucu ne zaman gerekir yazısındaki eşikler iyi bir referans.

Sık Yapılan Hatalar#

En yaygın hata darboğazı ölçmeden kaynak eklemektir. CPU %95 görünüyor diye çekirdek iki katına çıkarılır, hiçbir şey değişmez; çünkü asıl sorun indeksi olmayan bir sorgunun diski dövmesidir. Kaynak artırmadan önce mutlaka vmstat, iostat ve uygulama tarafında yavaş sorgu kaydını incele.

İkinci hata yatay ölçeklemeyi durumsuzlaştırmadan denemektir. İkinci sunucu eklenir, kullanıcılar rastgele çıkış yapmaya başlar, yüklenen dosyalar bazen görünür bazen görünmez. Bu noktada çoğu ekip "yatay ölçekleme çalışmıyor" diyip sticky session açar ve sorunu halının altına süpürür; oysa sorun mimaridedir.

Üçüncü hata veritabanını unutmaktır. On web sunucusu eklersin, hepsi aynı tek veritabanına bağlanır ve bağlantı havuzu tükenir. Web katmanını ölçeklerken veritabanı bağlantı sayısını da planlaman gerekir; her düğüm için ayrı bir havuz açıldığını unutma.

Dördüncü hata küçülmeyi hiç düşünmemektir. Ölçekleme yalnızca büyümek değildir; kampanya bittiğinde ek düğümleri kapatabilmek maliyetin yarısını belirler. Büyürken eklediğin her bileşenin nasıl geri alınacağını da yaz.

Sıkça Sorulan Sorular#

Yatay ölçekleme her zaman dikeyden iyi midir#

Hayır. Yatay ölçekleme dayanıklılık ve neredeyse sınırsız büyüme sunar ama beraberinde dengeleyici, ortak depolama, oturum deposu ve daha karmaşık bir dağıtım süreci getirir. Küçük ve orta ölçekli, trafiği kararlı bir uygulama için dikey büyümek hem daha ucuz hem daha az risklidir. Doğru soru "hangisi daha iyi" değil, "hangi sorunumu çözüyorum" sorusudur.

Dikey ölçekleme kesinti yaratır mı#

Çoğu durumda evet. Sanal sunucuya CPU veya RAM eklemek genellikle makinenin kapatılıp yeniden başlatılmasını gerektirir; bu da birkaç dakikalık bir kesinti demektir. Bazı sanallaştırma platformları sıcak ekleme (hot add) destekler ama işletim sistemi ve uygulamanın da bunu desteklemesi gerekir. Planlı bir bakım penceresinde yapmak en güvenli yoldur.

Kaç sunucudan sonra yatay ölçeklemeye geçmeliyim#

Sunucu sayısı değil, iki sinyal belirleyicidir: tek makinenin ölçülmüş kapasitesinin %70'ini düzenli olarak geçiyorsan ve bir kesintinin maliyeti ikinci sunucunun aylık bedelinden büyükse. İkinci koşul genellikle birincisinden çok daha önce oluşur; bu yüzden pek çok ekip aslında kapasite için değil, erişilebilirlik için yatay ölçeklemeye geçer.

Ölçeklendikten sonra maliyetim ne kadar artar#

Yatay ölçeklemede sunucu başına maliyet aynı kalır ama üstüne sabit bir mimari maliyeti eklenir: iki dengeleyici düğümü, ortak depolama ve izleme. Küçük kurulumlarda bu sabit maliyet toplamın önemli bir kısmını oluşturur, düğüm sayısı arttıkça oransal olarak erir. Dikey ölçeklemede ise üst segmentlere çıkarken fiyat orantısız yükselir; iki orta makine çoğu zaman bir büyük makineden ucuza gelir.

Otomatik ölçekleme yatay ölçeklemenin yerine geçer mi#

Otomatik ölçekleme yatay ölçeklemenin yerine geçmez, onun otomatikleştirilmiş hâlidir. Yani önce uygulamanın yatay ölçeklenebilir, yani durumsuz olması gerekir; ancak ondan sonra düğüm sayısını yüke göre otomatik ayarlayabilirsin. Durumsuz olmayan bir uygulamada otomatik ölçekleme yalnızca sorunları rastgele zamanlarda ortaya çıkarır.

Veritabanını da yatay ölçekleyebilir miyim#

Okuma tarafını görece kolay ölçeklersin: bir veya daha fazla okuma replikası ekleyip okuma sorgularını oraya yönlendirirsin. Yazma tarafı ise zordur; tek birincil düğüm modelinde yazma kapasitesi o düğümün sınırıdır. Bunu aşmanın yolu parçalama (sharding) ya da yazma yükünü azaltacak tasarım değişiklikleridir. Çoğu proje için doğru sıra önce sorgu iyileştirme, sonra replika, en son parçalamadır.

Konteyner kullanmak ölçeklemeyi kolaylaştırır mı#

Kolaylaştırır ama sihirli değildir. Konteynerler dağıtımı tekrarlanabilir kıldığı ve yeni bir düğümü saniyeler içinde ayağa kaldırdığı için yatay ölçeklemenin operasyon tarafını ciddi biçimde basitleştirir. Ancak uygulaman durum tutuyorsa konteynere almak bunu düzeltmez; hatta konteynerlerin geçici dosya sistemi yüzünden sorunu daha görünür hâle getirir.

Kapanış#

Yatay mı dikey mi sorusunun tek bir doğru cevabı yok, ama sağlıklı bir sıralaması var: önce darboğazı ölç, kolay kazanç varsa dikey büyüyerek zaman satın al, bu zamanı uygulamayı durumsuzlaştırmak için kullan ve erişilebilirlik gereksinimin ortaya çıktığında yatay geç. Aklında kalması gereken üç şey: kaynak eklemeden önce ölç, yatay ölçeklemenin ön koşulu durumsuzluktur ve web katmanını ölçeklerken veritabanı planını yapmayı unutma.

Bu geçişi planlarken donanım tarafını bize bırakabilirsin: sabit yükler için VDS, dalgalı yükler için esnek kaynaklı bulut sunucu, tek makinenin sınırlarını gerçekten zorladığın noktada dedicated sunucu seçenekleri mevcut. Kurulum, izleme ve düğüm ekleme işlerini kendin üstlenmek istemiyorsan sunucu yönetimi hizmetimiz bu adımların tamamını devralır.