Bir önceki yazımda, CAP Prensibinden bahsetmiştim. Bu yazımda, sistemimizi kurgularken strong consistence olarak mı? yoksa highly available olarak mı? kurgulamalıyız üzerine fikirler ortaya sunacağım. Öncelikle biz, verimizin Partition Toleransının yüksek olmasını istiyoruz. Veriyi parçalamak ve dağıtmak istiyoruz. Partitioning ve Sharding konularına ileri ki bölümlerde değineceğim.
Peki; CAP prensibi bize sadece 2 özelliğe sahip olabileceğimizi söylüyordu. Biz P’nin sistemimizde olmasını istiyorsak geriye C ve A arasında seçim yapmak kalıyor. Neye göre seçmeliyiz? Neden seçmeliyiz? sorularına yanıt aramak için bu yazıyı yazıyorum. Strong Consistency mi? yoksa High Availability mi?
CAP prensibine göre, ya strong consistence olacaksınız, ya da highly available olacaksınız.
Strong Consistency;
Saklanılan verinin bir kopyası varmış gibi çalışıyor muyum, çalışmıyor muyum?
Highly Available;
İstediğim node’a bir request atarım ve ben bu request’e cevap alır mıyım?
Günümüzde çoğu firma availability’e daha çok önem vermektedir. Buna sebep olarak hizmet devam ettirebilme ve müşteri kaybını önleme verilebilir.
Düşünsenize, kullandığınız bir sosyal medya var ve arkadaşlarınızın neler paylaştığını görmek istiyorsunuz. Ama sayfa ortada yok, gitmiş. Hemen bir alternatif servis aramaya başlarsınız ki günümüzde alternatif olarak bir çok servis var.
Peki bir bankayı ele alalım. Para transferi yapmak istiyorsunuz, ama yapamadığınızı hayal edin. Ve bu transferini yapmak sizin için çok önemli olsun. Bankayla aranızda ki ilişki çok sıkı olacaktır diye düşünüyorum :)
Veya bir mail servisi kullandığınızı düşünelim. Birden çok mail servisi veren firma var. Siz o kadar firma arasından o firmayı seçmişsiniz ve o firmaya bir şans vermişsiniz. Ama maillerinizi görüntüleyemediniz. Aynı şekilde mail de gönderemediniz. Bir daha o servisi kullanır mısınız? Hayır tabi ki.
Siz bir servisi kullanıyorsunuz, üstelik ücretsiz. Sakın firmaya müteşekkir olmayın. Çünkü siz ona bir şans veriyorsunuz! Bir söz var, şuan bu durumu çok güzel özetliyor.
Aldığınız hizmet karşısında bir ücret ödemiyorsanız,
Ürün aslında sizsiniz!
Yukarıda sürekli availability’den bahsettim ancak, servisin doğru ve tutarlı çalışması da, servisin çalışması kadar önemlidir.
Aklınıza şu soru gelmiş olabilir, CAP teoremine göre, AP olduysak Consistency’e elveda dememiz gerekmiyor mu? CAP teoremi sistemi 1–0 Binary variable olarak ele aldığı için teoride elveda demeniz gerekiyor.
Ama teori ve pratik çoğu zaman farklıdır. Yani hybrid bir sistem kurabilirsiniz. Ama aynı anda strong consistence ve highly available olmak çok zordur. Günümüzde bazı firmalar bu sorunları aşmış olabilir.
Örneğin siz, strong consistence, sticky available olabilirsiniz. Consistency ve Availability’nin dereceleri ve modelleri bulunmaktadır.
Peki strong consistency isteyen firmalar neler yapıyor? Consistency isteyen firmalara bakacak olursak, birinci sırayı bankalar, yatırım şirketleri, kısaca para içeren sektörler çekmektedir :)
Örneğin şöyle bir şey olsa dünyada nasıl bir kaos hakim olurdu?
Strong consistency olmayan bir bankanın sistemine girdiniz ve A node’unda işlem yaptığınızı düşünelim. Para transfer işlemi başlattınız. Bakiyeniz X miktarından Y miktarına azalacaktır.
Daha sonra sistemden çıkıp tekrar girdiğinizi hayal edin. Ve B node’unda çalıştığınızı varsayalım. A node’unda yapılan değişiklikler daha B node’una gelmemiş. Yani bakiyeniz hâlen X miktarında :) Tabi ki bu bir hayal :)
Consistency ve Availability’nin ne kadar önemli olduğunu sanırım anladık. Peki bir Mühendis veya Mühendis adayı olarak siz/biz/onlar ne yapıyor, ne yapmalı?
CAP Prensibi sistemi 1–0 Binary variable olarak tanımlamaktadır. Bunların da kendilerine göre dereceleri ve modelleri bulunmaktadır.
Consistency; Data centric, Client centric
Availability; High availability, Stick availability, Non-availability
Ne istediğinizi bilmelisiniz. Örneğin, sticky available oldunuz. Ama 1 yıl boyunca hiç down olmamış olabilirsiniz. Her zaman sorun çıkacak diye bir kural yok. Ama siz her zaman bad case’e göre hareket etmelisiniz. Polyanna’cılık oynamamalısınız.
Data Centric
Strong consistency istiyorsanız, data centric olmalısınız. Yani siz clusterınızda bir tane görüntü varmış gibi çalışıyorsunuz, ama aslında veri dağıtık.
Herkes aynı şeyi görüyor ve bunu yapmak gerçekten zor. Clusterda veri üzerinde yapılan her işlemi transaction bitmeden tamamlamış olmak bunu sağlamanın bir yolu. Tabi ki maliyeti zaman. Ve clusterda ne kadar çok node varsa, replication süresi de o kadar artıyor.
Client Centric
Tam olarak strong consistence denemez ama, size bir consistency sağladığı bir gerçek. Clusterımıza clientlardan bağlantı gelecek. Read-write işlemleri olacak. Consistency’i sağlamak için her client için kendisine özgü, kendi bakış açısından bir model/görüntü oluşturulur. Ve client sadece bu model üzerinden işlem yapmaya başlar. Diğer clientlar tarafından yapılan yapılan write işlemlerini bilmesin, tabi ki kısa bir süreliğine.
Bunu bir örnek ile anlatsam daha iyi olacak sanırım.
Bir sosyal medya platformu düşünün. Acaba hangisini düşündünüz? Şu ilk çıkanı düşünsek daha iyi gibi sanki :)
Platform highly available. Her an aktif ve ayakta. Veri merkezlerini kurmuş ve veri merkezleri yenilenebilir enerji ile çalışıyor. Ve consistency istiyorlar. Kullanıcılarına olabildiğince güncel paylaşımlara erişmelerini istiyorlar. Bunu yapabilmek için de client centric modelini kullanıyorlar. Çünkü strong consistence’a yakın olmak istiyorlar. Data centric yapmak çok zor olduğu için bu modeli seçmişler.
Bir post paylaştınız. UI/Sayfayı güncellediğiniz zaman siz bu post’u görebilirsiniz. Böylece consistency’i sağlamış oldunuz. Ama sizin takipçileriniz bir kısmı bu durumdan hemen haberdar olmayabilir. Bu demektir sizin takipçilerinizin bağlı olduğu replica bu güncellemeden haberdar değil. Daha replicate olmadı. Ama bu bir sorun değil. Çünkü o bunun paylaşıldığı bilgisini henüz bilmiyor :) Biliyorsa da, 1–2 sn içinde o posta erişebilir konumda olacaktır. Çünkü replication işlemi 1–2 sn içinde tamamlanır.
Asıl sorun 1–2 sn sonra görmesi değil, takipçinin postu daha önce görmüş olması ve daha sonra bu post’u göremiyorsa, burada büyük bir sorun var demektir. Buna da Lost Update diyoruz buna bir sonra ki yazımda değinmeyi düşünüyorum.
Bu şekilde olursa sistemi 1–0 olarak değil de, birden fazla spekturuma sahip bir hale getirebiliriz. Seçilen modele göre replication modeli değişiklik gösterir.
Her zaman olduğu gibi projenin gereksinimlerine göre; high availability mi, yoksa strong consistency mi istiyoruz? diye sorup seçimlerimizi ona göre yapmalıyız.