Комментарии 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 видно
По поводу проблем протоколов: cейчас очень распространен Raft, вроде как самый понятный и легкореализуемый протокол, который уже много где используется. Думаю, эти ранние детские болезни уже чуть менее актуальны с его приходом. В zookeeper вообще проприетарный ZAB используется, древний монстр, но вроде как работает исправно. В любом случае, команда Kafka уже успешно переложила часть задач на сам брокер, поэтому этим ребятам я доверяю, продукт ключевой и очень серьезный.
cейчас очень распространен Raft, вроде как самый понятный и легкореализуемый протокол, который уже много где используется.
проблема не в рафте — к нему как раз доверие есть, а скорее к особенностям имплементации — даже в трех соснах можно заблудиться :-)
В zookeeper вообще проприетарный ZAB используется, древний монстр, но вроде как работает исправно
так в этом и ценность зукипера. Как там говорят — "старый друг лучше новых двух" и "старый конь борозды не испортит". Надежное и проверенное решение. А что там наимплементят в кафке — да пес его знает ) точно с первого раза будут какие-то детские болячки.
Как я и сказал ранее, брокер уже частично забрал часть функционала на себя и весьма успешно, лично я верю в прямоту рук этих ребят.
Вот классная статья от Conluent, почему нужен этот переход к беззукиперной модели, уже есть четкий роудмап, в том числе упоминают про операционные расходы: www.confluent.io/blog/removing-zookeeper-dependency-in-kafka
Apache Kafka в вопросах и ответах