Elasticsearch ILM (Index Lifecycle Management) ile Disk Tasarrufu

Her devops mühendisinin kabusudur: Gece yarısı gelen ve uykuyu piç eden o meşhur “Disk Space Low” uyarısı. Hele ki bu uyarı, log analizi için canla başla koşturduğumuz, saniyede on binlerce satır log yutan bir elasticsearch cluster’ından geliyorsa durum daha da can sıkıcı olur. Sürekli büyüyen log yığınlarını yönetmek, sadece daha fazla ve daha pahalı disk satın almakla çözülmez; akıllıca bir ilm (Index Lifecycle Management) stratejisi kurmak gerekir. Bu yazımızda, 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 Sadece “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. Neden mi?

• 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’ler ile 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 Nedir?

Verinin yaşlandıkça değerini kaybetmesi felsefesine 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 (Ilık Evre): Veri artık yazılmaz (read-only), ancak 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ımızı toplayacağız, bunları 50 GB veya 30 gün sınırlaması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’sini kullanarak 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ı Cevaplayalı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 shrink ve forcemerge yapı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. forcemerge ile 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 olarak uygulanması için bir index template tanımlıyoruz. Burada dikkat etmemiz gereken 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 bizim manuel olarak oluşturmamız ve yazma iznini (write index) vermemiz gerekir. Index isminin sonunun sıralı bir sayı formatında (örn: -000001) bitmesi şarttır.

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.) doğrudan spesifik index ismine değil, sadece 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 bazen arka planda işler karışabilir. DevOps mühendislerinin bu süreçte bilmesi gereken bazı “under the hood” detaylar şunlardır:

Shrink İşlemi Nasıl Gerçekleşir?

Bir index’i shrink edebilmek için Elasticsearch öncelikle 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 devasa 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’un canını okurdu. 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”

Bu makalede kurduğumuz ILM yapısı sayesinde, pahalı SSD disklerimizi sadece aktif olarak yazılan taze veriler için rezerve etmiş 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.

Unutmayın, iyi bir DevOps mühendisi sadece çalışan sistemler kurmaz; aynı zamanda şirketin bulut faturasını da optimize eden kişidir. Loglarınızı kendi haline bırakmayın, ILM ile onları disipline edin!