При всех достоинствах Apache Kafka, для этого популярного Big Data средства управления сообщениями характерны определенные трудности в обеспечении производительности. Сегодня мы поговорим про некоторые проблемы использования этого распределенного брокера сообщений в высоконагруженных системах. В качестве реального примера рассмотрим особенности практического использования Кафка в отечественном сервисе объявлений Авито.
Что такое высоконагруженная Big Data система
Прежде всего, определим, что такое высоконагруженная система (Highload) обработки больших данных (Big Data). Итак, Highload – это приложение с высокой нагрузкой, которая спровоцирована [1]:
- большим количеством одновременно работающих пользователей;
- большим объемом обрабатываемых данных;
- многочисленными сложными вычислениями.
Для высоконагруженных систем характерны быстрое время отклика, масштабируемость и модульность. Яркие примеры высоконагруженной Big Data системы – это сайты соцсетей, крупных интернет-магазинов и другие многопользовательские веб-сервисы с миллионной аудиторией. Таким образом, рассматриваемый в этой статье кейс компании Авито полностью соответствует критериям высоконагруженной системы.
Apache Kafka для централизации микросервисов: пример Авито
На практике Apache Kafka часто используется в качестве средства централизации при обмене данными между множеством распределенных микросервисов. Например, именно так это реализовано в Авито [2]. Такое применение Кафка при переходе от монолитного решения к гибкой микросервисной архитектуре принесло компании следующие положительные результаты [3]:
- простая интеграция;
- централизованное управление конфигурацией;
- абстрагирование от конкретных технологий;
- безопасная аутентификация;
- валидация событий.
Обратной стороной этих преимуществ стали следующие недостатки [3]:
- снижение производительности;
- необходимость поддержки;
- высокая цена ошибки при разработке.
Не вдаваясь в особенности процессов поддержки и разработки, далее мы рассмотрим, как именно была решена проблема снижения производительности Big Data системы.
Что такое производительность Highload-системы и как ее измерить
Вообще производительность Кафка, как и других Big Data систем, оценивается с помощью 2-х основных свойств [4]:
- пропускная способность — это максимальная скорость, с которой данные могут быть обработаны;
- задержка (latency) — это время на сохранение или получение данных.
В реальности DevOps-инженер ищет баланс между пропускной способностью, задержкой и стоимостью инфраструктуры приложения. При этом стоит учитывать требования к общей производительности Big Data системы. В рамках этой задачи можно выделить 3 наиболее распространенные ситуации [4]:
- высокая пропускная способность (порядка 1,5 Гбит/с) и низкая задержка (около 100 миллисекунд), например, при мониторинге за доступностью сервисов. Это наиболее сложный технический и дорогой с точки зрения финансов кейс. Однако, именно этот вариант чаще всего требуется для высоконагруженных систем.
- высокая пропускная способность и высокая задержка (не более 250 миллисекунд), например, прием данных телеметрии практически в реальном времени для обеспечения безопасности объектов и обнаружения вторжений.
- низкая пропускная способность и низкая задержка (менее 10 миллисекунд), к примеру, при онлайн-проверке орфографии и грамматики.
В рамках баланса двух разных показателей производительности, отметим один достаточно простой способ повышения пропускной способности Кафка – увеличение размера пакета для сообщений. Напомним, пакет – это группа сообщений от производителей (producers), которые отправляются как одно целое для хранения в едином разделе (partition). Изменение параметра batch.size (размер пакета) может повысить пропускную способность, уменьшив нагрузку на обработку запросов сети и операции ввода-вывода. Но при низкой нагрузке увеличенный размер пакета может увеличить задержку отправки Kafka, так как производитель ожидает готовности пакета [4]. На практике этот способ подходит только для тех Big Data систем, в которых не требуется сверхбыстрый отклик. Поэтому в Highload-сервисе Авито было найдено другое решение.
Администрирование кластера Kafka
Код курса
KAFKA
Ближайшая дата курса
9 декабря, 2024
Продолжительность
24 ак.часов
Стоимость обучения
72 000 руб.
Queue as a Service: как повысить производительность Кафка
Итак, в случае Авито была реализована концепция «очередь как сервис» (Queue as a Service, QaaS) [3], когда подписчики сервиса получают доступ к очередям и/или темам для обмена данными напрямую или через шаблоны публикации и подписки [5]. Такая модель повышает отказоустойчивость при сбоях отдельных приложений, поскольку в случае сбоя сообщение вернётся в очередь и его сможет прочитать другой обработчик, не влияя на работу отправителей. QaaS позволяет отправлять сообщения даже если получатель временно недоступен, что нередко происходит при высоких нагрузках на Big Data систему. Также, благодаря QaaS, можно вынести выполнение длительных задач в отдельные приложения, быстрее освободив ресурсы для новых запросов пользователей. Кроме того, данная концепция отлично поддерживает масштабируемость системы, поскольку отдельные модули можно менять независимо от других [6].
Обычно QaaS-платформы представляют собой готовое облачное решение от крупных провайдеров, например, Amazon Simple Queue Service, IBM MQ, Microsoft Azure Service Bus [5] или Yandex Message Queue [6]. Однако, подобную функциональность для собственной Big Data системы можно реализовать самостоятельно на Java, используя Confluent REST Proxy для кластера Kafka, как это было сделано в Авито [3]. Также возможно выполнить это в виде отдельного сервиса Queue-Over-Http, что облегчает балансировку системы, но несколько увеличивает задержку (latency) из-за особенностей http-протокола [7].
Впрочем, размер пакетов и QaaS-решение не избавят от других проблем Apache Kafka, связанных с очередью запросов, когда при многопоточной обработке необходим разный порядок считывания сообщений из разделов топика Кафка [8]. Почему возникает такая задача, как ее решить и при чем тут гарантии доставки сообщений, мы рассмотрим в следующей статье.
Apache Kafka для инженеров данных
Код курса
DEVKI
Ближайшая дата курса
20 января, 2025
Продолжительность
24 ак.часов
Стоимость обучения
72 000 руб.
Освоить все тонкости администрирования кластера Apache Kafka и особенности разработки распределенных приложений потоковой обработки событий вам поможет обучение Кафка на специализированных практических курсах в «Школе Больших Данных» — лицензированном учебном центре для разработчиков, менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data в Москве:
Источники
- http://hawkhouse.ru/blog/chem-standartnaya-arhitektura-otlichaetsya-ot-arhitektury-vysokonagruzhennyh-prilozhenij/
- https://habr.com/ru/company/avito/blog/465315/
- https://devopsconf.io/moscow/2019/abstracts/5582
- https://docs.microsoft.com/ru-ru/azure/hdinsight/kafka/apache-kafka-performance-tuning
- https://en.wikipedia.org/wiki/Message_queuing_service
- https://cloud.yandex.ru/services/message-queue
- https://habr.com/ru/post/435346/
- https://habr.com/ru/post/326880/
