Николай Ижиков, главный эксперт по технологиям в команде по развитию баз данных в СберТехе, представил на форуме «Управление данными 2024» Platform V Corax — гибрид распределенной базы данных и брокера сообщений для работы с потоками данных в реальном времени, основаный на Apache Kafka. Это импортозамещенная Kafka с доработками команды — сейчас их в продукте более 50. Помимо этого, разработчики регулярно отдают в комьюнити свои фиксы — 70+ уже закоммитили в ванильную Kafka.
Одна из свежих доработок увеличила производительность Kafka более чем в полтора раза в различных сценариях. Ее сделали разработчики Platform V Corax — Антон Виноградов и Иван Дащинский.
Вкратце: когда вы шифруете данные, производительность падает. Команда продукта сделала модуль интеграции с kTLS, который в режиме с шифрованием в полтора раза ускоряет чтение и снижает нагрузку на CPU.
Эта статья — текстовая версия доклада Николая Ижикова о том, как все устроено.
Разберемся, из чего состоит наша Kafka:
- kTLS — ключевой модуль, как раз-таки он и позволяет ускорить Kafka. Ему посвящена эта статья, но есть и другие компоненты.
- Schema Registry (SR) — реестр схем. Это приложение для управления и валидации схем сообщений в топиках. А также для сериализации и десериализации записей. У нас есть своя имплементация, совместимая с Confluent SR.
- UI, интегрированный со Schema Registry и всеми другими компонентами.
- Дополнительные метрики. Например, consumer lag — время между записью и чтением сообщений в разрезе consumer group. У Kafka нет такой метрики из коробки, ее надо считать отдельно, а у нас она есть.
- Cluster auto rebalance tools — инструменты для автоматической балансировки кластеров.
- Ansible role — скрипты развертывания. Есть из коробки.
- Функционал для безопасности. Сбер скрупулезно относится к безопасности. В нашем продукте пользователи разделены по ролям из коробки: прикладные пользователи, суперпользователи, администраторы. Есть защита от привилегированного пользователя. Думаю, что отдел безопасности любой крупной компании это должно устроить.
Почему Kafka быстрая?
В первую очередь высокую скорость дает подход zero copy (sendfile). В чем суть? Sendfile копирует данные из одного файлового дескриптора в другой без использования пространства пользователя — на уровне ядра.
Так как в Linux все является файлом, то из сети на диск можно писать без использования памяти в user space — это быстро.
Второй момент — последовательная запись. Kafka пишет в файл партиции последовательно. Даже на современных SSD-дисках это все еще быстрее, чем случайная запись.
Как выглядит чтение в Kafka? У вас есть consumer, который считывает то, что вы положили в Kafka.
Количество прочтений может быть таким же или большим, чем количество записей — данные читаются минимум один раз:
- consumer приходит с офсетом для чтения данных с диска;
- выполняется вызов ядра ОС — считываются данные с диска;
- после прочтения данные записываются в буфер сетевой карты без копирования в user space и отправляются потребителю.
Простое чтение в Kafka, когда нет шифрования и безопасность полностью выключена — это очень быстро. Ниже замеры нашим бенчмарком.
Приходит SSL и все ломает
Почему SSL все ломает? Реализация SSL в Java работает на уровне JVM, поэтому с включенным SSL чтение выглядит так:
- сonsumer приходит с офсетом для чтения данных с диска;
- выполняется вызов ядра ОС — считываются данные с диска;
- данные копируются в user space;
- выполняется шифрование;
- зашифрованные данные копируются в kernal space;
- записываются в буфер сетевой карты и отправляются потребителю.
Невооруженным глазом видно, что выполняется два копирования: kernal space -> user space и обратно. Это значительно снижает итоговую производительность.
kTLS to the rescue!
kTLS — это модуль внутри ядра Linux, который обеспечивает блочное шифрование на уровне ядра без перехода в пользовательское пространство. Java-приложения с ним не интегрированы, и Kafka тоже. Мы доработали ядро Kafka и сделали интеграцию с kTLS. Теперь чтение из топика выглядит так:
- consumer приходит с офсетом для чтения данных с диска;
- выполняется вызов ядра ОС — считываются данные с диска;
- kTLS выполняет шифрование в kernal space;
- данные записываются в буфер сетевой карты и отправляются потребителю.
Очевидно, что производительность ниже, чем без шифрования, но она на 62% выше по сравнению со сценарием, где используется SSL без kTLS.
Интересный момент. Чтобы проявился положительный эффект от нашего модуля, надо, чтобы вы упирались в возможности процессора. Если вы не упираетесь, то интеграция позволяет взять менее мощный процессор, соответственно, потратить меньше электричества и выгадать на стоимости решения. Особенно это полезно, если у вас много Кафки в проде.
Еще одно преимущество — вы ничего не меняете на своих прикладных приложениях. Все, что надо сделать для ускорения — включить модуль kTLS в ядре Linux и две настройки на уровне брокера, которые позволяют ему заработать.
Подытожу: мы провели большую работу с Kafka, собрали свой дистрибутив и добились ускорения операций чтения более чем в полтора раза в условиях, когда нужно использовать шифрование. Или можно на столько же снизить нагрузку на процессор.
Вы можете получить консультацию по Platform V Corax, взять тестовый дистрибутив или заказать техническую поддержку Apache Kafka — заполните для этого форму по ссылке.