Elasticsearch'te Tenant Başına Index: 7.000 Shard Sonrası

Bir fintech due-diligence platformu, çoğu Elasticsearch danışmanını irkiltecek bir rakamla geldi: prod cluster'da 7.000 index, 7.000 shard, toplam 400 GB veri. Hesap başına bir index. Index'lerin %90'ı 100 MB'ın altında. Elasticsearch 7.x, 20 GB heap, production'a çıkışa bir ay var.

Kendi yük testleri 7.000 index + 3 TB ile "sorunsuz çalışıyor" diyordu—ve dürüst olalım, çalışıyordu da. İlk soruları doğru soruydu: bu neden henüz sorun değil? İkincisi daha da iyiydi: sorun olmadan önce monitoring kuralım. Bu rehber, o toplantıda verdiğim cevabın yazılı hali.

Kısa cevap: Binlerce minik index ilk gün çalışır; çünkü 7.x'te boşta duran shard ucuzdur ve 400 GB modern donanım için hiçbir şeydir. İş, cluster state, shard başına heap maliyeti ve cluster.max_shards_per_node tavanı büyümeye yetiştiğinde bozulur—genelde tam da trafik arttığında. Heap başına shard hesabını yapın, Stack Monitoring'de index bazlı index/search rate'i izleyin, GC'yi takip edin ve tenant sayısı ikiye katlanmadan konsolidasyon planını (routing'li ortak index veya shrink + ILM) hazırlayın.

Kurulum: hesap başına bir index

Tenancy modeli en basitiydi: her hesaba bir index. Gerçek avantajları var—tenant silmek bir DELETE index, tenant'a özel mapping bedava, erişim kontrolü net. Kullanıcıların %90'ı free tier olunca bu index'lerin çoğu neredeyse boş duruyor.

Cluster'ın aritmetiği şöyle:

400 GB / 7.000 shard ≈ shard başına ortalama 57 MB

Elastic'in kendi shard boyutlandırma rehberi 10–50 GB aralığından bahseder. Buradaki ortalama shard bunun üç kat mertebe altında. Tek başına ölümcül değil—ama cluster, birkaç doğru boyutlu index'in taşıyabileceği veri için shard overhead'ini 7.000 kere ödüyor demek.

Üzerinde durulması gereken bir detay: 7.000 index'in toplamda 7.000 shard etmesi, index başına bir primary, sıfır replica demek. Pre-production testi için sorun değil. Production'da ise tek bir data node kaybı veri setinin bir kısmını red yapar. Replica'lar shard sayısını ikiye katlar—yani production için planlanacak gerçek sayı 7.000 değil, 14.000'di.

Bugün neden çalışıyor?

Yük testinin geçmesinin üç dürüst sebebi:

• 7.x affedici. Elasticsearch 7, shard başına heap maliyetini 6.x'e göre ciddi düşürdü, cluster state güncellemelerini ucuzlattı. Trafik almayan shard çoğunlukla sadece orada durur.
• Veri küçük. 400 GB—testteki 3 TB bile—sıradan node'lara rahat sığar. Burada darboğaz disk veya I/O değil.
• Trafik küçük—şimdilik. %90 free-tier kullanıcı, index'lerin çoğunda sıfıra yakın index ve search rate demek. Toplantıda kendileri söyledi: launch sonrası "search rate artacak." Değişecek olan değişken tam olarak bu.

Nerede acıtmaya başlar?

Cluster state ve master node

Her index; mapping, settings ve routing kaydıyla cluster state'te yer kaplar. 7.000 index'te her index oluşturma, mapping değişikliği veya settings güncellemesi, master'ın daha büyük bir state'i tüm node'lara yeniden yayınlaması demek. Signup dalgaları—her yeni hesap bir index yaratıyor—master'da pending-task kuyruğuna dönüşür.

Heap: GB başına shard kuralı

Klasik 7.x pratiği: data node'da heap'in GB'ı başına en fazla ~20 shard. 20 GB heap ile node başına kabaca 400 shard eder. Replica'lı 14.000 shard'ı bu kurala sığdırmak 35 civarı data node heap'i ister—ya da kural sessizce çiğnenir ve kendini sonradan GC baskısı olarak gösterir. Müşterinin monitoring listesinde GC collection kontrolü açıkça vardı. Doğru refleks: old-gen GC'nin sinsice artması, oversharding'in kendini duyurma biçimidir.

Sert tavan

7.x, cluster.max_shards_per_node: 1000 varsayılanıyla gelir. Hesap sayısındaki doğrusal büyüme shard sayısında doğrusal büyümedir ve bir gün index oluşturma shards_limit hatasıyla düpedüz durur. Ayarı yükseltmek yara bandıdır, plan değildir.

Isırmadan önce izleyin

İkinci gündem maddesi monitoring'di ve böyle bir cluster'da liste jenerik değil, spesifik olmalı:

• Index bazlı index rate ve search rate — Kibana Stack Monitoring, Indices sekmesi. Index-per-tenant tasarımda bu, bedavaya tenant bazlı throughput demek: launch sonrası hangi hesabın ısındığını birebir görürsünüz. Toplantıda birlikte yürüdüğümüz ekran buydu.
• Cluster health ve pending tasks — GET _cluster/health içindeki number_of_pending_tasks; bu topolojide master'daki iş kuyruğu ilk duman alarmıdır.
• GC ve heap — GET _nodes/stats/jvm; sadece heap yüzdesine değil, old-gen collection süresinin trendine alarm kurun.
• Shard sayısı vs. limit — toplam shard'ı cluster.max_shards_per_node × data node sayısı tavanına karşı izleyin, tavana yaklaşmadan alarm alın.
• Audit log — müşterinin açık talebiydi; due-diligence ürününde "kim neyi sorguladı" overhead değil, üründür.

Bunlara elle bakıcılık yapmak istemiyorsanız, searchali.com monitoring tam olarak bunun için var.

Konsolidasyon yolu

Index-per-tenant'ı bir gecede terk etmek zorunda değilsiniz; ama bir varış noktanız olmalı:

POST /tenant_shared/_doc
{ "account_id": "acme", ... }

• Ortak index + routing + filtered alias: küçük (free-tier) tenant'lar account_id ile route edilen tek ortak index'te yaşar; her biri filtered alias arkasında olduğundan uygulama kodu neredeyse değişmez. Büyük, ödeme yapan tenant'lar kendi index'lerini korur—buradaki 90/10 kullanıcı dağılımına neredeyse birebir oturan hibrit model.
• Soğuk tenant'ları shrink/merge edin: aylardır yazılmayan index'ler ortak index'e reindex + DELETE adayıdır.
• Zaman bazlı kalan ne varsa ILM'e bağlayın (audit log, aktivite kayıtları); retention cron script'i değil, policy olsun.

Bunlar uygulandı mı? Bunu iddia etmeyeceğim—elimdeki evidence pack bir ilk toplantı notu ve içinde sonuç yok. Arkasında durduğum şey teşhis ve yukarıdaki playbook; aynısını sonrasında duvara gerçekten çarpan cluster'larda uyguladım.

Sık Sorulan Sorular

Elasticsearch'te kaç index "çok fazla"dır?

Tek bir sayı yok—bütçe, heap'in GB'ı başına shard (~20/GB, 7.x pratiği) ve cluster-state boyutudur. 20 GB heap üzerinde 7.000 minik shard, cluster boşta sağlıklı görünse bile bu bütçenin ruhunu ihlal eder.

Index-per-tenant bir anti-pattern mi?

Özünde değil. İzolasyon, tenant bazlı silme ve tenant'a özel mapping için mükemmeldir. Tenant sayısı sınırsız büyüyüp tenant'ların çoğu minikleşince anti-pattern'e dönüşür—tam da %90 free-tier tablosu. Hibrit model (küçüklere ortak index, büyüklere özel) avantajları korur.

7.000 index'lik yük testi neden geçti?

Çünkü boştaki shard ucuz, 3 TB da küçük. Launch sonrası değişkenleri—artan search rate, replica shard'lar, signup kaynaklı index oluşturma—simüle etmeyen yük testleri geleceği değil, bugünü doğrular.

Oversharded bir cluster'da ilk neye alarm kurmalı?

Master pending tasks, data node'larda old-gen GC süresi ve max_shards_per_node tavanına karşı toplam shard sayısı. Bu üçü, kullanıcı bir şey fark etmeden önce öter.

Öğrendiklerimiz

1. Bölmeyi yapın. Toplam veri ÷ toplam shard, en hızlı oversharding testidir; 10–50 GB hedefe karşı 57 MB ortalama, hikâyeyi tek satırda anlatır.
2. Replica'yı plana dahil edin. Sıfır replica ile 7.000 shard, production'da 14.000 demektir—heap ve node sayısını gerçek sayıya göre planlayın.
3. 7.x'te heap'in GB'ı başına ~20 shard bütçeleyin ve cluster.max_shards_per_node tavanını büyüme yetişmeden kontrol edin.
4. Bu tasarımda index bazlı monitoring, tenant bazlı monitoring'dir—Stack Monitoring'in index rate/search rate ekranını bedava tenant dashboard'u olarak kullanın.
5. Sadece node'lara değil, master'a alarm kurun—pending tasks ve cluster-state çalkantısı en erken sinyallerdir.
6. Hibrit çıkışı (küçük tenant'lara routing + filtered alias) ihtiyaç doğmadan tasarlayın, incident sırasında değil.

Index-per-tenant bir cluster işletiyorsunuz ve ne kadar pistiniz kaldığından emin değil misiniz? searchali.com üzerinden ulaşın.