Наткнулся на замечательную статью «Paxos Made Live — An Engineering Perspective» рассказывающую о реализации инженерами Гугл алгоритма распределеннго консенсуса Пакос в проекте Chubby (аналог Zookeeper). В статье разбираются большинсво вопросов возникающих у прикладного программиста после озкакомления с алгоритмом. Помимо прочего интересного, в разделе «Unexpected failures» упоминается об одном рабочем эпизоде, который многим из нас покажется чем-то знакомым:

В нашем первом релизе (YM: первый релиз на самописном движке имплементирующем Пакос, до это использовали стороннюю БД) мы увеличили количество рабочих тредов в десять раз относительно оригинальной Chubby. Мы надеялись, что это изменение позволит обрабатывать больше запросов. К несчастью, под нагрузкой рабочие треды вызывали голодание некоторых других ключевых тредов, что станавилось причиной частых таймаутов, это в свою очередь выливалось в быстрое падение мастера с последующей массовой мигргацией клиентов на новый мастер, а это приводило к падению ошеломленного нового мастера и так далее.

Когда, это проблема проявилась, точная причина была неизвестна и мы должны были защитить себя от потенциально опасного бага в системе. Из осторожности мы решили откатить нашу систему в одном из наших дата центров на старую верию Chubby (основанную на сторонней БД). В то время механизм отката не был нормально задокументирован (потому что мы и не планировали его использовать), его использование было неинтуитивным, у оператора осуществлявшего откат не было никокого опыта в этом деле. Как результат устаревший снапшот был случайно использован для отката. К моменту когда мы осознали ошибку, мы потеряли 15 часов данных, потребовалось перестроение нескольких ключевых датасетов.

Когда мы попытались снова проапгрейдить эту систему несколько месяцев спустя, наш апгрейд-скрипт упал, потому что мы забыли удалить файлы созданные прошлым неудачным апгрейдом. Система стартовала со снапшота устаревшего на месяцы и недолго проработала, прежде чем мы осознали проблему. Мы потеряли примерно 30 минут данных. К счастью, все клиенты Chubby восстанивили свою работоспосбнсть после этой неполадки.

В общем, если вы думаете, что в вашем проекте творится безобразие и так ПО разрабатывать и релизить нельзя и если вдруг верите, что где-то все совсем по другому — извините, кажется, в любом живом проекте одно и то же, даже в Гугле.

P.S.: Другие интересные статьи об алгоритмах косенсуса:

1. Paxos Made Simple — попытка Лесли Лампорта объяснить Пакос на «чистом английском»

2. In Search of an Understandable Consensus Algorithm — алгоритм RAFT

Комментарии (1)


  1. sshikov
    04.01.2018 10:15

    извините, кажется, в любом живом проекте одно и то же, даже в Гугле.

    Кажется вы излишне обобщаете. Скорее граница "бардака" проходит не между нами и гуглем, а между теми системами, которые зарабатывают компании деньги, и всеми остальными. У Гугля много разных систем, "даже в Гугле" — это где? На какой бизнес повлияло то, что тут описывали, сколько денег потеряли? Если в первый раз потеряли, почему меры не были приняты?


    мы потеряли 15 часов данных, потребовалось перестроение нескольких ключевых датасетов.

    Вот эта вот фраза — ни о чем. Практика показывает, что когда/если подобные потери переводятся в деньги, то бардака становится несколько меньше. Что такое 15 часов данных, если никто за это не заплатил? А похоже, что не заплатили, судя по повторному факапу.