ElasticSearch Hosting Maliyet/Performans Analizi: Net Rehber (2026)

ElasticSearch (ES) barındırmak, klasik web uygulaması hosting’inden farklı bir bütçe kalemidir. Çünkü ES; CPU, RAM, disk I/O, ağ bant genişliği ve özellikle arama/indeksleme yüküyle birlikte “toplam sahip olma maliyeti” (TCO) çıkarır. Bu rehberde 16.10.2026 koşullarına göre ElasticSearch hosting maliyetini kaliteyle birlikte ölçmeyi öğreneceksiniz: hangi kaynaklar parayı yiyor, hangi mimari kaliteyi yükseltiyor ve hangi seçeneklerde maliyet gerçekçi şekilde düşüyor.

Aşağıdaki başlıklarda hedeflediğimiz şey; “marka seçmek” değil, ölçülebilir kriterlerle doğru altyapıyı seçmek. Sonunda da kendi yük senaryonuza göre karar verebileceğiniz net bir kontrol planı bırakıyorum.

ElasticSearch’te maliyeti belirleyen 6 gerçek kaynak

ElasticSearch’te maliyeti belirleyen şey çoğu zaman “kaç GB depolama var?” sorusu değildir. Asıl farkı yaratanlar, kaynakların birlikte nasıl kullanıldığıdır.

1) Arama gecikmesi (latency) = CPU + heap + shard düzeni

Arama işlemleri; query türü (term/range/full-text), filtreleme ve aggregations nedeniyle CPU tüketir. Ayrıca ES’in JVM heap alanı (genelde RAM’in bir kısmı) ve shard (parça) sayısı gecikmeyi doğrudan etkiler.

Net nokta: Aşırı shard sayısı, küçük indekslerde bile ek bellek ve CPU maliyeti doğurur. Bu, “disk dolu değil ama sistem yavaş” senaryosunu tetikler.

2) İndeksleme hızı = disk I/O + refresh/merge davranışı

ElasticSearch, belgeleri ekledikçe segment üretir ve bunları zamanla birleştirir (merge). Bu merge işlemleri disk I/O’yu artırır. Yüksek ingest senaryosunda (log toplama, event akışı) maliyet en çok burada şişer.

Net nokta: “SATA disk” yerine daha yüksek IOPS sağlayan disk tipleri (NVMe gibi) performansı belirler; ancak maliyet artabilir. Doğru boyutlandırma burada kritiktir.

3) Replica sayısı = maliyetin çarpanı

Replica (yedek kopya) sayısı arttıkça hem disk hem de arama kapasitesi artar. Kalite (okuma dayanıklılığı ve ölçek) yükselirken, maliyet de çoğalır.

Net karar kuralı: - Yüksek okuma var, arama gecikmesi düşük olmalı: replica artırma mantıklı. - Yazma (ingest) ağır ve para sınırlı: replica yerine shard/ilm (index lifecycle management) stratejisiyle veri yaşam döngüsünü optimize etmek genellikle daha ekonomiktir.

4) Bellek (RAM) = cache + heap

ES, sık erişilen verileri page cache ve heap üzerinden yönetir. RAM yetersizse disk okuması artar, latency yükselir.

Net nokta: Sadece “toplam RAM” değil, heap ayarı ve ilgili esnada GC (garbage collection) davranışı önemlidir. Çok yüksek heap de sorun üretebilir.

5) Ağ (network) = replikasyon ve cross-node trafik

Birden fazla düğüm (node) kullanırken replikasyon, recover/restore ve büyük shard taşımalarında ağ maliyeti doğar.

Net nokta: “Aynı veri merkezinde” olmak genelde maliyeti düşürür. Farklı lokasyonlara yaymak veya yüksek paket kaybı latency’yi büyütür.

6) Yedekleme ve geri yükleme = operasyonel maliyet

ES yedekleri sadece dosya kopyalamak değildir; snapshot/restore süreçleri doğru tasarlanmazsa geri dönüş süresi uzar (RTO büyür), bu da dolaylı maliyet demektir.

Net nokta: Snapshot’ların reposu (S3 uyumlu storage vb.), şifreleme (encryption at rest), saklama politikası ve geri yükleme testleri maliyet/kaliteyi birlikte etkiler.

Hosting seçeneklerini maliyet/kaliteye göre kıyaslayın

ElasticSearch için yaygın seçenekler şunlardır: - Yönetilen Elastic/Elastic Cloud benzeri servisler - Kendi kurulumunuz (VPS/VDS/dedicated) üzerine ES - Container tabanlı kendi altyapınız (Kubernetes veya benzeri)

Aşağıdaki tablo “genel” kıyas sağlar; gerçek fiyatlar sağlayıcıya göre değişir. Bu rehberin amacı doğru karar çerçevesini kurmaktır.

Net karar yaklaşımı: - Eğer arama/ingest işi “çekirdek iş” ve uzman ekibiniz yoksa yönetilen servis maliyetini, “operasyon riskini azaltma” olarak düşünün. - Uzmanlığınız varsa kendi kurulumunda maliyet düşürme şansı daha yüksektir; ancak yanlış shard/heap ayarları maliyeti geri çağırır (daha çok node, daha çok RAM, daha çok disk).

Ölçekleme planı: Node eklemeden önce doğru ayarlar

ElasticSearch’te maliyeti düşüren en net yöntem, “daha çok kaynak al” değil; önce mevcut kaynakla verimi artırmaktır.

1) Shard tasarımı: maliyeti ve performansı aynı anda etkiler

Shard sayısını doğru kurmak hem disk hem heap hem de CPU maliyetini etkiler.

Uygulamada net kontrol: - Her indeks için shard sayısını, beklenen veri hacmi ve yaşam süresiyle uyumlu yapın. - Çok sayıda küçük indeks yerine ILM ile yaşam döngüsü tasarlayın.

2) Refresh aralığı ve bulk ingest

Yüksek ingest’te refresh çok sık olursa performans düşer. Bulk ingest kullanımı ve refresh ayarlarıyla maliyet/kalite dengesi kurulur.

Net kontrol: - Büyük yüklemeler sırasında refresh aralığını uzatmayı, araya test koyarak uygulayın. - Bulk boyutunu ölçerek belirleyin; tek seferde dev bulk, heap baskısı yaratabilir.

3) Index lifecycle (ILM) ve veri sıcak/soğuk katmanlama

Sık sorgulanan veriler sıcak tutulur; daha sonra daha ucuz depolama/ daha az performanslı node’lara taşınır.

Net kontrol: - Log ve event gibi zaman serisi verilerinde ILM kullanın. - Saklama süresi gereksiz uzarsa maliyet kalıcı artar.

Maliyet hesaplaması için ölçülebilir KPI’lar

“Maliyet”i sadece saatlik fiyatla düşünmeyin. ES’te kaliteyi gösteren performans metrikleriyle birlikte bakın.

Önerilen KPI seti

• P95/P99 arama latency (ms): Kullanıcı deneyimi
• İndeksleme için: docs/sec ve ingest gecikmesi
• CPU utilization (%): query/merge yük payı
• JVM heap kullanım ve GC: kararlılık
• Disk I/O (read/write IOPS ve latency): özellikle merge anlarında
• Replica/primary durumları: relocation/recovery süreleri
• Snapshot süresi ve restore testi: geri dönüş RTO

Net yorumlama kuralı

• CPU yüksek ama disk düşükse: shard/query optimizasyonu ve heap/GC ayarlarını kontrol edin.
• Disk I/O yüksek ve latency artıyorsa: refresh/merge ayarları veya disk tipi/IOPS kapasitesi hedef olmalı.
• Heap doluyorsa: doğru boyutlandırma ve mapping/field sayısı (özellikle çok cardinality) gözden geçirilmelidir.

Somut karşılaştırma: Küçük-orta ölçek örnek senaryosu

Aşağıdaki örnekler “kesin bir fiyat” değil, hangi kaynağın nereye gittiğini gösterir.

Senaryo A: 50 milyon doküman, log benzeri zaman serisi

Varsayım seti (örnek): - Veri günlük büyüyor, ilk 7 gün yüksek sorgu, 30-90 gün daha az sorgu - ILM ile hot/warm/cold ayrımı uygulanacak

Net maliyet etkisi: - Hot dönemde daha fazla RAM ve daha hızlı disk gerekir. - Cold dönemde replica ve refresh mantığı gözden geçirilir.

Pratik seçim: - Yönetilen servis: hızlı devreye alma, ILM ayarlarıyla maliyeti kontrol etmek kolay. - Kendi kurulum: ILM ve shard stratejisi doğruysa daha düşük birim maliyet mümkün; ancak ayar ve test süresi gerektirir.

Senaryo B: E-ticaret araması (kısa SLA, yüksek kullanıcı eşzamanlılığı)

Varsayım seti (örnek): - Çok sayıda arama sorgusu, aggregations ve filtreleme - SLA: P95 latency düşük olmalı

Net maliyet etkisi: - Replica sayısı ve node ölçekleme, arama kapasitesini belirler. - Ağ ve cache etkisi büyür: aynı lokasyonda node’ları konumlandırmak önemlidir.

Pratik seçim: - Performans hedefi net ise dedicated veya yüksek SLA’lı yönetilen planlar mantıklıdır. - Kendi kurulumda doğru donanım seçimi (disk IOPS + yeterli RAM) yapılmazsa, “ucuz başladım pahalıya döndü” riski oluşur.

ElasticSearch maliyetini düşüren net stratejiler

Aşağıdaki maddeler doğrudan maliyeti etkiler ve çoğu yanlış anlaşılmayı giderir.

1) Gereksiz alanları indekslemeyin (mapping disiplini)

Her alan indekslenirse shard segmentleri büyür; heap ve disk maliyeti artar.

Net kontrol: - Sorguda kullanılmayan alanları ya hiç indekslemeyin ya da “doc_values” gibi seçenekleri dikkatle yönetin.

2) Replica ve shard sayısını veri yaşam döngüsüne bağlayın

Replica artırmak kaliteyi yükseltir ama maliyeti çarpar. Replica’yı her zaman aynı tutmayın.

Net kontrol: - Sıcak dönemde replica yüksek, soğuk dönemde daha düşük planlayın.

3) Snapshot saklama süresini veri geri dönüş hedefiyle belirleyin

“Ne olur ne olmaz” diye saklama uzarsa maliyet kalıcı artar.

Net kontrol: - RPO/RTO hedeflerine göre saklama politikanızı tanımlayın. - Restore testi yapın: snapshot’ın gerçekten kullanılabilir olduğunu doğrulayın.

4) Yük testiyle kapasiteyi belirleyin

ES’te “tahmin” yerine yük testi vardır. Yanlış kapasite seçimi genellikle maliyeti artırır.

Net kontrol: - Arama yoğunluğu ve ingest yoğunluğu birlikteyken test edin. - P95/P99 ve CPU/heap birlikte izleyin.

Sık yapılan 8 hata ve maliyete etkisi

• Sharding’i otomatiğe bırakıp kontrol etmemek: Heap ve disk maliyeti gereksiz büyür.
• Aşırı replica ile başlamak: Kalite artar ama maliyet çarpan gibi yükselir.
• Disk IOPS hedefini göz ardı etmek: Merge dönemlerinde sistem kilitlenir.
• Refresh’ı agresif tutmak: Ingest maliyeti artar, latency bozulur.
• Yetersiz RAM ile “idare etmek”: Page cache ve heap sorunları büyür.
• Snapshot’ı sadece almak sanmak: Restore testi yapılmazsa RTO uzar.
• Mapping disiplini olmadan büyümek: Alan sayısı ve cardinality maliyeti şişirir.
• Network/zone tasarımını ihmal etmek: Recover/relocation süreleri uzar.

Net karar kontrol listesi (sonraki adım)

ElasticSearch hosting maliyet/kalite analizini tamamlamak için aşağıdaki listeyi kullanın.

1) Yük profili

• Günlük ingest (docs/sec ve büyüme miktarı)
• Arama günlük istek sayısı ve yoğun saat piki
• SLA: P95/P99 hedefi (ms)

2) Veri yaşam döngüsü

• Sıcak veri süresi (hot)
• Soğuk veri süresi (warm/cold)
• Toplam saklama (gün/ay)

3) Dayanıklılık ve kurtarma

• RPO ve RTO hedefi
• Snapshot sıklığı ve saklama süresi
• Restore testi planı

4) Kaynak hedefleri

• CPU tavanı: normalde kaç % hedefleniyor?
• Heap kullanım aralığı ve GC davranışı
• Disk I/O beklentisi (özellikle merge anları)

5) Seçenek kararı

• Uzman ekibiniz var mı? (kendi kurulum için)
• Devreye alma süresi kritik mi? (yönetilen servis için)
• Geniş ölçek ve uzun vadeli maliyet kontrolü hedef mi?

Bu kontrol listesine göre net bir plan çıkarın. Ardından iki seçeneği (ör. yönetilen servis vs kendi kurulum) aynı yük test senaryosuyla karşılaştırın. Böylece maliyeti “liste fiyat” değil, hedef KPI’larla gerçekçi biçimde anlarsınız.

Sonuç olarak: ElasticSearch hosting’te doğru karar, sadece donanım almak değil; shard/ILM/mapping gibi ayarların maliyete etkisini ölçmek ve snapshot/restore ile kurtarma kalitesini garanti altına almaktır. Önce yük profili + SLA + veri yaşam döngüsünü yazın; sonra iki mimariyi aynı KPI setiyle karşılaştırın ve en düşük toplam TCO’yu veren seçeneği seçin.