Redis Kurulumu ve Temel Yapılandırma: Prod Hazır Rehber

Redis, anahtar-değer (key-value) tabanlı hızlı bir veri deposu olarak birçok sistemde önbellek (cache), oturum (session) ve kuyruk (queue) benzeri senaryolarda kullanılır. Sunucu tarafında Redis’i doğru kurmak, sadece “çalıştırmak” değil; gecikmeyi (latency) ve veri kaybı riskini yönetmek demektir. Bu rehberde Linux üzerinde Redis kurulumu, temel konfigürasyon dosyası ayarları, kalıcılık (persistence), erişim güvenliği, bellek planlaması ve pratik doğrulama adımlarını net bir sırayla öğreneceksiniz.

Hedef: Redis’i yerel testten çıkarıp üretime (production) yakın bir şekilde, kontrol edilebilir parametrelerle ayağa kaldırmak.

1) Kurulum öncesi: Mimariyi netleştirin

Redis kurulumu kadar önemli olan şey, Redis’in hangi rolü üstleneceğini bilmektir.

Hangi senaryoda Redis?

• Önbellek (cache): Örneğin WordPress sayfa önbelleği, API yanıt önbelleği. Genelde yüksek okuma/az yazma vardır.
• Oturum (session): Oturum verisi Redis’te tutulur. Kısa TTL (time-to-live) ve düzenli temizlik önemlidir.
• Kuyruk (queue) / rate limit: Yazma daha yoğun olabilir; gecikme kritik hale gelir.

Bu rehberde Redis’i tek sunucuda (VPS/VDS ya da dedicated) çalıştırmayı temel alacağız. Birden fazla node ile kümeleme (cluster) ayrıca ele alınmalıdır.

Redis’i hangi porttan açacaksınız?

Varsayılan olarak Redis 6379 portunu kullanır. Üretimde bu portu genel internete açmayın. - Aynı sunucu içinde kullanılacaksa: sadece localhost veya uygulamanın çalıştığı ağ aralığı. - Farklı sunuculardan erişilecekse: firewall ile sadece gereken kaynak IP’lere izin.

2) Linux’ta Redis kurulumu

Aşağıdaki adımlar çoğu Debian/Ubuntu tabanlı sistemde sorunsuz çalışır. (Dağıtımınıza göre paket adı ve servis adı değişebilir.)

Debian/Ubuntu örneği

• Güncelleme:
• sudo apt update
• Redis kurulumu:
• sudo apt install -y redis
• Servis kontrol:
• sudo systemctl status redis
• Redis’in ayağa kalktığını test:
• redis-cli ping

Başarılı sonuç: PONG

redis-cli komutu çalışmıyorsa paket yöneticisi ile CLI aracını da kontrol edin.

Servisi başlat/yeniden başlat

• sudo systemctl enable --now redis
• Konfig değişikliği sonrası:
• sudo systemctl restart redis

3) Temel konfigürasyon: redis.conf’de “kritik alanlar”

Redis konfigürasyonu genellikle /etc/redis/redis.conf dosyasında bulunur. Dağıtımınıza göre farklı dizin olabilir; doğrulamak için redis-server --help çıktısından da yararlanabilirsiniz.

Aşağıda, üretim senaryosunda doğrudan etki eden temel başlıkları sıralıyorum.

3.1 Dinleme (bind) ve koruma

Varsayılan olarak Redis’i internete açık hale getiren bir kurulumla karşılaşabilirsiniz. Bunu netleştirin. - Öneri (tek sunucuda kullanım): - bind 127.0.0.1 ::1 - Öneri (belirli ağ): - Sadece uygulamanın erişeceği IP aralığına bağlanın.

Ayrıca firewall tarafını da kapatmayın. Örneğin UFW kullanıyorsanız sadece gerekli kaynaklara izin verin.

3.2 Şifre/kimlik doğrulama (requirepass)

Redis tek başına bir “auth sistemi” değildir ama şifre parametresi kritik koruma sağlar. - requirepass "GUVENLI_BIR_SIFRE"

Not: Parola mutlaka güçlü olmalı ve loglarda/konfig yönetiminde sızmamalıdır.

3.3 Koruma modülü: protected-mode

Redis “protected-mode” ile istemci erişimini kısıtlar. Üretimde bu modun açık kalması doğru varsayımdır. - protected-mode yes

Eğer bind ile internete açılmıyorsa zaten güvenlik artar. Yine de çakışan ayarları doğrulayın.

3.4 Kalıcılık (persistence): RDB ve AOF

Redis verisini bellekte tutar; yeniden başlatma/çökme durumunda kalıcılık stratejisi belirleyici olur.

• RDB (snapshots): Belirli aralıklarla anlık durum dosyası üretir.
• AOF (append-only file): Yazma işlemlerini dosyaya ekleyerek daha sık “yakın veri” sağlar.

Hangisi seçilmeli?

Aşağıdaki tablo hızlı karar vermenizi sağlar:

Örnek ayarlar (başlangıç için)

• RDB için:
• save 900 1
• save 300 10
• save 60 10000

Bu satırlar “belirli sürede belirli değişiklik olursa snapshot al” mantığını kurar.

• AOF için:
• appendonly yes
• appendfsync everysec

everysec genelde iyi denge verir: performans düşüşü görece sınırlı, veri kaybı da sınırlanır.

AOF açarsanız disk yazma (write I/O) yükü artabilir. Hosting tarafında IOPS kapasitesini hesaba katın.

3.5 Bellek yönetimi: maxmemory ve eviction

Redis’in bir “sınırsız bellek” mantığı yoktur; bellek dolarsa ne olacağını karar vermelisiniz. - maxmemory 1gb (örnek) - maxmemory-policy allkeys-lru

maxmemory-policy seçenekleri (temel)

• allkeys-lru: En az kullanılan anahtarlar atılır
• volatile-lru: Sadece TTL’si olanlarda LRU uygulanır
• noeviction: Bellek dolunca yazma reddedilir

Oturum senaryolarında çoğunlukla TTL kullanılır; bu durumda volatile-... politikaları daha anlamlıdır.

3.6 Zaman aşımı (TTL) temizliği

Redis’te otomatik silme (eviction/expiration) mekanizması vardır. Redis konfigürasyonunda TTL ile uyumlu çalışma için temel ayar zaten uygulama tarafında yapılır; örneğin EXPIRE komutları.

Bu nedenle konfigürasyonda ana kural: TTL’siz sınırsız büyüyen anahtarlar oluşmasını önlemek.

4) Temel doğrulama: Redis gerçekten hazır mı?

Redis’i kurduktan sonra sadece “çalışıyor” demek yeterli değildir. Şunları kontrol edin.

4.1 Ping testi

• redis-cli ping

Kimlik doğrulama yaptıysanız: - redis-cli -a "GUVENLI_BIR_SIFRE" ping

4.2 Konfigürasyonun etkisini kontrol etme

Redis runtime konfigürasyonu redis-cli config get ile okunabilir. - redis-cli config get maxmemory - redis-cli config get requirepass - redis-cli config get appendonly

4.3 Persist dosyaları oluşuyor mu?

• RDB için dump.rdb (konfigte belirtilen dizinde) üretimi
• AOF için appendonly.aof üretimi

Dosyalar oluşmuyorsa: - snapshot/aof ayarları yanlış olabilir - yazma trafiği yoktur (özellikle RDB için “değişiklik eşiği” önemli)

5) Güvenlik ve erişim: Redis’i “kapalı servis” olarak yönetin

Redis genellikle arka uç sistemler için hızlı bir bileşendir; bu yüzden güvenlik varsayılanı “kapalı ve kontrollü erişim” olmalıdır.

5.1 Firewall ile kapı kapatın

Redis portu 6379’u sadece ihtiyaç duyan kaynaklara açın.

Örnek yaklaşım (mantık): - Uygulama sunucusunun IP’si -> 6379’a izin - Diğer tüm IP’ler -> blok

Bu, Redis’in requirepass ayarıyla birlikte “katmanlı güvenlik” sağlar.

5.2 bind ile sadece gerektiği kadarını dinleyin

bind 127.0.0.1 kullanıyorsanız Redis sadece aynı makineden erişilir. Bu, en düşük riskli başlatma modelidir.

5.3 Yönetim erişimini kısıtlayın

• SSH erişimi için IP kısıtı ve anahtar tabanlı kimlik doğrulama kullanın.
• Redis admin komutlarını (ör. FLUSHALL) uygulama kullanmasın.

6) Performans için temel ayar stratejileri

Redis performansı; bellek, persistence, eviction, komut tasarımı ve ağ gecikmesine bağlıdır.

6.1 maxmemory + eviction: “panic” yaşamayın

Uygulama yazma yaparken bellek dolduğunda ne olacağı kritik.

Hızlı kılavuz: - Önbellek: maxmemory + allkeys-lru gibi eviction politikası - Oturum: TTL’li alanlar için volatile-... politikaları - Kritiklik yüksek: noeviction yerine dikkatli plan + yeterli RAM + gerekirse AOF stratejisi

6.2 Persistence performans dengesi

• RDB sıklaşırsa: snapshot maliyeti artar
• AOF açılırsa: her yazma diske log düşebilir

Bu yüzden üretime geçmeden önce “trafik senaryosu” ile bir deneme yapmak en doğru adımdır.

6.3 Komutları izleyin

• Çok büyük payload’lar göndermek gecikmeyi artırır.
• Anahtar adlarını aşırı uzatmayın.
• İhtiyaç yoksa büyük veri yapıları yerine daha uygun tasarımlar kullanın.

7) RDB/AOF seçimi için pratik karar akışı

Aşağıdaki liste, konfigürasyonu tek okumada netleştirmenize yardımcı olur.

• Redis’i sadece cache amaçlı kullanıyorum -> Kalıcılığı minimum tut (RDB veya düşük sıklık)
• Redis’te oturum tutuyorum, veri kaybı kullanıcı deneyimini etkiler -> RDB + yeterli snapshot planı, TTL disiplinini koru
• Redis’te kritik sayaç/kuyruk tutuyorum -> AOF (çoğu durumda) + appendfsync everysec gibi dengeli ayar
• Disk I/O kapasitem sınırlı -> AOF’yi çok agresif yapma, maxmemory + eviction ile büyümeyi kontrol et

8) Son adım: Değişiklikleri kontrollü uygulayın

Konfigürasyonu değiştirdikten sonra aşağıdaki sırayı izleyin:

1. Konfigürasyonu düzenle (redis.conf)
2. sudo systemctl restart redis
3. redis-cli ping ile bağlantıyı doğrula
4. Persistence dosyalarının üretildiğini kontrol et (ihtiyaca göre)
5. Uygulama tarafında TTL/okuma-yazma senaryosunu test et
6. Sistem loglarını incele: journalctl -u redis -n 200 --no-pager

Redis’i tek seferde “her şeyi açarak” optimize etmeyin. Üretimde en doğru yol, önce güvenlik ve kalıcılığı düzgün kurmak, sonra trafikle birlikte ince ayar yapmaktır.

Sonuç: Redis’i doğru kurmak, sonraki sorunları azaltır

14.11.2026 itibarıyla Redis ekosistemi aynı temel prensiplerle yönetiliyor: doğru bağlanma (bind), erişim güvenliği (requirepass + protected-mode + firewall), kalıcılığı senaryoya göre seçme (RDB/AOF) ve bellek dolması durumunu önceden planlama (maxmemory + eviction). İlk kurulumda bu dört grubu netleştirin; ardından uygulamanın yazma/okuma örüntüsüne göre persistence ve maxmemory değerlerini ayarlayın. Redis hazır olduğunda, performans ve veri kaybı riskini birlikte kontrol altına almış olursunuz.