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

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

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

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

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

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

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

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

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

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

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

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

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

Так как запросы и нужды росли, нам перестало хватать 80 RPS/store

(примерно столько было когда мы проивзели замену)

а с новой схемой, carbonserver <-> carbonzipper может обслуживать несколько тысяч запросов в секунду - то есть больше эта связка не узкое место

все это написано на Го

Распределение метрик

(картинка с одного из последних кластеров со старым хэшом)

Когда store серверов становится много, встает вопрос о том как этим управлять