Что такое Kafka? Где стоит, а где не стоит применять этот инструмент? Чем Kafka отличается от RabbitMQ и других брокеров сообщений? Как её правильно эксплуатировать? Всё это обсудили на митапе «Apache Kafka в вопросах и ответах», который Слёрм провёл в ноябре 2020. В разговоре участвовали спикеры из Авито, Stripe, ITSumma и Confluent. Запись митапа доступна на YouTube, а текстовую версию разговора читайте ниже.
Знакомство со спикерами
МАРСЕЛЬ ИБРАЕВ: Сегодня мы говорим о Kafka, но не про философию, а про приложение. У нас очень крутые спикеры, разрешите мне их представить и сразу задать каждому приветственный вопрос: «какой RPS на вашем проекте?»
Анатолий Солдатов — lead engineer в Avito, много работал с базами данных, Kafka, Zookeeper, ClickHouse и много выступает на митапах и конференциях. Если не секрет, какой RPS на вашем проекте?
АНАТОЛИЙ СОЛДАТОВ: У нас около 600 RPS и порядка 25 Гб/с. Это в сумме все кластера.
МАРСЕЛЬ ИБРАЕВ: Огонь! Также с нами Александр Миронов, Infrastructure Engineer из компании Stripe, занимается развитием системы CI, работал в таких компаниях, как «2ГИС», Lingualeo и 4 года возглавлял инфраструктурную команду разработки сервисов стриминга данных в Booking.com. И это нам о чём-то да должно говорить: стриминг, большие данные, и вот это вот все наверняка как-то связано. Правильно я понимаю, Александр? И какой RPS?
АЛЕКСАНДР МИРОНОВ: Да, ты понимаешь все совершенно правильно, на середину 2020 года в Booking.com RPS получалось около 60 Гб входящего трафика и около 200 Гб исходящего, в миллионах сообщений я, честно говоря, не помню. Но это десятки миллионов сообщений в секунду.
МАРСЕЛЬ ИБРАЕВ: Супер.
АНАТОЛИЙ СОЛДАТОВ: Мы, кстати, у ребят из Booking.com учились. У нас Kafka помоложе, и Саша нам очень сильно помогал затащить всё это. Делились опытом.
МАРСЕЛЬ ИБРАЕВ: Далее у нас Виктор Гамов, Developer Advocate в Confluent. Специализируется на обработке потоковых данных с помощью Kafka. Также спикер российских, международных IT-конференций.
ВИКТОР ГАМОВ: И стример. Стал стримить, вот до чего жизнь довела! На конференции не пускают, приходится стримить. Всем привет! Какой RPS я не знаю, потому что я бездельник, маркетолог, я Kafka только продаю, не замеряю её вес. На самом деле, у нас свой Public Cloud, и у нас есть и большие, и маленькие клиенты. Не могу конкретно о цифрах говорить, но клаудный бизнес растет достаточно хорошо, люди приходят за managed-решениями. Есть SLA до трех девяток, не всегда дело в RPS, а еще иногда и в SLA, и в других вещах, которые связаны с reliability, не только со скоростью.
МАРСЕЛЬ ИБРАЕВ: Не RPS единым.
ВИКТОР ГАМОВ: Да.
МАРСЕЛЬ ИБРАЕВ: Ну и наконец Иван Сидоров, Chief Technology Innovation Officer из компании ITSumma. Самое интересное, что Иван прошел путь от простого разработчика к архитектору и обратно несколько раз, совместив это с менеджментом. Более того, вдохновившись книгой по Kafka, он инициировал создание технического издательства в компании. К Ивану вопрос такой же: как используете Kafka, какие есть максимально нагруженные проекты? Есть ли такие данные и можно ли их озвучить?
ИВАН СИДОРОВ: Отвечу немного уклончиво. По должности я исполнительный директор компании и занимаюсь внедрением различных инноваций, моя работа — узнавать про новые технологии, применять их в своей деятельности. Компания у нас сервисная, поэтому своя Kafka нам если и нужна, то только какая-то карманная. Но мы поддерживаем около половины Рунета крупного точно, и Kafka мы видели очень много, в разных конфигурациях, в разных вариантах использования. И RPS тут совершенно неважен. Тут важно, как используется Kafka, для чего она нужна. Конкретные цифры сказать не могу, но очень большие бывают тоже.
МАРСЕЛЬ ИБРАЕВ: Теперь, я думаю, наша уважаемая аудитория понимает, что компетенции участников достаточно высоки. Определенно будет, о чем поговорить.
АНАТОЛИЙ СОЛДАТОВ: Чем больше RPS, тем выше компетенция. Саша выиграл здесь, мне кажется.
АЛЕКСАНДР МИРОНОВ: Не, ну, Public Cloud от Confluent, я думаю, выиграет в любом случае.
АНАТОЛИЙ СОЛДАТОВ: Наверное, да, выиграет.
МАРСЕЛЬ ИБРАЕВ: Сам придумал такую линейку, сам решил.
ВИКТОР ГАМОВ: Вот мы это и делаем. Появилась Kafka, давайте из нее сделаем Kafka для всего, вот. У нас теперь Kafka для всего.
Что такое Kafka
МАРСЕЛЬ ИБРАЕВ: Много раз звучало слово «Kafka», и я бы хотел, чтобы наша аудитория вышла на один уровень понимания, что же такое Kafka и чем оно не является. В определениях часто встречается такое слово, как «брокер сообщений». И для меня, человека рефлексирующего по 2007 году, это словосочетание вызывает ассоциации с Jabber, ICQ и прочим. Все-таки хочется понять, что же такое на самом деле Kafka и для чего она предназначена.
АНАТОЛИЙ СОЛДАТОВ: Давайте по вариантам, чтобы было интереснее. Это лог, это стриминговая платформа, это база данных, свой вариант?
ВИКТОР ГАМОВ: Свой вариант. В книжке от Бена Стоффеда есть замечательная метафора: слепые встретили слона и начали его ощупывать. И в зависимости от того, что они трогали, у всех складывалось определенное впечатление. Кто-то потрогал за хвост и подумал, что это опоссум. Кто-то потрогал за хобот и подумал, что это удав. Кто-то потрогал за кожу и вообще ничего не понял. Такая же история и с Kafka. Все зависит от того, откуда вы пришли, от вашего изначального опыта и того, как вы ее начали трогать. Толя дал варианты: лог, стриминговая платформа, база данных? Я скажу так — это всё. Попробуйте переубедить меня.
С Kafka интересная история. Можно сказать, что пришли маркетологи и заставили нас думать, что Kafka — это такая панацея от всего. На самом деле, Kafka появилась из одной простой идеи. Эта идея не нова, но её решили выкатить в первый ряд. Это идея лога, и она всегда присутствовала в любой системе, где есть персистентность, будь то база данных или система обмена сообщениями. Лог — это простая идея: у тебя есть файлик, ты в него пишешь просто в конец и читаешь с начала. Эту идею имплементировали сами не раз руками. Поэтому, когда приходит слепой (из той метафоры), эксперт из мира очередей, он смотрит: ну, это же очередь! Мы же пишем в конец и читаем из начала. Это же очередь. Значит, месседжинг, правильно? Правильно.
Дальше приходит человек из мира баз данных и говорит: погодите, но мы же в Kafka данные размазываем по брокерам. Там есть партицирование, там есть consistent hashing, когда мы по какому-то ключу вынимаем, по значению знаем, куда класть. Когда клиенту не надо иметь какого-то внешнего load balancer, чтобы договориться. Это же распределенная база данных, это же NoSQL во все поля. Плюс, потому что там есть persistence, это точно база данных.
Потом приходят люди из мира ESB (enterprise service bus) и говорят: ну, там же есть коннекторы, которые позволяют нам перетаскивать данные отсюда сюда. Это ж ESB! Есть небольшой коннектор, на коннекторе есть какие-то определенные SMT (single message transforms), которые позволяют раутить в минимальном объеме. Точно ESB!
Получается неразбериха. Поэтому решили остановиться на таком определении, как Event Streaming Platform — платформа для захвата и обработки стримов, потоков сообщений, потоков событий. Событие — это какая-то иммутабельная запись, которая не меняется, и в идеале постоянно лежит в Kafka.
ИВАН СИДОРОВ: Дополню. Ты перечислил много применений, а если у нас замешаны датчики, то это уже IoT — интернет вещей. Kafka тоже там! А вообще, это такая же категория, как операционная система. Что делает операционная система? Все что угодно. Kafka — это система для работы с данными. Соответственно, в каком контексте её используют, такие возможности она и предоставляет.
АНАТОЛИЙ СОЛДАТОВ: Да, еще забыл вариант «труба». И ещё вопрос: встречали ли вы сетапы, где Kafka используется как база данных самостоятельно? Без всяких PostgreSQL, MongoDB и так далее. Вот есть приложение, есть Kafka, и больше ничего нет.
ИВАН СИДОРОВ: Мы — да.
АНАТОЛИЙ СОЛДАТОВ: То есть, такие кейсы вполне себе есть?
АЛЕКСАНДР МИРОНОВ: Да, встречали.
АНАТОЛИЙ СОЛДАТОВ: А с ksqlDB что-то такое уже пробовали, чтобы это была полноценная замена реальной базе данных: с индексами, с селективными запросами, которые могут ходить в прошлое?
ИВАН СИДОРОВ: Кейсы, которые видели мы, были чем-то вроде хранилища логов. Сложные запросы не нужны были.
ВИКТОР ГАМОВ: В чате пишут, что я еще забыл самый правильный юзкейс, который Kafka использует — RPS строить поверх нее.
ИВАН СИДОРОВ: А чем он отличается от ESB, например?
МАРСЕЛЬ ИБРАЕВ: Все зависли над твоим вопросом.
ВИКТОР ГАМОВ: Накручиваешь, накручиваешь, и получается сборка того, что тебе нужно. Года три назад была статья от The New York Times о том, как они используют Kafka в качестве хранилища. Но у них такое, каноническое хранилище — источник информации, из которого все забирают и потом каким-то образом модифицируют. Тут нужна СMS, она все это вычитает и в какие-то форматы обернёт, чтобы отрисовать это всё на экране. Если это система каталогизации, она Kafka берёт как исходник, а поверх строит какой-то индекс.
В чате пишут, что Kafka — это винегрет. Kafka это Kafka.
АЛЕКСАНДР МИРОНОВ: Такое количество способов использования системы, в очередной раз подчеркивает, что перед тем как начинать пользоваться Kafka, вам нужно чётко понимать, что именно вы от неё ожидаете, какую пользу для бизнеса вы планируете извлечь. Будь то open source Kafka или managed-решения вроде Confluent, и так далее.
Может быть, вы хотите обрабатывать данные и получать репорты для ваших аналитиков в реальном времени, а не через сутки — это один способ использования. Или, может быть, как в Times, вы хотите сохранить всю историю изменений вашей базы данных. Возможно ли это для вашего юзкейс, разумеется, невозможно заранее ответить, потому что у Times, все топики занимали несколько терабайт, по-моему, а если у вас петабайты данных, вам наверняка будет намного сложнее это сделать.
ВИКТОР ГАМОВ: Но все ещё возможно, есть способы.
АНАТОЛИЙ СОЛДАТОВ: Возможно-то всё, вопрос здравого смысла.
ВИКТОР ГАМОВ: Это самое главное. Спасибо, что есть Толик, который приходит и говорит правильные мысли. Вопрос не в RPS, а в здравом смысле.
МАРСЕЛЬ ИБРАЕВ: Получается, Kafka — это действительно комбайн, который сочетает в себе различную функциональность. Это может быть обработчик сообщений (брокер), база данных…
Где стоит, а где не стоит применять
МАРСЕЛЬ ИБРАЕВ: В каких областях Kafka можно применить? Я так понимаю, это анализ данных. Ещё я сталкивался с системой логирования мониторинга. Где помимо этих сфер можно применять Kafka?
АНАТОЛИЙ СОЛДАТОВ: В чатике было дополнение, что Kafka хорошо подходит для обмена сервисов, то есть notification туда отлично ложатся.
Давай я перечислю, для чего Kafka используется в Avito, а то фантазировать много можно. Для аналитики, для всяких кликстримов, для стриминга, для message broker, для того, чтобы вставлять различные буферы перед системами типа Elastic или ClickHouse. У нас это хорошо задружилось с трейсингом, например. Такие в основном паттерны: аналитика, message broker, буфер, база данных.
АЛЕКСАНДР МИРОНОВ: Fanout еще, такой классический кейc.
ИВАН СИДОРОВ: Аналитика в каком плане?
АНАТОЛИЙ СОЛДАТОВ: Самый простой кейс — это когда на платформу входит весь входящий трафик кликстримовый, а нашим аналитикам весь трафик не нужен, потому что там очень много ботов. И мы прямо в Kafka берём и фильтруем всё это. У нас появляется отфильтрованный топик, в котором содержится только чистый трафик, и он идёт, например, дальше в ClickHouse.
АЛЕКСАНДР МИРОНОВ: Еще один классический кейс — это security-анализ, анализ фишинга. Потому многие фреймворки для реал-тайм анализа из коробки позволяют использовать sliding window пятиминутное, которое автоматически за вас будет пересчитывать счетчики. Это очень удобно.
МАРСЕЛЬ ИБРАЕВ: Огонь! У каждого инструмента есть лучшие/худшие практики: молоток хорошо забивает гвозди, но замешивать им тесто не очень удобно, хотя и возможно. Есть ли области, где Kafka не ложится никак?
ВИКТОР ГАМОВ: High-Frequency-Trading (HFT). Здесь Kafka ни о чём, потому что, где диск привязан, там начинаются проблемы. Плюс, это распределённые системы. Там, где начинаются всякие сетевые вопросы, скорее всего, Kafka не подойдет. Если нужен простой месседжинг с простым раутингом (без внедрения тех вещей, о которых мы уже поговорили вкратце, KSQL, Kafka-streams, флипинг и т.д), здесь Kafka тоже не подходит. Потому что нужен просто message broker. Можно, конечно, использовать Kafka. Но потом люди приходят и говорят: «вот, Kafka для нашего HFT не подходит». Ну, естественно не подходит. Для этого есть какой-нибудь Aeron или ZeroMQ, которые были создан для того, чтобы не бежать по распределёнке, а локально.
АНАТОЛИЙ СОЛДАТОВ: Тут в целом, если тебе нужны и очереди, и супер low latency, и 100% гарантия доставки, и у тебя поток данных небольшой, то лучше не искать огромных инструментов типа Kafka...
ИВАН СИДОРОВ: … а использовать хардварные решения.
АНАТОЛИЙ СОЛДАТОВ: Ну, я подводил к RabbitMQ, конечно, но можно и так.
ИВАН СИДОРОВ: Нет, это долго.
ВИКТОР ГАМОВ: Правильное, на самом деле, уточнение по поводу хардварных решений. Я раньше трудился в компании, которая делала небольшой распределенный кэш, назывался Hazelcast. И мы делали такую интеграцию интерпрайзную со всякими балалайками, чтобы делать кросс-датацентерную (как вы по-русски говорите?) — Multi-Datacenter Replication.
АЛЕКСАНДР МИРОНОВ: Очень по-русски сказал.
ВИКТОР ГАМОВ: И мы как раз перед тем, как запилить адаптер для Kafka, мы запилили адаптер для Solace, который давал хардварное решение. Люди с большими деньгами покупали платы, которые давали супербыстрый latency. Там вопрос был именно передачи информации между океаном, между Чикагской биржей и Лондонской, поэтому Solace давал какие-то дикие цифры, потому что лежал поверх кастомной сети и кастомного железа. Поэтому шутки шутками, но если хочется скорости, всегда можно опуститься, как Ваня сказал, на уровень железки.
ИВАН СИДОРОВ: Если ты в HFT, у тебя уже есть деньги для того, чтобы сделать кастомную железку.
ВИКТОР ГАМОВ: Или деньги инвесторов.
ИВАН СИДОРОВ: Да, а если нет, то HFT не будет.
АЛЕКСАНДР МИРОНОВ: Ну, и еще одна холиварная тема — это использование Kafka в качестве базы данных. Теоретически это возможно и даже практически мы видим какие-то кейсы, но чтобы сделать это правильно, потребуется значительное количество времени, и во многих случаях, возможно, имеет смысл продолжить спокойно использовать PostgreSQL или что-то еще, что позволяет делать простые запросы по любым ключам. Потому что Kafka все-таки да, имеет выборку по офсету ID, но даже эта операция значительно медленнее...
ВИКТОР ГАМОВ: Вот ты правильно говоришь, но для слушателей надо немного пояснить. Почему Kafka ассоциируется с известным докладом Мартина Клеппмана (Martin Kleppmann) «Turning the database inside-out» (если вы не видели, сходите посмотрите). Отличие Kafka от базы данных в том, что… и там, и там есть лог и durable-хранилище, которое обеспечивает хранение данных на долгий срок, но в обычной базе данных для вас в API есть Query Engine, с которым вы взаимодействуете посредством какого-то DSL: SQL, в данном случае, если noSQL, там тоже какой-то свой, JSON, не знаю, что-нибудь в MongoDB. В Kafka всё немного иначе. Там storage, собственно, вот этот лог, и ваш Query language разнесены. Поэтому абсолютно непрактично использовать какой-то стандартный low level кафковский API для того, чтобы бегать по апсету. Это не нужно, неправильно и вообще вредно.
Обычно смысл Kafka в том, что вы можете насадить туда любое приложение, и оно становится вот этим Query Agent, и вы дальше накручиваете. Вы хотите иметь какой-то хитрый язык запроса? Вы можете это сделать. Речь идет о том, что стандарта нет такого, чтобы вот взять и сделать из Kafka k-value какой-то Storage. Вам нужно все равно что-то либо написать, например, взять Kafka Streams, написать там две строчки, и у вас получается из топика сделать материализованный View и отдать его через REST. Это достаточно просто сделать. Такой же процесс использует skim-registry. Вот мы сделали балалаечку, которая позволяет хранить схемы, данные. Skim-registry не нужно ничего, кроме Kafka. Она внутри Kafka хранит все ваши схемы. Она наружу отдаёт REST-интерфейс. Если вы пришли и сказали: вот у меня есть такой тип схемы, вот мой номер ID, отдай мне всю схему, — всё это реализовано внутри Kafka. Kafka используется как хранилище.
Kafka Сonnect использует Kafka как базу данных. Там тыща параметров всяких, настроек лежит внутри Kafka. Когда вы стартует, Сonnect голый, он все настройки хранит внутри Kafka. То есть, здесь ничего не надо. Это к вопросу о том, что Марсель сказал про молоток. Можно молотком помешать тесто? Можно. Можно ли на Kafka сделать базу данных? Можно. Можно ли на ней сделать серьезную базу данных? Можно. Вопрос в уровне упоротости. Насколько глубоко вы готовы пойти.
ИВАН СИДОРОВ: Kafka и база данных — это звучит дико из-за того, что не сходится с парадигмой обычной базы данных, где язык запросов и база данных неотделимы друг от друга. Но это достаточно просто показывается на примере того же самого Hadoop, который стал уже достаточно расхожей технологией. Что такое Hadoop? Обычно, когда говорят Hadoop, говорят HDFS. Это просто файловая система, а поверх нее можно накручивать схемы, разные движки запросов, Hive, HBase, все что угодно. И в Kafka, как я понимаю, просто пока вот этих Query Engine которые бы уже закрепились в индустрии, пока нет. И поэтому Kafka для базы данных
воспринимается так.
И если вопрос о том, где Kafka применяется неправильно, чуть переиначить и спросить: а где нерационально или слишком дорого применять Kafka — это логирование. Можно делать логирование на Kafka и писать вокруг что-то или можно взять готовый ELK, который ты «клик» — и установил. Зачем тут Kafka? Нерационально. Но если нужна система логирования, которая потом обрабатывает кучу микросервисов, отправляется через Сonnect в какой то-то data warehouse и так далее, то тут уже надо подумать, что ELK не принесёт пользы, а принесет
больше вреда, пока будешь ковыряться внутри Elastic.
МАРСЕЛЬ ИБРАЕВ: Супер, с этим вопросом разобрались. Теперь понятно, что за инструмент такой Kafka. Пойдем дальше.
Kafka vs RabbitMQ
МАРСЕЛЬ ИБРАЕВ: На круглый стол зарегистрировались около полутора тысяч человек, они задали порядка 200 вопросов, 90-95% которых были про RabbitMQ.
И первый вопрос: в чем отличие? Как я понял, Kafka — это многофункциональный инструмент. RabbitMQ работает с очередями и для этого предназначен. Так ли это?
АНАТОЛИЙ СОЛДАТОВ: По большому счету, наверное, да. RabbitMQ планировался в первую очередь для очередей, и по-другому мы его не использовали. Kafka дизайнилась как бы с другой парадигмы, что ли. Во–первых, там очереди и топики — это разная семантика, они не повторяют свои свойства. Во-вторых, у Kafka была изначально цель — высокая пропускная способность, реально высокая. RabbitMQ, я и на своем примере знаю, и от разных компаний слышал, что 20-30 K RPS для RabbitMQ — это предел. Как очередь он в принципе и не должен выдерживать больше. Наверняка, есть какой-нибудь мастер RabbitMQ, который его так соберёт, что это будет суперскоростной реактивный RabbitMQ, но это тоже вопрос: а зачем он такой, если есть технологии под этот кейс? А для Kafka перемалывать сотни, миллионы RPS — это нормально. Она дизайнилась именно для этих целей. Но, с другой стороны, если нужен low latency и вам важно, чтобы одно сообщение быстренько долетело до консюмера, нигде не потерялось, то здесь RabbitMQ может и лучше подойти.
АЛЕКСАНДР МИРОНОВ: Тут нужно уточнить, что Kafka всё равно можно затюнить под low latency, чтобы у вас были миллисекундные задержки. Но для этого нужно постараться.
АНАТОЛИЙ СОЛДАТОВ: Надо потрудиться, да. И это будет, скорее всего, выделенный кластер. Не получится сделать один кластер и под high-throughput и под low latency.
АЛЕКСАНДР МИРОНОВ: Самое главное, действительно, в разной семантике топиков и очередей. Виктор уже назвал десяток технологий подобных очередей. В концепции очереди у вас есть возможность удалить сообщение или пометить его как прочитанное. Вы можете это сделать в любом порядке. Kafka — это лог, которому всегда аппендятся записи. Из него ничего удалить нельзя. Соответственно, единственная метка того, где сейчас находится ваш консюмер — это текущий upset, который всегда монотонно возрастает (monotonic increasing). Соответственно, вы не можете просто взять и без дополнительных инструментов пропустить какое-то сообщение, чтобы потом к нему вернуться и прочитать. Вам пришло 10 сообщений, вы должны дать Kafka ответ: вы их все обработали или нет.
АНАТОЛИЙ СОЛДАТОВ: Не могу удержаться и не сказать, что так тоже можно…
АЛЕКСАНДР МИРОНОВ: Можно, да. У Uber есть большая статья: Dead Letter Queues with Apache Kafka. Про то, как они сделали Dead letter queue.
АНАТОЛИЙ СОЛДАТОВ: Кстати, в чем отличие того же Dead letter queue — в RabbitMQ оно встроено в брокер, а в Kafka клиенты или что-то там над брокерами реализует эту всю логику.
АЛЕКСАНДР МИРОНОВ: Вам понадобится ещё дополнительный функционал, чтобы это сделать. И возможно, можно взять просто out of the box инструменты, а уж тем более, если вы находитесь где-то в Public Cloud, в Amazon или в Google, у вас уже есть очереди, которые доступны из коробки.
АНАТОЛИЙ СОЛДАТОВ: Опять же, различия есть. Они тоже из топиков вытекают, как Саша сказал, что есть offset consumer-groups, в RabbitMQ ты не особо почитаешь несколькими консюмерами из одной очереди. Это можно сделать, размножив очередь. А в Kafka ты читаешь один и тот же лог, и у тебя апсеты трекаются независимо для разных consumer-groups. Это вполне себе легко работает.
ВИКТОР ГАМОВ: Вот это, кстати, такой очень интересный момент, который не всегда все до конца понимают. Люди спрашивают: как мне сделать так, чтобы кто-то другой не прочитал мое сообщение? Или наоборот, чтобы смог. Я думаю, это опять все связано с тем, что Kafka не появилась из научного института, где все было сразу продумано, она появилась от сохи: люди решали собственную проблему. Вот эта категория имен, которая пришла из месседжинга, и вызывает определенные вопросы. Топик, брокер — это же все месседжинг. И люди накладывают поверх этого какой-то свой предыдущий бэкграунд.
Соответственно, когда у тебя есть возможность репроцессить лог и возвращаться к каким-то вещам, например, ты получил данные и знаешь, что у твоего поставщика данных нет возможности их перечитать. Они у тебя уже лежат в системе, и ты их можешь просто препроцессить, может быть, применить алгоритм. Или ты просто пытаешься что-то новое из этих документов получить. Какую-то информацию. Это уникальная вещь, которая есть в Kafka, и зачастую о ней забывают.
Но, как только мы начинаем говорить про вещи, как Event Sourcing, QSRs, вот эти все микросервисы обмена сообщениями, вот тут люди начинают видеть бенефиты. Если они приходят в Kafka из мира обмена сообщениями, какого-то там ивентсорсинга (хотя это тоже не чистая Event Sourcing система, можно накрутить и добавить, есть там определенные решения, которые это все реализуют), люди видят бенефит. И опять же, при добавлении каких-то клевых штук, например, хранилища, которое позволяет хранить всю историю сообщений в системе, которое позволяет в любой момент в любой новой системе перечитать эти данные по новой и получить репорт.
Например, у нас есть система, которая захватывает все заказы, и нам в конце года нужно подвести итоги — запустить большую джобу (от англ. job), которая выдаст репорт. Эта джоба запускается один раз в год, но данные нужно откуда-то брать. Чтобы не переливать из одного места в другое, она вычитывает данные из Kafka один раз и получает отчёт.
АНАТОЛИЙ СОЛДАТОВ: Иногда бывают вопросы: у меня в компании RabbitMQ, мы слушали, что Kafka крутая и модная, давайте мы ее поставим на замену, потому что она лучше. Хотя RabbitMQ не хуже в каких-то своих кейсах, и вообще отличная штука для очередей.
ВИКТОР ГАМОВ: Самое лучшее программное обеспечение — это то, которым вы умеете пользоваться. Если вы умеете хорошо варить RabbitMQ, и он у вас не падает, по ночам вам не звонят админы, а если вы админ, то не звонят пользователи-разработчики, то вообще нет проблем.
ИВАН СИДОРОВ: Я вот все ждал, когда уровень абстракции поднимется, потому что, вот как я написал про свою должность, от разработчика к архитектору и обратно…
В: Ты как Хоббит — туда и обратно.
ИВАН СИДОРОВ: Да, и каждый раз с приключениями. Вообще, разница между RabbitMQ и Kafka — это то, что одна машина красная, другая синяя. Если в общем говорить. В архитектурном плане. У меня есть теория, откуда начались эти холивары, которые достаточно жестко цепляются за незначительные нюансы. Kafka и RabbitMQ стартовали примерно в одно время. RabbitMQ был написал на Erlang. Тогда был фетиш, все верили, что Erlang — это потрясающая система, которая спасёт мир технологий и ускорит всё, а Java — это кровавый интерпрайз, мол, чтобы мне запустить на моей VPS-ке с 16-ю мегабайтами памяти Java, придется купить еще 10 таких .
Дальше закон Мура работает, вычислительная мощность позволяет не думать о том, что внутри (если не HFT, а там вычислительные мощности китайских полупроводниковых заводов справляются). Сейчас это абсолютно одинаковые технологии, которые разошлись уже с точки зрения бизнеса.
АНАТОЛИЙ СОЛДАТОВ: Ты вот подводишь, что Kafka и RabbitMQ — это одно и то же, но нет. Напомню, на всякий случай.
ИВАН СИДОРОВ: Я говорил с точки зрения архитектуры.
МАРСЕЛЬ ИБРАЕВ: Итак, мы обсудили, что разница у Kafka и RabbitMQ есть. И всегда нужно идти от продукта, от задачи и от умения пользоваться инструментом. Не стоит слепо верить статьям, где написано, что Kafka — это круто, и у вас сайтик на WordPress взлетит после её установки.
АНАТОЛИЙ СОЛДАТОВ: Я добавлю ещё про RabbitMQ. Бывает ещё, что ты просто упираешься в технологию. У нас были случаи, когда RabbitMQ приходилось отключать реплику, чтобы он успевал. И это уже звоночек, что надо что-то другое. Плюс всякие истории с нестабильными сетями. Там тоже RabbitMQ разваливается хорошо, и стоит сразу смотреть другие технологии. Даже если вы сейчас умеете с ним работать, то Multi-DC с нестабильными сетями и высокие нагрузки не очень подходят для RabbitMQ.
Как правильно эксплуатировать Kafka
МАРСЕЛЬ ИБРАЕВ: Предположим, мы решили, что проект подходит для Kafka, мы его поставили. Но поставить и настроить — это полдела. Дальше его надо эксплуатировать. Как правильно эксплуатировать Kafka? На что стоит обратить внимание? Какие метрики собирать?
АЛЕКСАНДР МИРОНОВ: Надо начать с вопроса, «А на чём вы собираетесь запускать Kafka: на виртуальных машинах, на Kubernetes, на bare metal?» И от этого способы развёртки и инсталляции будут кардинально меняться. Multi-DC и прочие сетапы добавляют проблем.
Классическая инсталляция Kafka — это некий кластер с минимум тремя нодами, чтобы данные копировались как минимум дважды. То есть у вас будет три брокера. Как вы будете их запускать, это зависит от вас: можете с помощью Puppet, можете попробовать сделать это в Kubernetes, что будет намного сложнее. Kafka — это распределённая система, у Kafka есть один небольшой недостаток, который постепенно устраняется, это зависимость от ZooKeeper.
ZooKeeper — это ещё одна распределённая система, с ещё одним сетом собственных особенностей (мониторинговых, инсталляционных и всего остального), который вам придётся тоже развернуть и использовать.
АНАТОЛИЙ СОЛДАТОВ: Почему недостаток?
АЛЕКСАНДР МИРОНОВ: Ну не знаю, если ты садомазохист, то тебе может быть прикольно запускать две системы, чтобы какого-то продуктового кейса добиться, но вообще…
АНАТОЛИЙ СОЛДАТОВ: Ну слушай, ты этот ZooKeeper один раз описываешь в Puppet, и потом тебе уже не важно будет, Kafka одна или с ZooKeeper.
АЛЕКСАНДР МИРОНОВ: Мы же обсуждаем это с точки зрения DevOps? Для любого DevOps-инженера это ещё одна система, которую нужно знать, алертить, мониторить, которая у вас будет падать.
АНАТОЛИЙ СОЛДАТОВ: С другой стороны, ZooKeeper может не только для Kafka использоваться, он вполне может жить в компании в каких-то других системах.
АЛЕКСАНДР МИРОНОВ: А этого, кстати, лучше не делать. Лучше не использовать ZooKeeper для нескольких систем.
АНАТОЛИЙ СОЛДАТОВ: С этим я согласен, но я про другое. Я про то, что ты где-то в Puppet имеешь описанные модули под ZooKeeper, и сетапишь ты его для Kafka или для ClickHouse — не важно. Понятно, конфигурация изменится, нагрузка будет другая, но ты уже умеешь с ним работать и у тебя уже мониторинг настроен (немного что-то другое появится, конечно). Я не разделяю нелюбовь к ZooKeeper.
АЛЕКСАНДР МИРОНОВ: Никакой нелюбви нет, просто нужно отдавать себе отчёт, вот и всё…
АНАТОЛИЙ СОЛДАТОВ: Да ладно!
АЛЕКСАНДР МИРОНОВ: К слову сказать, в моей команде в Booking.com за всё время эксплуатации Kafka не было каких-то больших проблем с ZooKeeper. Но, чтобы их не было, нам пришлось его подробно изучить.
АНАТОЛИЙ СОЛДАТОВ: ZooKeeper — очень старая система. У нас тоже с ним никогда не было проблем.
АЛЕКСАНДР МИРОНОВ: Но у нас в компании всё же были проблемы с ZooKeeper. Не в моей команде, но в других командах. И когда они случаются, они обычно очень серьёзные.
В чём ещё особенность Kafka для людей, которые приходят из managed-сервисов? Например, когда вы работаете с SQS в Amazon, вы чётко знаете лимиты вашей очереди. Вы не можете записать, условно, больше тысячи сообщений в секунду; не можете записать больше чем 1 Мб сообщений в секунду. И вы можете выстраивать приложение, отталкиваясь от этих очень чётких лимитов. С Kafka такого нет. Это зависит и от того, как зависит ваше приложение — и продюсеры, и консюмеры; от того, как настроен ваш кластер. Если придёте к админу и скажете: «Заведи мне топик и скажи, сколько я смогу записать сообщений в одну партицию». Скорее всего, он не сможет дать вам простой ответ. Это ещё одна особенность Kafka, с которой мы сталкивались очень часто. Потому что приходят люди с очень разным бэкграундом, особенно из продуктовых команд, и последнее, что им нужно — это думать про Кб и Мб в секунду, которые они могут пропустить через одну партицию с какой-то latency. Придётся прописывать какие-то гайдлайны для разработчиков. Нужно будет запускать бенчмарки. Нужно будет понимать, вот на вашем сетапе, на вашем железе, сколько данных за какой интервал времени вы можете пропустить.
Что ещё нужно знать про Kafka? Клиенты — на каком языке вы пишете, и чем вы пользуетесь. Kafka изначально написана на Scala, теперь уже больше на Java. Соответственно, последний vanilla-клиент, которые поддерживает это всё, это джавовый клиент. Если вы используете C#, то официальный клиент Confluent, например, сделан поверх C-библиотеки librdkafka, которая тоже поддерживается человеком, который работает в Confluent, но всё равно у вас будет задержка с фичами, они будут приходить позже.
Клиенты C Sharp, Java, Go, Python, Ruby… мы в Booking.com ещё Perl любили использовать, как вы знаете, нам пришлось свой клиент поверх librdkafka писать. Это достаточно большая боль, которая может возникнуть в тех компаниях, которые используют разные языковые экосистемы.
АНАТОЛИЙ СОЛДАТОВ: Да, но здесь можно либо пользоваться вот этими клиентами или писать свои, либо второе — какие-то прокси комплементить или использовать, там уже нет привязки к языку.
АЛЕКСАНДР МИРОНОВ: Совершенно верно! И мы опять приходим к тому, что это ещё один возможный компонент, который придется внедрить, чтобы эту систему развязать. Это всё подчеркивает то, Kafka, она как брокер сообщений, как бы мы его ни называли, достаточно бесполезна сама по себе. Самый большой бенефит Kafka по сравнению с RabbitMQ или Pulsar — это её экосистема. Это количество коннекторов, приложений, проприетарных решений, которые просто из коробки будут работать с Kafka. Я знаю даже кейсы из других компаний, где интегрировали данные из нескольких компаний с помощью Kafka. Просто потому, что у них уже она была, и им было намного проще таким образом запродюссить друг другу сообщения в кластере, прокинуть сетевые доступы условные, чем городить свои собственные проприетарные http-протоколы или ещё что-то. Вот именно эта инфраструктура и её распространенность — вот это самая главная мощь Kafka, на мой взгляд.
АНАТОЛИЙ СОЛДАТОВ: Мне тоже так кажется. Более того, есть ребята из разных компаний, в том числе российских, которые из Kafka используют только коннекторы. Всё вот это вот связали, поставили Kafka, и за счет этой экосистемы не пишут вообще никакого кода. На конфигах у них всё взлетает, всё работает. Здесь иногда цена внедрения очень маленькая. Она вся упирается в инфраструктуру, по сути.
Чем глубже Kafka прорастает в компанию, есть у нее такая фишка, кластера начинают плодиться с большой силой после первого, инфраструктура тоже разрастается и порой становится очень сложной. Всё что мы перечислили: коннекторы, Zookeeper, репликаторы, мониторинги, штуки, которые позволяют легче администрировать кластера Kafka (потому что администрирование — это довольно большой объём toil work). И очень быстро. Стандартная история — когда у нас есть Kafka, а вокруг нее еще 10 инфраструктурных сервисов или технологий вращается.
АЛЕКСАНДР МИРОНОВ: На эту тему еще можете посмотреть как раз в Avito мы в январе этого года делали доклады, я и Толя, и мы подробно обсуждали экосистемы. То, как мы делали это в Booking.com и Толя рассказывал, как ребята делают коннекторы в Avito, и можно посмотреть, какое количество дополнительных компонентов нужно для того, чтобы эффективно ранить эту систему, чтобы ваши девелоперы занимались продуктовой разработкой, а не разработкой для Kafka.
Я еще хотел по-быстрому ответить на вопрос из чата: «Лучше Kafka Connect или NiFi?» В NiFi нет репликации. Если у вас падает нода в NiFi перед тем, как она прокинула данные ещё куда-то, если вы не поднимите её обратно (не знаю, помолитесь или пойдёте диск собирать руками), то не сможете эти данные восстановить.
ИВАН СИДОРОВ: Хочу всё же про мониторинг резюмировать. С коллегами я полностью согласен. Единственная метрика, которую нужно мониторить на инфраструктуре — это теряем мы деньги или не теряем, а дальше уже спускаться до самого нижнего компонента. Если рассматривать Kafka как вещь в себе, то её нужно мониторить как обычное Java-приложение. Побольше памяти поставил, она не вылетает — всё хорошо.
АЛЕКСАНДР МИРОНОВ: Это, кстати, плохое решение для Kafka, ну да ладно.
ИВАН СИДОРОВ: Мы же в отрыве от инфраструктуры, нам же не сказали данные. А дальше нужно смотреть, выполняет ли выбранная часть инфраструктуры, реализованная на Kafka, свою бизнес-задачу. Самый простой кейс, когда мы используем Kafka как очередь и кидаем с одной стороны сообщение в другое, то смотрим: они отправляются и принимаются? с какой скоростью принимаются? с какой отправляются? почему так мало или много принимается? есть ли аномалии? Аномалии в том бизнес-процессе, который технологически реализует Kafka.
АНАТОЛИЙ СОЛДАТОВ: Ты говоришь про ISO-мониторинг, насколько я услышал, это штука крутая. Кажется, из неё нужно исходить, и всякие там алерты на пейджеры присылать, когда начинаются всякие такие проблемы, потому что у Kafka отказ одной, пяти или десяти машин — это не проблема, можно спать дальше, если всё остальное выполняется.
Но все равно нужно еще иметь инфраструктурный мониторинг, который внутри самой Kafka смотрит, что происходит, потому что когда там проблемы начинаются, в Kafka очень много метрик, это не только то что Java дает, для Kafka их там миллион.
Мы сделали себе три окна. Первое — на уровне всех кластеров смотрим, что вообще происходит там, сколько брокеров живых/неживых в процентном соотношении, есть ли офлайн-реплики, например, сколько у нас не выполняется isr.
Дальше спускаемся на уровень конкретного кластера, смотрим, сколько у него входящих сообщений сейчас, сколько исходящих. Сколько было неделю назад в этот же день, в это же время. Количество топиков партиций можно посмотреть, ну, просто серверные метрики, очевидно, в первую очередь надо смотреть — сеть, наверное.
АЛЕКСАНДР МИРОНОВ: Сеть, файловые дескрипторы, disk io.
АНАТОЛИЙ СОЛДАТОВ: Файловые дескрипторы можно поставить 1 млн, и не смотреть их. Но у нас они тоже выведены, на самом деле.
АЛЕКСАНДР МИРОНОВ: Ну да, к вам просто придёт 1 млн коннекшенов, вы даже не узнаете об этом.
АНАТОЛИЙ СОЛДАТОВ: Я думаю, мы узнаем об этом быстро. Все пользователи Avito узнают об этом.
И самый низкий уровень — это уже когда ты на уровне брокера смотришь специфичные какие-то метрики, сколько там в Q висит это сообщение, как часто меняются shiring expand. Там много всего, что может позволить помочь понять, где проблема (с ДЦ что-то произошло, не вывозят рейды, и их надо увеличить). Такой мониторинг тоже должен быть. Я не вижу кейса, когда вы без него можете понять, что происходит.
ИВАН СИДОРОВ: Есть проблема овермониторинга. Как ты классно рассказал, что вы спускаетесь фактически с SLA-мониторинга на процессы конкретных систем, на конкретный кластер, на конкретную джобу. Если мы спускаемся на конкретную джобу и видим экран из тысячи метрик, и 30 из них горят красными, сделать вывод, что происходит, невозможно. Исчерпывающим мониторингом можно считать тот, который срабатывает в большинстве случаев. А с верхнего уровня у нас стоит «все сломалось». И «все сломалось» запускает ресеч до расширения списков алертов.
АЛЕКСАНДР МИРОНОВ: Мне кажется, что мы просто приходим к топику white box VS black box мониторинг, насколько я знаю у Слёрма есть всякие курсы на эту тему.
АНАТОЛИЙ СОЛДАТОВ: Самый простой путь — это взять какой-то проприетарный мониторинг, который работает уже долго (например, от Confluent). Посмотреть, как у них работает, и понять что вам нужно. Там всё довольно-таки красиво, в картинках. Не надо это покупать, но заимплементить через Prometheus, Consul, Grafana, Graphite точно можно.
АЛЕКСАНДР МИРОНОВ: У Kafka в главной документации есть описание критических метрик, за которыми надо следить.
Особенности разработки приложений для работы с Kafka
МАРСЕЛЬ ИБРАЕВ: Есть ли особенности разработки приложения для работы с Kafka? Какие-то подходы?
АЛЕКСАНДР МИРОНОВ: Хочется как-то сформулировать, чтобы опять это не превращать в часовую дискуссию, потому что очень широкие вопросы. Мы уже затронули клиенты. В зависимости от того, какой клиент вы используете, он будет вести себя по-разному. Давайте обсудим Java vanilla клиент, потому что он наверняка самый популярный. В Java vanilla клиенте у вас есть две части этой библиотеки: producers и consumers. Обе эти части тюнятся совершенно по-разному. У каждой свой набор конфигураций, который вы можете настроить в зависимости от того, под какие продуктовые цели используете Kafka. Продюсер вы можете затюнить либо под low latency, чтобы он как можно быстрее отправлял сообщения с высокой гарантией доставки, либо вы можете сказать: мне нужно медленно, но много, или мало, но качественно, либо что-то среднее (in the middle).
По умолчанию, кстати, это касается и настроек брокера тоже, Kafka настроена как система in the middle: она не дает вам супергарантии доставки и не заточена под супер low latency, она где-то посередине, чтобы удовлетворять 80% юзкейсов. Это важно упомянуть, потому что если вы не видите проблем с продюсерами, с консюмерами или брокерами, скорее всего, вам не нужно трогать эти настройки.
Приведу пример. В Booking.com в первые несколько лет мы, может быть, 3 или 4 из сотни top level конфигов меняли. То есть вот этот дефолт действительно очень «same» в Kafka. Если возвращаться к producer side. Джавовый producer — это мультитредное приложение, которое внутри открывает n тредов, коннектится к брокерам, начинает слать сообщения. Лучшая практика его применения — это переиспользование одного и того же инстанса в Java. Не нужно открывать тред-сейф, соответственно, вы можете успешно пользоваться одним и тем же инстансом.
С консюмером совершенно другая история, он не тред-сейф. Мало того, что, когда вы делаете какие-то запросы типа poll, если в данный момент в буфере у этого консюмера нет сообщений, которые он вам может отдать напрямую, он заблокирует ваш main trap и начнет делать запросы Kafka. Это уже совершенно два разных поведения вроде как одной и той же библиотеки.
Но я уверен, что в 80-90% вам не надо будет ничего тюнить, вам просто нужно понять, с какой гарантией вы хотите доставить ваше сообщение. Вам, например, без разницы, дойдет оно или нет (поскольку это метрика или log line), или вам важно не потерять его (сообщение о заказе на сайте). Для этого есть одна top level настройка, которая будет фактически контролировать, на какое количество реплик будет записано сообщение, и ответ в ваше приложение вернётся только тогда, когда n реплик подтвердили запись. Соответственно, вы можете сказать, что я просто послал по сети сообщение, и мне даже TCP-акт не нужен, (это акт 0, по-моему).
Про всю эту тему есть отличная статья «How to Lose Messages on a Kafka Cluster». И там достаточно большое исследование проведено. Там в Docker чувак поднимал разные конфигурации кластеров, писал в них сообщения, валил эти ноды и смотрел, где какие сообщения теряются. Пойдите почитайте и вы поймёте, что нужно и не нужно делать.
АНАТОЛИЙ СОЛДАТОВ: Я с Сашей полностью согласен. Единственное, добавил бы, что вы, скорее всего, в какой-то момент придёте к коробочкам. У вас будут как раз эти конфиги и вы можете их всех загнать в какой-нибудь фреймворк и использовать всё время одни и те же, чтобы не давать клиентам сильно много ручек, чтобы они не крутили и не портили сами себе жизнь случайно.
АЛЕКСАНДР МИРОНОВ: Согласен. У нас в Booking.com примерно так же и было сделано: ты мог затюнить все конфиги, которые хотел, ничего не ограничивали, но мы давали набор пресетов или коробочек, как ты сказал. У них было human-readable название типа «low latency», «No AX», «high-throughput» и мы затюнивали 3-5 параметров в бэкграунд за тебя.
АНАТОЛИЙ СОЛДАТОВ: Да, потому что кажется, что это проблема со всеми системами, где много клиентских настроек, что если у вас сотни сервисов или клиентов, скорее всего, кто-то из них сделает неправильно.
АЛЕКСАНДР МИРОНОВ: Наверное, тут еще про консюмеры нужно упомянуть. Самая главная теория, которую нужно знать про консюмера — когда вы отправляете offset, коммитите offset. Гарантия обработки сообщения это: at least once, at most once или exactly once. Это важно для того, чтобы не потерять ваши данные, не потерять результаты обработки ваших данных и, по сути, по большому счету это все сводится к тому, что вот вы считали сообщение, вы получили сообщение из Kafka, после этого вы проводите работу над этим сообщением (неважно, что вы делаете), и перед вами стоит ключевой вопрос: в какой момент вы будете коммитить этот offset обратно в Kafka. Вы будете коммитить его как запроцешенный до того, как вы сделаете процессинг или после? И в зависимости от этого у вас будут разные гарантии доставки и обработки этих сообщений.
АНАТОЛИЙ СОЛДАТОВ: Я бы еще добавил про консюмера то, что он скейлится, их параллелизм зависит напрямую от количества партиций в топике, тоже такая базовая штука. Саша сказал про механику офсетов, есть еще вторая базовая механика: не нужно консюмеров больше делать, чем количество партиций, потому что в Kafka так сделано — там больше, чем один консюмер на одну партицию не намапится. Если у вас их будет, условно, 10, а партиций всего три, то никакой пользы вы из этого не извлечете, и вам надо будет сначала партиции увеличить, а потом уже вы получите параллелизм.
АЛЕКСАНДР МИРОНОВ: Совершенно верно, да.
Бэкапы
МАРСЕЛЬ ИБРАЕВ: Последний вопрос из заготовок, который мы успеем рассмотреть: бэкап. Kafka — штука распредёленная, и вроде как можно забить и сказать: она сама себя поддерживает, и если что-то упадет, то ну и ладно, она будет работать. Махнуть рукой и предположить, что никаких проблем не будет. Но при этом что-то такое админское в душе просит все-таки какие-то сохранения состояний, бэкапы на всякий случай. И вопрос такой: нужны ли вообще бэкапы на Kafka, если нужны, то почему или почему не нужны?
АЛЕКСАНДР МИРОНОВ: Я придерживаюсь мнения, что скорее не нужны. Во-первых, в Kafka есть встроенный механизм репликации, который полностью конфигурируется вами, и вы можете контролировать количество реплик от нуля до бесконечности. Помимо этого механизма встроенной серверной репликации у вас есть те самые гарантии доставки, которые мы уже обсудили (тот самый параметр Ex). Вы можете контролировать, на сколько физических или виртуальных машин, контейнеров, подов у вас будет записано сообщение перед тем, как producer получит «Всё OK» от сервера. Исходя из тех бизнес-кейсов, с которыми работал я, этой гарантии было более чем достаточно.
Тут ещё такой момент, что Kafka имеет замечательный встроенный механизм ретеншена данных. Она может из коробки по времени или по размеру вашего топика удалять старые сегменты. Сегменты данных, которые были записаны, допустим, неделю назад, если вы ее так сконфигурировали. Это даёт вам гарантию, что сейчас внутри вашего кластера будут данные за прошедшую неделю, а более ранние Kafka автоматически из кластера выкинет. Чаще всего Kafka используется именно с таким паттерном, а не как бесконечная база данных.
Один из популярных паттернов — складывать результаты аналитической обработки в тот же самый Amazon S3, чтобы потом их можно было поднять другим каким-то компонентом.
Ещё один интересный момент — это поддержка infinite retention, то есть бесконечного ретеншена. Это значит, что вы сможете сконфигурировать Kafka таким образом, что вот те самые старые сегменты, которые выкидываются и просто удаляются с диска, вы можете сказать Kafka, что она должна их сложить в какой-то холодный object store (по большому счёту, это Tiered Storage). Интерпрайзный уже есть, но я им не пользовался, так что не буду говорить (open source должен появиться). Так что холодные сегменты, данные, которые вы уже не будете активно использовать, вы можете сложить в S3 и потом доставать раз в год, когда нужно перечитать весь лог. Так вы будете сохранять место на горячем диске и при этом не понадобиться задумываться о бэкапах и прочих дополнительных настройках.
АНАТОЛИЙ СОЛДАТОВ: Я полностью «за», и у меня есть несколько дополнений. Начну с Tiered Storage. Это крутая штука, которая изменит в целом конфигурацию машин по Kafka. Сейчас у нас есть какие-то заряженные железками, дисками машины, а можно будет просто какие-то маленькие (почти in memory) Kafka ставить, а все остальное складывать в Tiered Storage. Это как один из вариантов использования.
По поводу бэкапов у нас такой же подход. Kafka — это по умолчанию распределённая отказоустойчивая система, которая не должна терять данные, и она для этого практически всё делает. Угробить можно любую систему, конечно. Один из ключевых конфигов, которые нужно не забыть использовать это rack awareness, на мой взгляд. Даже если вы живете в одном дата-центре, попробуйте, если у вас есть контроль над серверами, хотя бы в разные стойки разнести брокеры, всем брокерам прописать, где они стоят (rack id). И Kafka будет следить, чтобы у вас все лидеры равномерно по этим рэкам распределились. Тогда вероятность проблем минимальная. При этом стоимость бэкапов Kafka высокая. Так что Kafka бэкапить-то можно, но будет это стоить дорого, а реального профита вы наверняка не получите.
И второй момент: у Kafka есть Zookeeper, как мы уже обсуждали, и это та система, которую, бэкапить можно. Она довольно недорогая. Мы бэкапим ее. Просто раз в неделю снимаем бэкапы, валидируем их довольно примитивно. Смотрим, что у брокеров id стоят, в Docker разворачиваем и считаем, что всё OK.
АЛЕКСАНДР МИРОНОВ: Мы тоже бэкапим Zookeeper, это важно.
АНАТОЛИЙ СОЛДАТОВ: Без Zookeeper Kafka теряет информацию о том, какие данные где лежат, как их получить. Даже если вся Kafka работает хорошо, а кластер Zookeeper по каким-то причинам отлетел, вам будет очень сложно восстановить данные. Есть всякие Kafka-дампы, которыми можно вытащить из конкретных топиков, которые вы знаете, где лежат, конкретные данные. Но это будет долго и скорее всего не восстановите весь кластер. Поэтому лучше Zookeeper-мозги где-то хранить.
АЛЕКСАНДР МИРОНОВ: При том что объём этих «мозгов» измеряется в Мб.
Там еще спрашивают в чате: учитывается ли rack id в min.insync.replicas? Я отвечу — нет. Просто смысл rack id, в том, что он используется Kafka в момент создания топика. Когда вы говорите, сколько у вас есть партиций в топике, и для каждой у вас будет n реплик. Вот этот rack id, Kafka вам гарантирует, что эти реплики партиций будут раскиданы по разным рэкам. Что она не положит их все в один рэк. После этого она и никакой rack id в своём рантайме не использует.
АНАТОЛИЙ СОЛДАТОВ: Не Kafka использует, а всякие админ-команды. Это будет влиять только на ребалансировки, когда вы будете партиции двигать по брокерам. Тогда да. Он опять заиграет, и Kafka будет смотреть на них так, чтобы лидеров или партиций перетащить так, чтобы они были во всех стойках были распределены правильно.
АЛЕКСАНДР МИРОНОВ: И если, например, вы зададите, что у вас два рэка, но при этом min.insync.replicas у вас там три, то по умолчанию команда создания топиков скажет вам, что не может создать топик, потому что не может раскидать партиции равномерно.
ИВАН СИДОРОВ: По опыту наших клиентов на поддержке могу сказать, что сейчас данные, хранимые в Kafka, не настолько дороги, чтобы делать бэкапы с них. Пока что в типовых случаях время жизни данных в Kafk довольно короткое. Тут правильная мысль про то, что реплики должны быть в разных дата-центрах. Но реплика — это кластер, и даже учитывая, что мастер-ноды там нет, они сами себе выбирают, с кластером что-то может пойти не так. Но сохранять данные очень дорого по соотношению стоимость данных/стоимость хранения данных, и самый эффективный вариант, который мы видели — это mirroring кластера. Чем отличается от реплики: поднимается точно такой же кластер и настраивается туда пересылка данных. Он просто работает как резерв и как бэкап.
АНАТОЛИЙ СОЛДАТОВ: Тут сразу два момента интересных — если несколько ДЦ, это не синоним того, что у нас несколько кластеров. И всегда, когда про Kafka читаешь, начинается с того, что «О! Stretch cluster, ужас какой, не используйте». Это всё неправда. На самом деле, нужно исходить из latency, которую ваша сеть дает, проверить хотя бы это, и скорее всего там stretch cluster заведётся, будет всё работать хорошо. Есть варианты с асинхронными кластерами, которые на основе репликаторов, но здесь тоже не стоит забывать, что это повышает сложность всей системы и то, что появляется еще одна точка отказа, и это не бесплатно. И начинать все-таки стоит с простого stretch cluster, который один, растянутый на несколько дата-центров. И часто он работает.
ИВАН СИДОРОВ: Добавлю ещё не про кластеры, а про mirroring кластера. Читал в вопросах, как разделять контуры безопасности, практический опыт — если есть интранет и экстранет, и в интранет пускать нельзя, а потоки данных идут из внешки, можно миррорить часть топиков из внешней Kafka во внутреннюю Kafka. Открыть только одну дырочку.
Для тех, кто хочет узнать больше о настройке и оптимизации Apache Kafka Слёрм готовит новый видеокурс. Спикеры — Анатолий Солдатов из Авито и Александр Миронов из Stripe. Доступ к первым урокам будет бесплатным. Оставить заявку на курс можно уже сейчас.
Автор: Polina_Averina
