Docker, Kubernetes, Kafka, Redis ve Elasticsearch'i Ölçek İçin Nasıl Kullanıyorum

Altyapı anahtar kelimelerini ne yaptığını söylemeden listelemeyi sevmiyorum. Docker, Kubernetes, Kafka, Redis ve Elasticsearch ancak kullanım somutsa anlamlı sinyaldir. B2B projelerimde ve platform araçlarımda bunları nasıl konumlandırdığımın dürüst versiyonu bu.

B2B sistemlerde Redis

Redis, son müşteri işlerimde en doğrudan kanıtlanmış B2B bağımlılığı. Digiflow'da anket slaytları ve kırtasiye iş akışları gibi yüksek verimli cache yollarında seçici kullanılıyor; amaç temel iş durumunu Oracle'da otoritatif tutarken tekrarlı pahalı okumaları azaltmak. E-Export City'de Redis, Socket.io bildirim sayaçlarını destekliyor; böylece gerçek zamanlı mesajlaşma ve okunmamış sayıları yalnızca memory socket state'e bağlı kalmıyor. Pometop'ta katalog/yönetim yükleri ve ödeme konuşma durumu için Redis destekli dağıtık cache yapılandırması var; API örnekleri restart olduğunda veya yatay ölçeklendiğinde bu önem kazanıyor.

Teslimat ve araçlarda Docker

Docker iki şekilde görünüyor. Proje işlerinde yerel bağımlılıkları tekrarlanabilir kılmak için kullanıyorum: veritabanları, cache'ler, analiz araçları ve servis stack'leri geliştirici makinesini snowflake'e çevirmeden başlatılabiliyor. Ürün araçlarında ise Re-Shell, yeni servislerin container hikayesi sonradan eklenmesin diye Docker uyumlu servis iskeletleri ve compose dosyaları üretiyor.

Platform üretiminde Kubernetes

Kubernetes en güçlü şekilde platform işimde görünüyor. Re-Shell, workspace yapılandırmasından Deployment, Service, HPA, NetworkPolicy, Helm chart ve GitOps varlıkları üretiyor. Bu, her B2B müşterinin prod'da Kubernetes çalıştırdığını iddia etmekle aynı şey değil. Bu uygulamalı altyapı aracı: CLI deployment varlıklarını üretiyor, YAML şeklini testlerde doğruluyor ve ölçeklenebilir servislerin ihtiyaç duyduğu readiness/liveness sınırlarını modelliyor.

Kafka ve Redis Streams

Kafka, Re-Shell'in async transport ve message-queue iskeletlerinde yer alıyor. Amaç, üretilmiş servislere net bir event-streaming yolu vermek: producer, consumer, topic, consumer group, dead-letter davranışı ve yerel Docker compose desteği. B2B sistemlerde bu desene iş akışı downstream işi beklememeli dediğim yerlerde giderim: bildirimler, analitik, audit event'leri, entegrasyonlar ve uzun süren iş süreçleri.

Elasticsearch ve gözlemlenebilirlik/arama

Elasticsearch, Re-Shell şablonlarında full-text search, indexing, analytics ve ELK/EFK tarzı log aggregation için görünüyor. Pratik ölçek kullanımı net: birincil transactional veriyi operasyonel veritabanında tut, arama/log/analitik görünümlerini ayrı index'le; böylece kullanıcı araması ve operasyonel debugging ana write path'i cezalandırmasın.

Takip ettiğim kural

Bu araçları mimariye ancak gerçek bir darboğazı kaldırdıklarında veya operasyonel riski azalttıklarında koyarım. Redis, tekrarlı okumalar veya socket state ölçek problemi olduğunda yerini hak eder. Kafka, iş async ve replayable olmalıysa hak eder. Elasticsearch, arama veya logların kendi read model'ine ihtiyacı olduğunda hak eder. Docker ve Kubernetes de tekrarlanabilir ortamlar ile kontrollü rollout/scale davranışı basit tek sunucu deploy'undan daha önemli olduğunda yerini hak eder.