czay.devSystem Design: Milyon Kullanıcıya Ölçeklenmek
Bu harita "Kubernetes var, bütçe sınırsız, yine de çöküyor" videosunun devamı. Mimariyi tek bir şemadan ezberlemek yerine, yükün yolunu izleyip her katmanın hangi sorunu çözdüğünü gösteriyor.
Sıra bilerek şöyle: önce sorunu koy, sonra kapıda koru, okumayı hafiflet, yazmayı sıraya al, en sonda dayanıklı ve görünür kıl. Her adımda bir öncekinin yetmediği yer var.
- Temelİşe girmeden önce sağlam bilinmeli
- İyi olurİlanlarda sık geçiyor, elini güçlendirir
- Sonraİşe girdikten sonra, ihtiyaç doğunca
Bir konuya tıkla: ne bilmen gerektiği ve kaynaklar açılır.
- 01
Neden çöküyor?
Sunucuyu çoğaltmak yetmiyor: asıl darboğaz hep ortak olan yerde. Önce sorunu doğru koy.
- 02
Kapıda koru
Yükün veritabanına ulaşmadan önce kesilmesi, ona yetişmeye çalışmaktan ucuzdur.
- 03
Okumayı hafiflet
Trafiğin çoğu okuma. Aynı veriyi tekrar tekrar veritabanından çekmeyi bırak.
- 04
Yazmayı sıraya al
Ağır işi doğrudan veritabanına yazma; kuyruğa al, sindire sindire işle.
- 05
Dayanıklı ve görünür kıl
Bir şey kesinlikle bozulacak. Önemli olan, bozulduğunda hepsinin birden düşmemesi ve neyin bozulduğunu görebilmen.
Konu konu
Haritadaki her konunun açıklaması, bilmen gerekenler ve kaynaklar — tek listede.
01Neden çöküyor?
Ölçeklemenin iki yolu· Temel
Dikey ölçekleme makineyi büyütür, yatay ölçekleme sayısını artırır. Uygulama sunucuları yatay ölçeklenir; veritabanı ise çoğu zaman ilk tıkanan yer.
Bilmen gerekenler
- Dikey: kolay ama tavanı var
- Yatay: sınırsıza yakın ama durumu (state) paylaşmak zorunda
- Uygulama sunucusunu durumsuz (stateless) tut
Kaynaklar
Durumsuz uygulama sunucusu· Temel
Oturum ve dosya gibi durumu sunucunun belleğinden çıkarıp dışarı al; böylece her sunucu birbirinin yerine geçebilir.
Bilmen gerekenler
- Oturumu Redis'te ya da imzalı token'da tut
- Dosyayı yerel diske değil nesne depolamaya yaz
Tek hata noktası· İyi olur
Her sunucunun gittiği tek bir veritabanı, ağın ortasında tek bir bileşen: biri düşünce hepsi düşer.
Bilmen gerekenler
- Mimarideki her tek kutuya 'düşerse ne olur?' diye sor
Veritabanı neden tıkanır?· Temel
Bağlantı sayısı, disk ve kilitler sınırlı. Yirmi sunucu aynı anda binlerce yazma gönderince bağlantı limiti dolar ve istekler birbirini bekler.
Bilmen gerekenler
- Bağlantı havuzu (pool) ve bağlantı limiti
- Kilit çekişmesi ve yavaş sorgular
- Tıkanma anında latency bir anda katlanır
Kaynaklar
Bağlantı havuzu· İyi olur
Her istek için yeni bağlantı açmak yerine sınırlı sayıda bağlantıyı paylaşmak; veritabanını bağlantı fırtınasından korur.
Bilmen gerekenler
- PgBouncer gibi bir havuz yöneticisi
- Sunucu sayısı × havuz boyutu = veritabanına gelen bağlantı
02Kapıda koru
Load Balancer· Temel
Gelen trafiği sağlıklı sunucular arasında dağıtır, düşen sunucuyu devreden çıkarır. Tek bir giriş noktası olmasa yatay ölçeklemenin anlamı kalmaz.
Bilmen gerekenler
- Round-robin, en az bağlantı gibi algoritmalar
- Sağlık kontrolü (health check)
- L4 ve L7 farkı
Kaynaklar
Sağlık kontrolü· İyi olur
Yük dengeleyici sağlıksız sunucuya trafik göndermesin diye uygulamanın kendini raporlaması.
Bilmen gerekenler
- Hafif bir /health ucu, veritabanı bağımlılığını ayır
Rate limiting· Temel
Bir istemcinin ya da herkesin saniyede yapabileceği istek sayısını sınırlar; aşırı yük içeri girmeden reddedilir, sistem ayakta kalır.
Bilmen gerekenler
- Token bucket ve sabit pencere
- 429 Too Many Requests + Retry-After
- Kimlik başına ve IP başına sınır
Kaynaklar
Sanal bekleme odası· Sonra
Bilet satışı gibi ani patlamalarda kullanıcıları sıraya alıp sistemi boğmadan içeri sırayla alma.
Bilmen gerekenler
- Reddetmek yerine sıraya almak
CDN ve statik içerik· İyi olur
Görsel, script ve değişmeyen sayfalar kullanıcıya yakın uçlardan sunulur; kaynak sunucuya hiç uğramaz.
Bilmen gerekenler
- Cache-Control başlıkları
- Dinamik sayfayı kısa süreli önbelleğe alma
Kaynaklar
03Okumayı hafiflet
Önbellek (Redis)· Temel
Sık okunan veriyi bellekte tutan hızlı bir katman. Veritabanına giden okumanın büyük kısmını keser; ama yanlış kurulursa kendi sorununu yaratır.
Bilmen gerekenler
- Cache-aside deseni
- TTL (geçerlilik süresi) ve geçersiz kılma
- Önbellek de düşebilir: veritabanı bunu kaldırır mı?
Kaynaklar
Cache-aside deseni· Temel
Önce önbelleğe bak; yoksa veritabanından oku, önbelleğe yaz, öyle dön. En yaygın ve en basit desen.
Bilmen gerekenler
- Okuma yolunda iki adım, yazmada geçersiz kıl
Önbelleği geçersiz kılma· İyi olur
Veri değişince eski kopyayı ne zaman ve nasıl atacağın: bilgisayar biliminin zor sorularından biri.
Bilmen gerekenler
- TTL'e güven, kritik veride yazmada sil
Cache stampede (izdiham)· Temel
Popüler bir anahtarın süresi dolduğu anda yüz binlerce istek önbelleği ıskalayıp aynı anda veritabanına iner. Videonun asıl uyarısı bu.
Bilmen gerekenler
- TTL'e rastgele sapma (jitter) ekle
- Tek uçuş (single-flight): yalnız biri yenilesin
- Süresi dolmuş veriyi yenilenirken sunmak (stale-while-revalidate)
Kaynaklar
TTL jitter· İyi olur
Aynı anda yazılan anahtarlar aynı anda sona ermesin diye süreye küçük rastgele bir fark eklemek.
Bilmen gerekenler
- 3600 sn yerine 3600 ± %10
Tek uçuş / kilit· İyi olur
Aynı anahtar için yalnızca bir istek veritabanına gider; diğerleri sonucu bekler ya da eski veriyi alır.
Bilmen gerekenler
- Dağıtık kilit ya da süreç içi tek-uçuş
Okuma replikası· İyi olur
Yazma tek ana veritabanına, okuma bir ya da birkaç kopyaya gider. Okuma yükü kopyalar arasında bölünür.
Bilmen gerekenler
- Replika gecikmesi (replication lag)
- Yazdığını hemen okuman gerekiyorsa ana sunucudan oku
Kaynaklar
04Yazmayı sıraya al
Mesaj kuyruğu· Temel
Bilet satışı, sipariş gibi ağır işlemler önce kuyruğa girer, işçiler (worker) kuyruğu kendi hızlarında tüketir. Ani patlama kuyrukta emilir, veritabanı sakin kalır.
Bilmen gerekenler
- Üretici – kuyruk – tüketici
- Kullanıcıya hemen 'alındı' dön, sonucu sonra bildir
- Kafka ve RabbitMQ farkı
Kaynaklar
Kafka mı RabbitMQ mu?· İyi olur
RabbitMQ görev dağıtımı için, Kafka büyük hacimli olay akışı ve tekrar oynatma için. İlk kuyruğun için ikisi de yeterli.
Bilmen gerekenler
- Önce işin ne olduğuna bak, aracı sonra seç
Geri basınç (backpressure)· Sonra
Tüketici yetişemediğinde üreticiyi yavaşlatmak ya da reddetmek; kuyruğun sonsuza kadar şişmesini engeller.
Bilmen gerekenler
- Kuyruk uzunluğuna alarm kur
Tekrar güvenliği (idempotency)· Temel
Kuyrukta aynı mesaj iki kez işlenebilir; ödemenin iki kez çekilmemesi için işlemin tekrar çalıştırılabilir olması gerekir.
Bilmen gerekenler
- İstek başına benzersiz anahtar
- İşlenmiş anahtarları kaydet
Kaynaklar
Okuma/yazma ayrımı (CQRS)· Sonra
Yazma modelini ve okuma modelini ayırmak; her biri kendi ihtiyacına göre ölçeklenir ve depolanır.
Bilmen gerekenler
- Olay temelli güncelleme
- Karmaşıklığı bedeli: gerçekten gerekiyorsa
Kaynaklar
05Dayanıklı ve görünür kıl
Devre kesici (circuit breaker)· İyi olur
Yanıt vermeyen bir bağımlılığa istek göndermeyi bir süre durdurur; sistemin geri kalanı onunla birlikte çökmez.
Bilmen gerekenler
- Zaman aşımı + yeniden deneme (üstel bekleme ile)
- Yedek davranış (fallback)
Kaynaklar
Otomatik ölçekleme· İyi olur
Kubernetes gibi araçlar yüke göre uygulama sunucusu sayısını artırır; ama veritabanı bunu otomatik yapamaz, bu yüzden önceki katmanlar şart.
Bilmen gerekenler
- CPU ve istek sayısına göre ölçekleme
- Ölçeklemenin soğuk başlangıç gecikmesi
Kaynaklar
İzleme ve yük testi· Temel
Neyin yavaşladığını görmeden ölçeklenemezsin. Büyük günden önce sistemi kasıtlı olarak yükle ve nerede kırıldığını öğren.
Bilmen gerekenler
- Gecikme (p95/p99), hata oranı, doygunluk
- Üretime benzer ortamda yük testi
Kaynaklar