Redis Cloud Nedir? Yönetilen Redis Hizmeti Rehberi

Özet: Redis Cloud, Redis Inc. tarafından sunulan resmi yönetilen Redis hizmetinin ticari adıdır; günlük kullanımda bu terim AWS ElastiCache, Cloud4U DBaaS gibi tüm yönetilen Redis çözümleri için de kullanılır. Yönetilen Redis, kurulum, replikasyon, yedekleme ve failover yükünü sağlayıcıya devrederek mikrosaniye seviyesinde in-memory veri katmanını üretime hazır şekilde sunar. Türkiye'deki uygulamalar için region seçimi kritik: yurt içi DBaaS, yurt dışına kıyasla 50-70 ms ek gecikmeyi ortadan kaldırır.

Ana noktalar:
- Redis Cloud (Redis Inc.) ile "managed Redis" terimi birbirinden farklı; sağlayıcı seçimi öncesi netleştirilmeli.
- In-memory mimari sayesinde Redis ortalama komut süresi 0,1 ms altında; tek instance 100K–500K komut/sn işler.
- Persistence için RDB + AOF hibrit kullanımı, 1 sn'lik RPO ile hızlı recovery sunar.
- Türkiye veri merkezinde konumlanan Redis, Frankfurt'a kıyasla her komut çağrısında 50-70 ms gecikme avantajı sağlar.
- Session verileri KVKK kapsamında kişisel veridir; yurt içi DBaaS Redis yurt dışı transfer formalitelerini ortadan kaldırır.

Modern bir e-ticaret platformunun ana sayfasını, bir API gateway'in rate-limit kontrolünü ya da bir oyun sunucusunun gerçek zamanlı leaderboard'unu PostgreSQL ile çalıştırmaya kalkışırsan saniyede milyonlarca sorgu altında diz çökersin. Bu yükü kaldırmak için ortaya çıkmış özel bir araç var: Redis. Mikrosaniyeler mertebesinde yanıt süresi, esnek veri yapıları ve operasyonel sadeliği ile arka uç ekosisteminin vazgeçilmez bileşeni — Stack Overflow Developer Survey verilerinde yıllardır en sevilen veritabanları arasında üst sıralarda yer alır.

Bu rehber, Redis'i bilen ama "kendi VM'imde mi çalıştırsam, yönetilen bir hizmet mi alsam, hangi kullanım senaryosunda Redis Cluster ile yatay ölçekleyim?" sorularına net cevap arayan geliştiriciler, DevOps ekipleri ve teknik yöneticiler için yazıldı. Redis'in temel mimarisinden persistence stratejilerine, sağlayıcı karşılaştırmasından KVKK uyumuna kadar pratik konuları sırayla ele alıyoruz.

Sonunda elinde şu olacak: Redis Cloud terminolojisinin net anlamı, yönetilen Redis hizmetinin self-hosted'a göre TCO farkı ve Türkiye'deki uygulamalar için doğru region seçiminin neden gecikme avantajına dönüştüğüne dair gerçekçi bir bakış.

Redis cloud nedir?

"Redis cloud" terimi iki farklı şeyi anlatmak için kullanılır ve bu sıklıkla karışıklık yaratır.

Redis veritabanının kısa tanımı

Redis (REmote DIctionary Server), 2009'da Salvatore Sanfilippo tarafından geliştirilmiş, açık kaynaklı (lisans değişikliklerinden sonra bir kısmı SSPL/RSAL) bir in-memory veri yapısı sunucusudur. Verileri RAM'de tutar, çok hızlı okuma/yazma sağlar; key-value ana modelinin yanı sıra hash, list, set, sorted set, stream, bitmap, hyperloglog gibi zengin veri yapılarını yerel olarak destekler. Resmi Redis dokümantasyonu tüm veri yapıları, komutlar ve mimari ayrıntıları için referans kaynağıdır.

Tipik kullanımı veritabanı yerine değil, veritabanı önünde bir hızlandırma/yardımcı katman olarak konumlanır. Cache, session store, queue, rate limiter, pub/sub broker, leaderboard, real-time analytics gibi pek çok problem için "varsayılan araç" haline gelmiştir.

Redis Cloud (Redis Inc.) ile managed Redis hizmetleri farkı

Redis Inc., Redis'in kurucusunun şirketi ve "Redis Cloud" bu şirketin sunduğu yönetilen Redis hizmetinin ticari adıdır. Ancak günlük konuşmada "redis cloud" terimi, herhangi bir bulut sağlayıcısı üzerinde yönetilen Redis hizmetini ifade etmek için de kullanılır.

Pazardaki yaygın yönetilen Redis seçenekleri: Redis Inc. Cloud, AWS ElastiCache for Redis, Azure Cache for Redis, GCP Memorystore for Redis, Cloud4U Türkiye DBaaS gibi yerel sağlayıcı yönetilen Redis hizmetleri ve Aiven, Upstash gibi bağımsız sağlayıcılar.

Self-hosted Redis vs yönetilen Redis

Self-hosted Redis, kendi VM'inizde apt/yum ile veya Docker konteyneriyle çalıştırdığınız Redis'tir. Yönetim sorumluluğu (kurulum, sürüm yükseltme, replikasyon, yedekleme, monitoring, failover) tamamen sizdedir. Maliyet sadece VM kaynağıdır.

Yönetilen Redis ise sağlayıcı tarafından sunulan, sürüm yükseltme, yedekleme, replikasyon, izleme ve gerektiğinde otomatik failover dahil "hazır" hizmettir. Aylık ücret VM'den yüksektir ama operasyonel yük neredeyse sıfıra iner. Ekip büyüklüğü ve uzmanlığa göre karar verilir; küçük/orta ekipler için yönetilen genelde daha ekonomik bir TCO çıkarır.

Redis nasıl çalışır?

Redis'in performansının arkasındaki temel mimari kararlar.

In-memory key-value mimarisi

Redis tüm aktif veriyi RAM'de tutar. Disk yalnızca persistence (RDB snapshot, AOF) için kullanılır. Bu sayede ortalama komut süresi 0,1 ms'nin altındadır. Tek bir Redis örneği, modern donanımda saniyede 100K–500K komutu rahatlıkla işler.

Veri modeli temelde anahtar-değer, ama "değer" tarafında çok zengin türler vardır. Bu zenginlik, atomik operasyonlarla birleştiğinde Redis'i sadece bir cache'ten çok daha fazlasına dönüştürür.

Veri yapıları (string, hash, list, set, sorted set, stream)

• String: en basit veri tipi; counter, JSON blob, cache değeri için kullanılır.
• Hash: alan-değer çiftleri; bir kullanıcı objesinin alanlarını tek bir anahtar altında tutmak için.
• List: sıralı, FIFO/LIFO destekli; queue ve activity feed senaryoları için.
• Set: tekil elemanlar; etiket, üye listesi, kesişim sorguları için.
• Sorted Set: skorlu sıralı set; leaderboard, range sorguları, zaman serisi için.
• Stream: append-only log; modern event sourcing ve Kafka-benzeri akışlar için.

Bu veri yapıları sayesinde uygulama kodunda yapılması karmaşık olan işlemler (TOP-N sorgu, set kesişimi, atomik increment) Redis tarafında tek komutla çözülür.

Single-threaded modeli ve performans

Redis komut yürütücüsü tek thread'lidir. Bu kasıtlı bir karardır: lock yok, context switch yok, dolayısıyla her komut deterministic ve atomik. Performans, modern CPU'da tek bir çekirdek üzerinde son derece yüksektir.

Modern Redis sürümleri ağ I/O ve bazı yardımcı işler için ek thread kullanır, ama "komut yürütme" tek thread'de kalır. Tek bir Redis süreciyle bir CPU çekirdeğinden fazlasını kullanmak için Redis Cluster ile sharding yapılır.

Redis cloud kullanım senaryoları

Redis hangi sorunları çözer?

Önbellekleme (cache) ve session store

En klasik senaryo. Veritabanına giden tekrarlı sorguların sonucu Redis'e cache'lenir; aynı sorgu tekrar geldiğinde mikrosaniyelerde dönülür. Session verileri (kullanıcı oturum bilgisi, sepet, kişiselleştirme) de Redis'e konur; web sunucuları stateless hale gelir, yatay ölçeklendirme sorunsuzlaşır.

TTL (Time-To-Live) ile cache'in otomatik süresi yönetilir; eviction politikaları (LRU, LFU) ile RAM dolduğunda hangi anahtarların düşeceği belirlenir.

Kuyruk ve görev yönetimi (queue)

Redis List ya da Stream ile basit ama dayanıklı kuyruklar kurulur. Sidekiq (Ruby), Celery (Python), Bull (Node.js), Resque gibi popüler arka plan iş kütüphaneleri Redis'i broker olarak kullanır. Hafif, hızlı, operasyonel olarak basit.

Daha karmaşık enterprise mesajlaşma için RabbitMQ ya da Kafka tercih edilir; ama küçük-orta ölçekli iş yükleri için Redis genelde yeterlidir ve tek bir veritabanıyla iki ihtiyacı (cache + queue) karşılar.

Rate limiting ve sayaçlar

API gateway'lerde "her IP başına dakikada 100 istek" gibi rate-limit kuralları, Redis'in INCR ve EXPIRE komutları ile atomik şekilde uygulanır. Saniyede binlerce isteğin geldiği bir API için Redis tabanlı rate limiter neredeyse standart yaklaşımdır.

Sayaçlar (ziyaretçi sayısı, kampanya görüntüleme, A/B test bucket sayımı) için de aynı atomic increment kullanılır; sonuç batch'lenip kalıcı veritabanına yazılır.

Pub/Sub ve gerçek zamanlı mesajlaşma

Redis'in Pub/Sub özelliği, channel'a publish edilen mesajların subscribe olan tüm istemcilere anlık iletilmesini sağlar. WebSocket sunucuları arasında mesaj yayını, gerçek zamanlı bildirimler, canlı sohbet alt yapısı için kullanılır. Mesaj garantili teslimat istemiyorsa hafif ve hızlı.

Garantili teslimat gerektiğinde Redis Streams kullanılır; consumer group mantığı ile her mesajın işlenmesi izlenebilir.

Leaderboard ve sıralı veri

Sorted Set, oyun leaderboard'larının doğal aracıdır. Her oyuncunun skoru ZADD ile eklenir, ZRANGE ile ilk 100 kişi mikrosaniyelerde dönülür. Aynı yapı sıralı içerik akışları, trend hesaplama, en çok satanlar gibi pek çok senaryoda kullanılır.

Persistence ve veri kaybı yönetimi

Redis in-memory olsa da disk persistence seçenekleri sunar. Bunlar doğru yapılandırılmadığında "Redis'i restart ettik, veri gitti" senaryosu yaşanır. Redis persistence dokümantasyonu yapılandırma örnekleri ve trade-off'lar için detaylı referanstır.

RDB snapshot

RDB, belirli aralıklarla (örneğin "1000 değişiklik olduysa 5 dakikada bir") Redis bellek imajını diske yazar. Hızlı geri yükleme sağlar, dosya boyutu küçüktür. Dezavantajı: iki snapshot arasında olan veri kaybedilebilir; ortalama 1–5 dakika RPO.

AOF (Append-Only File)

AOF, her yazma komutunu sırayla bir log dosyasına ekler. fsync politikası ile her komutta, saniyede bir veya OS'un kararına bırakılarak diske yazılır. Saniyede bir fsync, dengeli bir RPO/performans karması verir: en kötü ihtimalle 1 saniyelik veri kaybı.

Hybrid persistence

Modern Redis sürümleri RDB + AOF kombinasyonunu önerir: periyodik RDB snapshot ile hızlı baseline, üzerine AOF ile incremental veri. Restart sırasında RDB yüklenir, sonra AOF replay edilir. Hem hızlı recovery hem düşük RPO.

Replikasyon ve Redis Sentinel

Replikasyon, master'a yazılan verinin bir veya birden çok replica'ya asenkron olarak kopyalanmasıdır. Master arızasında manuel olarak bir replica master'a promote edilir, ya da Redis Sentinel ile otomatik failover yapılır. Sentinel, master ve replica'ları izler, oy çoğunluğuyla failover kararı verir, istemcileri yeni master'a yönlendirir.

Yönetilen Redis hizmetlerinde Sentinel veya benzeri otomatik failover mekanizması altyapı seviyesinde kurulu gelir.

Redis Cluster ve ölçeklendirme

Tek bir Redis örneği RAM ve CPU sınırına ulaşınca Cluster devreye girer.

Sharding ve hash slot mantığı

Redis Cluster, anahtar uzayını 16384 hash slot'a böler. Her slot bir node'a atanır. Bir anahtar yazılırken hash'i alınır, hangi slot'a düştüğüne bakılır, o slot'un sahibi node'a yönlendirilir. Yeni node eklendiğinde slot'lar yeniden dağıtılır; bu işlem online yapılabilir.

Aynı transaction veya MULTI/EXEC içinde birden çok anahtar kullanılacaksa "hash tag" mantığı ile bunların aynı slot'a düşmesi sağlanır. Çoklu-key işlemler farklı slot'lar üzerinde çalışmaz.

Read replica yapılandırması

Yazma yükü tek master'a düşerken, okuma yükü read replica'lara dağıtılabilir. İstemci kütüphaneleri (Redis-py, ioredis, Jedis, Lettuce) read replica kullanımını destekler. Yüksek okuma/yazma oranı olan iş yüklerinde belirgin performans artışı sağlar.

Asenkron replikasyon olduğu için read replica'dan okunan veri birkaç ms gecikme ile master'ın gerisindedir; "okuma sonrası kendi yazısını görme" senaryolarında master'dan okumaya zorlamak gerekebilir.

Yatay ve dikey ölçekleme stratejileri

Dikey ölçekleme (sunucunun kaynağını büyütmek), tek Redis node için RAM 100 GB civarına kadar pratik. Bu sınırın üstünde Cluster ile yatay ölçekleme tercih edilir. Dikey ölçek operasyonel olarak basit; yatay ölçek esnek ve sınırı yüksek ama uygulama tarafı bazı kısıtlara uymak zorunda.

Yönetilen Redis sağlayıcılarının karşılaştırması

Redis Cloud (Redis Inc.)

Redis'in resmi yönetilen hizmeti. Açık kaynak Redis dışında Redis Stack (RedisJSON, RediSearch, RedisGraph, RedisBloom) modüllerini de yönetilen olarak sunar. AWS, Azure, GCP üzerinde çalışır. Fiyatlandırma USD bazlıdır; Türkiye için en yakın region genelde Frankfurt'tur.

AWS ElastiCache

AWS ekosisteminde yaygın seçenek. Redis ve Memcached desteği var. VPC entegrasyonu olgun, IAM ile erişim, CloudWatch ile izleme dahil. Türkiye için Frankfurt veya İrlanda bölgesi tercih edilir; 50–70 ms ek gecikme yaratır. KVKK için yurt dışı transfer formaliteleri gerekir.

Cloud4U Türkiye DBaaS Redis

İstanbul veri merkezinde yönetilen Redis. KVKK uyumlu yurt içi konum, TRY üzerinden faturalandırma, Türkçe 7/24 destek. Otomatik yedekleme, replikasyon, failover ve sürüm yükseltme dahil. Türkiye'de çalışan uygulamalar için 1 ms altında gecikme.

Self-managed Redis (kendi VM'inizde)

VM kira fiyatı sadece. Yönetim, yedekleme, izleme, failover sizin sorumluluğunuzda. Ekibinizde Redis konusunda deneyimli mühendis varsa ve operasyonel kapasite ayırabiliyorsanız ekonomik olur. Aksi halde yönetilen hizmet TCO açısından genelde daha avantajlı çıkar.

Redis ve ağ gecikmesi (latency (gecikme süresi))

Redis komutları mikrosaniyelerde çalışır; bu, ağ gecikmesinin toplam yanıt süresinin baskın bileşeni olduğu anlamına gelir.

Neden region seçimi kritik?

Uygulama sunucusu ile Redis arasındaki her komut bir ağ round-trip'idir. Aynı veri merkezi içinde bu 0,5–1 ms iken, farklı şehir arasında 5–15 ms, farklı kıta arasında 80–200 ms olabilir. Bir sayfa yüklenirken 50 Redis komutu çalışan bir uygulama, ağ gecikmesine bağlı olarak 100 ms ile 5 saniye arasında fark yaşar.

Bu nedenle Redis her zaman uygulama sunucularıyla aynı region'da, mümkünse aynı zon'da konumlandırılır.

Türkiye'deki uygulamalar için Türkiye veri merkezi

Cloud server'ı İstanbul'da olan bir uygulama için Redis'in de İstanbul'da olması, sayfa render süresinde kullanıcının doğrudan algıladığı performans farkını yaratır. Almanya'daki ElastiCache instance'ı ile çalışan aynı uygulama, her Redis çağrısında 50–70 ms ek gecikme yer; tipik bir sayfa render'ında bu yüzlerce ms toplama olarak yansır.

Connection pooling ve pipeline kullanımı

Redis'in tek thread mantığı, bir komutu tamamlamadan sonrakine geçmemesini ister. Pipeline (birden çok komutu tek round-trip'te göndermek) ve connection pooling (bağlantı kurma maliyetini amortize etmek) ile uygulama tarafında belirgin hızlanma sağlanır. İyi yazılmış bir Redis istemcisi bunları otomatik yapar; geliştiricinin sadece dikkat etmesi gerekir.

Güvenlik ve KVKK uyumu

Redis varsayılan olarak güvenlik açısından "açık" bir araçtır; üretimde mutlaka sıkılaştırılır.

TLS, AUTH ve ACL yapılandırması

Yönetilen Redis hizmetleri varsayılan olarak TLS şifreli bağlantı sunar. AUTH (şifre tabanlı kimlik doğrulama) zorunlu yapılır. Redis 6 ile gelen ACL (Access Control List), her kullanıcıya hangi komutları çalıştırabileceği ve hangi anahtar pattern'lerine erişebileceği detayında izin tanımlama imkânı verir.

VPC ve özel ağ erişimi

Redis instance'ı internete açık olmamalı, sadece uygulama sunucularının bulunduğu özel ağdan (VPC) erişilebilmelidir. Public IP üzerinden Redis erişimi, denetim açısından düşüş ve güvenlik açığı kaynağıdır. Yönetilen hizmetlerde VPC peering veya private endpoint ile özel ağ erişimi standart sunulur.

Session verileri ve KVKK gereklilikleri

Session store olarak kullanılan Redis, içinde kullanıcı kimlik bilgileri, sepet içerikleri, kişiselleştirme tercihleri tutar. Bu veriler KVKK kapsamında kişisel veri sayılır. Türkiye'deki bir kullanıcının session verisinin yurt dışındaki bir Redis instance'ında tutulması, açık rıza ve standart sözleşme yükü doğurur. Türkiye'de tutulan bir DBaaS Redis bu yükü ortadan kaldırır.

Cloud4U Türkiye DBaaS ile yönetilen Redis veritabanınızı kurun

Üretim Redis'i bir yan-iş değildir; persistence, replikasyon, failover, izleme ve sürüm yükseltme süreçleri operasyonel olarak yer kaplar. Cloud4U Türkiye DBaaS Redis hizmeti, bu süreçleri sizin yerinize üstlenir; siz sadece bağlantı bilgilerini alıp uygulamanızı bağlarsınız.

• Türkiye veri merkezi ve <1 ms ağ gecikmesi: İstanbul'daki uygulama sunucularınızdan Redis'e milisaniye altı erişim; KVKK kapsamında yurt içi veri konumu; kişisel veri içeren session store senaryolarında uyum yükü ortadan kalkar.
• Otomatik yedekleme, replikasyon ve 7/24 Türkçe destek: RDB + AOF hibrit persistence, master-replica failover, planlı sürüm yükseltme ve 7/24 Türkçe konuşan kıdemli DBA desteği.
• TRY üzerinden öngörülebilir fiyatlandırma: Faturanız TRY bazlıdır, kur sürprizi yaşamazsınız; ihtiyacınıza göre RAM kapasitesi ve HA topolojisi seçimi.

Redis altyapınızı yönetim yükü olmadan üretime almak için Cloud4U Türkiye DBaaS sayfasını ziyaret edin, ücretsiz deneme ve fiyat teklifi alın. Mevcut self-hosted Redis'inizden göç için ekibimiz veri kopyalama ve cutover planlamasını birlikte yapar.