Николай Сивко, okmeter.io
Table of Contents generated with DocToc
- Metric store v1: chunked
- Metric store v1.1: bunched
- Metric store v2: идея!
- Long-term storage
- Kafka в production
- Рекомендации
- Результат
- Итоги
Цель okmeter: найти проблему. Для этого нужен контент — метрики. Их собирает агент, отправляет в платформу и считает метрики.
- копим данные за 4 часа
- интервал знаем, поэтому не храним timestamp
- сериализуем и жмём lz4
- пишем в cassandra
- при каждой точке перезаписываем весь chunk
- чтобы не читать при записи, версионируем чанки
- при чтении объединяем все версии
Результаты:
- примерно десятикратное сжатие объема
- в несколько раз ускорилось чтение
- увеличилась нагрузка на Cassandra
- в результате нагрузка на диск в форме пилы.
Bunch — набор метрик, который пишется и читается одновременно. Пишем в один BLOB.
- Ещё вдвое сжали
- В несколько раз ускорилось чтение
- Иногда читаем лишнее
Научиться хранить «хвост» данных в памяти надёжно.
- Уметь восстановить откуда-то за разумное время
- несколько консистентных реплик
Сможем хвост читать из этой памяти, а более давние данные — уже из Casssandra.
В результате начали изобретать велосипед. В любой БД есть WAL — write ahead log. Копим данные, а потом асинхронно пишем их, потому что сразу писать — дорого. Есть offset — какие данные мы уже записали.
Концепция такая:
- Пишем в primary
- Он реплицируется в реплики
- Читать можем только из реплик
В качестве WAL будем использовать kafka. Это просто надёжный лог. Producer в него пишет, а Consumer читает.
Преимущества kafka:
- репликация из коробки
- шардинг из коробки
Как работает Consumer:
- на низком уровне: ConsumePartition(...), GetOffset(...), и другие методы
- на высоком уровне: Consumer groups.
В okmeter использовали низкоуровневый интерфейс.
Если большой лаг или запрашивают диапазон больше чем у нас есть — ошибка.
In-memory storage: реузльтаты
- быстрое чтение
- легко масштабируется
- простой код (ничего не знаем про репликацию, всё из коробки)
Проблема: на полный потк метрик нужно 1,5 ядра на каждом инстансе
- сидит на потоке и формирует 4х-часовые чанки
- знает, откуда нужно начинать читать
- готовые чанки складывает в отдельный топик
- если пришла точка из прошлого — дописывает в тот же чанк, но с отдельным типом сообщения
- Читает чанки
- если прилетает чанк — пишем его в C*
- если точка из прошлого — достаём чанк, добавляем точку, перезаписываем
Результаты
Cassandra: 30000 → 150 writes/second.
- 6 x brokers v1.o
- подселяем брокеры на ноды k8s
- сырые точки храним 5 дней, это 5 терабайт
- чанки храним 2 месяца, это 3.3 терабайта с учётом репликации
- 20000 produced messages/second
- суммарно на kafka: 10 ядер и 45Gb памяти
- Не обновляйтесь на *.0 релизы, даже если очень хочется. Могут быть баги.
- Kafka не парится о том, чтобы уменьшить количество копирований. Используйте generate.
- Если не задать лимит на скорость копирования, kafka убьёт диск, сеть и проц. После запуска лимит для операций копирования задать нельзя. Но если задать лимит заранее, можно поменять значение лимита.
- Не запускайте много переносов партиций за раз. С одного брокера-лидера только одну партицию за раз.
- Больше года в продакшене
- Поняли, как всё работает
Бонус: легкость экспериментов.
- Можно выгрузить настоящие сырые данные
- можно сесть на поток настоящих сырых данных
- небольшой overhead на хранение
- можно хранить много данных на дешёвых и больших дисках
Бонус: точка опоры
- от БД теперь не требуется распределённость
- Consumer + standalone db
Если вы хотите написать свою специализированную БД:
- Подумайте 100 раз
- разберитесь, как работают взрослые БД
- используйте kafka в качестве wal
- напишите остаток кода
- Profit!?