Reliability Üzerine

Selamlar. Bir önceki yazımda Veri Sistemleri Üzerine bir ufak girizgahta bulunmuştum. Sonuçta data-intensive bir uygulama geliştiriyor isek, bunlar hakkında da konuşabilmeliyiz. Bu yazıda ise reliability kavramı üzerine konuşacağız.

Reliability ya da bir şeyin reliable olması demek güvenilir olması demektir. Negatif durumlarda ise unreliable olduğunu söyleriz.

Yazılım süreçlerinde ise reliable olma konusunu konuşurken şunları düşünebiliriz.

Uygulama, kullanıcının beklediği şekilde fonksiyonu çalıştırır
Kullanıcı kaynaklı hataları ya da kullanıcının bir yazılımı beklentilerin üzerinde bir şekilde kullanmasını tolere eder
Performansı söz konusu ise hem yük hem de veri yoğunluğu noktasında yeterli düzeydedir
Sistem, herhangi bir yetkisiz erişimi ve kötüye kullanımı engeller.

Eğer tüm bu bahsedilenler bir araya geldiğinde iyi bir şekilde ya da doğru şekilde çalışmak anlamına geliyorsa, reliability kavramını şöyle düşünebiliriz

bazı şeyler yanlış gittiğinde bile doğru şekilde çalışmaya devam etmek

Yanlış gitmesi mümkün olan şeylere faults deriz yani hatalardır. Bu hataları tahmin edebilen sistemlere ise fault-tolerent ya da resilient sistemler deriz.

Kavramlara Bir Göz Atalım

faults: Hatalar

fault tolerent: Hata tolere edebilirlik

resilient: Esnek ya da dayanıklılık

Kısacası bir şeyler yanlış gidebilir bu mümkün, bu durumda faults olarak değerlendiririz. Bu hataların oluşmasını tolere edebilecek bir sistemden de bahsettiğimizde ya fault-toleren ya da resilient sistemlerden bahsetmiş oluyoruz.

Aslında fault-tolerent kavramını belki yanlış anlayabileceğimizi öğretiyor bu kitap.

Düşünün bir kara delik dünyamızın yanında belirdiği anda dünyayı da yok yutacaktır. Bu noktada var olan bütün sunucularımız da bununla birlikte yok olacaktır. Bu durumda 2 senaryo var.

Senaryo 1

Mister Spak ve Turist Ömer verilerimizi kompüter’e taşıyabilir.

Senaryo 2

Bir başka gezegende de host edilebilir ortamlar oluşturmak

İlk senaryo kurgu olsa da ikinci senaryo da şu an için pek mümkün değil gibi. Çünkü sisteminizin fault tolerent olabilmesi için milyarlarca doları gözden çıkarmanız gerekebilir.

Yani fault tolerent sistem olmak, her durumu temsil etmez. Ancak belirli durumlarda fault tolerent olmaktır.

Fault vs Failure

Bir sistem hakkında konuşurken fault yani hata ya da failure gibi durumlardan bahsedebiliriz. İkisi aynı anda söylenebilir ancak aynı şeyler değildir.

Fault dediğimiz durumda sistem çalışıyordur ancak bir şeyler yanlış gidiyordur. Failure durumda ise gerçekten bir sorun vardır ve hizmet verilemezlik ortaya çıkmıştır. Faults dediğimiz durumların failure ortaya çıkarabileceğini de bilmemiz gerekiyor.

Sıfır Hata, Sıfır Arıza mı Demek Hocam?

Gerçekçi olmak gerekirse hataların tamamen yok edilmesi en azından günümüzde pek mümkün görünmüyor sevgili okur 😛

Bu nedenle fault tolerent sistemler tasarlarken de, hataların arıza oluşturan yani failure oluşturan durumlara yol açmasının önüne geçecek fault tolerent sistemler tasarlamamız gereklidir

Kitapta bu noktadan sonra hata türleri önümüze geliyor. Bunlar ise şunlar

Hardware Faults
Software Errors
Human Errors

Bunlara da birazcık değinmek gerekebilir.

Hardware Faults Bize Neyi Anlatır?

Genellikle bir sistemsel hata ile karşılaşınca, donanımsal hataları düşünmeye başlarız.

Örnek vermek gerekirse bir anda hard-disk’ler çökebilir, RAM kaynaklı hatalar ortaya çıkabilir, dünyanın en mükemmel en sorunsuz elektrikli ülkesi olan Türkiye’de elektrik bir anda kesintiye uğrayabilir, ya da kediniz ağ kablosunu kemirebilir ya da daha fena şeyler yapabilir. Takılmayın kedidir kedi

Bir firmada çalışan bir arkadaşım bu tarz şeyleri veri merkezlerinde sürekli olabildiğini söylüyordu. Bu gerçekten Enuygun’dan önceki firmamda iş ortaklığı yürüttüğümüz bir firmada sistem admin ve daha fazlası olarak çalışan bir arkadaşla olan sohbette duyduklarımdı.

Peki ne yapılabilir?

İlk olarak, bir HDD’nin bozulacağı senaryo için, bir başka yedek satın alarak onu bekletmek olabilir. Diskler belki RAID olarak yarlanabilirler. Sunucularda belki çiftli güç kaynakları olabilir. (Donanımdan anlamadığım belli mi lan?) Ya da jeneratorler yedek güç olarak bu noktada yer alabilir.

Günün sonunda bir HDD mi bozuldu? Diğeri devreye girebilir, sallıyorum bir güç kaynağı mı bozuldu? Diğeri devreye girer. Elektrik mi gitti? Bu noktada artık jeneratorler devreye girer.

Siz bu sayede bir donanımın bozulmasını engellemiş olmuyorsunuz, sistemin yıllarca sorunsuz şekilde çalışmış oluyorsunuz.

Maliyetler?

Normalde bu tarz bir yaklaşım sorun yaratmazken, yüksek işlem gücü gerektiren uygulamalar ve veri saklama alanları nedeniyle donanım gereksinimleri de arttı. E bu durumda her donanımı çiftlemek de birazcık güç olabilir. Bunun yerine AWS gibi Azure gibi ya ad Google Cloud gibi sistemler sanal makineler oluşturarak size esnek ve elastik yapıları tek bir reliable makine üzerinde çalışma fırsatı sunuyor.

Software Errors Bize Neyi Anlatır?

Genellikle donanım kaynaklı hataların birbirinden bağımsız ya da bir anda ortaya çıktığını varsayarız. Bir makinenin diski ya da RAM’i arızalanıyor ise, bu başka bir makinede de böyle bir sorunun olacağını göstermez. Çünkü bu sıcaklıktan, voltajdan vs. birçok şeyden de ortaya çıkabilir.

Ayrıca bir başka hata türü de mesela, tasarlanan sistemde oluşan sistemsel hata türüdür. Bu tarz hataları tahmin etmek çok zordur. Bunun için testler yapıyor olmanız size tünelin sonundaki ışığı göstermeyecektir.

Örnek 1:

Belirli kötü bir girdi verildiğinde bir uygulama sunucusunun her bir örneğini çökerten bir yazılım hatası. Örneğin, 30 Haziran 2012'deki artık saniye (leap second) olayı, Linux çekirdeğindeki bir hatadan dolayı birçok uygulamanın aynı anda askıda kalmasına neden oldu.

Kaynak: https://www.wired.com/2012/07/leap-second-glitch-explained/

Örnek 2:

Örneğin CPU’yu, belleği, disk alanı vs. gibi paylaşılan kaynakları tüketen kontrolsüz bir süreç.

Örnek 3:

Bir sistem düşünün ana thread’i bloklasın. Bu nedenle yanıt verilebilir olması da sıkıntıya giriyor.

Örnek 4:

Kelebek etkisi. Bir hatanın bir başka hatayı, o hatanın da başka bir hatayı tetiklemesi nedeniyle ortaya çıkan kaotik hatalar da ortaya çıkabilir.

Maalesef bu türden hatalar ortaya çıkana dek kendisini göstermeyen sinsi düşmanlardır. Maalesef bu tarz hataların hemen uygulanacak hızlı çözümleri de yoktur :( Ama şöyle örnekler sunulabilir

Kapsamlı testler yapmak
Process’leri izole etmek
Process’lerin crash olmasına ve restart edilmesine izin vermek
Monitoring

Vs. vs. vs. bildiğiniz türden şeyler

Human Errors Bize Neyi Anlatır?

Günün sonunda bugün ortaya çıkan tüm ürünler, insan elinin değdiği sistemlerdir. Yapay zeka projelerinden tutun da yazdığımız CRUD uygulamalara kadar. Ayrıca bu sistemlerin çalışmasında görevli kişiler de yine insanlardır.

Kedi gibi bir insan da olsa sonuçta insanlar yani hata yapabilirler 😛 Localde çalışıyordu demeleriyle ünlüdürler.

Ünlü GitLab veri silme hikayesini biliyorsunuzdur belki. 300 GB data bir anda uçuruldu.

Kaynak: https://about.gitlab.com/blog/2017/02/10/postmortem-of-database-outage-of-january-31/

Hiç kuşku yok ki bu hatayı yapan kişi kötü bir niyetle yapmasa da insanlara ve yaptıkları işlere güvenme noktasında agnostik olmamız gerektiğini kabul etmeliyiz.

Nasıl Güvenilir Sistemler İnşa Ederiz?

Peki insanlar güvenilir değil yani unreliable ise, sistemlerimizi nasıl güvenilir yapacağız?

Hata oluşma ihtimallerinin en aza indirileceği sistemler tasarlayabiliriz. Mesela, iyi şekilde tasarlanan abstraction’lar, API’lar vs… Bunlar bir şeyleri doğru yapmaya sizi zorlarken, yanlış yapma noktasında da önünüze engeller çıkarır. Örneğin çok kritik bir şeyi silecekseniz, bunu bir UI ile yapacaksanız üzerinde düşünmeniz gereken bazı UI/UX durumları olabilir.
Sandbox ortamlar kullanarak, hataların yapılabileceği noktaları gerçek ortamlardan ayırabiliriz. Bu sayede gerçek kullanıcı datasına herhangi bir müdahalemiz de olmamış olur. GitLab örneği çok iyi açıklıyor bunu.
Çok yorucu olsa da manuel testler, integration testler ve unit testleri tüm noktalarıyla yapmaya çalışabiliriz. Burada belki automated testler de nadir de olsa ortaya çıkabilecek durumlar için önden size bu durumu bildirebilirler. (Çalıştığım firmada, kendi projemde bir test ile hiç karşılaşmadığımız bir hatayı cover edebildik)
Bu türden hatalar olabilir ancak bunların hızlı şekilde kontrol altına alınabileceği etkisi daha ufak geliştirmelere izin vermemiz gerekebilir. Örneğin bir noktada config sorunumuz var ise hemen roll-back yapabilmeliyiz.
Detaylı bir monitoring işimize yarayabilir. Mesela performans ölçümleri, hata oranları vs. gibi. Buna diğer mühendislik disiplinlerinde telemetry de denilebilir.

Peki Reliability Ne Kadar Önemlidir?

Reliable olma, bir nükleer tesis yazılımında ya da uzay araçları yaızlımlarında fark etmeksizin önemlidir. Bunun yanında bir e ticaret platformunun yazılımlarında da önemlidir. Yani reliable yani güvenilir olma durumu her koşulda önem arz eder.

X bir firmada sıklıkla ortaya çıkan buglar nedeniyle hem finansal kayıplar olabilir hem de prestij kaybı ortaya çıkabilir. Yani bu güvenilir olmama durumunun ortaya çıkaracağı etkilerdir.

Bazen ise reliable olma durumunun o kadar da olmadığı şartlara sahip olabiliriz. Mesela bir prototip ürün geliştirirken reliable olması çok önemli değildir. Prototipin işi bu değildir. Eğer bunun üzerine çok düşünülür ise geliştirme maliyetleri bir hayli artacaktır.

Bu konu bu kadardı. Umarım kafanızda data-system ya da veri sistemi üzerine birazcık da olsa bir şeyler oluşturabilmişimdir. Buradaki içerikler kitaptan geliyor.

Okuduğunuz için teşekkür ederim.

Kaynaklar

https://dataintensive.net/