В этой статье я представляю исследование по сравнению сред для 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, чтобы сосредоточиться на конкретных показателях производительности. Я хотел протестировать различные комбинации , поэтому было важно минимизировать влияние сетевого подключения и производительности диска. Я сделал это, запустив контейнеры с tmpfs для хранения данных: [JVM] x [instance_type] x [architecture] x [cloud_provider] 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 мы поддерживали следующие основные поколения вычислительных ресурсов: : экземпляры m5a (где i1 представляет m5 с процессорами Intel) Семейство s1 : экземпляры m6a (где i2 представляет m6i с процессорами Intel) Семейство s2 : экземпляры стандарта GCP n2 с процессорами AMD Rome. Семейство sg1 Для процессоров Graviton мы поддерживаем: : экземпляры m6g (Гравитон 2) Семейство g1 : экземпляры m7g (Гравитон 3) Семейство g2 Кроме того, я тестировал экземпляры t2a на GCP в качестве альтернативы Graviton на Ampere Altra. Мы не предлагаем их нашим клиентам из-за ограниченной региональной поддержки AWS, но я включил их в тесты для сравнения производительности. Это может быть хорошим вариантом, если вы находитесь в одном из «правильных» регионов. Инструмент для тестирования производительности Для бенчмаркинга я разработал облегченный на основе . Этот инструмент эффективно насыщает Kafka, не становясь при этом узким местом. инструмент библиотеки franz-go и примера Хотя известна своей надежностью и популярностью, я избегал ее из-за потенциальных проблем с cgo. librdkafka Тест 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. Это исследование помогло уточнить нашу матрицу тестирования, определив наиболее эффективные среды и области для дальнейшей оптимизации. Мы постоянно работаем над этим: настраиваем и совершенствуем «под капотом», и я рад поделиться нашими знаниями с сообществом. Следите за обновлениями!
