ElasticSearch Hosting Maliyet/Kalite Analizi: Net Karşılaştırma

ElasticSearch (ES) ile arama, log analizi veya arama-as-a-service kurarken “hangi hosting daha iyi?” sorusu çoğunlukla maliyet ve kaliteyi birlikte düşünmeyi gerektirir. ES tarafında tek bir metrik yoktur: indeks yazma hızı, arama gecikmesi, veri büyümesi, replikasyon, yedekleme ve operasyon riski toplam maliyeti doğrudan etkiler. Bu yazıda size pratik bir maliyet/kalite çerçevesi ve somut seçim kriterleri vereceğim; ayrıca VDS (self-host), managed servis ve bulut seçeneklerini hangi durumda tercih etmeniz gerektiğini netleştireceğim.

ElasticSearch’te maliyeti asıl büyüten 6 unsur

ElasticSearch’te maliyetin “abonelik fiyatı” ile bitmemesi normaldir. Aşağıdaki başlıklar, aynı kullanım senaryosunda bile toplam gideri ciddi şekilde değiştirir.

1) RAM ihtiyacı: veri boyutundan değil, segment/field yapısından

ES’in belleğe (RAM) olan ihtiyacı yalnızca “GB depolama = GB RAM” değildir. Gerçek etkiler şunlardır: - Index mappings ve field sayısı (özellikle text/keyword karışımı) - Lucene segment sayısı ve merge davranışı - Query cache / request cache davranışı - Heap (Java) ayarları ve GC (garbage collection) performansı

Net sonuç: Aynı veri miktarında bile kötü mapping ve aşırı parçalı segmentler, RAM tüketimini artırır; RAM artışı ise ES üzerinde doğrudan maliyettir.

2) CPU: analiz (analysis), aggregations ve kademeli yük

CPU maliyetini etkileyen unsurlar: - Tokenization/analysis (analyzer türleri) - Aggregation (terms, date_histogram, cardinality) - Query sayısı (QPS) ve eşzamanlı kullanıcı - Reindex / bulk işlemleri sırasında CPU piki

Net sonuç: “Gecikme düşük olsun” hedefi varsa, CPU marjı hesaplaması doğru yapılmalıdır. Aşırı sık yeniden indeksleme yapan sistemlerde CPU maliyeti hızla büyür.

3) Disk I/O: özellikle refresh/merge ve bulk

ElasticSearch’in disk davranışı; NVMe vs SSD/SATA gibi seçimlerde belirgin fark yaratır. - Bulk ingest sırasında segment yazımı - Refresh interval - Merge operasyonları

Net sonuç: Log/olay araması gibi sürekli yazılan senaryolarda disk IOPS sınırlaması arama gecikmesine yansır.

4) Depolama çoğaltması: primary + replica = katlanma

En sık maliyet sürprizi replikadan gelir. - Replica sayısı varsayılan olarak 1 kabul edilir (senaryoya göre değişir) - Snapshot (yedek) depolaması ayrıca ücretlenebilir

Net hesap kuralı: Depolama kapasitesi planlarken “veri büyümesi × (1 + replica sayısı) + snapshot payı” düşünün.

5) Ağ (network) ve cross-node trafiği

ES cluster içinde replikasyon, shard hareketleri (shard relocation) ve snapshot transferleri ağ trafiği oluşturur. - Aynı bölgede (region/zone) node dağıtımı - Egress ücretleri veya ağ sınırları

Net sonuç: Uzak bölgelere node dağıtmak arama gecikmesini değil, ayrıca transfer maliyetini artırır.

6) Operasyon riski: upgrade, mapping değişimi, reindex maliyeti

Self-host (kendi sunucunuzda) ile managed arasında kalite/riski ayrı düşünmelisiniz: - ES sürüm yükseltme (upgrade) planı - Disk doluluk yönetimi (watermark) - Mapping değişimi için reindex gerekliliği

Net sonuç: Managed servislerde operasyon iş yükü azalır; ancak birim maliyet genellikle daha yüksektir. Self-host’ta doğru uzmanlıkla maliyet düşer, yanlış planlamada reindex ve downtime maliyeti büyür.

Hosting modelleri: VDS, managed ve bulut servisleri nasıl ayrılır?

Aynı ES yükü için üç yaygın yaklaşım var: VDS ile self-host, managed ES (servis sağlayıcı yönetir) ve bulut sağlayıcının “managed/search” teklifi.

VDS ile self-host: kaliteyi siz kurarsınız

VDS ile ES kurduğunuzda maliyet/kalite tamamen şu değişkenlere bağlı olur: - Donanım kalitesi: CPU modeli, RAM, NVMe/SSD - OS ve kernel ayarları - ES config (heap, shard/replica, refresh/merge) - Yedekleme (snapshot) ve restore pratikleri

Avantaj: Doğru kurulumla birim maliyet düşer. Dezavantaj: İşçilik ve operasyon riski sizde.

Managed ElasticSearch: kaliteyi servis tarafı optimize eder

Managed servislerde genellikle şu konular sizin yerine yönetilir: - Node sağlama ve cluster health takibi - Upgrade planlaması ve bazı best-practice ayarları - Snapshot altyapısı

Avantaj: Operasyon maliyeti azalır. Dezavantaj: Aynı performans için fiyat genellikle daha yüksektir.

Bulut üzerinde managed: network ve ölçekleme avantajı

Bulut sağlayıcının arama hizmetleri (managed) çoğu zaman otomatik ölçekleme, zonlama ve yedekleme entegrasyonları sunar.

Avantaj: Kurumsal güvenlik ve ağ mimarisi daha kolay. Dezavantaj: Egress ve snapshot depolaması maliyeti planlanmazsa artar.

Maliyet/kaliteyi net değerlendirme: karar çerçevesi

Aşağıdaki kontrol listesi, “sadece fiyat” yerine kalite kriterlerini de hesaba katar. Her maddeye puan vererek (ör. 1-5) hangi modelin daha iyi olduğunu net görebilirsiniz.

Önce teknik hedefleri sabitleyin

Aşağıdaki hedefleri yazmadan hosting seçmek çoğunlukla yanlış çıkar: - Gecikme hedefi: p95/p99 arama gecikmesi (ör. 150ms, 500ms) - Yazma hızı: saniyede kaç doküman (docs/sec) - Günlük veri artışı ve beklenen retention (ör. 30/90 gün) - Cluster topolojisi: shard sayısı planı

Sonra kapasiteleri hesaplayın (minimum veri)

Aşağıdaki tablo bir “başlangıç taslağı”dır. Gerçek sayılar sizin mapping ve query tipinize göre değişir; ama yönlendiricidir.

Yedekleme ve restore testi: “var” yetmez

ES’te snapshot (yedekleme) alıp bir gün restore denediğinizde sorun çıkması maliyeti artırır. Bu yüzden: - Snapshot sıklığını (ör. 30 dk / 1 saat) iş yüküne göre seçin - Restore süresini ölçün: “30 dakika mı, 4 saat mi?” - Yedek depolama maliyetini (snapshot retention) hesaba katın

Net hedef önerisi: Kritik sistemlerde yılda en az 1 kez restore provası yapın; mümkünse staging cluster’da aynı mapping ile.

Somut senaryo karşılaştırması: hangi iş yükünde ne seçilir?

Aşağıdaki örnek senaryolar, “hangi hosting modeli” sorusunu daha net yanıtlar. Verileri siz sayısallaştırın, ama seçim mantığı sabittir.

Senaryo A: 30 gün log + arama (sürekli ingest)

Tipik özellikler: Yazma sürekli, sorgu pattern’i karışık (filtre + tarih aralığı + aggregations). - VDS self-host: disk ve replikasyon ayarları doğru yapılırsa maliyet avantajı sağlar. - Managed: operasyon yükü azalır; kapasite artışı daha hızlı yönetilir.

Net karar kuralı: - Eğer ekibinizde ES tuning ve operasyon yapan kişi yoksa managed/bulut managed tercih edin. - Ekibiniz varsa ve mapping/refresh/merge’i iyi yönetebiliyorsanız VDS ile toplam maliyet düşer.

Senaryo B: E-ticaret katalog araması (yüksek okunma, daha az yazma)

Tipik özellikler: Okuma ağırlıklı, indexing incremental. - VDS: cache/refresh ve shard düzeni ile p95 gecikme hedefi tutturulabilir. - Managed: garanti edilen performans daha tutarlı olabilir; ancak birim maliyet yüksek olabilir.

Net karar kuralı: p95 hedefi net ve ölçülebilir ise (ör. 250ms altında) her iki modeli de POC ile test edin; sonucu metriklerle kıyaslayın.

Senaryo C: Arama-as-a-service (müşteri başına farklı tenant)

Tipik özellikler: Multitenant mimari, izolasyon ihtiyacı, farklı retention. - Managed: tenant izolasyonu ve erişim kontrolleri daha hızlı kurulur. - VDS: tenant izolasyonu için shard/cluster stratejisini doğru kurmak gerekir; yanlış tasarım maliyeti büyütür.

Net karar kuralı: Tenant izolasyonu “kritik” ise managed yaklaşım daha düşük operasyon riski sunar.

Fiyat karşılaştırmasını “yanlış” yapan 5 hata

Aşağıdaki hatalar, NetKıyas’ta bakılan nominal fiyatı yanıltıcı hale getirir. - Sadece CPU/RAM’e bakmak: Disk I/O ve ağ gecikmesi ES’de arama performansını belirler. - Replica ve snapshot payını dışarıda bırakmak: Depolama katlanmasını hesaba katmazsınız. - Egress maliyetini unutmamak: ES sorgularını başka bölgeden alan sistemlerde veri çıkışı maliyeti büyür. - Restore hedefini düşünmemek: Yedek “var” ama “ne kadar sürede dönüyor?” bilinmiyor. - Şablon kapasite ile gerçek yükü karıştırmak: POC yapmadan karar verilirse maliyet/kalite beklenen gibi çıkmaz.

NetKıyas bakarken ElasticSearch için nasıl sorgulayın?

Hosting karşılaştırırken doğrudan ES metriklerine bağlanan şu soruları sorabilirsiniz. Sağlayıcıların tekliflerinde bu detaylar her zaman açık olmayabilir; ancak sorgulamak sonucu netleştirir.

1) Disk tipi ve performans sınıfı

• NVMe mi, SSD mi?
• IOPS veya throughput bilgisi var mı?

2) Network limiti ve egress ücretleri

• Bölge içi trafik mi, internet çıkışı mı?
• Egress ücretleri hangi başlık altında?

3) Yedekleme seçenekleri

• Snapshot altyapısı var mı?
• Restore süresi konusunda referans var mı?

4) İzleme ve loglama entegrasyonu

• ES health, ingest rate, thread pool queue izleniyor mu?

5) Ölçekleme stratejisi

• Node ekleme/eski node çıkarma ne kadar hızlı?
• Otomatik rebalancing var mı?

Pratik öneri: 14 günlük POC ile “maliyet/kalite”yi doğrulayın

ES için en net yöntem küçük bir POC (proof of concept) çalışmasıdır. 14 gün boyunca aşağıdaki metrikleri toplayın: - p95 ve p99 arama gecikmesi - ingest gecikmesi (indexing latency) - CPU ve heap/GC trendleri - disk iowait ve merge time - snapshot süreleri ve günlük büyüme

POC planı (kısa ve net)

• Gün 1-3: mapping, shard/replica tasarımı ve baseline
• Gün 4-10: gerçek sorgu örüntüleri + yazma yükü
• Gün 11-14: peak stres, snapshot/restore provası

Aksiyonel hedef: POC sonunda “aynı hedef gecikme” için hangi modelin daha düşük toplam maliyete indiğini (RAM+CPU+disk+snapshot+operasyon) tek tabloda görün.

Sonuç: ElasticSearch’te “en ucuz” yerine “ölçülebilir toplam maliyet” seçin

ElasticSearch hosting maliyeti; RAM, CPU, disk I/O, replica/snapshot planı ve ağ trafiği ile şekillenir. VDS self-host, doğru tuning ve operasyon disipliniyle birim maliyeti düşürür; managed servisler ise operasyon riskini azaltır ve kaliteyi daha tutarlı hale getirir. Bu yüzden tek bir liste fiyatına göre karar vermek yerine, yukarıdaki kontrol listesiyle teknik hedeflerinizi sabitleyin, 14 günlük POC yapın ve toplam maliyeti (donanım + depolama katlanması + snapshot + restore süresi + egress) metriklerle doğrulayın. Aksiyon olarak, önce mapping ve shard/replica tasarımını netleştirin; ardından NetKıyas üzerinden disk/network/backup parametreleriyle teklifleri karşılaştırıp POC için en uygun iki alternatifi seçin.