ElasticSearch Hosting Maliyeti: Kaliteyi Düşürmeden Bütçe Planı

ElasticSearch (çoğunlukla Elasticsearch + “ES” olarak geçer) arama, log analizi ve metrik toplama senaryolarında hızlı sonuç verir; ancak yanlış kurulumda maliyet kontrolü zorlaşır. Bu yazıda ElasticSearch hosting için maliyeti belirleyen kalemleri tek tek ayırıyor, “kalite”yi (arama doğruluğu, gecikme, dayanıklılık, kurtarma hızı) düşürmeden nasıl plan yapılacağını anlatıyoruz. Amacımız, ihtiyacı netleştirip kaynak israfını azaltacak somut bir çerçeve sunmak.

ElasticSearch maliyetini asıl belirleyen 7 kalem

ElasticSearch hosting fiyatlarını sadece “RAM” ya da “disk boyutu” ile okumak hata üretir. ES cluster maliyeti aşağıdaki bileşenlerin etkileşimiyle şekillenir:

1. RAM (heap + OS cache): Arama gecikmesini ve segment/field cache verimliliğini etkiler.
2. CPU (çekirdek sayısı + frekans): Indexleme, sorgu derleme ve sıkıştırma iş yükleri CPU’ya dayanır.
3. Storage ve IOPS: Lucene segmentleri diskte yaşar; yoğun indexleme dönemlerinde IOPS belirleyici olur.
4. Replika (replica) sayısı: Dayanıklılığı artırır ama aynı veri için depolama ve yazma maliyetini büyütür.
5. Shards (shard sayısı): Aşırı shard, bellek ve yönetim maliyeti doğurur; az shard ise paralellik azalır.
6. Network (trafik + egress): Cluster arası replikasyon ve kullanıcı sorgu trafiği maliyete yansır.
7. Operasyonel katman: Yedekleme (backup), snapshot saklama, sürüm güncelleme, izleme (monitoring) ve kurtarma testi maliyettir.

1) RAM: “Toplam RAM” değil, heap davranışı

ElasticSearch’te JVM heap boyutu kritik bir parametredir. Kurulumlarda tipik yaklaşım, heap’i sunucu RAM’inin belirli bir oranına sabitleyip (çoğu senaryoda yaklaşık 50% bandı) geri kalanını OS cache olarak bırakmaktır. Bu ayrım kaliteyi doğrudan etkiler: - Heap yetersizse: query latency artar, GC (garbage collection) davranışı kötüleşir. - OS cache yetersizse: diskten okuma artar, özellikle aggregation ve wildcard benzeri sorgularda gecikme yükselir.

Bütçe planlarken hedefiniz “minimum çalışsın” değil; belirli bir gecikme hedefini koruyarak heap/OS cache dengesini kurmak olmalı.

2) Disk/IOPS: “GB”den çok “yazma hızı” ve “okuma kararlılığı”

ElasticSearch Lucene segmentleri üretir. Indexleme arttıkça: - segment yazma - refresh - merge (segment birleştirme) - snapshot gibi okuma-yazma karışık işler ön plana çıkar.

Bu yüzden disk seçerken sadece kapasiteye bakmak yerine şu kriterleri arayın: - SSD/NVMe sınıfı storage - dengeli IOPS (ani düşüş yaşamayan) - mümkünse ayrı disk/volume stratejisi (ör. veri vs log/yedek)

Kalite ölçütleri: Maliyeti doğru tartmak için ölçün

Kaliteyi “gösterge paneli güzel görünüyor” diye değerlendirmek yerine, operasyonel olarak ölçülebilir kriterlere bağlayın:

Önerilen kalite metrik seti

• P95/P99 arama gecikmesi (search latency): Kullanıcı deneyimini belirler.
• Indexing latency ve ingestion backpressure: Log/stream akışında veri kaybı riskini azaltır.
• CPU utilization ve iowait: CPU darboğazı mı disk darboğazı mı ayırt ettirir.
• Heap usage + GC pause: İyileştirme planını doğrudan etkiler.
• Segment merge backlog: Büyük birikmeler kaliteyi düşürür.
• Recovery time (RTO/RPO): Donanım/zone arızasında kaç dakikada ayağa kalkacağınızı belirler.

Bu metrikleri başlangıçtan itibaren izleyin. Çünkü maliyet optimizasyonu, ölçmeden “tahminle” yapılırsa cluster çökmesine kadar gidebilir.

Maliyet modelini basitleştirin: “TCO” yaklaşımı

ElasticSearch maliyeti genellikle aylık sunucu bedeli sanılır. Oysa toplam sahip olma maliyeti (TCO) şu kalemlerle büyür:

• ES düğümleri (data + master/ingest rolü)
• Yüksek kullanılabilirlik için yedek düğümler
• Replikalar nedeniyle ekstra depolama
• Snapshot saklama (aylık GB)
• Trafik (özellikle egress)
• İzleme/alerting (self-host veya managed)
• Operasyon süresi (insan maliyeti)

Basit bir hesap şablonu

Aşağıdaki şablonla maliyeti “tahmini” çıkarın: - 1. Adım: Hedef iş yükünüz için gerekli kapasiteyi bulun (veri büyüme + sorgu sayısı). - 2. Adım: Replica ve shard planıyla gerekli toplam storage’ı hesaplayın. - 3. Adım: Seçtiğiniz instance sınıfının RAM/CPU oranına göre düğüm sayısını belirleyin. - 4. Adım: Kurtarma (recovery) hedeflerine göre master/ingest rol dağılımını ekleyin.

En sık yapılan 5 maliyet hatası ve net düzeltme

1) Aşırı replikayla “her şeyi kurtarırız” demek

Replika artırmak dayanıklılığı yükseltir; fakat depolama ve indexleme maliyetini büyütür. Net çözüm: - Kritik veri için replikayı koruyun. - Daha az kritik indeksleri ayrı lifecycle politikasıyla daha düşük maliyetli saklama katmanına taşıyın.

2) Shard sayısını rastgele artırmak

Shards hem bellek hem de cluster-state yönetimi maliyeti doğurur. Net çözüm: - Index başına shard hedefini iş yükü ve büyüme planına göre belirleyin. - Gereksiz “çok küçük shard” yerine daha doğru segment/rollover stratejisi kullanın.

3) Disk hızını “sonra bakarız” diye ertelemek

Indexleme yoğun olduğunda IOPS yetersizliği kaliteyi doğrudan bozar. Net çözüm: - Yükleme testinde P95/P99 gecikmeye ve iowait değerine bakın. - Disk performansı için pilot test yapmadan geniş yük geçirmeyin.

4) Tek rol ile production yapmak

Master/ingest/data rolleri ayrılaştığında hem stabilite hem de ölçekleme kolaylaşır. Net çözüm: - Küçük cluster’da bile rollerin net ayrımını düşünün. - Master rolünü veri yükünden mümkün olduğunca izole edin.

5) Snapshot’ı “sonra alırız” demek

Snapshot (yedek anlık görüntü) doğru tutulmazsa kurtarma maliyeti büyür. Net çözüm: - RPO/RTO hedefinize göre snapshot sıklığı ve saklama süresi belirleyin. - Kurtarma provası (recovery test) yapın.

Hosting tipi seçimi: Self-host mu, managed mı?

ElasticSearch barındırma seçenekleri maliyeti ve yönetim yükünü farklılaştırır. Aşağıdaki tablo karar vermeyi kolaylaştırır.

NetKıyas mantığıyla bakıldığında: “en ucuz” plan çoğu zaman en hızlı değil, en stabil de değildir. Fiyatı benzer aralıklara çekmek için aynı kalite metriklerini (P95, iowait, heap/GC) karşılaştırın.

Maliyet/kaliteyi birlikte optimize eden referans kurgu

Aşağıdaki kurgular “örnek” senaryolardır; gerçek değerler iş yüküne göre güncellenmelidir.

Senaryo A: Log arşivi + arama (orta trafik)

Hedef: - P95 arama gecikmesi orta seviyede - ingestion sırasında ingestion backpressure yaşamamak

Net optimizasyon: - Replica: kritik indekslerde 1 replika yaklaşımıyla başlayıp gözlemle ilerleyin. - Disk: indexleme yoğunluğunda yüksek IOPS sağlayan storage kullanın. - Roll/ILM: eski veriyi yavaş depolama mantığına taşıyın.

Senaryo B: Kullanıcı araması (yüksek sorgu, daha az indexleme)

Hedef: - sorgu gecikmesini P99 seviyesinde stabilize etmek

Net optimizasyon: - Heap/OS cache dengesini sorgu yüküne göre kurun. - Shard paralelliğini sorgu dağılımına göre ayarlayın; çok küçük shard’lar maliyeti artırır. - Trafik egress maliyeti varsa uygulama yakınlığını (region) optimize edin.

Senaryo C: Eğitim/PoC (düşük maliyet, kontrollü risk)

Hedef: - hızlı deneme ama “kurtarma planı yoksa” kalite düşüşünü kabul etmemek

Net optimizasyon: - Tek bölge yerine en azından snapshot ile geri dönüş planı oluşturun. - Yedek saklama süresini PoC riskine göre sınırlayın; ama snapshot almadan üretime yaklaşmayın.

Pahalıya kaçmamak için seçim kontrol listesi

Satın almadan veya ayarlamadan önce şu kontrol listesini uygulayın:

Donanım/spec kontrolü

• [ ] RAM yeterliliği: heap kullanım grafiği hedef gecikmeyi koruyor mu?
• [ ] Disk: iowait ve merge backlog değerleri artıyor mu?
• [ ] CPU: P95/P99 arama sırasında CPU doygunluğa yaklaşıyor mu?

Mimari kontrolü

• [ ] Replica sayısı net: dayanıklılık ihtiyacı karşılanıyor mu?
• [ ] Shard hedefi: indeks büyüme planına uygun mu?
• [ ] Rol dağılımı: master/ingest veri yükünden ayrışıyor mu?

Yedek/kurtarma kontrolü

• [ ] Snapshot sıklığı: RPO hedefine uyuyor mu?
• [ ] Kurtarma testi: son 30 günde test yapıldı mı?
• [ ] Snapshot saklama maliyeti: aylık GB hesabı yapıldı mı?

ElasticSearch hosting maliyetini düşüren, kaliteyi bozmayan “somut” stratejiler

• İndeks yaşam döngüsü (ILM) kullanın: sıcak (hot) katmandan soğuğa (warm/cold) geçişle storage maliyeti düşer.
• Replica’i kör artırmayın: dayanıklılık ihtiyacına göre seçin; kritik indeksleri ayırın.
• Shards’ı küçültün, doğru sayıda tutun: bellek ve cluster-state maliyeti azalır.
• Rollover stratejisi: sabit tarih yerine veri boyutunu hedefleyen rollover ile shard boyutlarını dengeleyin.
• Pilot yük testleri yapın: “ilk ay ucuz ama üçüncü ay pahalı” sürprizini engeller.
• Eğik ölçekleme planı: trafik artışında sadece CPU eklemek yerine veri/IO metriklerine göre ölçekleyin.

Sonuç: Hemen aksiyon planı çıkarın

ElasticSearch’te maliyeti kontrol etmenin yolu “en düşük fiyatlı” plana kaçmak değil; RAM/CPU/IOPS ile gecikme ve kurtarma hedeflerini birlikte tanımlamaktır. Bugün yapılacak en doğru aksiyon: iş yükünüz için P95/P99 arama gecikmesi ve ingestion gecikmesini hedefleyin, sonra storage (IOPS) ve replica/shard planınızı bu hedeflere göre belirleyin. İsterseniz mevcut cluster’ınıza ait heap/GC, iowait ve snapshot metriklerinizi paylaşırsanız; benzer yükte maliyet/kalite dengesini daha net bir şemayla çıkaracak şekilde yönlendirebilirim.