Cloudflare, Meerkat'ın neden alışılmadık QuePaxa consensus algoritmasını kullandığını açıkladı

Cloudflare ne inşa ediyor

Cloudflare, iç küresel kontrol düzlemini yönetmek üzere geliştirilen deneysel bir dağıtık consensus servisi olan Meerkat'ı duyurdu. Cloudflare bloguna göre Meerkat, QuePaxa üzerinde çalışıyor — bu alışılmadık bir tercih, çünkü üretimdeki consensus sistemlerinin çoğu Raft, Multi-Paxos veya Viewstamped Replication gibi iyi yerleşmiş algoritmalara dayanıyor.

Meerkat'ın kendisi bir replike log: replikalar olayların sıralı bir dizisi üzerinde anlaşıyor, her biri consensus algoritması tarafından karara bağlanıyor ve bu da makinelerin asla çelişkili değerlerde karar kılmamasını, dolayısıyla replikaların loglarının hiçbir zaman ayrışmamasını garanti ediyor. Bu logun üzerinde Meerkat, her girdisinin bir get ya da put olduğu bir key-value store sunuyor; bu da onu Consul, etcd ve Apache ZooKeeper ile aynı aileye yerleştiriyor. Fark, Cloudflare'e göre ölçekte: bir Meerkat kümesi kıtalara yayılabilir ve yüksek, öngörülemeyen gecikmeli bağlantılarla birbirine bağlanabilir; oysa consensus sistemleri tipik olarak katı gecikme gereksinimleri olan daha küçük, yerel ağlarda konuşlandırılır.

Standart consensus neden internette zorlanıyor

Cloudflare, yaygın consensus algoritmalarının ağ koşulları kötüleştiğinde orantısız biçimde performans düştüğünü, hiçbir makine gerçekten çökmediğinde bile öne sürüyor. Şirket bunu 2010'da değil 2020'de bizzat yaşadı: bir çekirdek ağ anahtarındaki kısmi arıza, consensusle çalışan bir sistemin bozulmasına neden oldu; Cloudflare dashboard altı saat boyunca normalden 80 kat yavaş çalıştı. Veri kaybı olmadı ama sorun çözülene kadar sistem yazma işlemlerini kabul edemedi.

Blog, bu davranışa neden olan iki özelliğe işaret ediyor ve bunlara yıkıcı girişim (destructive interference) ile arıza tespiti (fault detection) adını veriyor.

Yıkıcı girişimi görmek en kolay Paxos'ta, çoğu sonraki tasarımın miras aldığı algoritmada. Paxos'ta proposer'lar bir Prepare aşamasında acceptor çoğunluğuna ballot numaraları gönderir, ardından bir Accept aşamasında öneri sunar. İki ya da daha fazla proposer aynı anda harekete geçtiğinde, biri diğerinin iki aşaması arasına daha yüksek bir ballot numarası sokup onu engelleyebilir ve rakipler birbirini tekrar tekrar durdurabilir. Eşzamanlı proposer sayısı arttıkça sistemin önerme aşamasında takılma olasılığı büyür — her replika sağlıklı olsa bile. Cloudflare'nin resmi olarak belirttiği gibi Paxos, kısmi senkronluk varsayımı olmadan liveness garantisi vermez; yani mesajlar sonunda sınırlı bir süre içinde ulaşacaktır.

Konuşlandırılan algoritmaların çoğu — Raft, Multi-Paxos ve Viewstamped Replication bunlar arasındadır — bundan, öneride bulunmaya tek yetkili replika olan tek bir lider seçerek kaçınır. Bu, isteklere bir sıra dayatır ve kararların iki yerine tek ağ gidiş-dönüşünde tamamlanmasını sağlar. Lider sağlıklıyken ve ağ düzgün çalışırken lider tabanlı protokoller hızlıdır.

Lider zayıf nokta

Buna karşılık gelen bedel, liderin çalışır ve erişilebilir kalması zorunluluğu. Lider çöker, yavaşlar ya da kümeden koparsa, sistem bütün olarak, kalan replikalar arızayı tespit edip yerine yenisini seçene kadar durur. Ve Cloudflare'nin belirttiği gibi, lider kurtarma, yıkıcı girişimin tam da sızmaya başladığı yerdir.

Raft'ta liderin çöktüğünden şüphelenen bir replika kendisini candidate olarak ilan eder ve diğerlerinden oy ister. Birden fazla replika aynı anda arızadan şüphelenirse çoğunluk için yarışırlar ve birbirlerini engelleyebilirler — bu, yarışan Paxos proposer'larıyla aynı girişim örüntüsüdür. Her başarısız seçim daha fazla candidate davet eder, böylece kesinti orijinal arıza kaybolduktan sonra bile sürebilir. Cloudflare bunu bir metastabil arıza olarak tanımlıyor: ilk neden ortadan kalktıktan sonra kendini sürekli yeniden üreten bir arıza örüntüsü. İki saniyelik bir ağ kesintisi ya da kısa süreli arızalı bir anahtar, sağlıklı bir lideri ölmüş gösterebilir, başarısız bir seçim tetikleyebilir ve kesintinin kendisinden çok daha uzun süren yeni seçimler başlatabilir.

QuePaxa nasıl uyar

Meerkat'ın yanıtı QuePaxa; Cloudflare, ilerlemek için bir lidere bağlı olmaması sayesinde dalgalanma altında daha iyi kararlılık vaat ettiğini ve yıkıcı girişim ile arıza tespiti sorunlarının ikisini de aştığını söylüyor. Bu özellikle Meerkat'ın konuşlandırma ortamı için önemli: küresel ölçekte arızalar Cloudflare'nin kendi sunucularından çok ağda başlama eğilimindedir, dolayısıyla algoritmanın yalnızca replika çökmelerine değil, gecikme sıçramalarına ve kopan bağlantılara da dayanması gerekir.

Neden önemli

Consensus, sektör genelinde koordinasyon altyapısının temelini oluşturur — etcd, Kubernetes kümelerinin arkasındadır ve ZooKeeper sayısız dağıtık sistemi koordine eder. Cloudflare'nin savı şu: üretimde baskın olan lider tabanlı algoritmalar veri merkezi ölçeğindeki ağlar için biçimlendirildi ve gecikmenin yüksek, bağlantıların sürekli kestiği geniş alan internetinde kötü davranıyor. 2020 olayı maliyeti gözler önüne seriyor: veri kaybı değil, tek bir anahtar arızasının tetiklediği saatlerce süren yazma erişilemezliği. QuePaxa, Meerkat içinde küresel ölçekte tutarlı olursa, kıtalar arasında consensus sağlaması gereken her sisteme bir şablon sunar — ve daha yeni, sınanmamış algoritmaların üretimde Raft ve Paxos'un yerini alıp alamayacağının gerçek dünya bir sınavı olur. Cloudflare Meerkat'ı hâlâ deneysel olarak nitelediğine göre kanıtlar ancak çalıştıkça birikecek.