Elastic Search Scaling

Elastic Search Scaling

Elasticsearchin en önemli ve güzel özelliklerinden biri de scale out bir çözüm olmasıdır. Günden güne çok büyük verilerle uğraştığımız için scaling önemli bir faktör çünkü kimse o milyonlar boyutunda verileri tek bir makinada yani tek bir elasticsearch nodeunda karşılamak istemez. Bu yazımda uçtan uca elasticsearch üzerinde scaling hakkında birşeyler karalamak istedim. Yazı boyunca önce elasticsearch’ü scale edebilmek için elasticsearch clusterina node ekleme, sonrasında eklenen bu nodeların birbirini keşfetmesi yani node discovery daha sonra bu birbirini keşfeden nodeların kendi aralarında master nodelarını seçmesi yani master election, clusterdan kopan elasticsearch nodelarının kendi aralarında ayaklanması yani split brain sonrasında clusterda herhangi bir nodeun çökmesi durumu fault detection ve son olarak da clusterdan node silme olarak tüm konulara ufak ufak değinip elasticsearch için kafanızda bir şeyler canlandırmaya çalışacağım

1. Elasticsearch Clusterina Node Ekleme

Elasticsearch clusterınızı scale etmek için clustera yeni bir node eklemelisiniz. Clusterınıza node eklemek istemenizin farklı sebepleri olabilir. Bunlardan başlıcaları fault tolerance bir sistem inşa etme, reliability, avalibility ve performancetır.

1. Clustera node eklemek search ve indexing performansını artırır çünkü queryler paralelde hem shardlar hem de replika shardlar tarafından çalıştırılabilir. (Performance) ;
   Bu kısmı biraz daha açarsak elinizde 900.000 documentlik bir elasticsearch nodeu olduğunu varsayalım. Bu tek node üzerinde bir request gönderdiğiniz zaman 900.000 adet döküman search edilecektir. Ancak eğer 3 node’unuz varsa 900.000 document bu nodelara 300k 300k 300k olarak dağılacaktır. Attığınız search requesti de paralelde 300k lık bir bütün içerisinde search yapacaktır.
2. Bir query üzerinden out of memory sorunu yaşıyorsa bu da node eklenerek önlenebilir.
   Bu şekilde datayı scale etmek bir bütün olarak cluster’a daha fazla memory eklemek anlamına da gelir yani çok fazla vakit alan veya out of memory memory veren intensive searchler ve aggregationlar için çözüm daha fazla node eklemek olabilir.
3. Replication konsepti ile herhangi bir sebepten bir node’ın çökmesinin veri kaybına yol açması önlenir. (Avalibilty, Fault tolerance system)
   Normal şartlarda elastic search clusterimiza eklediğimiz her yeni node için elasticsearch otomatik olarak shardları eşit dengeleme eğilimine girer. Eğer ki replika ayarlarınız da yapılıysa ki default olarak yapılı gelir, elasticsearch otomatik olarak replikaları da dağıtır. Böylece herhangi bir sebepten sizin primary shardınızın bulunduğu node’unuz çökerse, client tarafında hiç bir sıkıntı yaşanmadan replica shard üzerinden veriye erişim sağlayabilirsiniz.

Elasticsearch clusterınıza yeni bir node eklediğinizde, index özelindeki primary ve replica sharlarınız otomatik olarak bu node’lara dengeli olarak bir node’da bir primary shard ve başka bir shardın replikası olacak şekilde fault tolerance’ı sağlayarak dağılacaktır.

2. Node Discovery

Clusterımıza yeni bir node daha ekledik. Peki ama eski node ile yeni node nasıl tanışacak yani birbirlerini nasıl bulacaklar 🙂 . Aslında sadece Elasticesearch’ün değil tüm dağıtık sistemlerin bir konusu olan, clustera bir node katıldığında bu node’un nasıl discover olacağı ve eski nodelarla iletişim kuracağıdır. Elasticsearch’ün bunun için multicast ve unicast olarak adlandırılan iki farklı yöntemi vardır. İki yöntemi beraber de kullanabildiği gibi, default olarak multicast yöntemini kullanır.

2.1. Multicast Discovery

Multicast networkteki diğer tüm nodelara, “benimle aynı clusterda olan var mı?” diye ping gönderip, response almasına dayanır. Aynı networkde çalışan çok sık IP eklenip çıkarılan esnek sistemlerde kullanışlı bir yöntemdir.

2.2. Unicast Discovery

Unicast discovery elasticsearche bağlanmak ve cluster hakkında daha fazla bilgi sahibi olabilmek için host list’i kullanır. Bu IP adreslerinin çok sık değişmeyeceği production ortamları için idealdir. Örneğin elasticsearch.yml içerisinde discovery.zen.ping.unicast.hosts : [“10.0.0.3”, “10.0.0.4:9300”,”10.0.0.5[9300-9400]] gibi bir listemiz olabilir. Elasticsearch clusterımızdaki tüm nodeların burada listelenmesine de gerek yoktur. Sadece gossip nodelar listelense yeterlidir. Örneğin, 7 nodelu bir sistemde first node diğer 4 node hakkında bilgi sahibiyse, listedeki 2. node da diğer 3 node hakkında bilgi sahibiyse, discovery işlemi yine o 7 tane nodeu bulabilir.

Eğer ki multicast kullanmak istiyorsanız unicasti iptal etmenize gerek yok, listeyi boş bırakmanız yeterli.

3. Master Node Election 

TAMAMMM. Elasticsearchümüz ayakta, nodelar birbirini buldu tanıştı. Şimdi sırada ne var? Master nodeun seçimi 🙂 Elasticsearch clusterında nodelar birbiriyle iletişim kurduğunda ikinci aşama olarak kimin master node olacağı konusunda uzlaşırlar. Peki master node neden var? nedir? ne iş yapar?. Master node ise cluster’in statetinden, shardlarının stateinden, indexten yani  genel anlamda slave nodelardan sorumlu olan nodedur. Eğer clusterınız tek nodedan oluşuyorsa bu node kendi kendini master node olarak seçer.

Master node belirlendikten sonra, ilk icraatı olarak tüm clustera ping atarak clusterin durumunu alive olup olmadığını belirlemeye calismaktır :). Bu duruma da fault detetion denir. Peki bir diğer klasik soru, madem master node diğer nodelar üzerinde yönetici rolune sahip, master node down olursa ne olur. Aslında elastic search’e göre tüm nodelar eğer ki settinglerindeki node.master’ı false’a set etmezseniz master eligible yani master çöktüğünde yerine geçebilecek  node’tur.

4. Fault Detection

Artık birden fazla node olan cluster yapımızı kurduğumuza göre ve üstüne üstlük master node’ımızı da belirlediğime göre, sıradaki aşama yukarıda da biraz bahsettiğim gibi, master nodeın clusterdaki tüm nodelarla iletişim kurarak hepsinin statetinin ok olduğu konusunda el sıkışması kısmıdır ki buna da fault detection process denir. Bu processte master node tüm diğer nodelara ping yollar ve tüm nodelar da mastera ping yollar. Master node herhangi bir nodedan belli bir süre dönüş pingi alamazsa onun down olduğunu kabul eder. Bu süre için aşağıdaki configurasyonlar kullanılır.

discovery.zen.ping_interval : Ping gönderme aralığı

discover.zen.fd_ping_timeout : Pingten dönüş bekleme süresi

discovery.zen.fd.ping_retiest : Retry sayısı.

Bu 3 parametre bir node’ın disconnect olduğunu ve shard routing yapılması gerektiğini ya da master electionun gerekli olduğunu belirleyen 3 parametredir. Bu 3 parametreyi set ederken network latencynizi de göz önünde bulundurmanız gerekir.

5. Split Brain Kavramı

Split brain denen kavram clusterdaki bir veya daha fazla nodein master node ile iletişimini kaybedip kendi aralarında yen  bir master node seçip süreçleri devam ettirmeleri durumudur. Bu durumda iki aynı bağımsız clusterınız olur. Bu durumu engellemek için zen.minimum_master_nodes ayarını set edebiliriz. Bu ayar yeni bir master node seçimi için ve yeni bir cluster tanımlanması için sağlanması gereken minimum master eligible node sayısıdır.

6. Clusterdan Node Silme

Clusterımızı oluşturduk. Nodelarımızı ekledik. Bu nodelar birbirini tanıdı. Masterlarını seçti vs vs. Peki ya clusterdan bir node inerse yahut sen bir nodeı kapatırsan ne olur?. İnen shardın replikaları otomatik olarak primary sharda döner. Bu elastic searchin yapacağı ilk şeydir. Çünkü indexin ilk olarak primary shardlara gider. Yani elasticsearch herhangi bir replicayı seçerek bunu primary sharda çevirebilir. Ancak bu durumdan sonra elastic search clusteri yellow state döner yani replicası olamyan ya da herhangi bir yere allocate edilmemiş shardlar var anlamındadır. Daha sonra elasticsearch kalan nodelar arasında replikalarını oluşturup dağıtır ve sonrasında cluster tekrardan green state’e döner yani her primary shard ve replica shard bir nodea atanmış vaziyette ve cluster güvendedir. Herşey güzel beki birden fazla node çökerse ya da replikası olmayan bir shard giderse ne olur. İşte burda cluster red state’e döner. Yani bir miktar data kalıcı olarak kaybolur… yapılabilecek şey makinayı tekrar ayağa kaldırıp clustera dahil edebilmektir.

Green state : Herşey yolunda, tüm primary ve replica shardlar güvenli bir şekilde nodelara dağıtıldı. Availibity tamam. Herhangi bir node çökerse datanın yedeği başka bir nodeda var.
Yellow state : Replicası olmayan bir shard demektir. Yani bir data parçasının tek bir kopyası var ve bu bir makinede, o da çökerse datan kaybolur. Availibility sallantıda.
Red state :  Replicası olmayan shard down oldu. Kalıcı bir veri kaybı var.

Aslında burada almak istediğiniz riske göre replica shard oranı var kendi sisteminiz için uygun replica yapısını seçebilirisiniz ama  indexlerin backupını almak da her zaman iyi bir fikir olacaktır.

Diğer yararlanılabilecek kaynaklar

1. https://alibaba-cloud.medium.com/elasticsearch-distributed-consistency-principles-analysis-1-node-b512e2b839f8

2. Elasticsearch in Action – Chapter 9 Scaling out