Версия сайта для слабовидящих
Какие инфраструктурные компоненты самые дорогие в эксплуатации популярной платформы потоковой передачи сообщений и как снизить затраты на сетевые ресурсы и хранилища данных при использовании Apache Kafka.
TCO для Apache Kafka: что учитывать в расчете затрат
Поскольку Apache Kafka используется для интеграции информационных систем в режиме реального времени, она становится критически важным компонентом ИТ-архитектуры предприятия. Однако, внедрить и поддерживать эту масштабируемую, производительную и надежную платформу для поддержки событийно-ориентированных архитектур и микросервисов не так-то просто. Как и любая критически важная технология, Kafka требует соразмерных затрат времени и ресурсов. Помимо прямых затрат на инфраструктурное окружение и зарплату специалистов по сопровождению Kafka и других компонентов потоковой передачи данных, надо учитывать альтернативную стоимость. Это означает, что каждый час, потраченный на обновление кластера, перебалансировку разделов топика или устранение незапланированных простоев, равен часу, потерянному при работе над другими инженерными проектами, которые также важны для бизнеса.
Рассчитать значение метрики TCO (Total Cost Ownership) для Apache Kafka, разворачиваемой в корпоративном контуре, а не как SaaS, может оказаться сложной задачей, т.к. необходимо учесть много факторов. Помимо расчета затрат на вычислительные ресурсы и ресурсы хранения данных, необходимые для работы платформы, надо учитывать затраты на сетевые ресурсы, которые могут составить более 50% затрат на инфраструктуру. Также следует учитывать дополнительные элементы: балансировщики нагрузки, шлюзы NAT для безопасного доступа во внешнюю сеть, кластеры Kubernetes, средства мониторинга и пр. Эти компоненты могут увеличить затраты на инфраструктуру Kafka до 25%. Далее рассмотрим наиболее затратные инфраструктурные элементы: сетевые ресурсы и хранилища данных.
Затраты на сеть
Поскольку Kafka имеет высокую пропускную способность и низкую задержку, сетевые ресурсы потребляются очень активно. Особенно, если кластер Kafka распределен между несколькими зонами доступности в разных ЦОД по разным регионам. Впрочем, это типичный случай развертывания Kafka, которую не рекомендуется запускать в одной зоне доступности, чтобы избежать простоев из-за сбоя. Например, если кластер Kafka распределен на 3 зоны доступности для обеспечения доступности и отказоустойчивости, будут следующие источники трафика:
- Приложения-продюсеры, которые отправляют сообщения в кластер. Для балансировки нагрузки лидеры разделов надо разместить в трех зонах, поэтому продюсеры будут обращаться к лидеру в другой зоне доступности примерно в 60% случаев.
- Приложения-потребители, которые потребляют сообщения из Kafka. В сбалансированном кластере потребители будут читать из лидера раздела в другой зоне доступности также примерно в 60% случаев.
- Репликация раздела — если коэффициент репликации равен 3, что рекомендуется по умолчанию, ведущим разделам потребуется реплицировать сообщения на подписчики в двух других зонах доступности.
Это означает, что для каждого байта, входящего в одну зону доступности, несколько его копий отправляются в другие зоны. Поэтому по мере роста пропускной способности сетевые ресурсы начинают доминировать в расходах на инфраструктуру. Поэтому рекомендуется включить выборку подписчиков для потребителей (KIP-392), чтобы брокер мог выбирать наиболее предпочтительную реплику чтения для приложения-потребителя. Если читать сообщения от подписчика в той же зоне, а не от лидера в другой, сетевые затраты существенно снижаются, т.к. количество потребителей, считывающих данные не влияет на трафик. Это настраивается в файле server.properties, где конфигурация broker.rack указывает местоположение брокера как стойку или регион, в котором находится брокер:
replica.selector.class=org.apache.kafka.common.replica.RackAwareReplicaSelector broker.rack=<region>
На стороне приложения-потребителя надо установить конфигурацию client.rack как свойство клиента:
client.rack=<rack-ID>
Наконец, можно снизить коэффициент репликации для топиков с некритичными для бизнеса данными, чтобы оптимизировать сетевые затраты, связанные с репликацией разделов. Это также сократит расходы на хранилище данных, о которых мы поговорим далее.
Затраты на хранение данных
Для правильного расчета емкости хранилища данных нужно учитывать не только их объем, но и количество операций ввода/вывода в секунду (IOPS, Input/output Operations Per Second), а также и пропускную способность сети, что было рассмотрено выше. Чтобы оценить затраты на хранение, можно умножить скорость входящего трафика, коэффициент репликации и период хранения. Так можно приблизительно понять, какой объем хранилища потребуется кластеру Apache Kafka в любой момент времени. Впрочем, затраты на хранение можно снизить, используя многоуровневое хранилище (KIP-405), о котором мы писали здесь. Оно позволяет выгружать старые данные топиков в облачное объектное хранилище, например, Amazon S3. Этот уровень хранения дешевле и устраняет необходимость платить за репликацию разделов, включая сетевые затраты. Так можно снизить расходы на хранение более чем на 90% в зависимости от того, как данные распределяются между хранением на локальных дисках и объектным хранилищем. Кроме того, многоуровневое хранилище также может снизить затраты на вычисления в сценариях с длинным сроком хранения (высокое значение конфигурации retention), позволяя не увеличивать количество брокеров для увеличения емкости.
Стоит отметить, что использование томов на основе экземпляров при запуске Kafka в Kubernetes чревато проблемами с надежностью и потерей данных. Для обеспечения надежности и производительности рекомендуется выделить избыточное количество вычислительных ресурсов для защиты от неожиданных скачков пропускной способности. Ресурсы хранения данных также следует выделить избыточно, чтобы избежать нехватки дискового пространства.
На практике большая часть самоуправляемой инфраструктуры работает с очень низкой загрузкой (иногда менее 20%), но они все равно оплачиваются в облачном развертывании. Частично это обусловлено сложностью динамического масштабирования ресурсов в зависимости от текущей рабочей нагрузки без ущерба для пропускной способности и производительности задержек или риска простоя кластера. Поэтому для управления расходами на инфраструктуру нужна оптимизация использования вычислительных ресурсов и хранилища данных. Например, бессерверные кластеры позволяют автоматически масштабировать многоуровневое хранилище. Подробнее про варианты развертывания и управление кластерами Kafka мы говорили в этом материале.
Также для оптимизации оптимизации производительности брокера следует настроить автоматическую балансировку разделов топиков и клиентские квоты для поддержки нескольких клиентов. Подробнее про механизм квотирования в Apache Kafka мы писали здесь.
Однако инфраструктура — это не единственные затраты на эксплуатацию Kafka. Эксплуатация и сопровождение платформы потоковой передачи событий тоже довольно затраты: нужны администраторы и инженеры для настройки, управления и масштабирования кластеров. Также потребуются специалисты на разработку и сопровождение систем сквозной потоковой передачи данных по мере масштабирования Kafka. Об этих эксплуатационных расходах мы поговорим в следующей статье.
Освоить администрирование и эксплуатацию Apache Kafka для потоковой аналитики больших данных вам помогут специализированные курсы в нашем лицензированном учебном центре обучения и повышения квалификации для разработчиков, менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data в Москве:
- Apache Kafka для инженеров данных
- Администрирование кластера Kafka
- Администрирование Arenadata Streaming Kafka
Источники
