Complex sistemler design ederken sıklıkla bazı seçimler yapmak durumunda kalırız.
Sistemlerin kompleksliği bazen high availability concern’lerinden ileri gelirken bazen de business complexity ile başa çıkmak sistemlerimizi öngörülemez seviyede complex kılabilir.
Modern sistem mimarilerinin genellikle distributed sistemler üzerine kurulduğunu düşünürsek sistemlerimiz adına alacağımız pek çok önemli karar vardır. Bu noktada CAP teoremi Consistency, Availability ve Partition Tolerance özellikleri arasında seçimler yapmak zorunda olduğumuzu bizlere söylemektedir.
Bu doğrultuda system component, business workflow ve user experience doğrudan veya dolaylı olarak etkilenecektir.
Öncelikle “Distributed Sistem” ve “CAP Teoremi” üzerine kısaca gerekli tanımlamaları yapalım.
Distributed Sistem nedir?
Birçok node’un birbirlerine bağlı olarak çalıştığı dağıtık sistemlerdir. Bu node’lar, birbirlerine veri ve bilgi paylaşabilir ve birbirlerine görevler dağıtabilirler. Bu sayede, distributed sistemler daha esnek ve performanslı hale gelir ve complex görevleri yerine getirirken daha verimli çalışabilirler.
Örneğin, bir distributed database sistemi, veritabanı verilerini birden fazla node’a dağıtarak depolayabilir ve bu sayede daha hızlı ve esnek hale gelir. Başka bir örnek olarak, bir distributed computing sistemi, büyük ve kompleks hesaplamaları birden fazla node’a dağıtarak yapabilir ve bu sayede işlem daha hızlı ve verimli bir şekilde yapılabilir.
CAP Teoremi nedir?
CAP teoremi, distributed sistem’lerde veri yönetimi ile ilgili bir teoremdir. Bu teorem, dağıtık sistemlerin, üç önemli özelliği arasında bazı seçimler yapmak zorunda olduğumuzu ileri sürmektedir. Nedir bu özellikler?
Consistency (Tutarlılık)
Sistemde yapılan data değişikliklerinin, kullanıcı veya sistemin geri kalanı adına aynı olabilmesidir.
Örneğin, bir banka hesabında para transferi yapılırken, tutarlılık özelliği göz önünde bulundurularak, hesap bilgileri doğru bir şekilde güncellenmelidir.
Availability (Erişilebilirlik)
Sistemde yapılan data değişikliklerinin, kullanıcı veya sistemin geri kalanı adına erişilebilir olmasıdır.
Örneğin, Bir e-ticaret sisteminde, ürünlerin her zaman gösterilebilir ve satın alınabilir olması önemlidir. Bu nedenle ürün bilgileri birden fazla node’da saklanır. Bu sayede, bir node’un çalışmaması durumunda bile, ürünlerin erişilebilir ve satın alınabilir olması sağlanır.
Partition tolerance (Hata töleransı)
Bir distributed sistem’in bir veya daha fazla node’un birbirlerine ulaşamaması durumunda sistemin hala çalışmaya devam edebilmesini ifade eder.
Örneğin, bir mesajlaşma uygulamasında partition tolerance özelliğine sahip olmak, uygulamanın bir kısmında bir hata olması durumunda diğer kısımların hala çalışmaya devam edebilmesini sağlar. Uygulamanın bir kısmında bir sunucu arızası olabilir ve bu nedenle bu sunucuya bağlı olan kullanıcılar mesaj gönderemeyebilirler. Ancak, uygulamanın diğer sunucuları hala çalışmaya devam edecektir ve bu sunuculara bağlı olan kullanıcılar mesaj gönderebilirler. Bu sayede, uygulama hala çalışmaya devam edebilir ve kullanıcılar arasında iletişim kurulabilir.
Önemli Not: CAP teoremi sadece database sistemlerini karşılaştırmak için değil, genel system design’ımız için bir başvuru kaynağı olarak görülmelidir. Örneğin, mission critical bir business işlettiğim complex bir sistem’e sahibim. Burada data consistency benim yürüttüğüm business’a bağlı olduğuna göre bu concern öncelikle domain katmanımın konusu olmalıdır. Aksi takdirde data consistancy odaklı ön plana çıkmış hangi database’i kullanırsam kullanayım bu sisteme ne zaman ve ne şekilde başvuru yaptığımı bilmeden consist bir data’dan söz edemem.
Distributed sistemler’in en iyi örneklerinden olan microservice mimarilerden bahsetmesek olmaz 🙂
Microservice Mimariler için CAP Teoreminin Önemi
Microservice mimarisi özetle, bir uygulamanın birkaç service’e bölünmesi ve bu service’lerin birbirinden ayrı bir şekilde çalıştırılmasıdır.
Daha detaylı bilgi için bu makale başta olmak üzere site üzerinde yer alan farklı makaleler incelenebilir..
Microservice mimari, service’ler arasındaki etkileşimleri azaltır ve her microservice’in spesifik bir amaç üzerine odaklanmasını sağlar. Bu durum sistem’lerimizin daha flexible, scalable ve maintainable olması için önemli bir avantajdır. Fakat microservice mimarilerin en büyük problemi service’lerin çoğunlukla asenkron etkileşime girmesi sebebiyle sistemler arasında eventual consistency oluşmasıdır.
Kısaca eventual consistency kavramından bahsedelim.
Eventual consistency nedir?
Bir sistem üzerinde yapılan değişikliklerin tüm sistemlerimiz tarafından doğru bir şekilde ele alınabilmesi adına az veya çok zaman geçmesi anlamına gelmektedir. Bu sebeple distributed system’ler için data tutarlılığı önemli bir problem olarak karşımıza çıkmaktadır.
Tüm bu bilgiler ışığında Distributed Sistem’lerimiz adına Distributed Transaction‘ları nasıl yürüttüğümüz büyük önem kazanmaktadır. Distributed transaction’lar, birkaç veritabanı sisteminde veya diğer dağıtık sistemde yapılan işlemlerin tamamının başarılı veya başarısız olarak tamamlanmasını sağlar.
Detay seviyede uzmanlaşmak için aşağıdaki konulara göz atmak faydalı olacaktır.
- Two-Phase Commit (2PC)
- Saga
- Event Sourcing
- Command Query Responsibility Segregation (CQRS)
- Optimistic Concurrency Control (OCC)
- Pessimistic Concurrency Control (PCC)
Bunların her biri için ayrı ayrı makaleler hazırlamayı planlıyorum fakat şu an için kısa bir kuplenin kimseye zararı olmaz 🙂
Hoşçakalın..
Yiğit Oğuz 