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 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 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/ ü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 ve keyword 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 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.
Top comments (0)