Redis Sentinel ile Üretim Ortamında Kesintisiz Yüksek Erişilebilirlik Mimarisi

 · 

Redis Sentinel ile Üretim Ortamında Kesintisiz Yüksek Erişilebilirlik Mimarisi

Redis Sentinel ile Üretim Ortamında Kesintisiz Yüksek Erişilebilirlik Mimarisi

Tekil bir Redis instance'ı, caching veya oturum yönetimi gibi kritik görevler üstlendiğinde, bu instance'ın arızalanması doğrudan servis kesintisine yol açar. Bu tür tek hata noktalarını (Single Point of Failure - SPoF) ortadan kaldırmak için Redis Sentinel mimarisi devreye girer. Redis Sentinel, Redis Master-Replica yapılandırmasını izleyen, arızaları tespit eden ve otomatik failover süreçlerini yöneten dağıtık bir sistemdir. Bu kurulum, veritabanı kesintisi riskini minimize ederek uygulamaların sürekli çalışır durumda kalmasını sağlar.

Redis Sentinel Nedir ve Neden Gereklidir?

Redis Sentinel, Redis dağıtılmış sistemlerinin temel bileşenlerinden biridir. Asıl amacı, Redis Master-Replica kümelerinin yüksek erişilebilirliğini sağlamaktır. Sentinel process'leri, bir veya daha fazla Master Redis instance'ını ve bunların tüm replikalarını sürekli olarak izler. Bir Master instance'ının ulaşılamaz hale geldiğini tespit ettiğinde, oylama mekanizmasıyla yeni bir Master seçer ve tüm replikaları yeni Master'a yönlendirir. Ayrıca, istemci uygulamalarına güncel Master adresini sağlayarak dinamik bağlantı yönetimine olanak tanır.

Gerekliliği, özellikle Redis'in kritik iş yüklerinde kullanıldığı üretim ortamlarında ortaya çıkar. Manuel failover süreçleri hem zaman alıcı hem de hata potansiyeli taşır. Sentinel, bu süreci otomatikleştirerek müdahale gereksinimini ortadan kaldırır ve RTO (Recovery Time Objective) değerlerini önemli ölçüde iyileştirir.

Redis Sentinel Mimarisi ve Çalışma Prensibi

Redis Sentinel, birden fazla Sentinel process'inden oluşan bir küme olarak çalışır. Her Sentinel, diğer Sentinel'lerle ve izlediği Redis instance'larıyla iletişim halindedir. Bu dağıtık yapı, Sentinel kümesinin kendisinin de yüksek erişilebilir olmasını sağlar. Temel çalışma prensipleri şunlardır:

  • İzleme (Monitoring): Her Sentinel, Master ve Replica Redis instance'larını belirli aralıklarla PING komutları göndererek durumlarını kontrol eder.
  • Arıza Tespiti (Failure Detection): Bir Sentinel, Master'ın belirli bir süre (down-after-milliseconds) yanıt vermediğini tespit ettiğinde, bunu "Subjectively Down" (SDOWN) olarak işaretler. Diğer Sentinel'lerden de aynı durumu teyit eden belirli bir çoğunluk (quorum) alındığında, Master "Objectively Down" (ODOWN) olarak kabul edilir ve failover süreci başlar.
  • Bildirim (Notification): Sentinel'ler, Redis instance'larının durumu veya failover olayları hakkında sistem yöneticilerini veya diğer sistemleri (örneğin, Slack, PagerDuty entegrasyonları) bilgilendirebilir.
  • Otomatik Failover (Automatic Failover): ODOWN durumuna geçen bir Master için, Sentinel'ler arasında bir lider seçimi yapılır. Seçilen lider Sentinel, mevcut replikalar arasından en uygun olanını (veri senkronizasyon durumu, öncelik vb.) yeni Master olarak atar. Diğer replikalar yeni Master'a senkronize olacak şekilde yeniden yapılandırılır ve eski Master geri geldiğinde de yeni Master'ın replikası olarak eklenir.
  • Konfigürasyon Sağlama (Configuration Provider): İstemci uygulamaları, Master'ın IP adresi ve portu için doğrudan Redis Sentinel'e sorgu atabilir. Sentinel, her zaman güncel Master bilgilerini döndürerek uygulama katmanının değişen topolojiden etkilenmemesini sağlar.

Redis Sentinel ve Redis Instance Kurulumu

Yüksek erişilebilir bir Redis kurulumu için en az bir Master Redis, birden fazla Replica Redis ve en az üç adet Redis Sentinel instance'ı gereklidir. Sentinel sayısı tek sayı olmalıdır (3, 5, vb.) quorum mekanizmasının sağlıklı çalışması için.

Redis Master-Replica Kurulumu

İlk adım olarak, Master ve Replica Redis instance'larımızı yapılandırmalıyız. Her Redis instance'ı farklı bir sunucuda veya farklı portlarda çalışabilir.

Master Redis Konfigürasyonu (redis-master.conf)

port 6379
daemonize yes
pidfile "/var/run/redis-master.pid"
logfile "/var/log/redis/redis-master.log"
dir "/var/lib/redis"
bind 0.0.0.0 # Tüm arayüzlerden erişime izin verir, güvenlik duvarı ile kısıtlanmalı
# requirepass your_master_password # Güvenlik için parola belirleyin
# masterauth your_master_password # Replikalar Master'a bağlanırken bu parolayı kullanır

Replica Redis Konfigürasyonu (redis-replica-1.conf)

port 6380
daemonize yes
pidfile "/var/run/redis-replica-1.pid"
logfile "/var/log/redis/redis-replica-1.log"
dir "/var/lib/redis"
bind 0.0.0.0
replicaof 192.168.1.100 6379 # Master Redis'in IP'si ve portu
# masterauth your_master_password # Master parolası varsa belirtin
replica-priority 100 # Varsayılan: 100. Düşük değerler önceliklidir.

replicaof direktifi ile Replica, Master'a bağlanır. İlk kurulumda Master henüz atanmamış olsa bile Sentinel bu bağlantıyı otomatik olarak güncelleyecektir.

Redis Sentinel Konfigürasyonu

Her Sentinel instance'ı için ayrı bir sentinel.conf dosyası oluşturulur. Bu dosyalar, Sentinel'in hangi Master'ı izleyeceğini ve failover davranışlarını tanımlar.

Sentinel Konfigürasyonu (sentinel.conf)

port 26379
daemonize yes
pidfile "/var/run/redis-sentinel.pid"
logfile "/var/log/redis/redis-sentinel.log"
dir "/tmp"

# 'mymaster' adındaki Master'ı izle. Master'ın IP'si 192.168.1.100, portu 6379.
# İlgili Master için failover başlatmak üzere en az 2 Sentinel'in (quorum) aynı fikirde olması gerekir.
sentinel monitor mymaster 192.168.1.100 6379 2

# Master'ın SDOWN durumuna geçmesi için beklenecek milisaniye cinsinden süre.
sentinel down-after-milliseconds mymaster 5000

# Master failover'ı sırasında eşzamanlı olarak rekonfigüre edilebilecek replika sayısı.
# Daha yüksek değerler, failover'ı hızlandırabilir ancak yükü artırabilir.
sentinel parallel-syncs mymaster 1

# Failover süreci için maksimum süre. Bu süre içinde failover tamamlanamazsa iptal edilir.
sentinel failover-timeout mymaster 60000

# Master Redis için parola tanımlanmışsa, Sentinel'in Master'a bağlanırken kullanacağı parola.
# sentinel auth-pass mymaster your_master_password

# Diğer Sentinel'lerin otomatik keşfedilmesi için gerekli interval (milisaniye).
sentinelTtl 10000

Bu konfigürasyon, Sentinel'in mymaster adındaki Redis Master'ı izlemesini sağlar. quorum 2 değeri, en az iki Sentinel'in Master'ın down olduğunu onaylaması durumunda failover sürecinin başlayacağını belirtir. down-after-milliseconds, bir Sentinel'in Master'ı ne kadar süre ulaşılmaz olarak görmesi gerektiğini belirler.

Üretim Ortamında Senaryo: E-ticaret Sepeti Verileri İçin Sentinel

Yüksek trafikli bir e-ticaret uygulamasında, kullanıcıların alışveriş sepeti verileri genellikle Redis üzerinde tutulur. Bu veriler, kullanıcının site deneyimi için kritik öneme sahiptir. Tekil bir Redis instance'ı ile bu senaryoyu yönetmek, Master'ın beklenmedik bir arızasında (örneğin, donanım hatası, ağ kesintisi, işletim sistemi crash'i) tüm aktif sepet verilerinin erişilemez hale gelmesine ve milyonlarca kullanıcının alışverişini tamamlayamamasına yol açabilir.

Redis Sentinel bu noktada devreye girer. Üç farklı EC2 instance'ına veya Kubernetes pod'larına dağıtılmış 3 Sentinel ve iki EC2 instance'ına dağıtılmış (bir Master, bir Replica) Redis instance'ları ile bir küme kurduğumuzu varsayalım. Sentinel'ler sürekli olarak Redis Master'ı izler. Eğer Master Redis instance'ı yanıt vermeyi durdurursa:

  1. Sentinel'lerden biri, Master'ın SDOWN olduğunu tespit eder.
  2. Diğer Sentinel'lerle konuşarak bu durumu doğrular ve quorum sağlanırsa Master ODOWN olarak işaretlenir.
  3. Sentinel'ler arasında bir lider seçilir ve lider Sentinel failover sürecini başlatır.
  4. Lider Sentinel, mevcut Replica'lardan birini (örneğin, veri senkronizasyonu en güncel olanı) yeni Master olarak yükseltir.
  5. Uygulama katmanındaki Redis client'ları, Sentinel kümesine bağlanarak güncel Master adresini sorgular (örneğin, Java için Jedis veya Lettuce kütüphaneleri bunu otomatik olarak yapabilir).
  6. Client'lar, yeni Master'a yönlendirilir ve kullanıcılar sepet verilerine kesintisiz erişmeye devam eder.

Bu süreç, manuel müdahaleye gerek kalmadan saniyeler içinde tamamlanır, böylece e-ticaret sitesi minimum kesintiyle çalışmaya devam eder ve potansiyel gelir kaybı önlenir.

Sentinel Topolojisi ve Failover Senaryoları

Sentinel, çeşitli arıza senaryolarını otomatik olarak ele alabilir:

  • Master Arızası: Sentinel kümesi yeni bir Master seçer ve replikaları yönlendirir.
  • Replica Arızası: Sentinel Master'ı etkilemez. Arızalı replica geri geldiğinde, mevcut Master'ın bir replikası olarak senkronize olur.
  • Sentinel Process Arızası: Bir Sentinel process'i down olduğunda, diğer Sentinel'ler çalışmaya devam eder ve quorum hala sağlanabiliyorsa sistemin yüksek erişilebilirliği etkilenmez. Bu nedenle en az üç Sentinel instance'ı önerilir. İki Sentinel ile, biri düşerse quorum sağlanamaz.

İzleme ve Yönetim

Redis Sentinel'in sağlıklı çalıştığından emin olmak için sürekli izleme kritik öneme sahiptir. Sentinel logları, failover olayları ve durum değişiklikleri hakkında değerli bilgiler içerir. Ayrıca, redis-cli -p 26379 info sentinel komutu ile Sentinel kümesinin genel durumunu, izlediği Master'ları, replikaları ve diğer Sentinel'leri sorgulayabilirsiniz.

$ redis-cli -p 26379 info sentinel
# Sentinel
sentinel_masters:1
sentinel_tilt:0
sentinel_script_running_time_us:0
sentinel_scripts_queue_length:0
sentinel_simulate_failure_flags:0
master0:name=mymaster,status=ok,address=192.168.1.100:6379,
... (detaylı bilgiler)

Prometheus, Grafana gibi izleme araçları ile Sentinel metriklerini toplayarak görselleştirmek ve alarm kurmak, proaktif yönetim için elzemdir. Sentinel'in yayımladığı Pub/Sub kanalları üzerinden de olayları gerçek zamanlı olarak dinleyebilir ve özel otomasyonlar tetikleyebilirsiniz.

Redis Sentinel, tekil Redis instance'larının getirdiği SPoF riskini ortadan kaldıran, kanıtlanmış ve sağlam bir yüksek erişilebilirlik çözümüdür. Doğru yapılandırıldığında ve izlendiğinde, üretim ortamlarında kesintisiz veri erişimi ve operasyonel dayanıklılık sağlar.

← Blog Listesine Dön