3. Если что-то случилось с одним из сторадж серверов, то нету готовых утилит чтобы восстановить пропавшие данные. Есть множество разных утилит по работе с виспер-файлами, но у всех свои допущения, которые очень не всегда применимы.

4. Из-за пункта 3 следствие - чем больше стораджей тем медленее все.

Мы в Booking решили исправлять проблемы по мере их возникновения

То есть не менять весь стэк целиком, а исправлять проблемы в текущем.

Собственно первым делом мы взялись за carbon-relay

Заменили его на carbon-c-relay, который написан на Сях, достаточно производительный (1 миллион метрик в секунду на 2-х ядрах)

Может делать балансировку нагрузки зная о протоколе

Притом балансируя нагрузку он старается выбирать тот сервер, куда эта метрика уже уходила

мы также поставили его на каждый сервер, как можно ближе к источнику данных

Во первых это дало возможность сказать разработчикам "вот вам порт на локалхосте, шлите данные сюда"

и дальше это не их забота как они дойдут до хранилища

А во вторых наш локальный carbon-c-relay знает о остальных relay'ах и может делать более умный failover если что-то пошло не так

К слову о failover - если у нас случилась проблема и relay не может отправить дальше, то он их какое-то время хранит в памяти. Не бесконечное, но обычно достаточно чтобы починить проблему.

Следующая проблема

Когда пользователи приходят на фронтэнд после аварии, то они на один и тот же запрос могут получить разный ответ

Потому что сервера имеют разный набор данных

Так появился zipper stack

он умеет в параллель спрашивать много store серверов и отдавать первый полный ответ. Если полного ответа нет, то он постарается восстановить как можно больше данных, используя метрики с других store серверов.

Заодно мы заменили graphite-web на store серверах

мы реализовали маленький сабсет возможностей graphite-web (только то что нужно для кластеризации)

И сделали его более быстрым.