Distribuirani sustavi: kada konsenzus postaje usko grlo

Zašto konsenzusni algoritmi usporavaju Vaš sustav

Raft algoritam postao je de facto standard za implementaciju distribuiranog konsenzusa nakon što je njegova razumljivost u odnosu na Paxos privukla široku zajednicu implementatora. etcd, Consul i CockroachDB samo su neki od sustava koji ga koriste u produkciji. Problem nije u ispravnosti algoritma — Raft funkcionira upravo onako kako je opisan. Problem nastaje kada arhitekti sustava pretpostavljaju da je konsenzus jeftin jer je brz na malom clusteru u testnom okruženju. U produkcijskom okruženju s geografski distribuiranim čvorovima, svaki write koji zahtijeva konsenzus mora proći kroz round-trip komunikaciju između leadera i kvorum čvorova. Uz prosječnu RTT latenciju od 50–100ms između datacentara u različitim regijama, sustav koji izvodi 1.000 konsenzusnih operacija u sekundi zapravo troši 50–100 sekundi mrežnog čekanja po sekundi — što znači da svaki čvor radi na djeliću svog kapaciteta. Rješenje nije zamijeniti Raft, već promijeniti kako se sustav oslanja na njega: odvajanje read i write putova, korištenje follower reads gdje konzistencija nije kritična, batching write operacija i, u pojedinim slučajevima, razmatranje eventual consistency modela za dijelove podatkovnog modela koji to toleriraju. Svaka od ovih odluka donosi vlastite kompromise koje je potrebno eksplicitno dokumentirati i komunicirati cijelom timu koji radi na sustavu.