Comments 14
Если кто-то уже экспериментировал с diskless-топиками (или Tiered Storage), расскажите, как ощущения? Интересно посмотреть на реальный опыт.
Во мне что-то завопило "астанавитесь!"
Всем привет. Я один из разработчиков KIPа, готов ответить на вопросы.
Привет! Спасибо большое, что заглянули в обсуждение! Если будет возможность, хотел бы уточнить пару моментов:
Через сколько версий, по вашему мнению, diskless-топики будут готовы к стабильному продакшену?
Какие юзкейсы лучше всего подходят под такую архитектуру? Где бы вы не советовали её использовать?
Какие сейчас наблюдаются средние задержки доставки сообщений на прототипах?
Какой объём событий рассчитан на Batch Coordinator? Можно ли его будет горизонтально масштабировать?
Заранее спасибо за ответы! Даже если не на всё сразу, всё равно очень ценно услышать ваше мнение.
Через сколько версий, по вашему мнению, diskless-топики будут готовы к стабильному продакшену?
Сложно сказать. У tiered storage заняло 5,5 лет от публикации KIP до general availability. Большая часть времени прошла в обсуждениях дизайна. Надеюсь, у diskless года 3 займет :)
Какие юзкейсы лучше всего подходят под такую архитектуру? Где бы вы не советовали её использовать?
Все, где допустимы producer-consumer latency в, скажем, 1 секунду (p99). Т.е. почти все, кроме риалтайм аналитики/рекомендаций/рекламы и того, где на Кафку завязан интерактив с пользователем.
Какие сейчас наблюдаются средние задержки доставки сообщений на прототипах?
Не буду пока говорить, чтобы цифры из этих ранних прототипов не остались потом в истории Гугла на годы :)
Обработка Produce-запроса состоит из трех частей:
Буферизация на брокере.
Загрузка буфера в хранилище.
Коммит.
1 конфигурируется пользователем. По дефолту будет 250 мс. При большом входящем трафике должно заполняться быстрее (там еще лимит по размеру буфера, 8 МБ по дефолту).
2 зависит от хранилища. Обычный S3 даст миллисекунд 200-300. S3 Express One Zone должен быть быстрее (мы еще не замеряли).
3 -- самое интересное и зависит от имплементации batch coordinator'а. Там маленькие транзакции и будет реалистично побороться за low two digits.
Какой объём событий рассчитан на Batch Coordinator?
Batch Coordinator будет сделан в виде плагинов, поэтому будет зависеть от имплементации. Мы ожидаем около 100 байт метаданных на один батч данных + оптимизации, до которых еще не дошла очередь + всякие трюки по снижению количества батчей, которые хранятся долгосрочно. 1 триллион батчей должен потребовать около 100 ГБ метаданных. По современным меркам это можно хранить и запрашивать много в чем.
Можно ли его будет горизонтально масштабировать?
Та имплементация, что мы предлагаем в KIP-1164, сделана на топиках самой Кафки. Можно будет масштабировать, увеличивая количество партиций в топике с метаданными и разнося их лидеров по разным узлам.
Иван, спасибо огромное за столь развернутые ответы! 🙌
Чисто из любопытства: если бы вдруг можно было полностью убрать партиции и лидеров, построив Kafka чисто на S3 – насколько сильно это изменило бы архитектуру?
Давайте пофантазируем.
Начем с одного единственного брокера. Тут все просто: мы можем писать на S3 что угодно в любом удобном формате. Тут одна проблема, которая проходит красной нитью через всю эту историю: писать множество маленьких файлов дорого (PUT-запросы не бесплаты). Поэтому тут мы тоже придем в каком-то виде к буферизации на брокере, как в Diskless.
Если у нас появляются несколько брокеров, то ситуация усложняется: нам неизбежно в том или ином виде нужен sequencer, т.е. компонент, который будет так или иначе задавать порядок для батчей в партиции.
В S3 не так давно появились conditional writes, т.е. CAS. На этом можно сделать счетчик оффсетов: брокер бронирует оффсет для батча и загружает батч на S3 под именем, включающим этот оффсет. Помимо того, что это неприлично дорого (буферизацию мы сделать не можем), появляется возможность "дырок" в оффсетах (брокер "взял" оффсет и упал). В принципе, в Кафке нигде явно не сказано, что оффсеты идут строго последовательно без дырок (и compacted топики и транзакции это нарушают), так что это терпимо.
Становистя сложнее, если нам нужно сделать compacted топики. Для этого нужно переписывать уже загруженные файлы, причем атомарно. Нужны транзакции на файлах в каком-то виде. В принципе, "we can solve any problem by introducing an extra level of indirection": добавляем некую структуру метаданных сверху над файлами и на ней сможем сделать транзакции. Например, описывать множества файлов в мета-файлах и подменять метафайлы, если нужно сделать атомарную операцию на нескольких файлах. Так примерно работает Apache Iceberg.
Развесистая структура метаданных может позволить сохранить буферизацию. Например, брокер загружает файл с кучей данных для разных партиций, а потом пытается с помощью optimistic locking (т.е. того же CAS) вставить батчи в соответствующие партиции. Это уже в целом похоже на Diskless, где вместо базы или топика под batch coordinator'ом -- сам S3.
Можно посмотреть с другого конца: оставить лидеров партиций и использовать CAS не для счетчика оффсетов и не для атомарной замены метаданных партиции, а для выбора лидера. Будет работать примерно как лок: брокер берет лок на партицию (т.е. становится ее лидером) и дальше steady режим похож на обычную Кафку. Но немного непонятно как делать fencing: что, если брокер думает, что он все еще лидер, а он уже нет? Тогда случится split brain. Наверное, можно придумать, как сделать fencing также используя дополнительную структуру с мета-файлами (например, увеличивать версию корня, когда меняется лидер, т.е. добавить leader epoch). С похожей проблемой мы столкнулись в tiered storage (что, если два брокера загрузят один и тот же сегмент), но там вышло проще, потому что все же есть нормальные удобные метаданные в самой Кафке.
В общем, в S3 есть strong read-after-write consistency и CAS, а это универсальный примитив для разных алгоритмов синхронизации и транзакций. Быстро и дешево не будет, но можно сделать что угодно :)
Иван, спасибо за столь подробный разгон по гипотетике!
Полностью поддерживаю мысль про стоимость PUT-запросов в S3 – реальная бомба под бюджет. Даже на средней нагрузке куча мелких файлов может вынести счёт за облако в стратосферу, в прямом и переносном смысле.
По ощущениям, без какой-то умной буферизации/агрегации батчей жить будет нереально – либо это будут сотни тысяч $$ за месяц только на storage API calls.
Кстати, а есть ли у вас мысли, можно ли как-то ещё "смягчить" эту проблему, кроме классической буферизации? (например, более агрессивная упаковка батчей, или какие-то спец-режимы загрузки?)
Ещё раз огромное спасибо за такое подробное роазъяснение!
Кстати, а есть ли у вас мысли, можно ли как-то ещё "смягчить" эту проблему, кроме классической буферизации? (например, более агрессивная упаковка батчей, или какие-то спец-режимы загрузки?)
S3 Express One Zone сократит затраты на PUT-запросы в 5 раз, но это не 500 как хотелось бы. А так больше идей нет... если пойти дальше по этому спектру, мы придем к tiered storage: по сути это создание больших буферов, за которые мы расплачиваемся межзонным трафиком (т.е., репликацией)
@Ivanhoeа вы в на Current в UK не собираетесь? Был бы рад пообщаться.
Kafka без дисков: плюсы и минусы KIP‑1150 (Diskless Topics)