Elasticsearch Index Rollover

Elasticsearch üzerinde Timeseries dataların performanslı şekilde tutulabilmesi için Elasticsearch Index rollover
özelliklerinin uygulanması önerilmektedir.

Elasticsearch index datasını shardlar halinde tutar. Shardların her biri memory’de bir lucene
instance’ına denk geldiğinden shard optimizasyonu performans açısından kritik konulardan bir tanesidir.
Yani shard sayısının gereğinden fazla olması Indexleme ve search işlemlerinde yavaşlığa sebep
olabilir. Shard sayısının arttırılması durumunda background process’lerin maliyetinin artacağı da göz
önünde bulundurulmalıdır.

Elasticsearch kullanırken dikkat edilmesi gereken best practices’lar şu şekildedir.
Her bir sunucu için max heap size’ın 31 GB olması,
Shard size’ın 20-40 GB civarında tutulması,
Shard sayısının optimum olarak her 1GB için 20 adet olması.

Diyelim ki elasticsearch üzerinde uygulama loglarını saklıyoruz. Hergün logstash’den gelen datayı
aşağıdaki gibi indexlere yazıyoruz;

systemlog.app1-23-03-2023
systemlog.app1-24-03-2023
systemlog.app1-25-03-2023

Bu indexler’in aşağıdaki gibi bir index template’den üretildiğini varsayalım;

PUT _index_template/systemlog.app1 { “priority”: 2, “template”: { “settings”: { “index”: {
“lifecycle”: { “name”: “3-day-policy” }, “number_of_shards”: “5”, “number_of_replicas”: “1”
} } }, “index_patterns”: [ “sys.syslog*” ] }

Sorun :
Bu index template’i oluştururken shard optimizasyonunu her gün 250GB civarında log datası indexe
yazılacak öngörüsüyle hareket ettik. Peki log boyutu artıp elasticsearch indexine gelen data günlük
750’gb’a ulaşıp ertesi gün 200GB’a düşüp bir sonraki gün de 800GB’a yükseldiği durumda hergün
shard sayısını optimum seviyeye getirmek için index template ve varolan indexlerle uğraşmak
gerekecek.

Çözüm :
İşte bu durumdan kaçınmak için rollover özelliğini kullanıyoruz. Index rollover mekanizması ile
ILM(index life cycle policy)’de belirlediğimiz rollover condition’larına göre elasticsearch bu
condition’lardan biri veya birkaçı sağlandığında index’i rollover ediyor. Rollover etmesi var olan index’e
yazmayı bırakıp template’den yeni bir index create ederek yeni index’e yazmaya devam etmesi
demektir. Yeni index’in ismi verilen rollover pattern’e göre belirlenir.
systemlog.app1-000001
systemlog.app1-000002
systemlog.app1-000003

Index Lifecycle Policy (ILM)

ILM index lifecycle policy de elasticsearch üzerinde data yönetimini yapmak için kullanılır. Örneğin bir
index template’den üretilen index’lerin verisi 3 gün saklansın ve 3 gün sonunda silinsin istersek bunu
ILM policy’ler ile gerçekleştirebiliriz. Yine index 3 gün saklansın ama 24.saatin sonunda bu index warm
veya cold phase’lardan birine geçsin istersek de ILM ile bunu gerçekleştirebiliriz.

Konumuzun ILM ile alakalı kısmı ise Index Rollover condition’larını ILM policy içerisinde belirliyor olmamız. Kibana aracılığı ile create policy adımından yeni bir ILM policy oluşturabiliyoruz. Burda rollover condition olarak shard size’ın 50 GB olduğu durumda rollover edilsin dediğimiz zaman
yukarıda verdiğimiz örneği hayata geçirmiş oluyoruz.

ILM policy’i aşağıdaki gibi bir request ile de oluşturabiliriz;

İlgili ILM’i index template uygulamak için de aşağıdaki request kullanılabilir;

Bu policy’de belirtilenler;
İlgili ILM’in uygulandığı indexler’in maximum primary shard size’ı 50GB olabilir.
Veya indexin Max age’i 1 gün olabilir.
Veya indexin max doküman sayısı 100000 olabilir.
Yukarıdaki şartlar’dan 1tanesi sağlandığında varolan index rollover edilir. Ve index pattern’e göre yeni bir index create edilir.

systemlog.app1-000001 indexinin boyutu 5 Primary shard’a sahipken 250 GB oldu (primary) bu durumda primary shard sizeları 50’şer gb’ı aştığından rollover yapılır ve systemlog.app1-000002 oluşturulur.

Peki systemlog.app1-000001 index’inin durumu ne olur ? Bu index’te yine ILM policy’de verilen kurallar çerçevesinde hayatına devam  eder. Burda verilmesi gereken kararlar bu index warm phase’a geçecek mi, shrink edilecek mi, replica sayısı değiştirilecek mi vs.. Bunlar belirlendikten sonra daha düşük maliyetle bu indexin saklanması sağlanabilir. Delete phase ile de indexin kaç gün sonra silineceği belirlenebilir. Hot warm ve delete phase’lardan daha sonra detaylı şekilde bahsedeceğim.

Elasticsearch ile ilgli diğer yazılarıma https://www.veritabaniegitimleri.com/category/dokuman/nosql/elasticsearch/ linkinden erişebilirsiniz. Video derslere ise https://youtube.com/@veritabaniegitimleri youtube kanalımızdan erişebilirsiniz. İyi Çalışmalar.