Рассказано на митапе hangops_ru Масштабируем Graphite --- сохраняем и строим миллионы точек в секунду

1. Graphite@Scale:
Как сохранять миллионы точек в секунду
Vladimir Smirnov
System Administrator
hangops_ru 2017

2. Зачем вообще хранить метрики?
Обычно метрики нужны когда:
Пришло время планировать закупки железа
Отладка проблем и расследование инцидентов
Бизнес-метрики и их визуализация
И многое многое другое...

3. Graphite и его архитектура
Оригинал: graphiteapp.org
Хранит time-series данные
Текствой протокол и простой HTTP API
Моудльный — меняй что хочешь

4. Типичный Graphite
LoadBalancer
graphite-web
graphite-web
carbon-cache
Store1
DC1
Servers, Apps, etc
carbon-relay
Metrics
User Requests
graphite-web
carbon-cache
Store2
graphite-web
graphite-web
carbon-cache
Store1
DC2
graphite-web
carbon-cache
Store2
carbon-aggegator

5. Ломаем Graphtie: проблемы масштабирования
LoadBalancer
graphite-web
graphite-web
carbon-cache
Store1
DC1
Servers, Apps, etc
carbon-relay
Metrics
User Requests
graphite-web
carbon-cache
Store2
graphite-web
graphite-web
carbon-cache
Store1
DC2
graphite-web
carbon-cache
Store2
carbon-aggegator
Что не так с этой схемой?
carbon-relay — SPOF
Плохо масштабируется
Синхронизация данных
после аварий?
Время ответа увеличивается
с ростом инфраструктуры

6. "Чиним"carbon-relay
LoadBalancer
graphite-web
graphite-web
carbon-cache
Store1
DC1
carbon-c-relay
carbon-c-relay
Metrics
User Requests
graphite-web
carbon-cache
Store2
graphite-web
graphite-web
carbon-cache
Store1
DC2
graphite-web
carbon-cache
Store2
carbon-c-relay
Servers, Apps, etc Server
carbon-c-relay

7. "Чиним"carbon-relay
carbon-c-relay:
Написан на C
Может 1M точек в секунду всего на 2-х ядрах
Играет роль L7 балансировщика
Может делать агрегацию
Позволяет пережить маленький падения

8. Zipper: скрываем проблемы от пользователей
Оригинал: "The essence of bugfixing" by irisuhime

9. Zipper: скрываем проблемы от пользователей
Запрос: target=sys.server.cpu.user
Результат:
t0 V V V V V t1 Node1
t0 V V V V V t1 Node2
t0 V V V V V V V t1 Zipped metric

10. Zipper: Архитектура
LoadBalancer
carbonzipper
carbonserver
go-carbon
Store1
DC1
User Requests
carbonserver
go-carbon
Store2
carbonzipper
carbonserver
go-carbon
Store1
DC2
carbonserver
go-carbon
Store2
graphite-web graphite-web

11. Zipper: Результаты
Написан на Go
Может опрашивать несколько серверов параллельно
Может "Лечить"данные
carbonzipper ⇔ carbonserver — 2700 RPS
graphite-web ⇔ carbon-cache — 80 RPS.
carbonserver теперь модуль go-carbon (с декабря 2016)

12. Распределение метрик: как это работало
Разница до 20%

13. Распределение метрик: jump hash
arxiv.org/pdf/1406.2294v1.pdf

14. Переписываем Frontend на Go: carbonapi
LoadBalancer
carbonzipper
carbonserver
go-carbon
Store1
DC1
carbon-c-relay
User Requests
carbonserver
go-carbon
Store2
graphite-web carbonapi

15. Переписываем Frontend на Go: итог
Существенно ускорились ответы пользователям (99-ый
Перцентиль 15s ⇒ 0.8s)
Стало возможно быстро выполнять сложные запросы
Проще добавлять новые мат. функции
Также можно использовать в другом коде, как package

16. Replication factor — что это такое и как его готовить
a,h c,a
b,c d,e
e,f g,b
f,d h,g
Replication Factor 2

17. Replication factor — что это такое и как его готовить
a,e c,g
b,f d,h
a,e c,g
b,f d,h
Replication Factor 1

18. Replication factor — что это такое и как его готовить
a,e c,g
b,f d,h
a,g h,e
c,f b,d
Replication Factor 1, randomized

19. Replication factor — что это такое и как его готовить

20. Replication factor — что это такое и как его готовить

21. carbonsearch — простой поиск по тэгам
Пример:
target = sum(virt.v1. ∗ .dc : dc1.status : live.role : graphiteStore.text − match : metricsReceived)
Поток тэгов и данных разделен
Не совсем честный — отсутствует история изменений
Синтаксис поддерживает только фильтрацию по "and"

22. Ищем тех кто неправильно использует систему

23. Ищем тех кто неправильно использует систему: flamegraphs
Собираем данные каждые 30 минут.

24. Что у нас есть сейчас
32 Frontend сервера
400 RPS на чтение
40k Метрик читается в секунду
3.5B точек в самом сложном периодическом запросе*
11 Gbps трафик на backend
200 серверов в 2-х DC
3M уникальных метрик в секудну (12M попадают на storage)
130 TB данных
Заменили весь стэк
* — Чтобы отфильтровать из них 9kb JSON.

25. Тестируем Clickhouse на одном сервере

26. Планы на будущее
Поиск по метаданным (в процессе)
Найти замену Whisper (в процессе)
Придумать что делать с Агрегаторами
Заменить протокол общения между компонентами
Улучшить совместимость с Graphite 1.0.0
Доделать тэги
Документация, пакеты, Docker образы

27. А еще все это — Open Source!
carbonapi — github.com/go-graphite/carbonapi
carbonzipper — github.com/go-graphite/carbonzipper
carbonsearch — github.com/kanatohodets/carbonsearch
carbon-c-relay — github.com/grobian/carbon-c-relay
go-carbon — github.com/lomik/go-carbon
carbonmem — github.com/go-graphite/carbonmem
replication factor test — github.com/Civil/graphite-rf-test

28. И еще пара ссылок на интересные проекты
Организация в которой мы собираем кластеризуемый
графит: github.com/go-graphite
buckytools — менедмент и ребалансировка графита,
написанная на Go: github.com/jjneely/buckytools
Proof of concept построения список метрик в виде flamegraph:
github.com/Civil/carbonserver-flamegraphs
Офигенный адаптер Clickhouse->Graphite от Романа
Ломоносова: github.com/lomik/graphite-clickhouse
Офигенный адаптер Graphite->Clickhouse от Романа
Ломоносова: github.com/lomik/carbon-clickhouse
Официальный адаптер Clickhouse<->Graphite:
github.com/yandex/graphouse

29. What’s next?
Спасибо за внимание!
А еще мы нанимаем в Амстердам!
Site Reliability Engineer
Site Reliability Engineer - Team Lead
Контакты: vladimir.smirnov@booking.com