Elasticsearch ILM ile Disk Tasarrufu: Hot-Warm-Cold-Delete Yapılandırması
DevOps dünyasının en acı verici maliyet kalemlerinden biri, her gün çığ gibi büyüyen log verileridir. Elasticsearch üzerinde koşan log kümelerinin kontrolsüz büyümesi, disk doluluk alarmları ve şişen bulut faturalarıyla sonuçlanır. İşte tam bu noktada, akıllı bir elasticsearch ilm (Index Lifecycle Management) stratejisi kurmak, disk ve donanım maliyetlerinizi kalıcı olarak optimize etmenin en efektif yoludur. Sadece eski verileri silmek bir çözüm değildir; verinin yaşlandıkça daha ucuz kaynaklara taşınması, sıkıştırılması ve segmentlerinin birleştirilmesi gerekir. Bu rehberde, production ortamında doğrudan uygulayabileceğiniz, shrink ve force-merge adımlarıyla desteklenmiş agresif bir hot-warm-cold-delete mimarisini nasıl kuracağınızı inceleyeceğiz.
1. Altyapının Hazırlanması: Node Rollerinin Dağıtımı
ILM mekanizmasının veriyi doğru katmanlar arasında taşıyabilmesi için öncelikle Elasticsearch cluster üyelerinin rollerini net bir şekilde tanımlamalıyız. Eski node.attr.box_type yaklaşımı yerine, modern Elasticsearch mimarisinde (7.x/8.x) yerleşik veri rollerini kullanıyoruz. Node’larınızın elasticsearch.yml dosyalarında şu tanımlamaların yapıldığından emin olun:
Hot Node Konfigürasyonu (Yüksek IOPS NVMe Diskler)
node.roles: [ master, data_hot, ingest ]Warm Node Konfigürasyonu (Orta Segment SSD / Standart Diskler)
node.roles: [ data_warm ]Cold Node Konfigürasyonu (Ucuz, Yüksek Kapasiteli HDD / Object Storage)
node.roles: [ data_cold ]Neden böyle? Yazma (ingest) yükü her zaman CPU ve I/O canavarıdır. Hot node’ları pahalı ve hızlı disklerde tutarken, artık arama sıklığı düşmüş eski verileri barındıran warm ve cold node’larda daha ucuz depolama birimleri kullanarak maliyetleri ciddi oranda dengeliyoruz.
2. Agresif Bir ILM Policy Tanımlama
Şimdi disk tasarrufunu asıl optimize edecek olan ILM policy yapısını kuralım. Senaryomuzda:
- Hot Fazı: Veri yazılır. Primary shard boyutu 50 GB’a ulaştığında veya 7 gün geçtiğinde rollover tetiklenir.
- Warm Fazı: Rollover olan veri warm node’lara taşınır. Shard sayısı 1’e düşürülür (shrink) ve segment birleştirmesi (force-merge) yapılarak diskte maksimum sıkıştırma sağlanır.
- Cold Fazı: Veri cold node’lara taşınır, replica sayısı 0 veya 1’e çekilerek alan kazanılır.
- Delete Fazı: 90 günün ardından veri cluster’dan tamamen silinir.
Bu akışı tetikleyecek API çağrısını aşağıdaki gibi cluster’a uygulayalım:
curl -X PUT "localhost:9200/_ilm/policy/log_maliyeti_opt_policy" -H 'Content-Type: application/json' -d'
{
"policy": {
"phases": {
"hot": {
"min_age": "0ms",
"actions": {
"rollover": {
"max_primary_shard_size": "50gb",
"max_age": "7d"
},
"set_priority": {
"priority": 100
}
}
},
"warm": {
"min_age": "0ms",
"actions": {
"shrink": {
"number_of_shards": 1
},
"forcemerge": {
"max_num_segments": 1
},
"allocate": {
"number_of_replicas": 1
},
"set_priority": {
"priority": 50
}
}
},
"cold": {
"min_age": "30d",
"actions": {
"allocate": {
"number_of_replicas": 0
},
"set_priority": {
"priority": 0
}
}
},
"delete": {
"min_age": "90d",
"actions": {
"delete": {}
}
}
}
}
}'3. Neden Shrink ve Force Merge?
Burada “Neden böyle yaptık?” sorusunu yanıtlayalım. Birçok DevOps mühendisi sadece rollover ve delete adımlarını kullanır. Ancak asıl disk tasarrufu warm fazındaki iki kritik adımda gizlidir:
- Shrink: Hot fazda yazma performansını optimize etmek için muhtemelen 5 primary shard kullandınız. Veri salt okunur (read-only) olduğunda, bu kadar çok shard’a ihtiyacınız kalmaz. Shard sayısını 1’e düşürerek hem Elasticsearch JVM Heap bellek tüketimini azaltırız hem de metadata overhead’ini sıfırlarız.
- Force Merge (max_num_segments: 1): Elasticsearch arkada verileri sürekli segmentler halinde yazar. Silinen veya güncellenen dökümanlar fiziksel olarak hemen silinmez, sadece silindi olarak işaretlenir. Force merge operasyonu ile tüm segmentleri tek bir segmente indirgeriz. Bu işlem, silinmiş tüm verileri diskten fiziksel olarak kazır ve sıkıştırma algoritmasının (LZ4/DEFLATE) maksimum verimle çalışmasını sağlayarak ortalama %20 ila %40 arasında anlık disk tasarrufu sağlar.
4. Index Template ve Bootstrap Oluşturma
ILM politikasının otomatik olarak yeni index’lere uygulanabilmesi için bir index template tanımlamamız gerekiyor. Burada önemli olan nokta, verilerin yazılacağı ilk “bootstrap” index’ini elle oluşturup alias’ı bağlamaktır.
Index Template Tanımlanması
curl -X PUT "localhost:9200/_index_template/log_template" -H 'Content-Type: application/json' -d'
{
"index_patterns": ["app-logs-*"],
"template": {
"settings": {
"index.lifecycle.name": "log_maliyeti_opt_policy",
"index.lifecycle.rollover_alias": "app-logs",
"index.number_of_shards": 3,
"index.number_of_replicas": 1,
"index.routing.allocation.include._tier_preference": "data_hot"
}
}
}'Burada index.routing.allocation.include._tier_preference: "data_hot" satırı çok kritiktir. Yeni oluşturulan tüm index’lerin öncelikli olarak hot node’lara yazılmasını garanti altına alır.
İlk Bootstrap Index’inin Tetiklenmesi
Rollover mekanizmasının çalışabilmesi için alias’ın işaret ettiği fiziksel bir index’in bulunması şarttır. İlk index’i write_index olarak tanımlayarak döngüyü başlatıyoruz:
curl -X PUT "localhost:9200/%3Capp-logs-%7Bnow%2Fd%7D-000001%3E" -H 'Content-Type: application/json' -d'
{
"aliases": {
"app-logs": {
"is_write_index": true
}
}
}'Artık uygulamanız logları doğrudan app-logs alias’ına yazabilir. Elasticsearch, arka planda ILM kurallarını işleterek index boyutlarını izleyecek ve eşikler aşıldığında rollover yaparak süreci warm katmanına devredecektir.
5. SRE Gözünden Production Sorunları ve Çözümler
Production ortamlarında bu yapıyı koştururken karşınıza çıkabilecek bazı tipik tıkanma noktaları ve bunları aşma yöntemleri şunlardır:
Shrink Operasyonunun Askıda Kalması
Bir index’in shrink edilebilmesi için, o index’e ait tüm primary shard kopyalarının cluster içinde tek bir node üzerine toplanması gerekir. Eğer cluster’ınızda disk doluluğu nedeniyle allocation engelleri varsa, shrink işlemi AWAITING_REALLOCATION durumunda takılır.
Çözüm: Warm node’larınızda tek bir node’un index’in tamamını (örneğin 150 GB) tek başına barındırabilecek kadar boş disk alanına sahip olduğundan emin olun. Gerekirse geçici olarak disk limit sınırlarını (watermark) esnetin:
curl -X PUT "localhost:9200/_cluster/settings" -H 'Content-Type: application/json' -d'
{
"transient": {
"cluster.routing.allocation.disk.watermark.low": "90%",
"cluster.routing.allocation.disk.watermark.high": "95%"
}
}'Force Merge Sırasında IOPS Tavan Yapması
Force merge işlemi, diski yoğun şekilde okuyup yazan (I/O intensive) ağır bir operasyondur. Aynı anda onlarca index warm faza geçip force merge olmaya başlarsa cluster yanıt veremez hale gelebilir.
Çözüm: ILM policy’nizdeki rollover tetikleyicilerini zamansal olarak yaymaya çalışın (örneğin tüm servislerin rollover’ını aynı gece saatinde tetiklemeyin, boyut bazlı rollover tercih edin) ve force merge limitlerini sınırlandırın.
Özet
Bu makalede kurguladığımız hot-warm-cold-delete yapısı sayesinde, aktif yazılan taze log verilerinizi yüksek performanslı disklerde tutarken, geriye dönük analizler için sakladığınız eski verileri minimum kaynak tüketecek şekilde optimize ettik. Shrink ile heap bellek ayak izini düşürdük, force-merge ile diskteki boşlukları temizledik ve soğuk katmanda replikaları azaltarak donanım maliyetlerimizi kalıcı olarak aşağı çektik. Bu kurgu, doğru uygulandığında Elasticsearch log altyapınızın sürdürülebilirliğini katbekat artıracaktır.