Büyüyen ve gelişen teknoloji dünyasında, kompleks problemlere çözüm sağlarken çoğu zaman büyük yanılgılar içerisinde olabiliyoruz. “Yaaa onun olması zor, milyonda 1 ihtimal” diye atladığımız bazı yazılım kavramlarının saniyede 3 milyardan fazla iş yapabilen işlemcilerde çalıştığını unutuyoruz. Problem olana kadar bu yanılgıların çok farkında olamıyoruz genellikle. Özellike birden fazla parçadan oluşan dağıtık sistemlerde bu yanılgılar daha fazla oluyor. 90’larda Peter Deutcsh‘ın ortaya çıkardığı “The Eight Fallacies of Distributed Computing”, günümüzde hala çoğumuzun yanılgıya düştüğü konular olarak karşımıza çıkıyor.

Her ne kadar dağıtık sistemler için söylemiş olsa bile, günümüzdeki çoğu yazılım çözümleri için dikkat edilebilecek başlıklar olduklarını düşünüyorum. Açıkcası sadece bu yanılgılardan bahsetmek istemiyorum, bu yanılgılara düşmemek için çözümlerimize farklı nasıl bakabilir ile de kafanızı biraz karıştıracağım. 🙂

1- Network güvenilir…

(The network is reliable)

İş yerlerinde, yerel ağ içinde olduğumuz ve genellikle sahip olduğu kapasite zorlanmadığı için network’lerin sağlam olduğu, problem yaşanmayacağını düşünürüz. Donanım olarak artık switch’ler ve router’lar farklı özellikler ile bu problemleri çok hissettirmese de, her zaman sağlam bir network üzerinde çalışacağız diye kesin bir yargı yok. En basitinden, bilinçsizce sökülen güç kabloları yaşanan şeyler…Network üzerinde farklı sistemlerin bir araya gelmesi ile oluşan çözümlerde özellikle, network problemleri ciddi sorunlara yol açabilir. Dolayısıyla network güvenilir değil…

Bu yanılgıya düşmemek için yazılımlarımızda çeşitli iyileştirmeleri başta geliştirebiliriz. Mesela kaçımız web servis request’lerinde HttpTimeoutException‘ı dikkate alıp, bir retry mekanizması oluşturuyor. Ya da ACK/NACK(acknowledge messages) yapısı kurup, request’lerin sağlıklı gittiğini doğruluyor… Network’ün güvenilir olduğu yanılgısı içerisinde olursak, en basitinden bir e-ticaret sitesinden bir bankaya yapılan request’de oluşan timeout’ları atlayabiliriz. “Yapılan işlemler başarılı mı yapıldı, ya yapılmadıysa…Bir daha request yapalım o zaman…Ama ya başarılı olduysa, çift işlem olmasın…”

2- Network’deki geçikme sıfır…

(Latency is zero)

“Latency” olarak adlandırılan bir kavram vardır; bir verinin bir noktadan, bir diğer noktaya taşınmasında geçen süreye denir. Ve ne yazık ki bu süreyi sıfıra yakın varsayarız genelde… Genelde lokal network’lerde(LAN) çalıştığımızdan böyle bir yanılgıya sahip oluyoruz. Geliştirdiğimiz uygulamalar internet üzerinde çalışacak ya da geniş bir kapalı network’lerde çalışacaksa, mutlaka ama mutlaka performans testi yapmalıyız. İstanbul’da LAN’da sorunsuz çalışırken, internete açtığınız uygulamaya 1 milyar nüfuslu Çin’den erişmek istediklerinde network’deki git-gel’lerden dolayı kesin problem yaşarsınız… Ben şimdiden söyliyim…

Mesela bir örnek olması için; genelde uygulama ve veri tabanı arasındaki iletişim bu açıdan problem yaratır. O/R Mapping araçları ile lazy-loading kavramı hayatımıza girince, uygulama-veri tabanı arası git gellerin artması network’de geçikme problemlerine sebep olabilir. DTO’ların varlık sebeplerinden bir tanesi de bu problem zaten… Bundan dolayı sadece ihtiyacımız olduğu zaman network’e çıkmalıyız, çıkmamız gerektiği durumlarda da kullanacağımız verinin hepsini almalıyız.

Bulut bilişim kavramı son bir kaç yılın, hatta gelecek bir kaç yılın da en önemli yazılım kavramlarından bir tanesi. Tanışma fırsatı elde etmediyseniz, çok yakında yollarınız kesişecektir zaten. Ama biraz öncesine gidip, “cloud-computing“(bulut bilişim)’in de bir parçası hatta belki temeli olarak yorumlanabilecek “distributed system“den (dağıtık sistemler) bahsetmek istiyorum. Cloud, biraz daha pazarlama üzerine ortaya çıkan bir kavram olduğu için, temelinde yatan “dağıtık sistemler” kavramlarının bazen atlandığını düşünüyorum. Bundan dolayı, eski konulara gidip biraz daha temellerden bahsetmek ihtiyacını hissettim…

Dağıtık sistem…

Ortak bir amaç için, çeşitli iletişim protokolleri ile birbirleri ile iletişim halinde olan birden fazla yazılım sisteminin oluşturduğu sistemlere dağıtık sistemler diyoruz. Basit olması ve daha kolay anlaşılması adına, multi-player bilgisayar oyunlarını örnek verebilirim. Tek bir bilgisayarda bir oyunu, aynı anda 100 kişi oynamaya çalıştığınızı düşünün…Yemez, ayy pardon olmaz… 🙂 Bunun  için ne yeriniz, ne işlem gücünüz ne de zamanınız yeterli olacaktır. Ama bir çok bilgisayar ile, farklı lokasyonlardan yüzlerce kişi ile, büyük bir işlem gücü ile oyunun en zor bölümünü daha rahat bir şekilde geçebilirsiniz.

Bir dağıtık sistem anatomisi…

Dağıtık sistemler ile, pratikte tek bir işlem gücüyle yapılabilecek işleri daha büyük ölçekte yapabilmek amaçlanır. Geliştirilen yazılım sistemlerinin belli bir süreden sonra çeşitli problemlere çözüm sağlayamaması, bu yazılım sistemlerini değiştirmeyi ya da genişletmeyi gerektirir. En basitinden CPU, RAM ve disk boyutu arttırma gibi fiziksel değişiklikleri düşünebiliriz. Hem ekonomik, hem de teknolojik bazı kısıtlamalardan dolayı ne yazık ki bir bilgisayara sınırsız CPU ya da hafıza eklemeniz mümkün değil. Teknolojik kısıtlarına gelene kadar, ekonomik olarak zaten herkes zorlanacaktır.

Zamanla birden fazla kullanıcı ile de problemlere çözüm sağlama ihtiyacımızdan dolayı, belli bir ağ içerisinde birbiri ile iletişim halinde olan bilgisayarları devreye almaya başlarız. İşte bu noktada artık merkezi sistemimizi dağıtmaya başlamış oluyoruz. Yeni problemlere de merhaba diyoruz tabi ki. Bu problemlere sonradan geleceğim…Şimdilik devam edelim.

Birbiri ile iletişimde olan farklı bilgisayarların iletişimlerini sağlıklı yapabilmesi için, belli protokoller radarımıza girer. Sistemimizi buna göre geliştiririz. Bazen bu protokoller yeterli olmaz ya da farklı ihtiyaçlar ortaya çıkar, dolayısıyla farklı yeni protokoller ile de iletişim sağlayacak ara katmanlar yapmamız gerekir. Fazla bileşen ve farklı sistemler olunca güvenlik konuları da ortaya çıkar. Hem iletişimin, hem de yapılan işlemlerin güvenilir olmasını sağlamak birden öncelikli olur.

Bir bakmışız, sistemle büyüyen ve gelişen iş ihtiyaçları artık farklı coğrafyalarda da sistemin 7/24 çalışmasını gerektirir. Farklı coğrafyalarda, aynı verinin güvenli bir şekilde iletilmesi ve işlenmesi gibi bir durum ortaya çıkar. Bütün bunları yaparken de, bu ayrı sistemlerin hata durumlarını yönetebileceğimiz bir senaryomuz ve hatta belli ölçekte yedek ikinci sistem ihtiyaçlarımız ortaya çıkar…

Basit olarak neden dağıtık sistemlere ihtiyaçımız olduğu ortaya çıktı aslında. Biraz daha canlanması adına havayolu yönetim sistemleri, multi-player bilgisayar oyunları, tedarik zinciri sistemleri ve ödeme sistemleri günümüzde hepimizin karşısına çıkan dağıtık sistem örnekleri olarak düşünülebilir. Hatta son zamanlarda oldukça popüler olan yazılım mimari stili olan Microservices yaklaşımı da, bu dağıtık sistem modellerinden biridir. Neyse…Şimdi tekrar oraya girmeyelim.

Karakteristik özellikleri…

Dağıtık sistemler ortaya çıktıkça belli özellikleri sağlamak ile yükümlü olurlar. Bu karakteristik özellikleri sağlıyor olmak, dağıtık sistemlerin en büyük ve en zor problemidir.  Önce bu özelliklere bir bakalım, sonra gerçekten sağlamak mümkün mü bakarız…

• Yüksek Erişebilirlik: Dağıtık sistemlerin, erişebilirliğinin olabildiğince yüksek olması beklenir. Başarısız bir işlem olsa bile, işlemi tetikleyen kaynağın mutlaka sisteme bir şekilde erişimi olması beklenir.
• Güvenlik: Dağıtık sistemlerde, işlemlere ve veriye erişim yetkilendirilir.
• Performans: Dağıtık sistemlerin, kendi performanslarının farkında olması beklenir. Belli sistem yoğunluklarında alacağı aksiyonların belirli olması sistem tasarımında önemlidir.
• Açıklık: Dağıtık sistemler genişletilmeye açık olmalıdır. Sisteme kolaylıkla alt sistem bileşenleri eklenebilmelidir.
• Ölçeklenebilirlik: Dağıtık sistemler kaynak kullanımı konusunda kolayca ölçeklenebilmelidir. Kaynak kullanımına göre sistemin verimli çalışmaya devam etmesi bir şekilde sağlanmalıdır.
• Tutarlılık: Sistemin tutarlı olması beklenir. Aynı anda, aynı veri kaynağına erişen sistemlerin uyumlu ve tutarlı çalışması gerekmektedir.

Bu özelliklere sahip olmak ve bunları belli bir kalite düzeyinde sağlamak oldukça zor. Hatta hepsinin birden sağlanamayacağına dair teoriler olsa da sonradan farklı yaklaşımlarda olmuştur. Eric Brewer’ın CAP teorisi ve sonrasındaki yaklaşımına göz atmanızı tavsiye ederim. (CAP Twelve Years Later: How the “Rules” Have Changed)

Dağıtık sistemlerin bu karakteristik özelliklerinden dolayı, çeşitli programlama yaklaşımları, prensipler ve kalıplar bu sistem tasarımlarında kullanılmaktadır. SOA prensipleri, mesajlaşma kalıpları, kuyruklama alt yapıları, senkron ve asenkron programlama modelleri dağıtık sistem programlama yaklaşımlarında temel olarak tercih edilen bir kaç kavramın başında gelir.  Tabi sistemin amacına göre başka farklı kavramlar da gündeminize girecektir. “Service Bus”lar, “Message Broker”lar falan filan…

Dağıtık sistem tasarlarken ya da bir şekilde içinde bir geliştirme yaparken, yukarıda bahsetmiş olduğum özellikleri sağlamanın da vermiş olduğu bir kaç yanılgıya düşeriz. Peter Deutsch, zamanında bunları çok güzel tanımlamış ve “The 8 fallacies of distributed systems” diye yazmış. Bir sonraki yazılarda bu yanılgıların ne olduğunu ve bu yanılgılardan nasıl kurtulabiliriz bunları anlatmaya çalışacağım…Şimdilik bu kadar. Fazla dağıtmayın… 🙂