Dikey ölçekleme genelde sadece CPU/RAM eklemektir. Yatay ölçekleme koordinasyon, parçalama, tutarlılık ve daha fazla operasyonel iş gerektirir—neden daha zor olduğuna dair açıklama.
Ölçeklendirme, “daha fazlasını çökmeden karşılamak” demektir. Bu “daha fazla” şunlar olabilir:
İnsanlar ölçeklendirmeden bahsederken genelde bunlardan bir veya birkaçını iyileştirmeye çalışırlar:
Bunun çoğu tek temaya dayanır: dikey ölçekleme “tek sistem” hissini korur, oysa yatay ölçekleme sisteminizi bağımsız makinelerden oluşan koordineli bir gruba çevirir—ve işte zorluklar koordinasyonda patlar.
Dikey ölçekleme, bir makineyi daha güçlü hale getirmek demektir. Temel mimariyi aynı tutarsınız ama sunucuyu (veya VM'i) yükseltirsiniz: daha fazla CPU çekirdeği, daha fazla RAM, daha hızlı diskler, daha yüksek ağ bant genişliği.
Bunu daha büyük bir kamyon almak gibi düşünün: hâlâ tek bir sürücü ve tek bir araç var, sadece daha fazlasını taşıyor.
Yatay ölçekleme, daha fazla makine veya örnek eklemek ve işi bunlar arasında bölmek demektir—genelde bir yük dengeleyicinin arkasında. Tek bir daha güçlü sunucu yerine, birlikte çalışan birkaç sunucu çalıştırırsınız.
Bu, daha fazla kamyon kullanmak gibidir: genel olarak daha fazla yük taşıyabilirsiniz ama artık zamanlama, rota ve koordinasyonla ilgilenmeniz gerekir.
Yaygın tetikleyiciler:
Takımlar genellikle önce dikey ölçeklemeyi dener çünkü hızlıdır (kutu yükseltilir), sonra tek bir makine limitlere ulaştığında veya daha yüksek kullanılabilirlik gerektiğinde yataya geçerler. Olgun mimariler genelde iki yöntemi de karıştırır: darboğaza bağlı olarak hem daha büyük düğümler hem daha fazla düğüm kullanılır.
Dikey ölçekleme caziptir çünkü sistemi tek bir yerde tutar. Tek bir düğümde genelde bellek ve yerel durum için tek bir gerçek kaynak vardır. Bir süreç in-memory cache'e, iş kuyruğuna, oturum deposuna (oturumlar bellekteyse) ve geçici dosyalara sahip olur.
Tek bir sunucuda çoğu operasyon basittir çünkü düğümler arası koordinasyon azdır veya yoktur:
Scale up yaptığınızda tanıdık kolları çekersiniz: CPU/RAM eklemek, daha hızlı depolama kullanmak, indeksleri iyileştirmek, sorguları ve yapılandırmaları ayarlamak. Verinin nasıl dağıtılacağını veya birden çok düğümün “sonraki adımda ne yapacağı” konusunda yeniden tasarım yapmanız gerekmez.
Dikey ölçekleme “bedava” değildir—sadece karmaşıklığı sınırlı tutar.
En nihayetinde sınırlarına ulaşırsınız: kiralayabileceğiniz en büyük örnek, azalan verimlilik veya üst kademede dik bir maliyet eğrisi. Ayrıca tek bir büyük makinenin arızalanması veya bakım gerektirmesi durumunda daha fazla kesinti riski taşır; yedeklilik eklemediyseniz sistemin büyük bir kısmı etkilenir.
Yatay ölçeklediğinizde sadece “daha fazla sunucu” elde etmezsiniz. Her biri bağımsız aktör olan daha fazla düğüm elde edersiniz ve bunların hangi işten kim sorumlu olduğu, ne zaman ve hangi veriyi kullanarak karar verecekleri konusunda anlaşmaları gerekir.
Tek bir makinede koordinasyon genelde örtük olur: tek bir bellek alanı, tek bir süreç, durum için bakılacak tek yer. Çok makinede koordinasyon tasarlamanız gereken bir özellik haline gelir.
Yaygın araçlar ve desenler:
Koordinasyon hataları nadiren temiz çöküşler gibi görünür. Daha sık gördükleriniz:
Bu sorunlar genelde gerçek yük altında, dağıtımlarda veya kısmi arızalar olduğunda (bir düğüm yavaş, bir switch paket düşürüyor, bir bölge kısaca erişilemez) ortaya çıkar. Sistem çoğunlukla iyi görünür—ta ki stres altında çökene kadar.
Yatay ölçeklediğinizde genelde tüm veriyi tek yerde tutamazsınız. Veriyi makineler arasında bölersiniz (shard'lar) ki birden fazla düğüm paralel olarak saklayıp hizmet verebilsin. Bu bölme karmaşıklığın başladığı yerdir: her okuma ve yazma “bu kayıt hangi shard'ta?” sorusuna bağlıdır.
Range partitioning veriyi sıralı bir anahtara göre gruplandırır (ör. kullanıcılar A–F shard 1, G–M shard 2). Bu sezgiseldir ve aralık sorgularını iyi destekler (“geçen haftanın siparişleri”). Dezavantajı dengesiz yük: bir aralık popüler olursa o shard darboğaz olur.
Hash partitioning bir anahtarı hash fonksiyonundan geçirir ve sonuçları shard'lara dağıtır. Trafiği daha eşit dağıtır, ama ilişkili kayıtlar dağılır, bu da aralık sorgularını zorlaştırır.
Node ekleyip onu kullanmak istediğinizde veri taşınmalıdır. Bir node'u kaldırdığınızda (planlı veya arıza nedeniyle) diğer shard'ların üzerine geçmesi gerekir. Yeniden dengeleme büyük transferler, cache ısınmaları ve geçici performans düşüşleri tetikleyebilir. Taşıma sırasında eski okumalardan ve yanlış yönlendirilmiş yazılardan kaçınmanız gerekir.
Hashleme olsa bile gerçek trafik eşit değildir. Bir ünlü hesap, popüler bir ürün veya zamana bağlı erişim desenleri okumaları/yazmaları bir shard üzerinde yoğunlaştırabilir. Tek bir sıcak shard tüm sistemin verimini sınırlayabilir.
Sharding sürekli sorumluluklar getirir: yönlendirme kurallarını sürdürme, migration'lar çalıştırma, şema değişikliklerinden sonra backfill yapma ve bölme/birleştirme planları hazırlama—bunların hepsi müşterileri bozmadan yapılmalıdır.
Yatay ölçeklediğinizde sadece daha fazla sunucu eklemezsiniz—uygulamanızın kopyalarını eklersiniz. Zor olan kısım durumtur: uygulamanızın istekler arasında veya iş sürerken “hatırladığı” her şey.
Bir kullanıcı Server A'da giriş yapıp sonraki isteği Server B'ye giderse, B kullanıcının kim olduğunu biliyor mu?
Redis veya bir DB) herhangi bir sunucunun isteği işleyebilmesini sağlar. Daha sağlam ama ek maliyet ve bağımlılık getirir. Oturum deposu yavaşlarsa tüm uygulama yavaş hissedilir.Cache'ler hız sağlar, ama birden çok sunucu birden çok cache demektir. Şimdi uğraşacağınız konular:
Birden çok worker varken, işler tekrarlanabilir. Genelde bir kuyruk, lease/kilit veya idempotent iş mantığı gerekir ki “fatura gönder” veya “kartı çek” iki kez gerçekleşmesin—özellikle retry ve yeniden başlatmalar sırasında.
Tek bir düğümde (veya tek bir primary DB'de) genelde net bir “gerçek kaynak” vardır. Yatay ölçeklendiğinde veri ve istekler makineler arasında yayılır ve herkesin senkron kalması sürekli bir endişe haline gelir.
Sonunda tutarlılık genelde daha hızlı ve daha ucuzdur, ancak beklenmedik kenar durumlar getirir.
Yaygın sorunlar:
Arızaları ortadan kaldıramazsınız ama bunlara hazırlanabilirsiniz:
Birden fazla servisi kapsayan transaction (sipariş + stok + ödeme) birçok sistemin aynı anda anlaşmasını gerektirir. Bir adım ortasında başarısız olursa telafi edici işlemler ve dikkatli kayıt tutma gerekir. Ağ ve düğüm arızaları bağımsız iken klasik “hepsi ya da hiçbiri” davranışı uygulamak zordur.
Doğruluğun zorunlu olduğu konularda güçlü tutarlılık kullanın: ödeme işlemleri, hesap bakiyeleri, stok sayımları, koltuk rezervasyonları. Daha az kritik veriler (analitik, öneriler) için genelde sonunda tutarlılık kabul edilebilir.
Dikey ölçeklemede birçok çağrı aynı süreç içinde fonksiyon çağrısıdır: hızlı ve öngörülebilir. Yatay ölçeklemede aynı etkileşim ağ çağrısına dönüşür—bu da gecikme, jitter ve kodun ele alması gereken yeni hata modları ekler.
Ağ çağrılarının sabit maliyeti (serileştirme, kuyruklama, hoplar) ve değişken maliyeti (tıkanma, routing, noisy neighbor) vardır. Ortalama gecikme iyi olsa bile tail latency (en yavaş %1–5) kullanıcı deneyimini domine edebilir çünkü tek bir yavaş bağımlılık tüm isteği yavaşlatır.
Bant genişliği ve paket kaybı da kısıtlayıcı hale gelir: yüksek istek oranlarında “küçük” yükler birikir ve yeniden gönderimler sessizce yükü artırır.
Zaman aşımı olmazsa yavaş çağrılar birikir ve thread'ler meşgul kalır. Zaman aşımı ve retry ile kurtarabilirsiniz—ta ki retry'ler yükü artırıp problemi büyütene kadar.
Yaygın bir arıza deseni retry fırtınasıdır: bir backend yavaşlar, istemciler zaman aşımı yaşar ve retry yapar, retry'ler yükü artırır, backend daha da yavaşlar.
Daha güvenli retry'ler genelde şunları gerektirir:
Birden çok örnekle istemcilerin isteği nereye göndereceğini bilmesi gerekir—yük dengeleyici aracılığıyla veya servis keşfi + istemci tarafı dengeleme ile. Her iki durumda da hareketli parçalar eklenir: sağlık kontrolleri, bağlantı boşaltma (drain), dengesiz trafik dağılımı ve yarım bozuk örneğe yönlendirme riski.
Aşırı yükün yayılmasını önlemek için backpressure gerekir: sınırlı kuyruklar, circuit breaker'lar ve rate limiting. Amaç, küçük bir yavaşlamanın sistem çapında bir olaya dönüşmesini önleyip hızlı ve öngörülebilir şekilde başarısız olmaktır.
Dikey ölçekleme genelde tek bir büyük makinenin çökmesiyle sonuçlanır: etki nettir. Yatay ölçekleme matematiği değiştirir. Birçok düğüm olduğunda bazı makinelerin sağlıksız olması normaldir; sistem “çalışıyor” ama kullanıcılar yine de hatalar, yavaş sayfalar veya tutarsız davranışlar görür. Buna kısmi arıza denir ve ölçek için tasarlanması gereken varsayılan durum haline gelir.
Yatay kurulumda servisler diğer servislere bağımlıdır: veritabanları, cache'ler, kuyruklar, downstream API'lar. Küçük bir sorun şu şekilde yayılabilir:
Kuyruklar dolar, cache'ler ıskalar ve downstream API'lar ezilir.
Kısmi arızalardan kurtulmak için sistemler yedeklilik ekler:
Bu kullanılabilirliği artırır ama split-brain, eski kopyalar ve quorum ulaşılamadığında ne yapılacağı gibi kenar durumlar yaratır.
Yaygın desenler:
Tek bir makinede “sistem hikâyesi” tek yerde yaşar: tek bir log seti, tek bir CPU grafiği, incelenecek tek bir süreç. Yatay ölçeklemede hikâye dağılır.
Her ek düğüm bir log, metric ve trace akışı daha ekler. Zor olan veri toplamak değil—bunları ilişkilendirmektir. Bir checkout hatası bir web düğümünde başlayabilir, iki servisi çağırabilir, bir cache'e takılabilir ve belirli bir shard'dan okuma yaparken farklı yerlerde ve zaman çizelgelerinde iz bırakır.
Sorunlar seçici hale gelir: bir düğüm yanlış konfigüre, bir shard sıcak, bir bölge daha yüksek gecikmeye sahip olabilir. Hata ayıklama rastgelemiş gibi gelebilir çünkü çoğunlukla her şey normal görünür.
Dağıtık izleme, bir isteğe takip numarası takmak gibidir. Correlation ID o takip numarasıdır. Bunu servisler arasında geçirip loglara dahil edersiniz, böylece bir ID alıp isteğin uçtan uca yolculuğunu görebilirsiniz.
Daha fazla bileşen genelde daha fazla alarm demektir. Ayarlama yapılmazsa ekipler alarm yorgunluğu yaşar. Eyleme dönüştürülebilir alarmlar hedefleyin:
Kapasite sorunları genelde arızalardan önce görünür. CPU, bellek, kuyruk derinliği ve bağlantı havuzu kullanımı gibi doygunluk sinyallerini izleyin. Doygunluk yalnızca bazı düğümlerde görünüyorsa, dengeleme, sharding veya konfigürasyon sürüklenmesi şüphelenin.
Yatay ölçeklemede deploy artık “bir kutuyu değiştir” değildir. Birçok makinede değişiklikleri koordine etmek ve hizmeti erişilebilir tutmak gerekir.
Yatay dağıtımlar genelde rolling update (düğümleri kademeli değiştirme), canary (trafğin küçük bir yüzdesini yeni versiyona yönlendirme) veya blue/green (iki tam ortam arasında geçiş) kullanır. Bunlar blast radius'u azaltır ama gereksinimler ekler: trafik kaydırma, sağlık kontrolleri, bağlantı boşaltma ve “ilerleme için yeterince iyi” tanımı.
Her kademeli deploy sırasında eski ve yeni sürümler yan yana çalışır. Bu versiyon karışımı şu gereksinimleri doğurur:
API'lar geriye ve ileriye uyumlu olmalı, sadece doğru olmak yetmez. Veritabanı şema değişiklikleri mümkün olduğunca ekleyici olmalı (önce nullable kolon ekleyip sonra required yapmak gibi). Mesaj formatları versiyonlanmalı ki tüketiciler hem eski hem yeni etkinlikleri okuyabilsin.
Kodu geri almak kolaydır; veriyi geri almak zor. Bir migration alanları düşürür veya yeniden yazar ise eski kod çöker veya kayıtları yanlış işler. “Genişlet/sözleş” migration'ları yardımcı olur: önce her iki şemayı destekleyen kod deploy edilir, veri migrate edilir, sonra eski yollar kaldırılır.
Birçok düğümde konfigürasyon yönetimi deploy'un parçası haline gelir. Eski konfigürasyon, yanlış feature flag veya süresi dolmuş kimlik bilgileri tek bir düğümü bozabilir ve tekrarlanması zor hatalar yaratabilir.
Yatay ölçekleme kağıt üzerinde daha ucuz görünebilir: birçok küçük örnek, her biri düşük saatlik fiyat. Ama toplam maliyet sadece hesaplama değildir. Düğümler eklemek daha fazla ağ, daha fazla izleme, daha fazla koordinasyon ve makineleri tutarlı tutmak için daha fazla zaman demektir.
Dikey ölçekleme maliyeti birkaç makinede yoğunlaşır—genelde yamalar için daha az host, çalıştırılacak daha az ajan, gönderilecek daha az log, çekilecek daha az metrik olur.
Yatayda birim başına fiyat daha düşük olabilir ama sıklıkla ödersiniz:
Patlamaları güvenle karşılamak için dağıtık sistemler sıklıkla düşük dolulukla çalışır. Web, worker, DB, cache gibi katmanlarda baş boşluk tutarsınız; bu da onlarca ya da yüzlerce örnekte boşa ödenen kapasite anlamına gelebilir.
Yatay ölçek ekip üzerindeki nöbet yükünü artırır ve olgun araçlar gerektirir: alarm ayarı, runbook'lar, tatbikatlar ve eğitim. Takımlar ayrıca sahiplik sınırları (hangi servisi kim sahiplenir?) ve olay koordinasyonu için zaman harcar.
Sonuç: “birim başına daha ucuz” olsa bile insanlar zamanı, operasyonel risk ve birçok makineyi tek bir sistem gibi davranır hale getirme işi dahil edildiğinde toplamda daha pahalı olabilir.
Dikey mi yoksa yatay mı ölçekleyeceğinize karar vermek sadece fiyata bağlı değildir. İş yükünün şekline ve ekibinizin hangi operasyonel karmaşıklığı kaldırabileceğine bağlıdır.
İş yükü ile başlayın:
Yaygın mantıklı yol:
Birçok ekip veritabanını dikey (veya hafifçe kümeleşmiş) tutarken stateless uygulama katmanını yatay ölçeklendirir. Bu, sharding acısını sınırlarken web kapasitesini hızlıca artırmanızı sağlar.
Sağlam izleme ve alarmlarınız, test edilmiş failover, yük testleri ve güvenli geri alımlarla tekrarlanabilir dağıtımlarınız varsa yataya geçmeye yakınsınız.
Çok ölçeklenmenin acısı sadece “mimari” değildir—operasyon döngüsüdür: güvenli iterasyon, güvenilir dağıtım ve plan işe yaramadığında hızlı geri alma.
Web, backend veya mobil sistemler inşa ediyorsanız ve kontrolü kaybetmeden hızlı hareket etmek istiyorsanız, Koder.ai size bu kararları verirken prototip oluşturup daha hızlı gönderme konusunda yardımcı olabilir. Koder.ai, altında ajan tabanlı bir mimariyle sohbet üzerinden uygulama inşa ettiğiniz bir vibe-coding platformudur. Pratikte bu şunları yapmanızı sağlar:
Koder.ai AWS üzerinde küresel olarak çalıştığı için, çok-bölgeli veya bölge bazlı dağıtımlar gerektiğinde gecikme ve veri aktarım kısıtlarını karşılayacak konuşlandırmaları da destekleyebilir.
Dikey ölçekleme, tek bir makineyi daha güçlü hale getirmek (daha fazla CPU/RAM/daha hızlı disk). Yatay ölçekleme ise daha fazla makine eklemek ve işi bunlara dağıtmaktır.
Dikey genellikle “tek bir sistem” gibi davranmaya devam ettiği için daha basit hissedilir; yatay ise birden çok sistemin koordinasyonunu gerektirir ve bu nedenle daha karmaşıktır.
Çünkü birden çok düğüm olduğunda açıkça koordinasyon gerekir:
Tek bir makine bu dağıtık sistem problemlerinin çoğundan otomatik olarak kaçınır.
Birden çok makinenin tek bir sistem gibi davranmasını sağlamak için harcanan zaman ve mantıktır:
Her düğüm basit olsa bile, yük altında ve arıza durumlarında sistem davranışını anlamak zorlaşır.
Sharding (veri parçalama), veriyi düğümler arasında bölerek hiçbir makinenin her şeyi saklamasını engeller. Zor olan noktalar:
Ayrıca operasyonel iş yükünü artırır: migration'lar, backfill'ler, shard haritaları gibi işler gerekir.
Durum (state), uygulamanızın istekler arasında veya iş ilerlerken “hatırladığı” her şeydir (oturumlar, bellek içi cache'ler, geçici dosyalar, iş ilerleme bilgisi).
Yatayda istekler farklı sunuculara gidebileceği için genelde paylaşılan bir durum deposu gerekir (ör. Redis/DB) veya yapışkan (sticky) oturumlar gibi ödünler kabul edilir.
Birden çok worker aynı işi alabilirse, faturayı iki kez göndermek veya çift e-posta yollamak gibi durumlar olabilir.
Yaygın çözümler:
Güçlü tutarlılık, bir yazma başarılı olduktan sonra tüm okuyucuların hemen en güncel değeri görmesi; sonunda tutarlılık ise güncellemelerin zaman içinde yayılmasıdır, bu yüzden kısa bir süre eski değerler görülebilir.
Önemli doğruluk gerektiren veriler (ödeme, bakiye, stok) için güçlü tutarlılık; analitik ve öneriler gibi gecikmeye toleransı olan veriler için ise genellikle sonunda tutarlılık yeterlidir.
Dağıtık sistemlerde çağrılar artık ağ üzerinden olur; bu da gecikme, jitter ve yeni hata modları getirir.
Genel olarak gerekli olanlar:
Kısmi arıza, bazı bileşenlerin bozuk veya yavaş olduğu durumdur; sistem “çalışır” görünebilir ama yine de hatalar ve tutarsızlıklar üretir.
Cevaplar arasında replika, quorum, çok-bölge dağıtımı, circuit breaker'lar ve kademeli bozulma (graceful degradation) yer alır, böylece sorunlar zincirleme şekilde yayılmaz.
Çok sayıda sunucuda kanıtlar parçalanır: loglar, metrikler ve trace'ler farklı düğümlerdedir.
Pratik adımlar: