CAP Teoremi ve ACID, BASE Kavramları

CAP TEOREMI

Sistemlerin büyümesi, sahip olduğumuz veri boyutunun ve öneminin giderek artmasıyla veri tutma ve işlemede tek makine ile çalışmak artık yeterli olmamaya başladı. Bu yetersizliğin farklı sebepleri olmakla birlikte başlıcaları, tek makine performansının yetersizliği, sistemin herhangi bir çökmede single point of failure oluşturması ve belli localization latencylerine sebebiyet verebilmesi olarak sıralanabilir ve bu da verimizi farklı makinalara dağıtma yani dağıtık sistemler kurma ihtiyacını doğurur . CAP teoremi dağıtık mimarı kurgularken aklımızda bulundurmamız gereken teoremlerin başında gelir. CAP teoremi bize dağıtık mimarı kurgularken karşılaşacağımız trade-off’u anlatır. Consistency, Availability ve Partition tolerance’nın baş harflerinden oluşur ve bize eğer ki bir dağıtık mimari kurgulamak istiyorsanız bu 3 kavramı aynı anda sağlamanız&önceliklendirmeniz mümkün değildir, bunu sağlayacak bir teknoloji yapamazsınız ve muhakkak birinden feragat edip geri planda bırakmak zorundasınız der.

Öncelikle bu kavramların ne olduğunu açalım.

Consistency (Tutarlılık) : Dağıtık mimarilerde tutarlılık, verinin birden fazla replicası olduğu durumlarda, siz bir veriyi güncellediğinizde verinin diğer tüm makinalardaki kopyaları en güncel halini alıyor mu? konusudur. Eğer tüm makinalar verinin en güncel haline sahipse consistency yani tutarlıdır diyebiliriz.

Availability (Mevcut olma) :Tüm serverlar tüm requestlere doğru ya da hatalı sonuç dönebiliyor mu? Eğer dönebiliyorsa available diyebiliriz. Burada hatalı sonuç dönmekten kasıt aslında tutarlı yani güncel olmayan bir sonuç dönmektir. Yani serverlarınız ya günceldir (consistent)  doğru sonuç döner ya da güncel değildir ve güncel olmayan sonuç döner. İki durumda da server avaliable’dır diyebiliriz.  Buradaki availability durumu, sunucunun veya sistemin cevap vermesini kapsar ama bu cevap verme bir hata mesajı veya az önce söylediğimiz sistemin şu anda istenen veriyi döndürememesi şeklinde de olabilir. Örneğin banka sisteminde, şu anda bakım yapılıyor olması yüzünden hesaplara ulaşılamaması, ve sistemin bu şekilde bir hata vermesi sistemin ulaşılabilir olduğu anlamına gelir. O zaman availability’yi bir nevi “server not respond” alıp almamak olarak da değerlendirebiliriz.  Alıyorsak available değil almıyorsak available’dır diyebiliriz.

Partition Tolerance (Hata Toleransı) : Sistemin bir parçasında sıkıntı olduğunda yani ağdan koptuğunda sistemin kalanı doğru bir şekilde çalışmaya devam ediyor mu? Eğer ediyorsa partition tolerance var diyebilriz.

İşte CAP teoremi de bize bu 3 özelliği aynı anda sağlayacak & önceliklendirecek bir sistem kurmanızın mümkünatı yoktur diyor. Nedenini bu özellikleri 2li 2li ele alarak inceleyelim.

1.Consistent ve Partiton Tolerance Sistemler (CP)

Bir atm sistemimiz olduğunu ve sistemimizin consistency ve partition tolerance özelliklerine sahip olduğunu varsayalım. Dolayısıyla Availabilityden feragat etmemiz gerekecek. Neden mi?

• Sistem consistency’e sahip ise bir atmye para yatırdığımda diğer tüm atmlerde de param güncellenir ve gidip diğer bir atmden para çektiğimde ya da bakiye sorguladığımda güncel rakamları görürüm.
• Sistem partition tolerance’a sahip ise atmlerden biri ağdan koptuğunda, kalan atmlerin hepsi doğru hizmet verebiliyordur.
• Ancak bu durumda availability sağlanamaz çünkü sistem consistent’tır yani tüm makinalarda güncel veri bulunmalıdır. Ancak ağdan kopan makina sisteme bağlı olmadığından güncel verilere ulaşamaz. Dolayısıyla sistemin availablity özelliğinden feragat edip consistency’ı sürdürebilmek için bu makinayı indirmeliyiz yani ATM ekranında “server not respond” yazdırmalıyız 🙂 diğer atmler de yukarıda bahsettiğim gibi doğru bir şekilde hizmet vermeye devam eder.

2.Available ve Partition Tolerance Sistemler (AP)

Aynı atm sistemi üzerinden düşünmeye devam edelim.

• Sistem partition tolerance’a sahip ise atmlerden biri ağdan koptuğunda, kalan atmlerin hepsi doğru hizmet verebiliyordur.
• Sistemin bir de available olduğunu varsayalım. Bu durumda ağdan kopan makineyi indiremeyiz yani ağdan kopmuştur ve yinede hizmet vermeye devam ediyordur. Ama farklı olarak ağdan koptuğu için güncellenemiyor ve güncel veriyi yani bakiyeyi müşteriye sunamıyordur. Ancak yukarıda availabilitynin tanımını yaptığım kısımda güncel olmasa dahi sonuç vermesinin available olması için yeterli olduğunu söylemiştim.
• Ağdan kopan makinanın availability’sini sağlamak için güncel olmasa bile hizmet vermesine olanak tanıyorsak zaten consistency’den feragat etmişizdir bile 🙂

3.Consistent ve Available Sistemler (CA)

• Sistem consistent ise bir atmye para yatırdığımda diğer tüm atmlerde de param güncellenir ve gidip diğer bir atmden para çektiğimde ya da bakiye sorguladığımda güncel rakamları görürüm.
• Sistem available ise her şekilde öyle veya böyle sonuç döner. Ancak burada bir durum var availability için doğru ya da yanlış yani güncel olmayan veri dönebilir demiştik ancak bu sistem aynı zamanda consistent yani tüm makinalar güncel olmalı. O zaman bu durumda makinalardan biri ağdan koparsa tüm sistem kitlenir. Yani CA durumunda tüm makinalar hem ayakta olacak hem de güncel olacak. Birinin bile çalışmadığı durumlarda sistem partition toleransa sahip bir şekilde kalan sistemi çalıştıramaz çünkü ağdan kopan consistent olmaz. Bu sefer de partition tolerancedan feragat ettik 🙂

Burada yanlış anlaşılmaya yol açabilecek bir konuyu özellikle belirtmek istiyorum. CAP teoremi size, bu üç özellikten sadece 2’sini seçebilirsiniz diğerini yok sayarsınız gibi bir şey söylemiyor. CAP teoreminin söylediği şey, bir ağ bölümlenmesiyle yani ağdan kopma vakası ile karşılaştığınızda bu 3 özellikten hangi 2sini önceliklendireceğinizdir. Bir örnek üzerinden gitmek gerekirse, availability ve partition tolerance’ı önceliklendirdiğinizi varsayalım. Bir makine ağdan koptuğunda o makine hala hizmet verir ancak güncel olmayan veriler ile hizmet verir. Ancak o makine tekrar ağa dahil olduğunda gerekli güncellemeleri alır ve 3 özelliği de sağlamış olur ki bu da bizi eventually consistency konseptine götürür. Bu da birazdan bahsedeceğim konudur.

Database teknolojieri de bu öncelikler üzerine kuruludur. Örneğin,

Apache Cassandra, tasarımı itibariyle partition tolerance’a sahiptir ve availability’i önceliklendirir. Bununla birlikte consistency’ı feda eder. Yani ağda bir kopma olması ve veri merkezlerinin birbiri ile senkronizasyon yapamaması durumunda, iki veri merkezi de hizmet vermeye devam eder (availability) ancak iki veri merkezindeki veriler de farklı şekilde güncellendiği için tutarlı değildir.

Klasik veri tabani teknolojileri consistency’ı önceler ve ağda herhangi bir problem olması durumunda diğer kopyalarla erişim probleminden dolayı hizmet vermeyi durdurur.

Diğer bir örnek ise MongoDB teknolojisi olabilir. MongoDB, yapısı itibariyle, consistency ve partition tolerance’a. Ancak bu sefer de availability feda edilmiştir.

Eğer verilerinizi dağıtık olarak tutacaksanız ve veri tabanı seçimi yapmanız gerekiyorsa, kullanacağınız veri tabanının hangi 2liye öncelik verdiğine de bakmanızı öneririm.

ACID ve BASE Sistemler

ACID (Strongly consistent)

ACID, RDMS transaction’u için tanımlanmış kurallar bütünüdür. Bu kurallar ile RDMS’ın consistent ve available olması amaçlanır.

1.Atomicity (Bölünmezlik) :Ya hep ya hiç kuralı da diyebiliriz. Transaction bir bütündür.  Bir transaction içerisinde ya bütün işlemler yapılır ya da biri dahi gerçekleşmiyorsa hiç biri gerçekleşmez ve bu transaction daha ufak parçalar halinde ele alınamaz.

2.Consisteny (Tutarlılık) : Transaction tam anlamıyla gerçekleşene kadar, işlemden etkilenen verilerin bir önceki değeri vermesi. İşlem gerçekleştikten sonra alınan çıktı ise yapılan işlemin sonucunda beklenen çıktı olmalıdır ki veriler arasında transaction işlemleri sebebiyle herhangi bir tutarsızlık olmasın.

3.Isolation (izolasyon) : Transactionlar izoledir. Birbirlerini etkilemezler. Her transaction birbirinden bağımsız olmalıdır. Bir diğer işlemin çalışması için o anda çalışan bütün işlemler, farklı kaynaklara erişmelidir veya aynı kaynakları kullanıyorlarsa da işlem bekletilerek kaynaklar serbest bırakıldıktan sonra çalışmalıdır. Çoğu veri tabanı bu özelliği sağlamak için veri tabanı kaynakları üzerine kilitler (lock) koymakta ve işlem bitene kadar diğer işlemlerin erişimini engellemektedir.

4.Durability : Transaction sırasında fiziksel veya işlemsel bir hata olması durumda sistemin kendisini bir önceki geçerli duruma döndürebilme kabiliyetidir. Yani sistem çökmeleri, ani kapanmalar, ağ kopmaları gibi çok sayıda donanımsal veya veri tabanı sisteminin dışında cereyan eden problemlerde, veri tabanı sisteminin verilerin ve işlemlerin (transactions) sağlığını garanti ediyor olması gerekir

BASE (Eventually consistent)

BASE ile sistemin partition tolerance ve availability’ye sahip olması olması amaçlanır. BASE ile dağıtık sistemlerde consistency feragat edilerek availability sağlanır. Consistency ise eventually olarak sonradan sağlanır. BASE’in açılımı da basically avaliable soft state services with eventually consisteny‘dir. Nosqllerin büyük bir kısmı BASE prensibi üzerinden çalışır. Yani consistency’den feragat eder.

BASE’in ana dayanağı olan eventually consistent’ın bize söylediği şey, ben sistem olarak sana her daim consistent data sunmayı vadetmiyorum o an elimde ne varsa onu veririm ki bu data henüz bir işlemin ortasında olabilir yani tutarsızlık olabilir ya da data henüz güncellenmemiş bir node’dan gelebilir. Ancak bu data elbet sistem gerekli operasyonları tamamladığında consistent hale gelecektir. Dolayısıyla NoSql çözümlerinde her zaman ulaştığınız datanın consistent olmasını bekleyemezsiniz.

Bir de BASE’in konseptlerini bir bir inceleyelim.

1.Basically Available : Sistem CAP teoremi bazında availability’i garanti eder. Yani yukarıda availability hakkında yapılan tanımlar, base sistemler için geçerlidir.

2.Soft State : Sistemin veri güncelleme veya geçiş durumlarında takındığı haldir. Sistemin statei zaman ile input olmasa dahi değişebilir ve sistem geçiş durumunda olabilir. Sebebi ise eventually consistent modeldir.  Yani anlık farklılıklardan doğan ve sistemin anlık resmi çekilse farklı olan veriler, sistemin soft stateini oluşturur.

3.Eventally Consistent : Sistem daha fazla değişiklik ve yeni veri almadığı durumlarda, yeterli zaman tanınırsa, verinin farklı kopyalarını eşleştirerek bütün sunucularda tutarlı bir duruma erişebilir ve soft state’ten çıkmış olur. Buna göre sistem zaman ile consistent olacaktır. (Sistemin zaman içerisinde girdi almadığı göz önüne alındıgında tabi).

Bu doğrultuda ACID prensiplerine baktığımızda vazgeçilmez görünüyor, ancak yine de çok büyük sistemlerde kullanılabilirlik ve performansla uyumlu değiller. Örneğin, bir online kitapçı işlettiğinizi ve envanterinizde her kitabın kaç tane olduğunu listelediğinizi varsayalım. Birisi bir kitap satın alma sürecinde olduğunda, veri tabanının bir bölümünü  işlem bitene kadar kilitlersiniz, böylece dünyadaki tüm ziyaretçiler doğru envanter numaralarını görebilir. Bu, yaklaşım ufak bir online book store’unuz varsa işler ancak amazon.com gibi bir sitede tabiki de patlar.

Peki Amazon bunun için neler yapabilir? Amazon bunun yerine cachelenmiş verileri kullanabilir. Kullanıcılar bu saniyedeki envanter sayımını değil, son anlık snapshot çekildiğindeki datayı görür. Ya da Amazon, eşzamanlı işlemlerin birbirini etkilemesine dair küçük bir olasılığı tolere ederek ACID’deki “I” i ihlal edebilir. Örneğin, iki müşteri belirli bir kitabın son kopyasını satın aldıklarına inanabilir. Şirket, sitelerini yavaşlatmak ve sayısız diğer müşteriyi rahatsız etmek yerine, iki müşteriden birinden özür dileme (ve belki bir hediye kartıyla telafi etme) riskiyle karşı karşıya kalabilir.

Her işlemden sonra tutarlı hale gelmek yerine, veri tabanının sonunda tutarlı bir durumda olması yeterli olabilir. (Muhasebe sistemleri bunu her zaman yapar. Buna “yılsonu kapanışı” denir.). Bu gibi sistemlerde eski verileri kullanmak ve yaklaşık cevaplar vermekte çok büyük sorun yoktur. Hataya toleranslı BASE dünyasında yazılım geliştirmek, titiz ACID dünyasına kıyasla daha zordur ancak Brewer’ın CAP teoremi, ölçeği büyütmek istiyorsanız başka seçeneğiniz olmadığını söylüyor. Ancak Brewer’ın bu sunumda da işaret ettiği gibi ACID ile BASE arasında bir süreklilik vardır. Önceliklerinize göre sürekliliğin bir ucuna veya diğer ucuna ne kadar yakın olmak istediğinize karar verebilirsiniz.