# ElasticSearch 1.7 versiyonun'dan 7.5 versiyonuna geçiş hikayemiz.
Tags: elasticsearch, versionupgrade
Published: 2020-04-09 12:37:57


Merhabalar,

Edindiğimiz tecrübeyi yazıya aktarmak genel'de zor oluyor, fakat tecrübe ve bilgi paylaştıkça daha anlamlı oluyor.

Turkcell içinde müşteri şikayetleri ve diğer süreçleri yönettiğimiz **Onedesk** adında bir uygulamaz var. 

Bu uygulama %100 türk mühendislerinin emekleri ile yazılmış bir BPM alt yapısı üzerinde koşmaktadır. Alt yapı üzerinde koşan tüm uygulamalar ve o uygulamalara ait veriler üzerinde arama ve sıralama işlemleri **ElasticSearch** alt yapısı kullanılarak çalışmaktadır.  Biraz rakamlar ile açıklayacak olursak.

 - Yaklaşık 600 milyon döküman üzerinde anlık 1500+ kullanıcı ile arama
   işlemleri yapılmaktadır. 
 - Sistemin bel kemiğini oluşturmaktadır.   
  - **10 Node** üzerinde **5 Primary ve Replica **  olacak şekilde bir konfügürasyonu ile çalışmaktadır.
   - Ortalama sorgu ve sıralama işlemlerinde **ElasticSearch** üzerinden dönüş
   sürelerimiz **5sn** altındadır.

## Neden version yükseltmeye ihtiyaç duyduk

Yaşam ömrünü tamamlamış bir sürümden dolayı, sıkıntı çektiğimiz durumlarda çözümler genelde yeni sürümler ile sunuluyordu.
 
ElasticSearch 1.7 sürümünden beri bir çok konuda mesafe kat etti ve çözümler sundu.

Özellikle 7.5 sürümünde bellek, disk ve cluster iyileştirmelerinde bize katkı sunacağını düşündük.

## Geçiş Hazırlıkları

ElasticSearch 1.7 versiyonunda [**type**](https://www.elastic.co/guide/en/elasticsearch/reference/7.6/removal-of-types.html) kullanımı vardı,   Indexin altında **type** ile verilerimizi kategorize edebiliyorduk. Fakat 6.8 versiyonundan sonra **type** kaldırıldığını öğrendik bu bizim için çok büyük bir süpriz oldu. 
Çünkü 1 alt yapı üzerinde koşan 12 farklı uygulama var.  Sadece değişiklik **type** ile sınırlı değildi [arama ve DSL](https://www.elastic.co/guide/en/elasticsearch/reference/5.0/breaking_50_search_changes.html)  yapısında değişiklikler söz konusuydu.  

**Neler yapacağımızı aşağıdaki gibi planladık.**

Tüm verilerimizi tekrar indexleyecektik, fakat tüm verileri veritabanından çekip indexlemek çok uzun bir süre olacağı için, Çözüm olarak  ES 1.7 ortamından alıp, 7.5 versiyon şemasına uygun hale getirip indexlemeye karar verdik. 

Bir aktarım aracı yazdık.  Kısaca bahsetmek gerekirse, verileri 1.7 versiyonundan alıp, [https://redis.io/](https://redis.io/) üzerinde muhafa ettik.

> **Redis** üzerinde dosyaya kaydetme işlemini kapattık, Verileri sadece **in-memory** tutacak şekilde konfügüre ettik. 
> Aktarımlar sırasında gördük ki, veri boyutu artıkça, redis anlık görüntüyü kayderderken ciddi problemler yaşıyor.

Bunu yapmamızın sebebi önce veriyi alıp, daha sonra başka bir uygulama vasıtası ile 7.5 uygun desene çevirmek olacaktı. 

Yaklaşık 2 aylık bir süre veriyi toplayıp ve dönüştürmek ile vakit geçirdik. 

Bu süre sonunda, yaklaşık **240 binlik** indexlememiz gereken veriyi yaklaşık **6** saatte aktarabilir hale geldik. 

## Test Süreçleri

Yaklaşık 4 aylık bir test süreci geçirdik.  Sürenin bu kadar uzun olmasının ana sebeplerinden biri kullanıcı deneyimlerinde herhangi bir kayıp yaşatmak istemedik,  1.7 sürümünde veri tipleri sınırlı olduğu için özellikle **Text** alanlarda çok fazla **lucene** syntax kullanmıştık. 
7.5 sürümü ile [`text`](https://www.elastic.co/guide/en/elasticsearch/reference/7.0/text.html "Text datatype")  ve [`keyword`](https://www.elastic.co/guide/en/elasticsearch/reference/7.0/keyword.html "Keyword datatype") gibi iki ayrım olduğu için ona göre kullanıcı deneyimlerimde iyileştirmeler yaptık. daha akıllı aramalar seçenekler sunduk. 

### Preprod test süreci
Canlıda çalışan ElasticSearch topolojisinin birebir uyguladık. ve ek olarak  burada 7.5 sürümü ile gelen [awareness](https://www.elastic.co/guide/en/elasticsearch/reference/7.x/allocation-awareness.html#forced-awareness)  ayarlamasını yaptık. 
Kısaca bahsetmek gerekirse 2 farklı lokasyonda veri tutuyorsanız, replica shard ile primary shardlar kesinlikle ayrı lokasyonda olması kuralını koyduk. 
Herhangi bir lokasyonda çıkacak problemde veri kaybı yaşamamak için çok güzel bir özellik. 2 farklı lokasyonda 2 master node olacak şekilde konfigüre ettik.  
Preprod testlerimizde başarılı sonuçlar alınca canlı geçişi için hazır hale geldik.

## Devreye  Alım

PROD devreye alımından sonra, bir süre sistemi izledik, Geçişten 2 gün sonra TCP Keep Alive ile ilgili bir sorun yaşadık,  ElasticSearch süresiz bir bağlantı açıyor ( long-lived TCP connections ) fakat şirket prensipleri gereği, bu sürenin bizde sınırlı olduğunu öğrendik, Windows yaptığımız konfügürasyon ile bu probleminde üstesinden geldik.   
<!--stackedit_data:
eyJoaXN0b3J5IjpbOTExNDY5MjEsMTM0MDc3NjY2M119
-->