💭 Иногда самые очевидные решения оказываются совсем не такими простыми, как кажутся на первый взгляд

Когда я работал в Яндексе и занимался развитием системы трейсинга, через нее проходило около 10-11 ГБ входящего трафика в секунду. Чтобы эффективно писать такой объем данных, мы батчевали спаны большими пачками - примерно по 60-70 тысяч штук и записывали их в ClickHouse. ClickHouse отлично работает с большими вставками, поэтому такой подход позволял эффективно использовать ресурсы и получать хорошую производительность.

Но была одна проблема.

Все эти батчи формировались в памяти коллекторов (пишущих сервисов). И если в неподходящий момент происходила авария, рестарт процесса или какая-то другая внештатная ситуация, часть данных могла потеряться.

На первый взгляд решение выглядит очевидным.

«Давайте поставим Kafka между коллекторами и ClickHouse».

Коллекторы будут писать данные в Kafka, Kafka обеспечит надежное хранение, а отдельные сервисы будут вычитывать сообщения большими пачками и записывать их в ClickHouse. Мы получим и надежность, и большие батчи для записи.

Красиво. Логично. Понятно.

Но когда мы начали считать ресурсы под такую схему, оказалось, что только для Kafka потребуется что-то около одной-двух тысяч CPU-ядер. Не говоря уже про память, диски, сеть и стоимость эксплуатации всего этого хозяйства. В этот момент становится понятно, что между фразой «давайте просто добавим Kafka» и реальной системой лежит огромная пропасть.

Именно поэтому мне всегда нравились инфраструктурные технологии. На презентациях все выглядит просто: поставили Kafka, подключили продюсеров и консюмеров - готово.

Но на практике вопросы обычно начинаются гораздо раньше:
• Нужна ли здесь вообще асинхронная обработка?
• Сколько ресурсов потребуется для эксплуатации такого решения?
• Какие дополнительные гарантии надежности даст Kafka именно в моей системе?

Часто оказывается, что самое сложное - не настроить Kafka, а понять, стоит ли ее использовать в конкретной задаче. Именно поэтому некоторое время назад мы решили сделать отдельный курс по Kafka для разработчиков.

Его ведет инженер с очень интересным опытом. С одной стороны, он несколько лет занимался построением и эксплуатацией стриминговых платформ в Райффайзен Банке и работал с крупными Kafka-инсталляциями на практике. С другой - сейчас он разрабатывает YDB Topics в Яндексе - систему, которая реализует Kafka API и выступает лог-брокером внутри экосистемы Yandex Cloud.

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

Если Kafka для вас пока остается чем-то вроде «черного ящика», который вроде работает, но не совсем понятно как устроен внутри, возможно, этот курс будет полезен.

Кто я | Навигация | Спасибо