Сравнительный анализ Apache Kafka: соотношение производительности и цены

В этой статье я представляю исследование по сравнению сред для Apache Kafka. Конечная цель — найти наиболее эффективную настройку и достичь наилучшего соотношения цены и качества.

Наша платформа данных предоставляет управляемые услуги по созданию аналитических платформ для больших наборов данных, конкурирующих с другими рыночными решениями. Чтобы оставаться конкурентоспособными, мы регулярно проводим внутренние исследования, чтобы выявить и улучшить наши сильные стороны, обеспечивая более выгодные сделки. В этой статье представлено одно из таких исследований. В настоящее время наша платформа поддерживает AWS и GCP в качестве поставщиков облачных услуг. Оба предлагают несколько поколений вычислений и две архитектуры ЦП (x86 с Intel и AMD и ARM). Я сравниваю эти настройки с использованием различных виртуальных машин Java (JVM), чтобы оценить производительность новых версий на новых процессорах.

Если вам нужен TL;DR: ARM великолепен. Современная дорогая архитектура не всегда означает «лучше». Вы можете сразу перейти к результатам или перейти к более подробной информации о методологии и настройке.

Методология

Я рассматривал возможность тестирования производительности с помощью нашего собственного сервиса, но хотел сравнить ее в различных средах, которые мы еще не поддерживали. Я хотел проверить новые виртуальные машины, регионы и даже других поставщиков облачных услуг. Итак, я начал с реализации игрушечного проекта, который использует базовый Kafka с различными базовыми образами контейнеров. Таким образом, я могу запускать тестовые инструменты на конкретном оборудовании и измерять производительность.

Я стремлюсь протестировать различные конфигурации, чтобы выявить наиболее интересные результаты. Для этого я использую идею матрицы тестирования для фильтрации первоначальных результатов. Я подробно проанализирую эти результаты, используя такие инструменты, как perf и eBPF, для дальнейшего повышения производительности.

Тестовые случаи

Давайте сначала опишем цели тестирования. У меня большой опыт работы с JVM OpenJDK, но сегодня существует множество альтернатив от Microsoft, Amazon и других компаний. Например, Amazon Correto включает дополнительные функции и исправления, оптимизированные для AWS. Поскольку большинство наших клиентов используют AWS, я хотел включить в тесты Amazon Correto, чтобы увидеть, как эти JVM работают на этой платформе.

Для первого сравнения я выбрал эти версии:

• OpenJDK 11 (для ретроспективного сравнения, хотя он и устарел)
• OpenJDK 17 (используемая в настоящее время JVM)
• Amazon Coretto 11.0.22-amzn (альтернативное ретроспективное сравнение)
• Amazon Coretto 17.0.10-amzn (альтернатива нашей текущей версии)
• Amazon Coretto 21.0.2-amzn (новая версия LTS, которая должна быть лучше)

После того как версии были определены, я подготовил несколько скриптов для создания образов Kafka с использованием Amazon Correto и OpenJDK .

Настройки изображения

Для тестов производительности я изменил настройки Kafka, чтобы сосредоточиться на конкретных показателях производительности. Я хотел протестировать различные комбинации [JVM] x [instance_type] x [architecture] x [cloud_provider] , поэтому было важно минимизировать влияние сетевого подключения и производительности диска. Я сделал это, запустив контейнеры с tmpfs для хранения данных:

 podman run -ti \ --network=host \ --mount type=tmpfs,destination=/tmp \ kfbench:3.6.1-21.0.2-amzn-arm64

Естественно, эта установка не предназначена для производства, но изолировать узкие места процессора и памяти было необходимо. Лучший способ — исключить из тестов влияние сети и диска. В противном случае эти факторы исказят результаты.

Я использовал инструмент тестирования на том же экземпляре, чтобы обеспечить минимальную задержку и более высокую воспроизводимость. Я также пробовал тесты без конфигураций хост-сети и с виртуальными сетями, изолированными cgroup, но это только добавляло ненужную задержку и увеличивало загрузку ЦП для пересылки пакетов.

Хотя tmpfs динамически распределяет память и может вызвать фрагментацию и задержку, для нашего теста этого было достаточно. Вместо этого я мог бы использовать виртуальный диск, который распределяет память статически и позволяет избежать этих проблем, но tmpfs было проще реализовать, и он все равно давал ту информацию, которую мы искали. Для наших целей это обеспечило правильный баланс.

Кроме того, я применил некоторые дополнительные настройки Kafka, чтобы чаще удалять данные из памяти:

 ############################# Benchmark Options ############################# # https://kafka.apache.org/documentation/#brokerconfigs_log.segment.bytes # Chaged from 1GB to 256MB to rotate files faster log.segment.bytes = 268435456 # https://kafka.apache.org/documentation/#brokerconfigs_log.retention.bytes # Changed from -1 (unlimited) to 1GB evict them because we run in tmpfs log.retention.bytes = 1073741824 # Changed from 5 minutes (300000ms) to delete outdated data faster log.retention.check.interval.ms=1000 # Evict all data after 15 seconds (default is -1 and log.retention.hours=168 which is ~7 days) log.retention.ms=15000 # https://kafka.apache.org/documentation/#brokerconfigs_log.segment.delete.delay.ms # Changed from 60 seconds delay to small value to prevent memory overflows log.segment.delete.delay.ms = 0

Вот краткий обзор изменений:

• Время хранения журнала установлено на 15 секунд для более быстрого удаления данных, а размер хранения журнала ограничен 1 ГБ для управления хранилищем в tmpfs. Размер сегмента журнала также изменен на 256 МБ для более быстрой ротации файлов.
• Интервал проверки хранения уменьшен до 1 секунды для быстрого удаления старых данных.
• Задержка удаления сегмента установлена на 0, чтобы предотвратить проблемы с памятью.

Эта конфигурация не подходит для промышленного использования, но она важна для наших тестов производительности, поскольку снижает влияние нерелевантных факторов.

Типы экземпляров

На момент написания этой статьи в DoubleCloud мы поддерживали следующие основные поколения вычислительных ресурсов:

• Семейство s1 : экземпляры m5a (где i1 представляет m5 с процессорами Intel)
• Семейство s2 : экземпляры m6a (где i2 представляет m6i с процессорами Intel)
• Семейство sg1 : экземпляры стандарта GCP n2 с процессорами AMD Rome.

Для процессоров Graviton мы поддерживаем:

• Семейство g1 : экземпляры m6g (Гравитон 2)
• Семейство g2 : экземпляры m7g (Гравитон 3)

Кроме того, я тестировал экземпляры t2a на GCP в качестве альтернативы Graviton на Ampere Altra. Мы не предлагаем их нашим клиентам из-за ограниченной региональной поддержки AWS, но я включил их в тесты для сравнения производительности. Это может быть хорошим вариантом, если вы находитесь в одном из «правильных» регионов.

Инструмент для тестирования производительности

Для бенчмаркинга я разработал облегченный инструмент на основе библиотеки franz-go и примера . Этот инструмент эффективно насыщает Kafka, не становясь при этом узким местом.

Хотя librdkafka известна своей надежностью и популярностью, я избегал ее из-за потенциальных проблем с cgo.

Тест

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

Поэтому в тестах использовались темы с одним разделом, чтобы полностью использовать возможности отдельных ядер.

Каждый тестовый пример включал два типа:

• Синхронное производство: ожидает подтверждения сообщения, идеально подходит для измерения сред с малой задержкой, где миллисекунды имеют значение, например, приложений реального времени.
• Асинхронное производство: буферизует сообщения и отправляет их пакетами, что типично для клиентов Kafka, которые балансируют потребности, близкие к реальному времени, с допустимой задержкой 10–100 мс.

Я использовал сообщения размером 8 КБ, что больше, чем среднестатистический клиентский запрос, чтобы полностью заполнить потоки тематических разделов.

Полученные результаты

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

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

Графики

На всех графиках я использую условные имена для экземпляров, такие же, как их провайдеры. Инстансы сортируются сначала по поставщикам облачных услуг (AWS, затем GCP), а затем по поколениям: от старых к новым.

Полные результаты, хотя и в необработанном виде, доступны в моей подробной таблице сравнительного анализа . Там вы можете найти больше данных, чем я привожу в этой статье, включая показатели задержки и пропускной способности, а также сравнительную производительность различных JVM.

Выводы AWS

Семейство s1: самая медленная производительность

Инстансы s1 «1-го поколения», основанные на поколении m5a с AMD EPYC 7571, выпущенные в третьем квартале 2019 года, являются нашим устаревшим вариантом. Они наименее эффективны и медленны среди наших вариантов во Франкфурте, их стоимость по требованию составляет примерно ~0,2080 евро/час. Переход на новое семейство s2 стоимостью ~0,2070 евро/час дает удвоенную эффективность практически за ту же цену. Мы рекомендуем клиентам перейти на эти более экономичные и производительные варианты, чтобы сократить время выполнения запросов и скорость приема данных для аналитических приложений.

Семейство g1: эффективность сравнима с s2

Семейство g1 основано на Graviton 2 и исторически имело хорошую ценность, но новое семейство s2 с процессорами AMD теперь соответствует уровню эффективности Apache Kafka. Несмотря на несколько меньшую пропускную способность и незначительное ценовое преимущество, семейство g1 сейчас считается устаревшим по сравнению с более новыми вариантами.

Семейство g2: высочайшая эффективность

Семейство g2 на базе Graviton 3 выделяется как наша лучшая рекомендация благодаря своей превосходной эффективности. В определенных сценариях он превосходит семейства s2 и i2 до 39 %, предлагая экономичное решение практически во всех регионах, что делает его идеальным для большинства случаев использования Apache Kafka. Учитывая типичную природу Kafka, связанную с вводом-выводом, оптимизация вычислительной эффективности имеет решающее значение для экономии затрат. Я заметил растущую тенденцию к внедрению архитектуры Arm64: почти половина наших кластеров уже использует эту новую технологию.

Тенденции эффективности x86_64

Тесты показывают, что каждый новый процессор AMD или Intel улучшает общую пропускную способность и задержку. Несмотря на это, прирост эффективности новых поколений m6 и m7 стабилизировался. Согласно нашим тестам, даже поколение m7, потенциально предлагая меньшую задержку в некоторых регионах, уступает по эффективности по сравнению с семейством g2.

Семейство m7a: лучшие показатели задержки

Семейство m7a превосходно работает в приложениях с низкой задержкой, превосходя Intel и предыдущие поколения AMD по пропускной способности и задержке. Хотя эта архитектура не является универсально доступной, она отражает прогресс AMD в повышении производительности. Если он доступен в вашем регионе, рассмотрите вариант m7a для получения превосходных результатов.

Выводы GCP

Сравнение эффективности с AWS

Инстансы GCP обычно имеют более низкую эффективность, чем их альтернативы AWS. Для меня это было большим открытием, поскольку клиенты обычно предпочитают GCP из-за его экономической эффективности в аналитических приложениях, что приводит к снижению счетов. В нашем семействе sg1 используется поколение стандарта n2, аналогичное семейству AWS s2. Однако моя попытка распространить это сравнение на другие типы инстансов была ограничена региональной доступностью, особенно для поколений c3 и n2.

Процессоры Arm Tau: экономичность

Экземпляры Arm, использующие процессоры GCP Tau, обеспечивают повышение эффективности на 5–7 % по сравнению с Graviton 2, что делает их разумным вариантом экономии средств, если они доступны в вашем регионе . Хотя поддержка GCP для экземпляров Arm ограничена четырьмя регионами, она обеспечивает производительность и эффективность, сравнимую с семейством g1.

Скидки за постоянное использование

Поскольку кластеры Apache Kafka постоянно используют виртуальную машину, использование скидок на устойчивое использование позволяет получить скидки до 20%. Это делает даже более старые вычислительные мощности, такие как Ampere Altra, конкурентоспособными с Graviton 3 с точки зрения эффективности. Однако прямое сравнение здесь затруднительно из-за дополнительных скидок AWS, которые также могут применяться.

Аналитика JVM

Я думал, что увижу значительное улучшение в новых версиях JVM на архитектуре ARM. Однако похоже, что openjdk-11 и corretto-11 уже достаточно оптимизированы для ARM. Поскольку для новых версий Kafka требуется Java 17 и выше, я перешел на Java 17, что привело к увеличению производительности примерно на 4–8 % в наших тестах.

Кроме того, 21.0.2-amzn кажется многообещающим, предлагая дополнительный прирост производительности на 10–20 % на новых типах инстансов.

Выводы

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

Использование ARM уже доказало свою эффективность, поскольку повышает производительность и экономическую эффективность как Managed Service для Apache Kafka, так и Managed Service для ClickHouse. Это исследование помогло уточнить нашу матрицу тестирования, определив наиболее эффективные среды и области для дальнейшей оптимизации. Мы постоянно работаем над этим: настраиваем и совершенствуем «под капотом», и я рад поделиться нашими знаниями с сообществом. Следите за обновлениями!