Elasticsearch ILM (Index Lifecycle Management) ile Disk Tasarrufu
Her DevOps mühendisinin kabusudur: Gece yarısı gelen ve uykuyu bölen o meşhur “Disk Space Low” uyarısı. Üstelik bu uyarı, saniyede on binlerce satır log yutan bir Elasticsearch cluster’ından geliyorsa durum daha da can sıkıcıdır. Sürekli büyüyen log yığınlarını yönetmek, daha fazla ve daha pahalı disk satın almakla çözülmez; akıllıca bir ILM (Index Lifecycle Management) stratejisi kurmak gerekir. Bu yazıda bütçe dostu ve yüksek performanslı hot-warm-cold-delete mimarisini nasıl kuracağımızı, shrink ve rollover operasyonlarının perde arkasını pratik örneklerle inceleyeceğiz.
Neden “daha büyük disk” çözüm değil?
Kapasite sorunuyla karşılaştığımızda ilk refleks genellikle disk boyutunu artırmak veya cluster’a yeni node’lar eklemek olur. Ancak bu yaklaşım sürdürülebilir değildir. Nedenlerine bakalım:
- Maliyet: Üretim ortamlarında hızlı yazma (indexing) performansı için NVMe SSD diskler kullanırız. 90 günlük log verisinin tamamını bu pahalı disklerde tutmak bütçeyi sarsar.
- Performans: Eski ve nadiren sorgulanan loglar, aktif olarak yazılan güncel index’lerle aynı kaynakları (özellikle heap memory) tüketerek sorgu performansını düşürür.
- Yönetilebilirlik: Tek bir devasa index yerine yönetilebilir boyutlarda shard’lara bölünmüş bir yapı, hem yedekleme (snapshot) hem de cluster kurtarma süreçlerinde hayat kurtarır.
Hot-warm-cold-delete mimarisi
Verinin yaşlandıkça değerini kaybetmesi fikrine dayanan bu mimari, veriyi yaşam döngüsüne göre farklı donanım özelliklerine sahip node gruplarına dağıtır:
- Hot phase (sıcak evre): Yeni logların yazıldığı, yoğun CPU ve NVMe SSD disklere sahip node’lardır. Veri tazedir ve sürekli sorgulanır.
- Warm phase (ılık evre): Veri artık yazılmaz (read-only) ama sorgulanmaya devam eder. Daha ucuz SATA SSD diskler barındıran node’lara taşınır. Burada shard sayısı azaltılarak (shrink) sistem üzerindeki yük hafifletilir.
- Cold phase (soğuk evre): Nadiren sorgulanan, arşiv niteliğindeki verilerdir. HDD tipi ucuz depolama birimlerinde saklanır. Arama performansı düşüktür ama maliyeti minimumdur.
- Delete phase (silme evresi): Belirlenen saklama süresi (retention period) dolan verilerin güvenli bir şekilde yok edildiği evredir.
Adım adım Elasticsearch ILM kurulumu
Gelin, teoriyi pratiğe dökelim. Senaryomuzda günlük uygulama loglarını toplayacağız, bunları 50 GB veya 30 gün sınırıyla yeni index’lere böleceğiz (rollover). Ardından shrink işlemiyle shard sayısını azaltıp daha ucuz disklere taşıyacağız ve 90 günün sonunda sileceğiz.
1. Node rollerinin tanımlanması
Öncelikle Elasticsearch cluster’ınızdaki node’ların hangi katmanda yer alacağını elasticsearch.yml dosyalarında belirtmeniz gerekir. Modern Elasticsearch versiyonlarında (7.10+) veri katmanları (data tiers) kullanılır:
# Hot Node konfigürasyonu
node.roles: [ master, data_content, data_hot ]
# Warm Node konfigürasyonu
node.roles: [ data_warm ]
# Cold Node konfigürasyonu
node.roles: [ data_cold ]2. ILM policy tanımlama
Şimdi Elasticsearch API’siyle ILM politikamızı tanımlayalım. Bu politikada hot, warm, cold ve delete fazlarındaki geçiş kurallarını ve yapılacak operasyonları belirtiyoruz.
PUT _ilm/policy/kertenkerem_log_policy
{
"policy": {
"phases": {
"hot": {
"min_age": "0ms",
"actions": {
"rollover": {
"max_primary_shard_size": "50gb",
"max_age": "30d"
}
}
},
"warm": {
"min_age": "0d",
"actions": {
"shrink": {
"number_of_shards": 1
},
"forcemerge": {
"max_num_segments": 1
},
"allocate": {
"number_of_replicas": 1
}
}
},
"cold": {
"min_age": "60d",
"actions": {
"readonly": {}
}
},
"delete": {
"min_age": "90d",
"actions": {
"delete": {}
}
}
}
}
}Buradaki “neden?” sorularını yanıtlayalım:
- Neden
max_primary_shard_size? Toplam index boyutu yerine tek bir primary shard boyutunu baz almak en doğru yaklaşımdır. Replica shard’lar hesaba katılmaz ve dengeli bir shard yapısı korunur. - Neden warm fazında
shrinkveforcemergeyapıyoruz? Yazma işlemi bittiği için artık çoklu shard yapısına ihtiyacımız yok. Shard sayısını 1’e düşürerek (shrink) overhead’i azaltıyoruz.forcemergeile segment sayısını 1’e indirip disk alanından ciddi tasarruf sağlıyor ve arama hızını optimize ediyoruz.
3. Index template oluşturma
Oluşturduğumuz ILM politikasının yeni açılacak log index’lerine otomatik uygulanması için bir index template tanımlıyoruz. Burada dikkat edilecek en önemli nokta index.lifecycle.rollover_alias tanımıdır.
PUT _index_template/kertenkerem_logs_template
{
"index_patterns": ["kertenkerem-app-logs-*"],
"template": {
"settings": {
"index.lifecycle.name": "kertenkerem_log_policy",
"index.lifecycle.rollover_alias": "kertenkerem-app-logs",
"number_of_shards": 3,
"number_of_replicas": 1
}
}
}4. İlk index’in tetiklenmesi (bootstrap)
Rollover mekanizmasının doğru çalışabilmesi için ilk index’i manuel olarak oluşturmamız ve yazma iznini (write index) vermemiz gerekir. Index isminin sonu sıralı bir sayı formatında (örn: -000001) bitmelidir.
PUT kertenkerem-app-logs-000001
{
"aliases": {
"kertenkerem-app-logs": {
"is_write_index": true
}
}
}Bu adımdan sonra log toplayıcı araçlarınızın (Logstash, Fluentd, Vector vb.) belirli bir index ismine değil, yalnızca kertenkerem-app-logs alias’ına (takma ad) veri göndermesi gerekir. Elasticsearch arka planda ILM kurallarına göre yeni index’ler açarak trafiği otomatik yönlendirecektir.
Shrink ve rollover operasyonlarının kritik detayları
Sistem tıkır tıkır çalışırken bile arka planda işler karışabilir. DevOps mühendislerinin bu süreçte bilmesi gereken bazı “under the hood” detaylar şunlar:
Shrink işlemi nasıl gerçekleşir?
Bir index’i shrink edebilmek için Elasticsearch önce o index’e ait tüm primary shard’ları cluster’daki tek bir node üzerinde toplamak zorundadır. ILM bunu otomatik olarak yönetir. Ancak o node üzerinde yeterli disk alanı yoksa shrink işlemi askıda (blocking) kalabilir. Bu yüzden warm node’larınızın disk kapasitesini planlarken bu geçici yoğunlaşmayı hesaba katmalısınız.
Neden günlük index (daily index) yerine rollover?
Eski usul logstash-YYYY.MM.DD yapısında, hafta sonu az log gelen günlerde de hafta içi çok log gelen günlerde de aynı sayıda index açılırdı. Bu durum cluster içinde “over-sharding” (aşırı shard birikmesi) sorununa yol açar ve master node’u yorardı. Rollover ise boyuta göre tetiklendiği için her shard’ın ideal boyut olan 30-50 GB aralığında kalmasını garanti eder.
Sonuç ve “DevOps tavsiyeleri”
Kurduğumuz ILM yapısıyla pahalı SSD disklerimizi yalnızca aktif olarak yazılan taze veriler için ayırmış olduk. Yaşlanan logları daha ucuz disklere taşıyarak, shrink operasyonuyla cluster üzerindeki shard yükünü hafifleterek ve nihayetinde eski verileri silerek disk maliyetlerinde %60’a varan tasarruf sağlayabilirsiniz.
İyi bir DevOps mühendisi yalnızca çalışan sistemler kurmaz; şirketin bulut faturasını da optimize eder. Loglarınızı kendi haline bırakmayın, ILM ile disipline edin.