Elasticsearch Version Upgrade

Merhaba, bu yazımda size İşin Olsun Elasticsearch clusterlarımızı upgrade etme deneyimimizden bahsedeceğim.

Elasticsearch’ü upgrade ederken aslında başlıca sorunumuz data migration işlemidir. Hedefimiz hiç bir verinin kaybolmamasıdır.

Data migration işlemini birden fazla şekilde yapmak mümkündür. Bunlardan başlıcalarını size açıklıyor olacağım.

• Incremental Approach

Bu yöntem aslında veriyi hangi tool yada api ile taşıyacağınızdan çok nasıl taşıyacağınızı söyleyen bir yaklaşımdır. Adından da anlayacağımız üzere datamızı bir sonraki versiyona sıra ile geçirme işlemidir. Ör: 1.x -> 2.x -> 5.x -> 6.x -> 7.x -> 8.x .Bu yöntemin dezavantajı çok fazla geliştirme maliyeti barındırmasıdır.

• Snapshot and Restore

Snapshot and restore işlemi de incremental approach’e bağlıdır. Snapshot and Restore işlemi ile sırası ile bir üst versiyona geçerek versiyon yükseltme işleminin yapılmasını amaçlar. Dolayısı ile aynı maliyet dezavantajı burada da geçerlidir.

• Custom Apps

Belli bir versiyondan belli bir versiyona veriyi taşıyan kendi uygulamanızı geliştirebilirsiniz. İlk başta kulağa çok maliyetli gibi gelse de eğer 1.x gibi remote reindex api ının olmadığı bir versiyonda iseniz bu seçenek sizin için en mantıklı seçenek olabilir. Remote reindex desteklemeyen bir versiyonunda iseniz remote reindex yerine eşdeğer olmasa da github’da yer alan elasticsearch-dump toolunu kullanılarak da data migration yapılabilirsiniz ancak bu işlemin de dezavantajı çok yavaş çalışmasıdır.

• Remote Reindex

Datanızı remote reindex api’ını kullanarak yüksek versiyonlu yeni clusterınıza kolay ve hızlıca taşıyabilirsiniz.

Geçiş öncesi adımlarımızı izledikten sonra biz data migration işlemi için remote reindexi kullanmayı tercih ettik. İşin Olsun ekibi olarak Elasticsearch 5.4 kullanıyorduk ve hedefimiz Elasticsearch sürümünün son versiyonu olan 8.11 e geçmekti. Ancak 8.x sürümüne 5.x sürümünden remote reindex api yı ile veri taşımak mümkün değildi. 8.x versiyonuna geçmek için ilk önce elinizde 7.x versiyonunda oluşturulmuş bir index gerekiyordu. Bunun için ilk önce Devops ekibimizden 7.17.12(7.x son sürüm) versiyonunda yeni bir cluster istedik.

Clusterımız hazır olduktan sonra yeni indeximizi oluşturmadan şu adımları gerçekleştirmemiz gerekir:

• Deprecation logları kontrol edilmeli
• Braking changes’ler incelenmeli
• Kullandığımız Elasticsearch pluginlerinin geçeceğimiz yeni versiyon ile uyumları incelenmeli
• Değişiklikler test ve stage ortamlarında denenmeli
• Backup ve snapshot alınmalı

Bu adımları izledikten sonra 7.17.12 sürümünde yeni indeximizi oluşturduk. 5.4 versiyonundan 7.17’ye geçerken bizim kullandığımız ve değişikliğe uğramış major değişikliklerden bazıları şunlardı:

• Types artık kullanılmıyor.
• Types artık kaldırıldığı için dynamic type özelliği de kaldırıldı.
• Index crate edilirken artık setting içerisinde index yazmak zorunda değiliz.
• icu_collation token filter’ı kaldırıldı.
• Search api’de total kullanımı değişti. (track_total_hits adında yeni bir search propertysi geldi)
• Scrol api artık önerilmiyor bunun yerine search after öneriliyor.
• doc[‘dateTimeProp’].value kullanımı artık milisaniye dönmüyor, okunabilir tarih dönüyor. Milisaniye cinsine çevirmek için doc[‘dateTimeProp’].value.toInstant().toEpochMilli() şeklinde bir kullanım yapabilirsiniz.

Yeni Index’imiz yeni versiyonlu clusterımızda hazır olduktan sonra datalarımızı remote reindex api yını kullanarak yeni clusterımıza geçirdik.

Remote reindex işlemini aşağıdaki örnek query yardımı ile gerçekleştirebilirsiniz.

POST _reindex
{
  "source": {
    "remote": {
      "host": "http://otherhost:9200",
      "username": "user",
      "password": "pass"
    },
    "index": "my-index-000001",
    "query": {
      "match": {
        "test": "data"
      }
    }
  },
  "dest": {
    "index": "my-new-index-000001"
  }
}

Query’de gördüğünüz gibi normal reindex işleminden tek farkı remote scope’udur. Remote değeri tanımlaması ile uzaktaki makinemizden querynin çalıştığı makineye data aktarımı yapabiliyoruz. Unutmamanız gereken tek nokta remote host değerinizi queryi çalıştıracağınız elasticsearh’ün whitelist’ine eklemek.

Reindex işlemi bittikten sonra Kibana Upgrade Asistant’ı kullanarak clusterımızın 8.11 versionuna geçirmek için yapmamız gereken adımları izledik. Bu adımdan sonra remote reindex yapmamıza bile gerek kalmadan Devops ekibimizin yardımı ile clusterımızı 7.17.12 versiyonundan 8.11 versiyonuna upgrade ettik. Bu şekilde sıfır veri kaybı ile Elasticsearch son sürümünde bir clustera sahip olduk.

Elasticsearch tarafı tamam, ancak bunun bir de kod tarafı var :) .Net tarafında elastic client olarak kullandığımız Nest kütüphanesini güncellememiz gerekiyor. Nest kütüphanesi son sürümü 7.17.5 ile birlikte aslında destek vermeyi bıraktı. Elasticsearch 8 ile birlikte Elastic.Clients.Elasticsearch adında yeni bir kütüphane çıkardılar.

Ancak bu kütüphaneye geçmek için bir mecburiyetimiz yok çünkü Nest’in son sürümünü 7.x versiyonu ile kullanıldığı gibi 8.x versiyonu ile de kullanabiliyor. Zamanla gelişen bu kütüphaneye sonunda geçecek de olsak şu an Nest’in yapabildiği her şeyi yapabilecek yetkinlikte olmadığından dolayı bu kütüphaneye geçmekte aceleci davranmayarak Nest kütüphanesinin son sürümünü kullanmayı tercih ettik. Nest kütüphanemizi güncellemeden önce deprecation log ve braking changes’leri inceledik. Gerekli değişiklikleri yaptıktan sonra da kütüphanemizi güncelledik.

Daha önceden incelediğimiz Elasticsearch deprecation logların ve breaking changlerin Nest kütüphanesinde de bulunduğunu zaten tahmin etmişsinizdir. Sonuçta Nest Elasticsearch’i kullanabilmemiz için yazılmış bir rest client kütüphanesi. Ancak Nest tarafındaki kullanım değişiklikleri, json parser değiliklikleri gibi başka değişiklerle de karşılaşacaksınız. Ne yazık ki tüm bu işlemleri yaparken az da olsa zorlandığımız tek yer bu değişiklikler oldu :) Bunun sebebi de Nest’in size dökümanlarında sadece bu componenti artık kullanmıyoruz şeklinde bir açıklama yapması. Sonrasında sizin bu kullanılmayan classlar, interfaceler yerine nasıl bir kullanım yapacağınızı öğrenmek için tekrar bir araştırmaya girmeniz gerekiyor. Breaking changes dökümanı Elasticsearch dökümanlarındaki gibi kapsamlı ve kolay değil şeklinde ufak bir serzenişte bulunabilirm.

Bu yazımda size çok fazla Türkçe kaynağı bulunmayan bir konu olarak gördüğüm Elasticsearch upgrade deneyimimden bahsettim. Faydalı olması dileğiyle,