Dağıtılmış Sistemlerde Lider Seçimi

Lider seçimi, dağıtılmış sistem içerisindeki bir şeye (süreç, ana bilgisayar, iş parçacığı, nesne veya insan) bazı özel yetenekler verme fikrinden ibarettir. Bu özel yetenekler arasında iş ataması yapma, bir veri parçacığını değiştirme veya sistemdeki tüm istekleri yönetme sorumluluğu bile bulunabilir.

Lider seçimi; verimliliği artırma, koordinasyon ihtiyacını azaltma, mimarileri basitleştirme ve işlem sayısını azaltmada kullanılabilecek güçlü bir araçtır. Diğer yandan lider seçimi, yeni hata modları ve ölçeklendirme güçlüklerini beraberinde getirebilir. Ayrıca, lider seçimi nedeniyle sistemin doğruluğunu değerlendirmeniz daha da zorlaşabilir.

Bu zorluklara bağlı olarak, lider seçimi uygulamadan önce diğer seçenekleri dikkatlice inceleriz. AWS Step Functions gibi iş akışı hizmetleri, hem veri işleme hem de iş akışları için lider seçimiyle aynı avantajları sunabilir ve lider seçiminin birçok riskinden kaçınmanızı sağlayabilir. Diğer sistemler için bir kez etkili API'ler, iyimser kilitleme ve tek bir liderin bulunmasını gereksiz kılan başka modelleri sıklıkla uygularız.

Bu makalede genel olarak lider seçiminin bazı artı ve eksi yönlerine ek olarak lider hatasına ilişkin öngörüler dahil olmak üzere dağıtılmış sistemlerimizdeki lider seçimine Amazon'un yaklaşımından bahsedeceğim.

Paxos gibi algoritmalardan Apache ZooKeeper gibi yazılımlara, özel donanımlara ve kiralamalara kadar lider seçmenin birçok yöntemi bulunur. Kiralama, Amazon'da en yaygın kullanılan lider seçme yöntemidir. Kiralama yönteminin anlaşılması ve uygulanması nispeten kolay olup yerleşik hata toleransı sunar. Kiralama yöntemi, mevcut liderin depolandığı tek bir veritabanı bulundurma şeklinde uygulanır. Ardından, liderin halen lider olduğunu belirtmesi için düzenli aralıklarla sinyal vermesi gereklidir. Mevcut lider belirli bir süre sinyal göndermezse, diğer lider adayları yönetimi devralabilir.

Amazon Elastic Compute Cloud (Amazon EC2) hizmetinin mükemmel zaman eşitleme özelliğine rağmen dağıtılmış sistemlerde zamana bağlı kalmamayı tercih ediyoruz. Dağıtılmış işlemleri sıralamak veya koordine etmek amacıyla bu eşitlemeye göre çalışması için sistem saatlerinin küme genelinde yeteri kadar eşitlenmesini sağlamak zordur. Amazon'da dağıtılmış sistemler, sadece insanların kullanımı için zamanı kullanır. Kiralamalar zamana bağlıdır. Ancak bu zaman, eşitlenmiş ve birden fazla sunucuda kabul edilen saat cinsinden zaman yerine yalnızca geçen yerel zaman süresine bağlıdır.

DynamoDB kilit istemcisi kaynak kodu, lider seçimiyle ilgili örnekler ve ayrıntılar sunmaktadır. Ancak, kiralama ve kilitlemelerin kavramsal olarak basit olmasına rağmen doğru uygulamanın zor olabileceğini belirledik. Bu konudaki uygulamalar, bir sunucunun yerel zaman süresini nasıl ölçtüğünün anlaşılmasını gerektirir. Örneğin, zamanı ölçen bir sunucu veya kitaplık zamanın bazen geri alındığını düşünürse, kiralamalarda yerleşik olarak bulunan zaman süreleriyle ilgili varsayımlar geçerli olmaz. Süreler, devamlı yüksek CPU kullanımından kaynaklanan saniye atlamalarından zaman içinde yerel saat sapmasına kadar sunucuların saatin kaç olduğunu kararlaştırmaya çalışmasını durdurmalarına neden olan küresel saat eşitlemesiyle ilgili sorunları ortadan kaldırır.

Kiralamalar ve her türlü dağıtılmış kilitlemede karşılaşılan daha büyük bir sorun ise liderin yalnızca kilide sahip olduğu sürece çalıştığından emin olmaktır. Liderin kilide sahip olduğundan emin olmak aslında oldukça zordur. Yavaş veya kaybı olan bir ağdaki liderin, kilide sahip olduğu gerçek süreden daha uzun süre kilide sahip olmadığına inanmasının önemli olduğunu belirledik. Benzer şekilde, kilit denetimi ile yapılan işler arasındaki çöp toplama duraklamaları, istenmeyen davranışlar sergilenmesine neden olabilir. Bu sorunlara karşı alınacak önlemler genellikle en büyük zorluktur.

DynamoDB ve ZooKeeper, hata toleranslı lider seçimi sağlayan basit, kiralama tabanlı kilitleme istemcileri sunar. Özel ihtiyaçlar bulunmadığında, lider seçiminde uygulanacak en kolay ve en çok test edilen yolu sağladıklarını düşündüğümüz için bu istemcileri tercih ediyoruz. Amazon ekipleri, lider seçimi için özel bir uygulama oluşturmaktan kaçınmayı tercih etmektedir. Bunun yerine, iyi test edilmiş ve dayanıklı mevcut istemcileri tercih ediyoruz.

Lider seçimi, Amazon'da yaygın olarak dağıtılan bir modeldir. Örneğin:

• Geleneksel ilişkisel veritabanı yönetim sistemlerini (RDBMS'ler) kullanan neredeyse tüm sistemler, tüm yazmaları ve bazen de tüm okumaları yöneten bir lider veritabanı seçmek için lider seçimi yöntemini kullanır. Bu sistemlerde seçim, otomatik yapılabilir ancak çoğu zaman insan bir operatör tarafından manuel olarak yapılır.
• Amazon EBS, bir birim için okuma ve yazma işlemlerini birçok depolama sunucusuna dağıtır. Tutarlılık sağlamak için okuma ve yazma işlemlerini sıralayan her birim alanına yönelik birincil unsurları belirlemek üzere lider seçimini kullanır. Belirlenen birincil unsur hata verirse, takipçi kopyalar aynı lider seçimi mekanizmasını kullanarak devreye girer. Amazon EBS'de lider seçimi, tutarlılık sağlamakla birlikte veri düzleminde koordinasyon ihtiyacını önleyerek performansı artırır. DynamoDB, Amazon Quantum Ledger Database (Amazon QLDB) ve Amazon Kinesis (Kinesis) aynı nedene dayanarak benzer yaklaşımlar kullanır.
• Kinesis Client Library (KCL), her Kinesis parçasının bir sahip tarafından işlenmesini sağlamak için kiralamalar kullanarak Kinesis akışlarının ölçeğini genişletme işlemini kolaylaştırır.

Dikkat edilmesi gereken bir diğer şey, lider hata verdiğinde yapmakta olduğu işe ne olacağıdır. Bir lider iş sırasında hata verirse, yeni lider işi nasıl tamamlar? Bir lider işini dayanıklı hale getirmeden önce hata verirse, sistem hala uygun durumda olur mu? Pek çok sistemde ayrı "işi dayanıklı hale getirme" ve "diğerlerine işin tamamlandığını söyleme" adımları vardır. Amazon olarak, sistemlerimiz daima bunlardan ilkine öncelik verir (veya veri kaybına tolerans gösterir). Yine, bir kez etkililik bu durumda faydalıdır. Bu sayede yeni lider, yerini devreden liderin yarım bırakmış veya tamamlayıp başkalarına bahsetmediği işlere güvenle devam edebilir.

Hatalara tolerans gösterebilmek için Amazon dağıtılmış sistemlerinde tek bir lider bulunmaz. Bunun yerine liderlik, sunucudan sunucuya veya işlemden işleme geçen bir özelliktir. Dağıtılmış sistemlerde, sistemde tam olarak bir lider bulunduğundan emin olmak mümkün değildir. Aksine, çoğu zaman tek bir lider olabilir ve hatalar sırasında lider olmayabilir veya iki lider bulunabilir.

Sistemin lider hatası durumundaki davranışını nasıl seçtiğimiz, sistemde iki lider varken neler olduğuna bağlıdır. Bir kez etkili işler yapan sistemler, genellikle en az verim kaybıyla iki lidere birden tolerans gösterebilir. İki liderli sistemler, daha yüksek erişilebilirlik sunabilir ve zayıf lider seçimi yaklaşımlarını kullanabilir.

En fazla bir lidere ihtiyaç duyan sistemler oluşturmak, çok liderli sistem oluşturmaktan daha zordur. Lider seçim sistemi her zaman doğru ve tutarlı olmalıdır. Ayrıca, yerini devreden liderin yeni bir lider seçilmeden önce devre dışı bırakıldığından emin olmasını sağlamalıdır. Bu işlem göründüğünden daha zordur. Dağıtılmış sistemlerde, bir sistemin hata verip vermediğini veya başka bir ağ bölümünde çalışmaya devam edip etmediğini bilmek genellikle kolay değildir. Amazon olarak, lider seçilen tüm sistemlerin bu ileri durumu yönetmesini sağlıyoruz.

Amazon olarak, lider seçimi için şu en iyi uygulamaları takip ediyoruz:

• Kalan kiralama süresini (veya genel olarak kilitleme durumunu) sıklıkla ve özellikle liderle ilgisi olmayan yan etkilere sahip herhangi bir işlem başlatmadan önce kontrol etme.
• Yavaş ağ iletişiminin, zaman aşımlarının, yeniden deneme işlemlerinin ve çöp toplama duraklamalarının kalan kiralama süresinin kodun beklediği süreden önce dolmasına neden olabileceğini göz önünde bulundurma.
• Bir arka plan iş parçacığında sinyal veren kiralamalardan kaçınma. İş parçacığı; kiralama süresi dolduğunda veya sinyal veren iş parçacığı sonlandığında kodu engelleyemezse, bu durum doğruluk sorunlarına neden olabilir. Sinyal veren iş parçacığı kiralama işlemine devam ederken iş parçacığı sonlanır veya durursa, erişilebilirlik sorunları ortaya çıkabilir.
• Bir liderin toplam iş yapma kapasitesini ve mevcut durumda ne kadar iş yaptığını gösteren güvenilir ölçümlere sahip olma. Bu ölçümleri sıklıkla gözden geçirin ve kapasite dolmadan önce ölçeklendirme için planlar hazırlandığından emin olun.
• Geçerli ve herhangi bir zamanda hangi ana bilgisayarın lider olduğunu bulmayı kolaylaştırma. Liderlik değişiklikleri için bir denetim kaydı veya günlüğü tutun.
• TLA+ gibi araçlar kullanarak dağıtılmış algoritmaların doğruluğunu modelleme ve resmi olarak doğrulama. Bu işlem; bir uygulamanın lider seçim protokolü tarafından sağlanan garantiler hakkında fazla varsayımda bulunması halinde ortaya çıkabilecek tespit edilmesi güç, gözlemlenmesi zor ve nadir karşılaşılan hataları yakalar.

Lider seçimi, sistemlerimizin hata toleranslı ve kullanımı kolay olmasına yardımcı olmak için Amazon sistemlerinde kullanılan güçlü bir araçtır. Ancak, lider seçimini kullanırken her bir lider seçim protokolünün sağladığı garantileri ve daha da önemlisi, sağlamadığı garantileri göz önünde bulundurmaya özen gösteririz.

Amazon sistemleri, yerleşik hata toleransı bulunduğundan emin olmak için sıklıkla lider seçimini kullanır. Sistemler en az bir sunucunun bir görevi yerine getirdiğinden emin olmak için lider seçimini kullandığında, aynı anda birden çok lider bulunması durumunda doğruluğu korumak için ayrı mekanizmalar kullanır. Örneğin; her iki lider de bir kiralama işlemine devam ettiğini düşünürse, birbirlerini engellemediklerinden emin olmak için temel bir veritabanı kullanabilirler. Bir kiralama uygulaması tarafından sağlanan garantiler hakkında varsayımlarda bulunmak yerine, bu sistemlerde sıklıkla TLA+ gibi tekniklerle modelleme kullanarak doğruluğa odaklanırız.

Küçük farklılıklara rağmen lider seçimi, bir kez etkili ve iyimser kilitleme gibi modellerle birlikte Amazon'daki dağıtılmış sistemler araç setimizde yararlı bir araç olmaya devam etmektedir.

Kiralamaların nasıl çalıştığı hakkında daha fazla bilgi için bkz.:

• How to do distributed locking
• Burrows, The Chubby lock service for loosely-coupled distributed systems
• Gray and Cheriton, Leases: An Efficient Fault-Tolerant Mechanism for Distributed File Cache Consistency