İki Yolla Daha Fazla Yük Taşıma
Hoşgeldin
Bir hizmetin yük altında ezilmeye başladığında, bir operatör iki seçenekten birini seçmek zorunda kalır. Mevcut makineyi büyütmek (daha fazla CPU, daha fazla RAM, daha hızlı diskler). Veya aynı işi yapan daha fazla makine eklemek.
İlk yol vertical scaling (yukarı ölçme) olarak adlandırılır. İkincisi horizontal scaling (dışa ölçme) olarak adlandırılır.
Bu ders, hemen hemen her modern web mimarisinin neden horisontal'ı seçtiğini ve bu seçim için yükün özniteliğinin ne olduğunu öğretir. Cevap, bir kelime içinde saklı: durum.
Bitirince anlamanız gerekenler:
- Vertical vs horizontal ölçme arasındaki maliyet eğrileri ve her birinin hangi durumlarda uygun olduğu
- 'stateful' ve 'stateless' terimlerinin pratikte ne anlama geldiği ve birinin ucuzca katlanmasının neden olduğu
- Bir kopya filosunun beklenen ve patlama sırasında boyutunu belirleyen matematik
- Bir katmanın kuyruklama bunalımından önce çökmemesi için gereken başlık kuralı
- Durumun nerede oturması gerektiğini (hiç ortadan kaybolmaz) ve ölçülen katmanlardan dışarı itmek için ne yapmak gerektiğini
Neden Horisontal Geçişi Bir Sınırın Ötesinde Kazanır
Dikey Ölçme: Bir Büyük Kutu
Avantajlar: basit. Hiç kod değişikliği. Hiç koordinasyon. Aynı süreç şimdi daha fazla CPU'ya sahip.
Savlar: tavan. En büyük ticari olarak mevcut VM'nin sınırlı RAM ve çekirdekleri vardır. Üstte, para daha fazla başlık alamaz. Kostenin süperlineer olarak pastın bir sağlayıcının sunumunda geçer. Bir makinanın başarısız olması hizmeti tamamen durdurur.
Horisontal Ölçme: Küçük Kutular
Avantajlar: tavan yok (paylaşıma ve koordinasyona kadar olan isteğinize bağlı). Kapasite, kopya sayısına lineer olarak eklenir, öngörülebilir bir şekilde. Bir kopya başarısız olursa, kapasitenin %1/N'sini değil, %100'ini kaldırır.
Savlar: yükün desteklemesi gereklidir. Bazı iş yükleri (bir büyük veri tabanı, canlı oturumları koruyan stateful bir oyun sunucusu) horisontal ölçmeye karşı direnç gösterir. Koordinasyon ve yük dağıtımı, operasyonel endişeler haline gelir.
Kesişim: herhangi bir makine hatası dayanmak için hizmetin en az iki makine üzerinde çalışması gerekir. İki makineyi kabul ettikten sonra, zaten yatay ölçeklendirme seçtiniz. Oradan, soru 'mi yapmalıyım?' değil, 'önümüzdeki kopyayı ne kadar ucuz bir şekilde ekleyebiliriz?'
Ana etkinleyici: makine üzerinde kendi itself'te tutulan hiçbir istek durumu olmayan bir yük. Sonra herhangi bir kopya herhangi bir isteği cevaplayabilir ve bir kopya eklemek kapasite eklerken koordinasyon gerektirmez.
Olağanüstü vs Durumsuz - Uygulama
Durum Yok Olmaz, Sadece Yer Değiştirir
Durumsuz bileşen: kaybedilirse davranış değiştirecek bilgileri tutan. Kullanıcı hesaplarını tutan bir veri tabanı. Oturum belirteçlerini tutan bir önbellek. Uzun süreli akışlı bir kullanıcıya özel bir bağlantı sabitleme çalışan bir işçi.
Durumsuz bileşen: kaybedilirse önemli olabilecek bilgileri tutmayan. Bir isteği okuyan bir web katmanı, bir veri tabanını sorgulayan, bir yanıt döndüren. Her istek tek başına durur; katmanlar arasında hiçbir şey hatırlanmaz.
Ana fikir: bir sistematik durum yok olur. Bir tabana (bir veri tabanı, Redis kümesi, nesne deposu) taşınır. Bu katmanların trafiği karşılayabileceği şekilde stateless olabilecek katmanlar stateless olabilir ve stateless katmanlar yatay olarak ölçeklendirilebilir çünkü herhangi bir kopya herhangi bir isteği cevaplayabilir.
Uygulama testi: bu katmanda bir süreçte rastgele bir işlem öldürülür ve yeniden başlatılırsa, bir kullanıcı yanlış bir yanıt veya kaybedilen bir oturum yaşar mı? Eğer evet, durum tutuyor demektir. Eğer hayır, durum tutmuyor demektir.
Örnekler
- Python web süreci: isteği okuyan, Postgres'i sorgulayan, JSON döndüren: durumsuz. Durum Postgres'te yaşamaktadır.
- Python web süreci: yerel bellekte kullanıcı alışveriş sepetlerini tutan: durumsal. Süreci öldürmek sepetleri kaybettirir.
- WebSocket sunucusu: chat kullanıcılarına açık bağlantıları tutan: durumsal bağlantısallaşma açısından. Süreci öldürmek bağlantıları düşürür; istemciler yeniden bağlanmalıdır. Sıklıkla bu durumlar da dikkatli oturumlar, konsantre işleme ile yatay olarak ölçeklendirilebilir.
- Redis örnekleme Postgres: Depolama için stateful, ancak cache atışları tolerablese kabul edilebilir. Bir kopya başarısız olursa, bu bir cache atışı, veri kaybı değil.
Yatay ölçeklendirme tasarımı = ölçeklenecek katmanın dışına state çıkarmak.
Şüpheli Katmanı Düzenlik Yap
Bir takım, 6 arka uç VM'si arkasında bir öneri API'si çalıştırır. Uygulama: İstekten bir kullanıcı ID'si okur, kullanıcı'nın son aktivitesini Postgres'ten alır, bir skorlama algoritması çalıştırır ve bir liste ile kullanıcıyı öneren maddeler döndürür. İki standart dışı davranış:
- Uygulama, bir kullanıcı için ilk talep üzerine 'son kullanıcı aktivitesi' cache'ini process belleğinde tutar ve sonrasında taleplerde yeniden kullanır.
- Uygulama, yapıcı oturumlar kullanır: Bir kullanıcı VM #3'e ulaştığında, tüm sonraki talepleri VM #3'e (proxy, bir çerez üzerinde yapıcı yönlendirme yapılandırılmıştır) gider.
Kopya Formülü
En Basit Kapasite Formülü
Bir katman stateless hale geldikçe, boyutlandırmak artık aritmetik olur. Sıkıştırılmış yükün sürekli aynı hızda gelip gitmesi ve patlama için ek alan olması gereken kopyalar yeterince fazla olmalıdır.
Formül:
kopyalar = ⌈ (zirve_yük × patlama_faktörü) / her_kopya_becerisi ⌉ + ek_becerilik
Nerde:
- zirve_yük: normal işlem süresince beklenen en yüksek sürekli istek/saniye
- patlama_faktörü: zirve üzerinde kisa patlamaları (beklenen trafik için 1,5x-2x, virüs/vahim/salgın için 3x veya daha fazla)
- her_kopya_becerisi: uygun gecikme ve kullanım oranı ile bir kopyanın ele alabileceği istek/saniye (genellikle %70 CPU, sınırlı kalmak için)
- ek_becerilik: birkaç kopya başarısız olursa katmanı çökertmemesi için ek kopyalar (küçük filo için 1-2 kopya, daha büyük olanlar için %10-20)
Örnek Çalışma: bir arka uç, her kopyada 100 istek/saniye ve %70 CPU kullanımıyla çalışır. Zirve yükü 600 istek/saniye. Geçerli 2x dalgalanmalara izin veriyorsunuz. 2 kopya başarısızlığı yaşamanızı istiyor.
kopyalar = ⌈ (600 × 2) / 100 ⌉ + 2 = 12 + 2 = 14 kopya
%80 Kurallı
Kopya başına kapasite değil sıcaklık noktasıdır. %70-80'de CPU kullanımını ölçün, asla %100'de değil.
Yaklaşık %80 kullanımın ötesinde, kuyrukların eğimi hızla artar: %60 kullanımında 10 ms'de kuyruk, %90 kullanımında 80 ms'de kuyruk. İlk olarak gecikme, değilse işleme hızı kırılır. (Eşsiz ve durumsuz yatay ölçeklendirme dersinin arkasındaki ders, bu eğimi matematiksel olarak çıkarır.)
Otomatik Ölçeklendirme vs. Statik Tahsis
Statik: zirve yükü × dalgalanma kalmışını hesaplayın ve düşük kullanım sırasında maliyeti kabul edin.
Otomatik Ölçeklendirme: gözlemlediği kullanım, hedef gecikme veya kuyruk derinliği temelinde bir kontrolör ek ve kaldırır.
Öneri: Otomatik Ölçeklendirme ipucu: Soğuk başlatma süresi önemlidir. Eğer yeni bir kopya 2 dakikayı beklemektedir, otomatik ölçeklendirme 30 saniyelik bir dalgalanmaya yanıt veremez. Yetkin bir otomatik ölçeklendirme, ölçeklendirme artırma eşiğinin hemen altında önceden hazırlanmış kopyalar havuzu tutar.
Yeni Bir Hizmet için Bir Filo Boyutlandırma
Ekibiniz, video metadata API'si (video metadata API'si) başlatmayı planlıyor. Performans testleri, bir kopyanın 250 istek/saniye, %70 CPU ve 50 ms p99 gecikme oranıyla işlediğini gösteriyor. Pazarlama, zirve yükünün prime-time saatlerinde 4.000 istek/saniye olacağını tahmin ediyor. Planlanan bir promosyon etkinliği, 3x zirve yüküne kısa süreli dalgalanmalara neden olabilir. 3 kopya başarısızlığı yaşamanızı istiyor ve hayatta kalanların %80'inden fazla kullanım sağlamıyorsunuz.
Soğuk Başlatma, Yavaş Akış ve Diğer Gerçek Sınırlandırmalar
Gerçek Filolarda Gerçek Sınırlandırmalar Var
Formül, kopyaların anında göründüğünü, trafiği anında kabul ettiğini ve trafiği anında terk ettiğini varsayar. Bu, üretimde geçerli değildir.
Soğuk başlangıç: yeni bir kopya, işletim sistemi başlatmak, süreci başlatmak, yapılandırmayı yüklemek, sıcak önbellekleri sarmak ve sağlık kontrollerini geçirmek zorundadır. Bu süreler, 5 saniye (kapsül yeniden başlatma) ile 5 dakikalık (tam VM başlangıç + görüntü çekme) arasında değişebilir. Otomatik ölçeklendirme, bu gecikme süresinden daha kısa olan patlamalara yanıt cannot respond.
Yavaş akış: bir kopya, havuzdan kaldırılırken, uçtan uca isteklerin tamamlanması için zaman gerekiyor. Aksi takdirde kullanıcılar kesik yanıt alır. Geri prosti destekler (yeni istekler kabul etmeyi durdur, aktif olanları tamamlamak için) ama bu saniyeler ile dakikalık bir süre alır.
Isıtılmış havuz: üretim filoları, trafiği almak üzere hazır durumda bekleyen ama pasif olarak sağlanan kopyalar havuzu korur. Sürekli küçük bir maliyet karşılığında hızlı bir artış tepkisi sağlar.
Akış indirgeme vs. anında öldürme: adil bir kapanış önemli. Bir SIGTERM, akış indirme başlatır ve SIGKILL'e kıyasla daha uzun sürer ama kullanıcı isteklerini bölmeyecektir.
Sağlık kontrol penceresi: yeni başlayan bir kopya, ilk sağlık kontrolünü geçebilir ve veri bağlantı havuzunun ısınmadan önce; proxy, gerçek trafiği gönderir ve ilk düzine istek yavaş olur. Sağlık kontrollerini, sadece süreci canlılık test etmek için değil, gerçek yolda test etmek için ayarlayın.
Bakışlı kriptleşme: even nominally stateless katmanlar, zamanla kriptleşmeye başlar (CDN önbellekleri, DNS çözücü önbellekleri, bağlantı havuzları). 'İdentiği kopyalar' olup olmadığına bakılmaksızın farklı şekilde davrandıkları için şüphelenin.
Isıtılmış Havuz veya Reaktif Otomatik Ölçeklendirme?
Video meta veri API'niz (önceki soru olan aynı API, sürekli yük için 51 kopya ile boyutlandırılmıştır ve patlama sırasında normal yükün 5 katına çıkar) yeni bir virüs video yüklemesiyle 30 saniye süren 5x normal yük patlaması yaşar. Otomatik ölçeklendirme şu anda soğuk (görüntü çekme + ısınma) nedeniyle 90 saniye sürer. 90 saniye arasındaki süre zarfında, gecikme önemli ölçüde artar ve bazı istekler zaman aşımına uğrar.
Kısıtlamalar Altında Devletsiz Bir Katman Tasarla
Synthesis
You have learned why horizontal scaling wins past a small threshold, what state means in practice, how to size a fleet under expected & surge load, & where horizontal scaling breaks at the edges.
Apply all four.
Design a backend tier for feed.example.com, a social-feed API. Constraints: per-replica capacity 200 req/s at 70% CPU; expected peak load 1500 req/s; surge factor 2.5x (occasional trending stories); survive 2 simultaneous replica failures; cold-start time 60 seconds; bursts can last 45 seconds; budget allows some idle capacity but not 2.5x permanent provisioning.
Where This Course Goes Next
Where This Course Goes Next
You now have a working mental model of a stateless tier: why it scales, how to size it, what breaks at its edges, & where state must move when you push it out of the layer that needs to grow.
The next lesson in this course (cs_distsys_ingress_egress_separation) tackles a subtler problem: even a perfectly sized stateless tier can fail in surprising ways when incoming & outgoing traffic share the same network path. The classic example involves a proxy trying to connect to itself; the fix involves splitting one tier into two with different responsibilities.
Companion lesson: geometry_of_stateless_horizontal_scaling derives the queueing curve, Little's Law applied to a replica fleet, & the geometric meaning of the 80% utilization knee.
Well done. Onward.