Информация

Дата основания
Местоположение
Россия
Сайт
southbridge.io
Численность
51–100 человек
Дата регистрации

Блог на Хабре

Обновить
Комментарии 7

Виктор, ты супер! Больше бы тебя, а то что-то в этом стриме мало! :-)
Александр Миронов — тоже плюсик, приятно было почитать.


По остальному, что коллеги пишут — ну, мое мнение, что очень спорно )
Например, это:


если несколько ДЦ, это не синоним того, что у нас несколько кластеров.
...

Ага, только учитываем, что какие там каналы связи (latency может быть и хороший, но не всегда) + локальность данных (кафка ничего о топологии не знает, нужно ее учить — выше был пассаж про rackid, кстати) + зукипер о два ДЦ — это прям мооооооощь (учитывая, что нам нужно минимум 3 узла для отказоустойчивости).


или это:


Так вы будете сохранять место на горячем диске и при этом не понадобиться задумываться о бэкапах и прочих дополнительных настройках.

Все равно придется думать о том, что надежно ли данные в S3 хранятся и сможем ли мы их оттуда забрать (не забываем, что необязательно S3 эквивалентно Amazon S3 и это может быть сервис, собранный кустарно на чем-то вроде Minio)...


Еще мне все еще не дает покоя вопрос, который я не раскопал — гарантирует ли кафка действительно то, что если продюсер получил ОК, то данные попали на диски узлов. Вроде как по дефолту нет. И это обеспечивает непревзойденную производительность. Но этот момент может быть важен в каких-то пограничных случаях, когда реально нужны строгие гарантии того, что мы данные не "продолбаем"

То, что попали данные на диски — Кафка не гарантирует.
ACK возвращается клиенту после того, как данные были реплицированы на требуемое количество реплик, а именно в page cache. А дальше уже сама ОС решает, в какой момент времени действительно синхронизировать этот кеш на диск. Хотя стоит отметить, что в Кафке есть настройки для тюнинга этого поведения (например, частота синхронизации), однако сами разработчики рекомендуют полагать на саму ОС в данных вопросах. Поэтому по сути надежность достигается количеством реплик, в которые ведется запись, потому что сброс кеша на диск — накладная операция.
Рекомендую ознакомиться с kafka.apache.org/documentation/#appvsosflush
АЛЕКСАНДР МИРОНОВ: Мы же обсуждаем это с точки зрения DevOps? Для любого DevOps-инженера это ещё одна система, которую нужно знать, алертить, мониторить, которая у вас будет падать.

АНАТОЛИЙ СОЛДАТОВ: С другой стороны, ZooKeeper может не только для Kafka использоваться, он вполне может жить в компании в каких-то других системах.

АЛЕКСАНДР МИРОНОВ: А этого, кстати, лучше не делать. Лучше не использовать ZooKeeper для нескольких систем.

Полностью поддерживаю Александра в данном вопросе, дополнительный компонент — это всегда дополнительно операционные расходы на поддержку, обновление, деплоймент, алертинг, мониторинг, и, в принципе, дополнительное железо. Не зря разработчики Кафка активно двигаются в сторону избавления от ZK и пытаются переложить все больше задач по протоколам согласования на сам брокер.
А если учесть, что сейчас модно разворачивать много автономных кластеров под отдельные бизнес-задачи/отделы/домены, то это означает дополнительный кластер ZK на каждую инсталляцию со всеми вытекающими вышеописанными проблемами, какими бы идеальными деплоймент скрипты/плейбуки не были. DevOps-ы и Ops-ы подтвердят :)
А если учесть, что сейчас модно разворачивать много автономных кластеров под отдельные бизнес-задачи/отделы/домены, то это означает дополнительный кластер ZK на каждую инсталляцию со всеми вытекающими вышеописанными проблемами, какими бы идеальными деплоймент скрипты/плейбуки не были

Да нет там особо оверхеда — чего это вы людей-то пугаете ) Я понимаю, если б там условно для Кафки нужен был Кликхаус, а для него ещё и зукипер )
Движение к интегрированному протоколу одобряю — лучше выбор, чем его отсутствие. Но я питаю особые опасения по этому поводу, потому что у тех же эластик/редис/younameit или любого решения в кластере всегда были «детские» болезни на первых этапах реализации, что в лучшем случае приводило к тому, что кластер ломался, а не к потере или порче данных, причём отследить момент поломки было невозможно. Очень хорошо это в т.н. Jepsen test видно

Почему пугаю? Это жизнь :) Скорее, рассказываю факты, в том числе на основании личного опыта. Новый компонент — всегда дополнительные ресурсы (пусть даже не такие огромные, как для clickhouse) и дополнительный операционный оверхед (особенно для такого критичного сервиса, как zookeeper, от которого зависят другие сервисы).

По поводу проблем протоколов: cейчас очень распространен Raft, вроде как самый понятный и легкореализуемый протокол, который уже много где используется. Думаю, эти ранние детские болезни уже чуть менее актуальны с его приходом. В zookeeper вообще проприетарный ZAB используется, древний монстр, но вроде как работает исправно. В любом случае, команда Kafka уже успешно переложила часть задач на сам брокер, поэтому этим ребятам я доверяю, продукт ключевой и очень серьезный.
cейчас очень распространен Raft, вроде как самый понятный и легкореализуемый протокол, который уже много где используется.

проблема не в рафте — к нему как раз доверие есть, а скорее к особенностям имплементации — даже в трех соснах можно заблудиться :-)


В zookeeper вообще проприетарный ZAB используется, древний монстр, но вроде как работает исправно

так в этом и ценность зукипера. Как там говорят — "старый друг лучше новых двух" и "старый конь борозды не испортит". Надежное и проверенное решение. А что там наимплементят в кафке — да пес его знает ) точно с первого раза будут какие-то детские болячки.

Про старого коня так и сказали разработчики ClickHouse, когда их попросили добавить поддержку etcd, мол, у нас в продакшене это много лет и сейчас смысла что-то менять нет, но с радостью рассмотрим ваш ПР :)

Как я и сказал ранее, брокер уже частично забрал часть функционала на себя и весьма успешно, лично я верю в прямоту рук этих ребят.
Вот классная статья от Conluent, почему нужен этот переход к беззукиперной модели, уже есть четкий роудмап, в том числе упоминают про операционные расходы: www.confluent.io/blog/removing-zookeeper-dependency-in-kafka
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.