Спойлер: Redpanda в 10 раз быстрее и обеспечивает 6-кратную экономию относительно Kafka.

В сегодняшних экономических условиях расходы для всех являются ключевой темой. Совокупная стоимость владения (Total Cost of Ownership, TCO) должна быть основным фактором при оценке показателя возврата инвестиций (Return On Investment, ROI) от внедрения новой программной платформы.

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

Для данного сравнения мы определяем TCO как сочетание следующих компонентов:

• Инфраструктура: Затраты на вычислительные ресурсы и хранилище, в данном случае на платформе AWS (Amazon Web Services).

• Администрирование: Затраты на деплой, установку и поддержку кластеров.

В этой статье мы исследуем общие затраты на функционирование кластеров Apache Kafka® и Redpanda для потоковой передачи данных и пропускной способности в реальных условиях с использованием модели развертывания с собственным хостингом. Мы начнем с определения модели затрат, протестируем физические характеристики обеих систем с использованием репрезентативных конфигураций, включая аспекты безопасности и аварийное восстановление (Disaster Recovery, DR), и затем оценим их инфраструктурные, административные и общие затраты.

Давайте разберемся в этом.

Сравнение затрат на инфраструктуру

Определение пропускной способности при заданной задержке

Redpanda построена с учетом того, что программное обеспечение должно полноценно использовать аппаратные средства, на которых оно развернуто. Redpanda спроектирована для полной загрузки быстрых накопителей данных, таких как SSD или NVMe-устройства, а также на использование преимуществ многоядерных процессоров и компьютеров с большим объемом оперативной памяти. Это позволяет достичь максимальной производительности при обработке значительных объемов данных и запросов.

Мы провели более 200 часов тестов с малыми, средними и большими рабочими нагрузками, чтобы сформировать профиль производительности для Kafka и Redpanda.

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

Наши результаты из отчета бенчмарка производительности выявили следующее: 

1. Профили средней и P99+ сквозной задержки Redpanda остаются невероятно стабильными даже при высокой пропускной способности.

2. Kafka не смогла справиться с нагрузкой 500 МБ/с и выше (итоговая пропускная способность 1 ГБ/с) на трех узлах. Тесты не завершились с требуемой производительностью.

3. Нам приходилось неоднократно создавать более крупные кластеры Kafka, чтобы сохранить неизменными профили задержек, но даже в этом случае задержки P99.9 превышали 200 мс при размере кластера в 3 раза больше, чем у Redpanda.

4. При небольших рабочих нагрузках Redpanda на недорогих процессорах AWS Graviton (ARM) продемонстрировала незначительное преимущество в скорости работы, в то время как Kafka не смогла функционировать на них совсем. 

При разработке модели затрат нам потребовалось определить оптимальные размеры кластеров для Redpanda и Kafka, чтобы обеспечить сопоставимые характеристики производительности. Нашей целью было, чтобы 99,9% операций завершалось за время менее 20 миллисекунд (P99,9 задержка). Тесты производительности подсказали нам необходимые размеры кластеров. Чтобы обеспечить такую же задержку, как у Redpanda, в некоторых сценариях системе Kafka потребовалось значительно больше вычислительных ресурсов. При исходных характеристиках задержка в Kafka была значительно выше (в 20 раз) по сравнению с задержкой в Redpanda. Для уравнивания задержки и достижения сопоставимой производительности, нам потребовалось увеличить количество узлов (серверов) в кластере Kafka в три раза, по сравнению с Redpanda. 

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

Одним из главных преимуществ использования Redpanda является простота деплоя. Поскольку Redpanda развертывается как единый исполняемый файл без внешних зависимостей, нам не требуется никакой инфраструктуры для ZooKeeper или для реестра схем (Schema Registry, SR). Redpanda также включает в себя возможности автоматической балансировки разделов и лидеров, поэтому нет необходимости запускать Cruise Control (инструмент для управления и оптимизации кластера Apache Kafka).

В представленной модели затрат мы демонстрируем расходы на инфраструктуру для работы с Redpanda в следующих сценариях:

• Небольшая рабочая нагрузка: 50 МБ/сек.

• Средние и большие рабочие нагрузки: 500 МБ/сек и 1 ГБ/сек.

Для выполнения рабочей нагрузки, связанной с обработкой данных, нужно определенное количество брокеров. В случае Apache Kafka это серверы, которые выполняют обработку и управление потоками данных. Дополнительно, в среде Kafka, для определенных опций, таких как управление производительностью, хранение схем данных и обеспечение отказоустойчивости, также требуются дополнительные экземпляры (инстансы) и под них опять же нужны ресурсы. Например, для системы управления производительностью (Cruise Control), хранения схем данных (Schema Registry) (два узла для обеспечения высокой доступности), обеспечения стабильности (ZooKeeper) (три узла), чтобы обеспечить надежную работу этих компонентов. 

Итак, общее количество серверов (брокеров) включает не только те, которые обрабатывают непосредственно рабочую нагрузку, но и дополнительные серверы для обеспечения различного функцонала и качества обслуживания системы.

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

Небольшая рабочая нагрузка: 50 МБ/с

Для небольшой рабочей нагрузки в 50 МБ/с, мы заметили, что Redpanda и Kafka показывают схожий профиль производительности при работе на инстансах i3en.xlarge. Однако Redpanda смогла продемонстрировать прирост производительности по сравнению с Kafka на меньших экземплярах i3en.large.

При этом мы отметили, что не смогли полностью использовать машины i3en.large, просто потому, что нагрузка была недостаточно большой. Внедрив инстансы AWS Graviton (на базе архитектуры ARM), мы повысили производительность Redpanda при значительно меньших затратах. Как было подробно рассмотрено в блоге "Производительность Kafka по сравнению с Redpanda", Kafka не смогла работать на инстансах Graviton.

В таблице ниже приведено сравнение стоимости Kafka, работающей на i3en.xlarge, и Redpanda, работающей на инстансах is4gen.medium.

По сравнению с запуском Redpanda на инстансах AWS Graviton, Kafka обходится в 3–4 раза дороже! Производительность на инстансах i3en.large для Kafka оказалась не такой высокой, как на i3en.xlarge. Также она хуже, чем производительность Redpanda на том же оборудовании или на Graviton. Используя Redpanda для этой рабочей нагрузки, вы можете сэкономить до $12,969 в год.

Средние и большие рабочие нагрузки: 500 МБ/сек и 1 ГБ/сек

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

Чтобы хвостовая задержка (tail latency) была в пределах допустимого 3-х кратного отклонения от Redpanda для средних и больших рабочих нагрузок, нам потребовалось масштабировать Kafka до девяти узлов, что значительно повлияло на стоимость инфраструктуры.

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

Только по затратам на инфраструктуру можно ожидать экономии от $80,000 до $150,000 в зависимости от объема и масштаба рабочей нагрузки, что представляет собой существенную 3-кратную экономию по сравнению с Kafka.

Сравнение административных расходов

Redpanda спроектирована прежде всего с учетом удобства и простоты использования  (наряду с рекордной производительностью). Следующие характеристики Redpanda вносят значительный вклад в снижение административной нагрузки по сравнению с Kafka:

1. Aвтонастройка — Автоматически определяет оптимальные настройки для вашего оборудования и настраивает его таким образом, чтобы оно наилучшим образом использовало преимущества конкретного деплоя.

2. Балансировка лидерства — Повышает производительность кластера, распределяя лидерство среди узлов (и, более того, между ядер, чтобы одновременно несколько лидеров не перегружали определенные ядра). 

3. Непрерывное балансирование данных (новое в версии 22.2) — Автоматически перемещает данные с узлов, на которых не хватает дискового пространства или при отказе узла, чтобы обеспечить поддержание производительности всего кластера в целом.

4. Режим обслуживания — Позволяет плавно (контролируемая и пошаговая остановка) выводить узлы из эксплуатации, передавая лидерство на другие узлы перед отключением (для установки патчей или при обслуживании дисков).

5. Постепенное обновление — Обновление кластера без прерывания работы потребителей или производителей.

Кроме того, Redpanda спроектирована с учетом безопасности данных, как указано в отчете от Jepsen. Улучшенная безопасность данных значительно снижает операционные и управленческие нагрузки при работе с кластером Redpanda, что, в конечном итоге, сокращает общие затраты в этой области.

В отчете Jepsen подчеркиваются основные различия между Redpanda и Kafka, в частности, недостатки механизма ISR (In-Sync Replicas) Kafka, который обеспечивает надежность и согласованность данных в распределенной системе сообщений. Если ISR механизм не функционирует должным образом, это может привести к потере данных или небезопасному выбору нового лидера, что повлияет на надежность и непрерывность работы системы. Redpanda не имеет такой уязвимости, поэтому она гораздо стабильнее в сценариях отказа, в том числе благодаря наличию единого домена отказов (по сравнению с Kafka, где доменами отказов являются ISR и ZooKeeper/KRaft).

Чтобы провести ориентировочное сравнение стоимости Redpanda и Kafka, мы опирались на данные, полученные от наших клиентов. Поскольку Redpanda не нуждается в JVM и ZooKeeper, клиенты подтвердили, что им удается сэкономить время на балансировке разделов, настройке JVM, ZooKeeper и операционных систем, а также на восстановлении после сбоев, вызванных проблемами с ISR. 

Тем не менее мы сделали следующие предположения, основанные на непосредственных отзывах клиентов:

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

• Запуск 9-узлового кластера Kafka, а также трех узлов ZooKeeper при высокой пропускной способности намного сложнее, с высокой вероятностью наличия сбоев и потребностью ручного вмешательства на регулярной основе.

Site Reliability Engineering (SRE) — это методология и подход к управлению операционной надежностью и производительностью в информационных технологиях. SRE объединяет практики разработки программного обеспечения с методами системного администрирования для создания надежных, масштабируемых и устойчивых систем.

TCO Redpanda и Kafka

Даже при сравнительно небольших рабочих нагрузках использование Kafka может быть в 3 раза дороже, чем применение Redpanda. Для больших и сложных нагрузок этот показатель может вырасти 5-кратно и выше.

В модели консолидированных затрат мы объединяем затраты на размещение инфраструктуры основного кластера и на администрирование, как указано выше.

В этой модели мы не учитываем стоимость резервной DR-площадки (площадка восстановления после сбоя) и связанные с ней расходы по передаче данных. Хотя, справедливости ради, следует отметить, что затраты на инфраструктуру в таком случае увеличатся как минимум вдвое. Поскольку для хостинга кластера MirrorMaker2 на Kafka Connect потребуется дополнительные ресурсы. (Хотя для Redpanda Enterprise есть возможность использовать репликацию S3 - подробнее об этом см. в нашем блоге, посвященном схемам высокодоступного (HA) деплоя). 

Все вышеприведенные показатели стоимости сравнивают Kafka с версией Redpanda Community Edition. Согласно этой модели, возможная экономия на инфраструктуре и административных расходах может варьироваться от $76,000 при небольшой рабочей нагрузке до $552,000 для больших нагрузок, т.е. в 6 раз.

Оценка дополнительной экономии при использовании Redpanda Enterprise

Redpanda Enterprise включает в себя несколько фич, которые могут быть использованы для дополнительного снижения совокупной стоимости владения (TCO) кластером Redpanda, даже при сравнении с коммерческими предложениями Kafka. Среди них - Redpanda Console и возможность многоуровневого хранения данных (tiered-storage capability).

Многоуровневое хранение данных в Redpanda осуществляется за счет асинхронной публикации закрытых сегментов журнала в S3-совместимое хранилище объектов, такое как AWS S3, GCS, Ceph, MinIO или физическое устройство, типа Dell ECS, PureStorage или NetApp ONTAP. Многоуровневое хранилище Redpanda предоставляет две дополнительные фичи. Во-первых, это возможность для медленных потребителей беспрепятственно считывать старые оффсеты без изменений клиента и с высокой пропускной способностью. Во-вторых, - создавать темы только для чтения на других кластерах, которые можно использовать для аналитики, машинного обучения или аварийного восстановления.

Kafka также работает над многоуровневым хранением данных в рамках KIP-405; однако этот процесс пока не завершен и продолжается уже больше двух лет. Некоторые вендоры поддерживают собственные многоуровневые системы хранения данных; однако эти решения не предоставляют реплики только для чтения, а также возможности восстановления кластера в случае чрезвычайной ситуации (DR). Поэтому для использования Kafka в активной/пассивной DR-топологии потребуется дополнительный кластер Kafka Connect и MirrorMaker.

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

Поскольку хранение в S3 (Simple Storage Service) [S3 - управляемое облачное хранилище данных, предоставляемое Amazon Web Services] значительно дешевле, чем использование инстансов на основе SSD/NVMe, лучше всего применять многоуровневое хранение. Это позволит не только снизить затраты на облако или инфраструктуру, но и послужит для уменьшения эксплуатационных сложностей, связанных с запуском большого кластера Kafka, рассчитанного только на хранение данных.

В следующих таблицах приведено наглядное сравнение использования Redpanda Enterprise, коммерческого Kafka (включая многоуровневое хранение, с учетом описанных выше ограничений и того, что кластер Kafka в любом случае должен быть больше для обеспечения пропускной способности), а также Redpanda Community и Kafka без многоуровневого хранилища.

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

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

Мы видим, что экономия от корпоративной подписки может составлять от $70,000 до $1,200,000 и даже выше для больших рабочих нагрузок или с учетом требований по хранению данных. При этом не рассматривается косвенная экономия за счет фич корпоративной версии Redpanda Enterprise, таких как Redpanda Console с SSO и RBAC, удаленное чтение реплик, непрерывная балансировка данных и "горячее" исправление (hot-patching).

Заключение

В этой статье мы сравнили совокупную стоимость владения (TCO) при работе с Kafka и Redpanda на основе проведенных нами бенчмарков на публичной облачной инфраструктуре.

Наши основные результаты:

• Redpanda в 3-6 раз экономичнее, чем аналогичная инфраструктура и команда Kafka, и при этом обеспечивает более высокую производительность.

• Redpanda Enterprise предлагает ряд фич, призванных упростить управление кластерами. Многоуровневая система хранения данных Redpanda обеспечивает экономию на инфраструктуре в размере от $70,000 до $1,200,000 в зависимости от нагрузки и размера кластера.

Итог: Redpanda оказывается в 6 раз более эффективной с точки зрения экономии затрат на эксплуатацию по сравнению с Kafka. К тому же гибкие варианты развертывания Redpanda делают сам процесс деплоя простым и удобным. Вы можете развернуть Redpanda как в облачной инфраструктуре Redpanda, так и в собственной облачной среде или на своей локальной инфраструктуре, на физическом оборудовании, либо в среде Kubernetes.

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

Материал подготовлен в преддверии старта онлайн-курса "Highload Architect".