ElasticSearch Hosting Maliyet/Kalite Analizi: Net Model

ElasticSearch (ve ekosistemi: Kibana, Logstash/Beats), arama ve log/ölçüm verisi için güçlü bir altyapıdır; ancak yanlış planlandığında maliyet hızla büyür. Bu yazıda "performans pahalıdır" gibi genellemeler yerine, ElasticSearch hosting maliyetini hangi teknik etkenlerin belirlediğini net şekilde ayırıyoruz. Ardından kaliteyi düşürmeden maliyeti kontrol altına almanız için bir karar modeli veriyoruz: kaynak gereksinimi, disk/RAM oranı, ölçekleme noktaları, yedekleme stratejisi ve izleme (monitoring) metrikleri.

ElasticSearch maliyetinin temel bileşenleri: nereden para akar?

ElasticSearch barındırma maliyeti; sadece aylık sunucu bedeli değildir. En büyük kalemler genellikle şu başlıklarda toplanır:

• RAM (bellek) ihtiyacı: Index’lerin ve özellikle filesystem cache (işletim sistemi sayfa önbelleği) verimi, RAM ile doğrudan ilişkilidir.
• Disk (SSD/NVMe) ve IOPS: Yazma (ingest), segment flush/merge ve arama sırasında dosya erişimi diske bağlıdır. Yetersiz IOPS hem maliyeti artırır (daha sık ölçek/yenileme) hem de gecikmeyi yükseltir.
• CPU: Analiz (analysis), sorgu çalıştırma, sıkıştırma/decompresion ve background işlemler CPU tüketir.
• Network: Cluster içinde shard replikasyonu, snapshot (yedek) aktarımı ve istemci sorgu trafiği ağ kullanımını etkiler.
• Depolama büyüme hızı: Günlük ingest hacmi ve retention (saklama süresi) belirleyici olur.

NetKıyas mantığıyla düşünürsek: Aynı "1 TB disk" sunucu ile aynı veriyi kaldıramayan iki kurulum görebilirsiniz. Çünkü ElasticSearch’te gerçek kullanılabilir disk; shard sayısı, segment yapısı, replikasyon (replica) ve silme/merge davranışına bağlıdır.

Kaliteyi belirleyen teknik parametreler

Kaliteyi (hız + istikrar + arama tutarlılığı) şu parametreler şekillendirir:

• Shards (shard sayısı): Çok küçük shardlar yönetim yükünü artırır; çok büyük shardlar ise recovery/snapshot sürelerini uzatır.
• Replica sayısı: Yüksek replica; arama kalitesini ve yüksek erişilebilirliği artırır ama depolama maliyetini yükseltir.
• Index mapping ve analiz pipeline’ı: Yanlış mapping, gereksiz alanları indeksler, disk/RAM tüketimini artırır.
• Refresh interval ve bulk ingest stratejisi: Fazla sık refresh ve hatalı bulk boyutları ingest maliyetini artırır.

Net kapasite modeli: ElasticSearch RAM/CPU/disk nasıl planlanır?

Aşağıdaki plan, "Managed mı Self-Hosted mı?" sorusuna geçmeden önce maliyet/kaliteyi doğru kurmak için temel iskeleti verir.

1) Günlük ingest ve retention ile toplam veri hesabı

Önce ham veri hacmini bulmanız gerekir:

• Günlük yeni veri (ham, GB/gün)
• Ortalama sıkıştırma etkisi (çok değişken; ölçerek ilerlemek gerekir)
• Retention süresi (ör. 30 gün, 90 gün)
• Replica sayısı (örn. 1 replica ile toplam depolama yaklaşık 2x)
• Merge sırasında geçici artış payı

Net formül yerine pratik yaklaşım: 1. İlk ay 1-2 haftalık veriyi aynı ayarlarla toplayın. 2. ElasticSearch’te store size ve segment yapısını ölçün. 3. Aylık büyüme hızını (GB/Ay) çıkarın. 4. Şu güvenlik katsayılarını ekleyin: - Replica: replica sayısına göre - Segment/merge payı: %10-%30 - Hızlı ölçek ihtiyacı: %10-%20

Bu yaklaşım özellikle "ElasticSearch hosting fiyatı ucuz göründü ama kapasite yetmedi" senaryosunu engeller.

2) Disk/RAM oranı: en sık yapılan hata

ElasticSearch’te disk hızlı olsa bile RAM yetersiz kalırsa aramalar yavaşlar, segment okuma daha sık disk tarafına kayar. Net bir kural gibi sabit oran vermek yanıltıcıdır; fakat pratikte aşağıdaki kontrol iyi çalışır:

• Index/segmentlerin aktif çalışma döneminde filesystem cache hedefleyin.
• Ortalama shard boyutlarını ve segment count’u izleyin.

Bu yüzden iki kutu parametreyi aynı anda planlayın: - Disk kapasitesi (retention + replica + merge pay) - Node başına RAM (cache ve query latency için)

3) Node sayısı ve shard mantığı: kaliteyi “maliyetle” dengelemek

Node sayısını tek bir sayıya indirgemek yerine şu dengeyi kullanın:

• Node sayısı az ise: daha büyük risk (failure durumunda recovery süresi)
• Node sayısı çok ise: shard yönetimi ve cluster overhead artar

Burada "minimum yeterli" yerine "bakım/arıza senaryosunu da taşıyan" plan kurun.

Örnek hedef: - Sıcak dönem (peak ingest) sırasında ingestion gecikmesi yükselmeye başlamadan ölçek planı - Node arızasında recovery süresinin retention penceresini yakmaması

Managed ElasticSearch mi Self-Hosted mı? Net maliyet/kalite farkı

Aynı donanım sınıfında bile yönetim maliyeti değişir. ElasticSearch’te bakım işi; sürüm güncelleme, mapping/migration, snapshot, disk watermarks, index lifecycle yönetimi (ILM) gibi kalemlerden oluşur.

Managed (servis sağlayıcı yönetimi) neyi kolaylaştırır?

• Sürüm güncellemeleri ve işletimsel kontroller
• Snapshot/yedekleme altyapısı
• Bazı izleme/uyarılar
• Yüksek kullanılabilirlik tasarımları

Self-Hosted neyi ucuzlatır?

• Donanımı ve ayarları tam kontrol
• Maliyet optimizasyonu (özellikle eğer kaynaklarınızı iyi kullanıyorsanız)
• Veri yerleşimi ve network kurgusu

Net karar tablosu

Aşağıdaki tablo, hangi senaryoda hangi yaklaşım daha net mantıklıdır sorusunu hedefler.

Yedekleme (snapshot) ve maliyet: “disk al” değil, “yedek akışı” planla

ElasticSearch’te yedekleme, sadece dosya kopyalamak değildir. Cluster snapshot yaklaşımı; repository ve depolama hizmetine göre hem maliyet hem de RPO/RTO hedeflerini belirler.

Snapshot repo maliyetleri nasıl oluşur?

• Object storage (ör. S3 uyumlu) üzerinden veri aktarımı
• Depolama maliyeti (GB-ay)
• Snapshot sayısı ve incremental mantığı
• Geri dönüş (restore) süresi ve restore sırasında oluşan kaynak kullanımı

Net hedef belirlemek gerekir: - RPO: Son veri kaybı hedefi (ör. 5 dakika / 1 saat) - RTO: Geri yükleme süresi hedefi (ör. 30 dk / 2 saat)

Sık yapılan hata: “Aylık snapshot yeter” düşüncesi

Aylık snapshot, restore gerektiğinde büyük veri kaybı yaratır. Log/ölçüm ekosisteminde bu, müşteri deneyimi ve analiz doğruluğunu bozar.

Şifreleme (encryption) ve erişim kontrolü

Yedeklerin depolandığı yerde: - Transit ve at-rest şifreleme uygulanmalı - Repository erişimi en düşük yetkiyle sınırlandırılmalı - Şifre anahtar yönetimi (KMS varsa) netleştirilmeli

Bu başlık, ElasticSearch maliyetini doğrudan artırmasa da geri dönüş maliyetini dramatik biçimde düşürür.

ElasticSearch’te performans kalite kriterleri: maliyeti “ölçülebilir” yap

Hosting karşılaştırmasında en kritik adım; kaliteyi tek bir metrikle değil, net performans/istikrar sinyalleriyle tanımlamaktır.

İzleme metrikleri (monitoring) ve net eşikler

Aşağıdaki sinyaller, maliyeti kontrol etmeye yardım eder:

• Ingest gecikmesi: pipeline yavaşlıyor mu?
• Query latency (p95/p99): kullanıcı deneyimi için kritik
• JVM heap usage: Garbage Collection artışı kalite düşürür
• Disk watermarks: “disk dolmaya yaklaşıyor” uyarıları maliyeti artıran ilk işaretlerden
• Shard rebalancing/recovery: toparlanma süresi uzun mu?

CPU %100, RAM baskısı ve disk IOPS: üçlüyü birlikte yorumla

• CPU %100 kalıcı ise: sorgu karmaşıklığı, analiz maliyeti veya bulk ayarı sorun olabilir.
• Heap baskısı artıyorsa: mapping/kullanılan field sayısı veya cache davranışı etkili olur.
• Disk IOPS yetersiz ise: ingest ve merge sırasında gecikme belirginleşir.

Bu üçü birlikte görülürse "donanım yetersiz" demek tek başına doğru değildir. Yanlış mapping veya shard tasarımı da aynı belirtileri üretebilir.

Donanım/hosting karşılaştırma çerçevesi: VDS/VPS/dedicated değil, “iş yükü” karşılaştır

ElasticSearch’te en doğru kıyas; aynı iş yükü parametreleriyle yapılan testtir.

Net test planı (kısa ama belirleyici)

1. 24 saatlik gerçek veri örneği (en az birkaç bin belge + gerçek alanlar)
2. Aynı mapping ve analiz ayarları
3. Aynı shard/replica hedefi
4. Peak benzeri bulk ingest senaryosu
5. 24 saat sonunda: - index store size - p95/p99 arama gecikmesi - ingest latency - heap ve disk watermark olayları

Bu testi yapmadan yapılan karşılaştırmalar çoğu zaman yanlış çıkar.

ElasticSearch için kaynak sınıfları nasıl okunmalı?

Hosting tekliflerini okurken şu kontrol noktalarını kullanın:

• Disk türü: NVMe/SSD, paylaşımlı IOPS garantisi
• RAM/CPU oranı: sadece toplam CPU değil, gerçek sürdürülebilir performans
• Network: cluster içi traffic ve snapshot aktarımı
• Storage limitleri: "disk sınırsız" ibaresi FUP/limit ile gelebilir
• Snapshot repo altyapısı: harici object storage maliyeti dahil mi

Maliyet/kaliteyi düşüren net optimizasyon adımları

Burada amaç, sadece daha güçlü sunucu almak değil; aynı bütçeyle daha iyi kaliteyi almaktır.

1) Mapping ve field seçimi

• Tam metin arama gerekmeyen alanlarda analiz maliyetini düşürün.
• Gereksiz multi-field (ör. text + keyword + başka varyantlar) maliyeti artırır.

2) Shard yeniden tasarımı

• Aşırı shard sayısı cluster overhead üretir.
• Çok büyük shardlar ise recovery süresini uzatır.

3) ILM ile retention yönetimi

Log/ölçüm kullanımında en net maliyet kuralı: veri ömrünü otomatik yönetin. - Hot/ Warm/ (varsa) Cold katman planı - Otomatik rollover ve delete

4) Bulk ingest ayarı

• Çok küçük bulk: overhead artar
• Çok büyük bulk: heap baskısı ve gecikme artar

Net yaklaşım: yükleme aracınızla bulk boyutunu 2-3 seviyede test ederek optimuma yakınlaşmak.

ElasticSearch hosting maliyeti için net “ölçek eşiği” yaklaşımı

Birçok ekip kapasite planını şu şekilde yapar: “Disk dolunca büyütürüz.” Bu yaklaşım kaliteyi bozur.

Net ölçülebilir ölçek eşiği: - Disk watermarks’a yaklaşmadan önce (ör. %75-%80 bandında) ölçekleme planı - Ingest gecikmesi belirli bir eşik üzerinde sabitleşmeye başladığında (kaç saniye/dakika olduğuna göre proje bazlı) - Recovery süreleri beklenen arıza süresini aştığında

Bu eşikleri belirlediğinizde, hosting karşılaştırması artık “hangisi daha ucuz” değil, “hangisi bu eşikleri daha düşük toplam maliyetle sağlıyor” olur.

Sonuç: ElasticSearch için kararınızı test + metrik + yedek akışıyla verin

ElasticSearch hosting maliyet/kalite dengesi; RAM, disk IOPS, shard tasarımı ve snapshot/ILM yönetiminin bileşiminden doğar. Bu yüzden tek bir teklif fiyatına bakarak karar vermek yerine, 24 saatlik iş yükü testiyle p95/p99 arama gecikmesi, ingest gecikmesi, heap baskısı ve disk watermarks sinyallerini karşılaştırın. Son adım olarak yedekleme (snapshot) repo maliyeti ve restore hedeflerinizi yazılı hale getirerek managed ile self-hosted arasındaki farkı netleştirin. Bu üç adımı uygularsanız, ElasticSearch için bütçenizi büyüten sürprizleri azaltıp kaliteyi kontrol altında tutarsınız.