- Dağıtık sistem mühendisleri çoğu zaman sahada yapılan hataların açtığı yaralardan öğrenir
- Bu yazı, yeni mühendislerin aynı yaraları yaşamamasına yardımcı olmak için yazıldı
Dağıtık sistemler sık sık başarısız olur
- Dağıtık sistemlerde, diğer yazılım mühendisliği alanlarına kıyasla hata olasılığı daha yüksektir. Özellikle de kısmi hata olasılığı yüksektir.
- Dağıtık hesaplama üzerinde çalışmamış sistem mühendisleri, "iki sisteme de yazma göndersek yeter" ya da "başarılı olana kadar yazmayı yeniden deneriz" gibi fikirler öne sürer
- Ağ tabanlı sistemler tek bir makineden daha sık hata verir ve bu hatalar çoğu zaman kısmi niteliktedir
- Yazmalardan biri başarılı, diğeri başarısız olabilir; peki artık verinin tutarlı bir görünümünü nasıl elde edeceksiniz? Bu tür kısmi hatalar hakkında akıl yürütmek çok daha zordur
- Switch'in çökmesi, garbage collection nedeniyle liderin "kaybolması" ya da socket write işleminin başarılı görünmesine rağmen gerçekte başarısız olması gibi sorunlar yaşanabilir. Yerel bellekte okumak, birkaç switch üzerinden okumaktan çok daha güvenilirdir
- "Hataya göre tasarım" yapmak gerekir
Dayanıklı dağıtık sistemler yazmak daha maliyetlidir
- Dayanıklı bir dağıtık çözüm oluşturmak, tek makine çözümüne göre daha pahalıdır.
- Sanal makineler ve bulut teknolojileri dağıtık sistem mühendisliğini ucuzlatır, ama yine de ciddi maliyet gerektirir.
- Simülasyon yararlıdır, ancak gerçek dağıtık ortamlarda ortaya çıkan tüm sorunları çözemez.
Dayanıklı açık kaynak dağıtık sistemler nadirdir
- Çok sayıda makineyi uzun süre çalıştırmanın maliyeti açık kaynak toplulukları için bir yüktür.
- Hobi olarak açık kaynak kod yazan kişilerin, dağıtık sistemlerdeki pek çok sorunu araştıracak veya çözecek mali kaynağı yoktur.
- Bazı sorunları şirketlerdeki mühendisler çözer, ancak onların öncelikleri her zaman örtüşmez.
Koordinasyon çok zordur. Mümkün olduğunca kaçınılmalıdır
- Yatay ölçeklenebilirliğin özü bağımsızlıktır. Makineler arası iletişim ve uzlaşma en aza indirilmelidir.
- İki makinenin bir konuda anlaşması gerektiği her durumda, servisin uygulanması daha zor hale gelir.
- Paxos algoritmasını uygulamak çok zordur.
Sorunu belleğe sığdırabiliyorsanız, muhtemelen önemsizdir
- Dağıtık sistem mühendisleri için tek makineyle sınırlı problemler kolay kabul edilir.
- Veri birkaç switch ötede olduğunda, onu hızlı işlemek daha zordur.
"Yavaşlık" en zor problemdir
- "Yavaşlık", kullanıcı isteğini yerine getiren birkaç sistemden birinin ya da daha fazlasının yavaş olması anlamına gelebilir.
- Kısmi hatalar grafiklerde görünmez; sorun netleşene kadar çözüm için gerekli kaynakları almak zordur.
Tüm sistem boyunca backpressure uygulanmalıdır
- Backpressure, hizmet veren sistemin istekte bulunan sisteme hatayı sinyallemesi ve isteyen sistemin de bu hataları nasıl ele aldığını ifade eder.
- Backpressure mekanizması yoksa zincirleme hatalar veya istenmeyen mesaj kaybı yaşanma olasılığı yüksektir.
Kısmen kullanılabilir olmanın yolları bulunmalıdır
- Bu, sistemin bir bölümü başarısız olsa bile bazı sonuçları döndürebilmesi anlamına gelir.
- Örneğin, bir arama sistemi belirli süre içinde tüm belgeleri tarayamazsa, o ana kadar topladığı sonuçları döndürür.
Metrikler işi bitirmenin tek yoludur
- Metrikleri dışa açmak, sistemin gerçekte nasıl çalıştığını anlamanın tek yoludur.
- Log dosyaları faydalıdır, ama çoğu zaman yanıltıcıdır. Başarı logları çoğu durumda tekrar niteliğinde olduğu için kaydedilmez.
Ortalama yerine yüzdelikler kullanılmalıdır
- Yüzdelikler ortalamadan daha doğru ve kullanışlıdır. Ortalama, çoğu zaman yanlış kararlar aldırır.
Kapasite tahmini yapmayı öğrenmek gerekir
- Bir işi yapmak için kaç makine gerektiğini bilmek önemlidir.
- Örneğin, bellekte ne kadar tweet ID'si tutulabileceğini hesaplamak gibi peçete üstü hesapları sık sık yaparsınız.
Özellik bayrakları altyapıyı yayına almanın yoludur
- Özellik bayrakları, yeni özellikleri sisteme kademeli olarak yayına almanın yaygın yoludur.
- Özellik bayrakları projeye güven kazandırır ve başarısızlık maliyetini azaltır.
ID alanı akıllıca seçilmelidir
- Sistemin ID alanı, sistemin yapısını biçimlendirir.
- Örneğin, Twitter API'deki tweet ID'leri yalnızca basit 64 bit sayılardır ve başka verilerle ilişkili değildir.
Veri yerelliğinden yararlanılmalıdır
- Veri işleme ve önbelleklemenin kalıcı depolamaya yakın tutulması daha verimlidir.
- Ağlar, pointer dereference ve fread(3)'e kıyasla daha fazla hata ve gecikmeye maruz kalır.
Önbelleğe alınmış veriyi tekrar kalıcı depolamaya yazmak kötüdür
- Bu sorun birçok sistemde görülür. Özellikle dağıtık sistem deneyimi az kişilerin tasarladığı sistemlerde sık ortaya çıkar.
Bilgisayarlar düşündüğünüzden daha fazlasını yapabilir
- Daha az deneyimli uygulayıcılardan, bilgisayarların kapasitesi hakkında çok fazla yanlış bilgi gelir.
- Modern web sunucuları binlerce isteği birkaç yüz milisaniye içinde işleyebilir.
Sistemleri eleştirmek için CAP teoremi kullanılmalıdır
- CAP teoremi bir sistemi inşa etmek için kullanılacak bir araç değildir. Ancak dağıtık sistem tasarımlarını eleştirmek için yararlıdır.
Servisler ayrıştırılmalıdır
- Buradaki servis, depolama sistemlerinden daha üst seviyede mantık içeren dağıtık sistem anlamına gelir.
- Bir servisi ayrıştırmak, bir kütüphane oluşturmaktan daha hızlı ve daha kolay dağıtılabilir.
GN⁺ özeti
- Dağıtık sistem mühendisliği, yüksek hata olasılığı ve kısmi hatalar nedeniyle diğer yazılım mühendisliği alanlarından farklıdır.
- Dayanıklı dağıtık sistemler yazmak daha maliyetlidir ve açık kaynak topluluklarında nadir görülür.
- Koordinasyon, veri yerelliği, backpressure ve kısmi kullanılabilirlik gibi kavramları anlamak ve uygulamak önemlidir.
- Metrikler ve yüzdelikler, özellik bayrakları ve ID alanı seçimi gibi yöntemlerle sistemin verimliliği ve kararlılığı artırılabilir.
- CAP teoremiyle sistemleri eleştirmek ve gerektiğinde servisleri ayrıştırmak iyi bir yaklaşımdır.
1 yorum
Hacker News görüşü
CALM (Consistency as Logical Monotonicity) ilkesi, CAP'ten daha kolay anlaşılır ve daha temel bir sonuçtur
Tam olarak bir kez teslimat imkansızdır; en fazla bir kez veya en az bir kez teslimattan birini seçmeniz gerekir
Güzel bir yazı. 8 yıl önce yazılmış olsa da hâlâ geçerli birçok nokta var
Geçmiş tartışma bağlantıları:
Pratik ve gerçekçi anlatımı güzel. "Microservices" gibi moda sözcükler yok
Lookout'ta çalışırken Jeff Hodges bu denemeyi paylaşmıştı
Bu yazının yazarıyla çalışma deneyimim oldu
2013'ten beri çok şey değişti