AWS & ELASTICSEARCH — NASIL YAPSAK ?

Mehmet Uğur Güral
hesapkurdu-development
4 min readMay 15, 2018

“Şimdi bu başlık ne alaka ?” dediğinizi duyar gibiyim :) Çok ufak bir arama ile Elasticsearch için onlarca makale, kurulum ve optimizasyonlar için bir çok tavsiye ve örnek bulunmakta. Teknik olarak bir çok yeterli kaynak mevcut, hatta hiç elinizi kirletmeden sizin için yeni bir cluster kurulumu yapabilecek çözümler de mevcut, özetle başlayabilmek oldukça kolay. Fakat cevabı çok değişken bir soru halen mevcut, “Bize nasıl bir çözüm gerekli ?”.

Sorular, olası senaryolar ve çözüm bulma çabaları :) İnsan geriliyor.

Hesapkurdu.com olarak Elasticsearch maceramıza atılmamızın temelinde esas olarak sitemiz üzerinde alıp işleyebileceğimiz çok farklı türde ve önemli olabilecek veri akışının olması, bunları anlamlandırıp hem gelen ziyaretçilerimize daha kişiselleştirilmiş bir deneyim sunmak, hem de işimizin merkezi finans olduğu için bu alanda da ne gibi yenilikler yaratabiliriz sorusuna cevap aramaktı.

Her ne kadar bir fabrikada olmasak da, binlerce sensörden gelen günlük milyonlarca farklı verimiz olmasa da ziyaretçi davranışlarını anlamlandırmaya çalışmak bile başlı başına yorucu bir iş ve burada müthiş bir fikir olarak aklımıza verilerimizi Elasticsearch üzerine taşımak geldi. Tamam kabul ediyoruz, fikrimiz pek de müthiş değil :), ancak Elasticsearch bu fikrimiz için müthiş bir ürün.

Fikrimizi hayata geçirebilmek için ilk adım olan Elasticsearch kurulumumuzda aslında çok da özel ve bu Post’un konusu olan bir durum bulunmamaktaydı. Onlarca farklı dağıtım ve servislerden birisi ile hızlıca işe girişmek istedik, bunun için de yine en kısa yoldan uygulama ve iş çözümlerimizin bir çoğunun barındığı AWS üzerinde bir Elasticsearch servisi ayağa kaldırdık. Evet, olması gerektiği gibi standart bir kurulum ve her şey akışa uygun gidiyordu. Fakat yeterli miydi, işte orada dertlerimiz başladı :)

AWS Elasticsearch Service her ne kadar hızlı ve basit bir çözüm olsa da iş senaryonuza göre kullanmanız önem taşıyor.

AWS Elasticsearch Service esas olarak bize başlangıçta istediğimiz her şeyi sundu, işin temelinde ne yatıyor, index yapısı nedir ve nasıl kullanmamız gerekiyor, verimizi nasıl tutabilir ve nasıl alabiliriz gibi sorularımıza cevap vererek bizi mağaramızdan çıkardı ve temelde neler yapabileceğimizi hızlıca öğretti :) Eğer siz de bu anlamda yolun başında iseniz veya veri trafiğiniz sınırlı ise gerçekten çok da sağa sola bakınmadan bir cloud provider üzerinde bu işi yapmak basit ve verimli bir çözüm olabilir.

Her şey güzel, ya sonra?

Fakat ilerledikçe yolunda gitmeyen bazı şeyler olduğunu fark ettik, ve evet tahmin edebileceğiniz gibi ay sonu gelen fatura bunlardan biriydi :) Adaptasyon kolaylığını düşünerek maliyeti bir süreliğine göz aldık. Ne de olsa hızlı bir giriş yapıp deneyim edinmeye başlamıştık. Ancak sadece teknik sorunlara odaklandığımızda bile yeterli cevaplar alamadığımızı gördük.

Debug & Log

Bu noktada AWS Elasticsearch Service şaşırtıcı bir biçimde etkisiz kalıyor. İşler beklenmedik şekilde gittiğinde teknik anlamda yapabileceğiniz ilk müdahale servis loglarını kontrol etmek ve imkanınız var ise debug edebilmektir. Ancak bu noktada loglar ve debug şansınız maalesef çok kısıtlı. Eldeki imkanlar hatanın kaynağını bulma noktasında pek yardımcı olmuyor. Saatlerce bir noktada takılıp kalmanız olası. Aynı şekilde servisinizin fail olması durumunda da monitoring için kullanılan Amazon cloudwatch bu noktada sadece çok basit isteklere cevap verebiliyor.

Plugin desteği

Bu noktada da bir çok yerde görebileceğiniz gibi baş ağrıtabiliyor. X-Pack gibi büyük ve her seviyede kullanabileceğiniz pluginlerin yanı sıra bizim de şu an kullanmakta olduğumuz ElastAlert gibi irili ufaklı bir çok işe yarar plugin maalesef şu an desteklenmemekte.

Instance seçimleri

Seçebileceğiniz instance tipleri üzerinde de AWS Elasticsearch Service üzerinde bir takım kısıtlamalar bulunmakta. Bu eğer amacınız küçük bir cluster’ı yönetmekse belki baş ağrıtmayabilir ancak veriniz katlandıkça ve genişlemek istediğinizde karşınıza gereksiz şişkin faturalar (Kendi EC2 Instance’ınız üzerinde kurulabilecek bir Elasticsearch kurulumuna nazaran nerdeyse 2 kat fazla) getirebilir.

Update ve hotfix’leri geriden takip etmek

Doğası gereği SAAS çözümlerinde eğer yazılımın kendisine bir güncelleme geldiyse bunun platformda da karşılık bulması biraz zaman alabiliyor. Fakat AWS üzerinde bu zaman biraz daha göreceli işliyor J hotfix ve update’ler konusunda Amazon biraz daha geriden takip etmekte maalesef, bu noktada da yeni bir çözüm veya teknoloji kullanmanız gerektiğinde bizim karşılaştığımız gibi bir duvarla karşılaşmanız kuvvetle olası.

Yaşadığımız sorunları bu başlıklar altında toparlamaya çalıştık bu henüz yolun başında olduğumuz macerada. Ancak bu kısa sürede bile, yaşadığımız sorunlar bizi tamamen kendimize ait bir EC2 Instance üzerinde Elasticsearch kurulumu yapmaya zorladı. Yazımızın genel gidişatı AWS’nin Elasticsearch çözümünü gömmek gibi algılansa da esas olarak belirtmek istediğimiz işin renginin senaryonuza göre değişebileceğini işaret etmek :) Başta da belirttiğimiz gibi senaryonuz bunları kaldırabilecek durumdaysa hızlıca kurulabilmesi, konfigürasyon kısmını fazla kullanıcıya bırakmaması noktalarında hiç de fena bir çözüm değil.

Tecrübeler biraz can sıkıcıydı ama geldik başlığımızın anlam kazandığı noktaya, peki nasıl yapsak ?

Nasıl yapmalı ?

Nasıl bir çözüm seçmeniz gerektiği de aynı şekilde yapacağınız iş ve almak istediğiniz sonuca göre şekilleniyor, işiniz yüksek önem içerip içermemesine, sizin Elasticsearch’ü ne seviyede kullanabildiğinize ve ne derece elinizi kirletmek istediğinize göre cevaplar değişkenlik gösterebiliyor. Aşağıdaki diyagramda temel sorulara göre ana bir fikir edinebilirsiniz :

Yaşadığımız macera ve yukarıda paylaştığımız sorunların detaylı incelemelerini ilerleyen yazılarda paylaşıp tekrar karşınızda olacağız, sorularınız için medium ve dev@hesapkurdu.com üzerinden bize ulaşabilirsiniz, takipte kalın !

--

--