Sınav Zirvesinde Yüksek Erişilebilirlik: 45.000–70.000 eşzamanlı kullanıcı için Redis Sentinel

Mahdi Molavi 4 Ekim 2026 4 dk okuma

Aralık 2021'den Ekim 2023'e kadar Tahran'daki Gozine2'de kıdemli backend mühendisi olarak çalıştım. İşin merkezinde, tasarlayıp devreye aldığım bir Redis Sentinel yüksek erişilebilirlik kurulumu vardı; bu kurulum sınav zirvelerinde 45.000–70.000 eşzamanlı kullanıcıyı kaldırdı. Etrafında ise sorgu ve API optimizasyonu, yük testi, release çalışmaları ve kurduğum bir veri bilimi ekibi yer alıyordu.

Bağlam

Sınav platformları takvime göre yaşar. Haftanın büyük bölümünde sıradan olan yük, bir sınav açıldığında bir anda gelir.

Kıdemli role geçmeden önce, Haziran 2021'de Gozine2'ye katıldım. O ilk aylarda raporlama sistemini yeniden tasarladım; bu, veritabanı yükünü azalttı ve sık kullanılan raporları hızlandırdı. Ayrıca Serilog ile yapılandırılmış loglamayı devreye aldım. İkisi de genel anlamda zirve sorunuyla bağlantılı. Veritabanına daha az yük bindiren raporlar sınav trafiğine daha fazla yer bırakır; yapılandırılmış loglar da bir sistemin yük altında ne yaptığını anlamayı çok kolaylaştırır.

Mühendislik problemi

Sınav trafiği ani ve senkronizedir. Kullanıcılar birlikte başlar, aynı sayfalar ve API'ler aynı sırayla çağrılır ve son teslim saatinden önceki son dakikalar yeni bir yazma dalgası getirir. Genel olarak bundan üç sonuç çıkar:

Hot path'ler baskındır. Yükün çoğunu az sayıda API taşır. Oradaki bir verimsizlik, çevrim içi olan her kullanıcıyla çarpılır.
Paylaşılan bağımlılıklar tek hata noktasına dönüşür. Her isteğin dokunduğu bir önbellek, çökene kadar bir performans kazancıdır. Çöktüğünde ise her istek, olabilecek en kötü anda veritabanına düşer.
Zirve, sorunu öğrenmek için yanlış zamandır. Sorunların önceden, simüle edilmiş yük altında ortaya çıkması gerekir.

Geliştirdiklerim

Redis için yüksek erişilebilirlik. Sınav zirvesi trafiği için bir Redis Sentinel kurulumu tasarlayıp devreye aldım.
Veritabanı ve API optimizasyonu. SQL Server sorgularını, önbellek yollarını ve yoğun trafik alan API'leri optimize ettim.
Zirveler öncesinde yük testi. Sınav zirveleri gelmeden önce darboğazları bulmak için Locust yük testleri kullandım.
Release güvenilirliği. Dockerize edilmiş servisler, yapılandırılmış loglama ve CI/CD ile release güvenilirliğini artırdım.
Bir veri bilimi ekibi. Sıralama, puanlama ve öneri algoritmaları geliştiren dört kişilik bir veri bilimi ekibini kurdum ve yönettim.

Tasarım notları

Aşağıdaki gerekçeler geneldir: bu tür sistemlerin nasıl davrandığını ve araçların neden uygun olduğunu anlatır, Gozine2'deki kurulumun iç yapısını değil.

Neden Redis Sentinel

Tek bir Redis instance'ı hızlı ve basittir, ama aynı zamanda tek bir makinedir. Sentinel, bir primary ile replikalarının yanına bir grup izleme süreci ekler. Yeterli sayıda Sentinel primary'ye ulaşılamadığı konusunda hemfikir olduğunda bir replikayı primary'ye yükseltir ve istemcilere yeni primary'nin nerede olduğunu bildirir. Uygulama aynı programlama modelini korur; sabit bir adres kullanmak yerine Sentinel'e güncel primary'yi sorar.

Ödünleşimler:

Redis replikasyonu asenkrondur; bu yüzden failover'dan hemen önce onaylanan bir yazma kaybolabilir. Kaybolmaması gereken veri veritabanında durmalıdır; Redis ise önbellek ya da hızlı bir ikincil kopya olarak kullanılır.
Sentinel oylamayla karar verir: primary'nin çöktüğü konusunda bir quorum'un hemfikir olması, failover'a da tüm Sentinel'lerin çoğunluğunun onay vermesi gerekir. Pratikte bu, ayrı makinelerde en az üç Sentinel süreci demektir; böylece bir makine kaybedildiğinde de çoğunluk korunur.
İstemcilerin güncel primary'yi bulmak için Sentinel desteğine sahip olması ve failover sürerken oluşan kısa aralığı idare edebilmesi gerekir.
Sentinel erişilebilirlik sağlar, sharding değil. Tüm veri hâlâ tek bir primary üzerinde durur. Redis Cluster veriyi node'lara dağıtır ama kendi karmaşıklığını da getirir; bu yüzden veri seti tek bir makineye sığıyorsa Sentinel çoğu zaman daha basit seçimdir.

Locust ile yük testi

Locust kullanıcı davranışını Python koduyla tanımlar; böylece bir test, tek bir URL'yi bombardımana tutmak yerine gerçekçi bir sınav akışını (giriş yapma, sınavı açma, cevapları gönderme) izleyebilir. Bu önemlidir, çünkü sınav darboğazları çoğu zaman adımların arasında ortaya çıkar; örneğin tek başına sorunsuz olan ama çok sayıda gönderim aynı anda geldiğinde yavaşlayan bir sorgu.

Sorgular, önbellek yolları ve yoğun API'ler

Zirve yük için optimizasyon büyük ölçüde trafiği taşıyan birkaç endpoint'le ilgilidir. Genel kaldıraçlar şunlardır: istek başına daha az iş yapmak (daha iyi sorgular), tekrarlanan işten kaçınmak (birçok kullanıcının okuduğu değerleri önbelleğe almak) ve önbellek yolunun kendisinin bir sonraki darboğaz olmamasını sağlamak. Hangi kaldıracın hangi endpoint için önemli olduğunu yük testleri gösterir.

Release'ler, loglar ve mesajlaşma

Docker image'ları test ve production ortamında aynı artifact'i sağlar; CI/CD de bir release'i tekrarlanabilir bir sürece dönüştürür. Serilog, adlandırılmış alanlara sahip yapılandırılmış olaylar yazar; böylece loglar düz metin olarak aranmak yerine isteğe, kullanıcıya ya da endpoint'e göre filtrelenebilir. RabbitMQ da teknoloji yığınının bir parçası. Genel olarak bir message broker, yavaş ya da acil olmayan işlerin istek yolundan çıkmasını sağlar; böylece bu işler zirve sırasında kullanıcılarla rekabet etmez.

Teknoloji yığını

.NET 6
SQL Server
Redis Sentinel
RabbitMQ
Docker
Serilog
Yük testi için Locust

Sonuç

Redis Sentinel kurulumu sınav zirvelerinde 45.000–70.000 eşzamanlı kullanıcıyı kaldırdı.
Daha önceki raporlama yeniden tasarımı veritabanı yükünü azalttı ve sık kullanılan raporları hızlandırdı.

İlgili

Uyarlamalı test platformu vaka çalışması, NovaTech'teki sonraki değerlendirme çalışmalarımı anlatıyor. Backend performansı ve yüksek erişilebilirlik işleri için Benimle çalışın sayfasına bakın.

Sık sorulan sorular

Redis Sentinel kurulumu kaç eşzamanlı kullanıcıyı kaldırdı?

Mahdi Molavi'nin Gozine2'de tasarlayıp devreye aldığı Redis Sentinel yüksek erişilebilirlik kurulumu, sınav zirvelerinde 45.000–70.000 eşzamanlı kullanıcıyı kaldırdı.

Sınav zirvelerinden önce darboğazlar nasıl bulundu?

Zirvelerden önce darboğazları bulmak için Locust yük testleri kullandı; SQL Server sorgularını, önbellek yollarını ve yoğun trafik alan API'leri optimize etti.

Gozine2'de başka neye liderlik etti?

Sıralama, puanlama ve öneri algoritmaları geliştiren dört kişilik bir veri bilimi ekibini kurdu ve yönetti.

Bu bölümdeki diğer sayfalar

Projeler