Couchbase Multi-Dimensional Model ve NoSQL Kullanım İyi Pratikleri

Merhabalar, bir önceki yazımda genel olarak PostgreSQL ile ilişkisel veritabanı sistemlerinin scaling ihtiyaçlarını DevOps yaklaşımı ile çözmek üzerine karalamıştım. Scaling konusu aslında platform ve teknoloji bağımsız bir konudur ve yoğun trafik altında, yönettiğimiz tüm platformların yatay olarak genişlemesi hayati önem taşımaktadır.

Bu yazımızda ise, Couchbase özelinde yaptığımız çalışmalardan ve sağladığı faydalara değinmeye çalışacağım. Couchbase yapısı gereği NoSQL olarak çalışan ve çoklu data-center üzerinde aktif aktif çalışmaya uygun bir veritabanı platformudur. Production ortamlardaki kullanımında, cluster mimarisi ve kullanım pratikleri bu platformun performansını ve scalibility yeteğinin üzerinde çok büyük etkilere sahiptir.

Couchbase Cluster Mimarisi

İlk etapta, birden fazla sunucudan oluşan örnek bir Couchbase cluster mimarisi üzerinden gidelim. Normalde bu platform’un her sunucusu üzerinde belirli servisleri çalıştırabiliriz. Yani, Couchbase Data,Index,Query,Search ve Analytics gibi birçok servisten meydana gelir. Kurulum esnasında biz konfigürasyon uygulamazsak tüm servisleri kurar ve hepsine birer bellek(memory) kaynağı ayırır. Bu durum normal gibi görünsede, yoğun kullanılan sistemlerde sadece ihtiyaç duyulan servisin kurulması ve cluster üzerindeki her sunucunun sadece belirli bir göreve hizmet etmesi gerekir. Bu sayede, data servisine sahip sunucuda darboğaz olduğunda sadece data servisini scale edebiliriz ya da index sunucusunda sorun olduğunda sadece o servis özelinde scaling konusuna çalışabiliriz. Bu bize scale olabilme konusunda esneklik kazandırıyor. Aşağıda görüleceği üzere, cluster’da bulunan her sunucunun sadece belirli bir rolü vardır. Bu sayede de, sunuculara ve ihtiyaçlara kaynak planlaması yaparken daha keskin ve doğru “sizing” yapma imkanı doğuyor bize.

Not: Temelde her servisin yoğun kullandığı kaynak farklıdır. Örnek; data ve index servisleri ağırlıklı olarak memory tüketirken query servisi ise CPU tüketmektedir. Multidimensional model ile ihtiyaç fazlası kaynak kullanımının da önüne geçmek mümkündür.

Cocuhbase cluster kurulumu için, daha öncesinde yayınlanmış olan otomasyon çözümüne göz atabilirsiniz ve cluster’ı kurulumunu o şekilde tamamlayabilirsiniz. Bkz :

https://medium.com/trendyol-tech/trendyol-techte-veritaban%C4%B1-provision-i%CC%87%C5%9Flemlerini-nas%C4%B1l-kolayla%C5%9Ft%C4%B1rd%C4%B1k-d0351e909a97

Couchbase cluster mimarilerinde ikinci olarak ise, multi datacenter konusu düşünülmelidir. Bu durumu Couchbase içerisinde bulunan XDCR özelliği ile çözmek mümkün. XDCR’ın temel amacı aktif-aktif şekilde en az 2 datacenter üzerinde Couchbase clusterlarının hizmet vermesidir. Ancak XDCR’ı aynı datacenter içinde de kullanmak mümkündür.

XDCR kurulumu için UI da tercih edilebilir CLI’da tercih edilebilir. Ben CLI kullanmayı tercih ediyorum. Sebebi ise, yapılan değişikliklerin ve konfigürasyonların versiyonlanıp değiştirilebilir ve geliştirilebilir bir durumda olmasını amaç ediniyorum ve gerektiğinde ekip arkadaşlarım git hizmeti veren bir ortamda bu konfigürasyonları geliştirip kullanabilsin.

Örnek XDCR scriptleri aşağıdaki gibidir. Burada ilk önce, clusterlar arası gerekli bilgiler ile birlikte XDCR replikasyonunu yapacak konfigürasyon uygulanmaktadır. Sonrasında ise (2. script), cluster üzerinde bulunan multidc_test isimli bucket’ın belirlenen hedefteki cluster’a replikasyonunun başlatılması işlemi gerçekleştirilmektedir.

Script 1 :

./couchbase-cli xdcr-setup -c kaynak_sunucu_adres:port -u kullanıcı_bilgisi -p password_bilgisi \
— create — xdcr-cluster-name=XDCR_ismi — xdcr-hostname=hedef_sunucu_adres:port \
— xdcr-username=kullanıcı_bilgisi — xdcr-password=password_bilgisi \
— xdcr-demand-encryption=0

Script 2 :

./couchbase-cli xdcr-replicate -c kaynak_sunucu_adres:port -u kullanıcı_bilgisi -p password_bilgisi \
— create — xdcr-cluster-name=XDCR_ismi \
— xdcr-from-bucket=multidc_test — xdcr-to-bucket=multidc_test

Couchbase Servis Rolleri

Cluster mimari işlemlerinde, hangi servislerin olduğundan ve bunların nasıl dağılması gerektiğinden bahsettik. Bu kısımda ise, bu servislerin görevleri ve etki alanları üzerine çalışacağız. Aşağıda temelde 3 servis üzerinden bahsedilmektedir ancak bunun dışında servisler de mevcuttur.

Data Servisi

Couchbase’in en temel servisidir. Cluster üzerinde, en az bir sunucuda data servisi olmak zorundadır. Bu servis key-value olarak tutulan datanın memory’den ve disk’ten okulup yazılması işlemini gerçekleştirir. Bir sonraki çalışmada, bu servisin içerisindeki bileşenleri ve mimari yapısını da irdeliyor oluruz.

Index Servisi

Couchbase üzerindeki primary ve secondary diye tabir ettiğimiz indexlerin oluşturulmasından ve kullanılmasından sorumlu servistir.

Query Servisi

Sistem üzerine gelen N1QL bloklarının çevirilmesinden, başlatılmasından ve sonuçlarının son kullanıcıya teslim edilmesinden sorumlu servistir.

Bunlar ile birlikte, Couchbase üzerinde bir tane N1QL sorgusunun yaşam döngüsü sırası ile şu şekilde gerçekleşmetedir.

  • N1QL sorgusu query sunucusu üzerine gelir ve sorgunun ihtiyaçları tespit edilir.
  • Query sunucusu üzerinden ilk etapta performans göz önüne alınarak talep edilen data index servisleri üzerinden indexlerde aranır. Eğer orada mevcutsa doğrudan index sunucusu üzerinden cevap alınır ve kullanıcıya teslim edilir.
  • Eğer data index servisinde bulunamazsa data servisine gelir ve oradan talep edilen veri seti çekilir ardından son kullanıcıya teslim edilir.

Aşağıdaki grafikte Query-Data-Index servisleri arasındaki ilişki verilmiştir.

Bu kısımda iyi pratik olarak, N1QL sorguları özelinde index çalışması yapılmalıdır. Sorguların ihtiyacı olan verinin %50’sinden fazlası index sunucuları üzerinden temin edilebilir duruma gelmelidir. Bunun için adaptive index ya da karma/birleşik(composite) indexleri tercih edebiliriz. Bununla birlikte primary indexlerin de kullanımını bırakmamamız gerekiyor. İlerleyen zamanlarda index konusundan daha çok bahsedeceğiz ancak, primary indexlerin kullanılmamasının en temel sebebi, bu index’i kullanan sorgular bucket içerisinde bulunan tüm veriyi tarayarak aradığı veri setini elde etmektedir. Bu nedenle de optimize ve iyi pratik olarak nitelendirilen bir kullanım değildir.

Couchbase multidimensional scaling mimarisi ile temelde kazanımlarımız aşağıdaki gibidir.

  • Veritabanı platformunun “scale olma” yeteğini kullanabilir duruma geldik ve ortamların yataya genişleme özelliğini kullanmaya başladık.
  • Veritabanı kümesinde, gereksiz kaynak tüketiminin önüne geçtik. Yani her servise ihtiyacı olan kaynağı vererek ilerlemeye başladık. Query sunucusuna CPU core sayısı olarak kaynak ayrırırken Data sunucusuna daha fazla bellek ayırmaya başladık.
  • Performans sorunlarında, sorunun çözümüne giderken harcadığımız süreyi azalttık. Çünkü artık kümedeki tüm sunucuları ayrı olarak değerlendirebiliyoruz ve darboğaza sebep olan servisi belirlemek kolaylaştı. Daha sonrasında ise, kazandığımız scaling özelliği sayesinde platformu scale edebiliriz. (Sorun bu ise 🙂 )

Sorun çözümleri esnasında, her zaman tek bir doğru ya da yanlış olmayabiliyor. Bu nedenle, cluster üzerindeki herhangi bir sorunu tespit ederken “complexity”’i mümkün olduğunca azaltmak niyeti ile clusterları kurmalıyız. Cluster’ın mimarisi ne kadar karışıksa, karşılaşılan sorunların anlamak,analiz etmek ve çözmek o kadar zorlaşıyor. Mimari ne kadar açık ve çözülmesi kolay ise problem çözümleri ve ileriye yönelik genişleme planları o kadar tutarlı ve gerçekçi olmaya başlıyor 🙂

Sevgiler,

Demir.

Leave a Reply

Your email address will not be published. Required fields are marked *