Tek bir Elasticsearch kümesinde yüz milyarlarca doküman, binlerce indeks ve diskta 700 TB üzeri veri olduğunu düşünün—küresel bot yönetimi analitiğinin omurgası. Bu boyutta bir kümede “yeniden başlat, düzelir” diye bir şey yok. Saldırı trafiğiyle indeksleme tıkandığında, koordinatör düğümlerde çöp toplama (GC) zıpladığında ve küme durumu tek başına yüzlerce megabayt olduğunda, her olay; kurtarma mekanizması ile gelen yazma yükü arasında bir yarışa dönüşür.
Beni dışarıdan bir çift göz olarak çağırdılar: stabiliteyi artırmak, yazma reddini (write rejection) azaltmak ve ekibe kısa vadede uygulanabilir öneriler vermek—bu büyüklükte bir kümenin tek sprintte “tamamen iyileşeceğini” iddia etmeden.
Sorun
DataDome’un Elasticsearch altyapısı uygulamanın kalbi: kabaca müşteri başına bir indeks, yaklaşık 250 müşteri; tek bir çok büyük müşteri ise toplam hacmin önemli bir kısmını (yaklaşık %25 civarı) üretiyor. Trafik dünyadaki birçok POP’tan geliyor, Kafka üzerinden akıyor ve toplu (bulk) indeksleme ile Elasticsearch’a yazılıyor—normal şartlarda dayanıklı bir tasarım; çünkü Kafka, Elasticsearch “şimdi olmaz” dediğinde veriyi arka planda bekletebiliyor.
Sorun, bu ölçekte operatörlerin çok iyi bildiği şekillerde göründü:
- Trafik sıçramalarında (saldırı kaynaklı sıçramalar dahil) indeksleme reddi ve taşma kuyruklarına düşen yeniden oynatmalar.
- Yüksek bekleyen küme görevleri ve yavaş cluster-state yayılımı—durum devasa olduğunda kaçınılmaz.
- Koordinatör katmanında yükselmiş GC ve baskı altında kümeden ayrılıp tekrar katılan düğümler.
- Önceki tam küme RED olaylarında, küme eş zamanlı yoğun indeksleme ile recovery/allocation işini birden yürütürken sıcak veri düğümlerinin dalgalanması.
Ekip uzun vadeli cevabı zaten biliyordu—işi birden fazla kümeye bölmek ve müşteriye özel taşımaları sürdürmek—ama *şimdi* stabilite ve netlik istiyordu; ayrıca sürüm ve operasyon için inandırıcı bir yol haritası.
Teşhis
Küme durumu ağırlığı ve operasyonel sürtünme
Bu ölçekte ~200 MB mertebesinde cluster state ihmal edilecek bir detay değil. Her master seçimi, ayar değişikliği ve ILM kaynaklı rollover aynı mekanizmaya yük bindiriyor. Eylül 2023’teki bir olayda binlerce ILM rollover işi bekleyen kuyruğa itildiğinde küme “biraz yavaş” hissettirmiyor; su altında kalıyor.
Recovery + indeksleme: olay anında kötü ikili
Elasticsearch çoğu zaman shard tahsisi/kurtarma ile tepe indekslemeyi aynı anda kaldırmakta zorlanır. Pratik reçete net: recovery yetişene kadar indeksleme baskısını düşürün; uç durumlarda pending boşalana kadar ILM’yi duraklatın. Bu teori değil—izleme toplama devreye girdikten sonra küme RED olduğunda ve kuyruk şiştiğinde yaptığımız şey buydu.
Ingest yapılandırması ve pratikler
Pipeline aşırı büyük bulk partileriyle yapılandırılmıştı—yüzlerce MB mertebesinde—Logstash tarzı hatlarda sık görülen birkaç MB bandının çok üzerinde. Aşırı büyük bulk’lar, sıcak katmanlarda bellek baskısını ve hata modlarını büyütebilir. Çözüm “tek knob sonsuza kadar” değil; daha küçük partileri testle doğrulamak ve kontrollü ilerlemek.
Topoloji ve trafik yönlendirme
Mimari sıcak / ılık / soğuk katmanları ve ayrılmış koordinatör düğümlerini içeriyordu. Operasyonel bulgular klasik örüntülere işaret ediyordu: trafik yanlış yere bindiğinde kuyruklar şişiyor, circuit breaker uyarıları heap/fielddata baskısını gösteriyor. Yön standart ama disiplin ister: HTTP arama/yazma trafiğini koordinatör yollarına verin, veri düzlemi işini data düğümlerinde tutun, bir alt küme düğüm “komşularından daha sıcak” olduğunda shard dağılımını izleyin.
Çözüm
Bunu tek bir “sihirli ayar” projesi gibi ele almadık. İş; anında olay müdahalesi kalıpları, ayar ve ingest hijyeni ve yol haritası (sürüm yükseltme, küme bölme/taşıma) bir araya geldi.
Elasticsearch fiziğine uygun müdahale
Küme RED olduğunda ve sıcak düğümler dalgalandığında öncelik, düğümler yeniden toplanırken yeni cluster-state işi üretmeyi kesmekti. Bunun anlamı:
- Bekleyen kuyrukta binlerce ILM rollover varken geçici olarak ILM’yi durdurmak (
_ilm/stop)—nefes alanı açmak. - Düğümler geri gelirken baskıyı düşürmek için Kafka’dan indeksleme hızını azaltmak.
- Pending görevler boşalıncaya kadar bekleyip sonra ILM’yi yeniden açmak (
_ilm/start).
Bu olayda, ölçekte birikmiş ILM işleri varken ölçülen uçtan uca toparlanma süresi yaklaşık 24 dakikaydı—“anında” değil; doğru sırayla doğru kollar çekilince kontrol altında.
Recovery ayarı (yönsel)
Büyük shard hareketleri sırasında recovery’yi daha öngörülebilir kılmak için recovery throughput ve ilgili eşzamanlılık ayarlarını (örneğin daha düşük bir başlangıçtan <code>indices.recovery.max_bytes_per_sec</code> artışı ve concurrent recovery/rebalance limitleri) konuştuk. Bunlar her ortamda farklıdır; mesele recovery’yi açlıktan ölmemek, ama disk ve ağı da boğmamak.
Yan yükü azaltmak
Slowlog çok değerli olabilir; ama şablonlar üzerinden geniş açıldığında stabilize olma aşamasında ek yük de getirebilir. Ekip, baskıyı azaltmak için slowlog’u kapattı—kalıcı bir felsefe değil, operasyonel takas.
Kümayı sarsmadan izleme
Bu kadar büyük bir kümeden metrik toplamak kolay değil. Küçük kümede işe yarayan yöntemler, timeout, retry fırtınası veya ek sorgu yükü yaratırsa dev kümede bir RED daha tetikleyebilir. Nasıl deploy edildiğini—düğüm bazlı toplama, kapsam—iyileştirdik; çünkü “daha çok metrik”, kümayı tehlikeye atıyorsa fayda sağlamaz.
Yol haritası: böl, taşı, yükselt
Kalıcı iyileştirmeler stratejikti:
- Monoliti birden fazla kümeye bölmek (planlama için sürdürülebilir bir üst sınır olarak küm başına ~80 düğüm gibi bir çapa; sınırsız şişirme değil).
- Bölgesel / müşteriye özel taşımaları (örneğin AB iş yükleri) hızlandırarak ortak altyapıdaki baskıyı azaltmak.
- Gerçekçi bir Elasticsearch yükseltme hattı (7.9 → 7.17 → 8.x); operasyonel araçlar (örneğin Kibana Upgrade Assistant) ve ILM/heap ile ilgili sürüm kazanımlarına erişim.
Sonuçlar
Proje notlarında ürün geliri veya benzeri iş KPI’ları yoktu; uydurma rakam yazmayız. Dayanak noktamız operasyonel ölçüler: toparlanma süreleri, küme ölçeği sinyalleri ve değiştirdiğimiz davranışlar.
Bu tür bir görevde en önemli “sonuç” operasyonel güvendir:
- RED senaryoları için tekrarlanabilir bir playbook: ILM duraklat → ingest azalt → pending boşalsın → ILM’yi aç.
- ILM rollover işleri ölçekte biriktiği gerçek bir olayda ölçülen ~24 dakikalık toparlanma penceresi.
- Aşırı büyük bulk boyutunun risk faktörü olduğunun netleşmesi ve aşağı çekmeyi test etmek.
- Küme bölme ve yükseltmelerin asıl maliyet/stabilite kazancı olduğunun hizalanması—tek dev küme üzerinde sonsuz kahramanlık değil.
Öğrendiklerimiz
- Yüzlerce düğüm ve yüzlerce TB’da cluster state boyutu önemlidir. Küme zaten tavandaysa ILM ve rollover koordineli bir fırtınaya dönüşebilir.
- Olay anında indeksleme ve recovery yarışır. Elasticsearch’un mekanik işi bitirmesine izin vermek için ingest’i kısmak ve gerektiğinde ILM’yi duraklatmak gerekir.
- Bulk boyutları bellek ve hata modlarına karşı doğrulanmalıdır—küçük ölçekte “çalışan” varsayılanlar petabyte ölçeğinde zarar verebilir.
- İzleme prod değişikliği gibi tanıtılmalıdır—çünkü bu büyüklükte kümede öyledir.
- Uzun vadeli çözüm mimaridir (kümeleri bölmek, hedefli taşımalar, yükseltmeler); tek dev küme üzerinde sürekli kahramanlık değil.
Elasticsearch veya OpenSearch cluster'ınızla ilgili yardım almak için searchali.com’u ziyaret edin. ILM için Elastic’in Index lifecycle management dokümantasyonuna bakın.