Широкое использование технологий Apache-стека — очевидный тренд. И Kafka на острие популярности: нынче людей, знающих такой брокер сообщений, пожалуй, превосходит количество тех, кто привык рядом со словом Кафка видеть слово Франц.
Мы и сами активно используем эту технологию в наших проектах. Но ведь всегда интересно, а как оно получается у других? И вдвойне интересно, если это не просто пример из чьей-то практики, а целенаправленное тестирование технологии. Поэтому мы перевели свежую статью, в которой рассказывается о том, как Dropbox опытным путём искал границы возможностей и лимиты выносливости у Kafka. И нашёл что хотел.
Исследуем пределы пропускной способности Kafka в инфраструктуре Dropbox
Apache Kafka является популярным решением для распределенной потоковой передачи и поочерёдной обработки больших объемов данных. Она широко применяется в индустрии высоких технологий, и Dropbox не является исключением. Kafka играет важную роль в структуре данных многих наших критических распределенных систем — анализа данных, машинного обучения, мониторинга, поиска и потоковой обработки (Cape) (— и это только некоторые из них).
В Dropbox Kafka-кластеры управляются командой Jetstream, основной обязанностью которой является предоставление высокого качества услуг, связанных с Kafka. Понимание предела пропускной способности Kafka в рамках инфраструктуры Dropbox критически важно для принятия правильных решений о выделении ресурсов в различных случаях использования, и это было одной из приоритетных целей для команды. Недавно мы создали автоматизированную тестовую платформу для достижения этой цели. И в этой публикации мы хотели бы поделиться нашим методом и полученными выводами.
Тестовая платформа
На рисунке выше показаны параметры нашей тестовой платформы для данного исследования. Мы используем Spark для размещения клиентов Kafka, что позволяет нам производить и потреблять трафик в произвольном объёме. Мы создали три кластера Kafka разных размеров, чтобы тюнинг размера кластера сводился буквально к перенаправлению трафика в другую точку. В Kafka был создан топик для производства и потребления тестового трафика. Для простоты мы распределили трафик по всем брокерам равномерно. Для этого мы создали тестовый топик с количеством разделов, десятикратно превышающим количество брокеров. Каждый брокер ведёт ровно 10 разделов. Поскольку запись в раздел идёт последовательно, слишком малое количество разделов, выделяемое на одного брокера, может привести к конкурентной записи, что ограничивает пропускную способность. Наши эксперименты показали, что 10 — хорошее число, чтобы исключить затруднения «бутылочного горлышка», связанные с конкурентной записью.
В связи с распределённой природой нашей инфраструктуры наши клиенты находятся в различных регионах США. Учитывая, что наш тестовый трафик значительно ниже предела магистральных каналов Dropbox, можно с уверенностью предположить, что этот предел межрегионального трафика также применим и для местного трафика.
Что влияет на нагрузку?
Существует множество факторов, которые могут повлиять на нагрузку кластера Kafka: количество производителей, количество групп потребителей, первоначальные смещения (offset) потребителей, количество сообщений в секунду, размер каждого сообщения, количество задействованных топиков и разделов. И это лишь некоторые из них. Степень свободы настройки параметров высока. Таким образом, нам необходимо найти доминирующие факторы, чтобы понизить сложность тестирования до приемлемого уровня.
Мы изучили различные комбинации параметров, которые сочли подходящими. Мы пришли к неудивительному выводу, что доминирующими факторами, которые стоит брать во внимание, являются основные компоненты нагрузки: количество производимых сообщений в секунду (с/с) и количество байт на сообщение (б/с).
Модель трафика
Мы приняли формальный подход к пониманию ограничений Kafka. Для конкретного кластера Kafka есть связанное пространство трафика. Каждая точка в этом многомерном пространстве соответствует уникальному состоянию трафика, применимого к Kafka и представленного в виде вектора параметров: <с/с, б/с, #производители, #группы потребителей, #топики, …>. Все состояния трафика, не приводящие к перегрузке KafKa, образуют замкнутое подпространство, чья поверхность будет ограничивать кластер Kafka.
Для нашего первого теста мы выбрали с/с и б/с в качестве основных параметров и свели пространство трафика к двухмерной плоскости. Границы допустимого трафика формируют чёткие области отслеживания. Обнаружение лимита Kafka в нашем случае равнозначно определению пограничных значений данной области.
Автоматизация тестирования
Для того чтобы установить границы с достаточной точностью, требовалось провести сотни тестов с различными параметрами — что было бы крайне нерационально делать вручную. Поэтому мы разработали алгоритм, позволяющий выполнить все эксперименты без вмешательства человека.
Показатель перегрузки
Очень важно найти набор показателей, который позволяет программным путем оценивать состояние Kafka. Мы исследовали широкий спектр возможных показателей и остановились на следующей небольшой выборке:
- простой потока ввода-вывода ниже 20%: это означает, что пул рабочих потоков, используемых Kafka для обработки клиентских запросов, слишком нагружен и не справляется с поступающими задачами.
- изменение набора синхронизированных реплик (ISR) более чем на 50%: это означает, что при использовании трафика в течение 50% наблюдаемого времени по крайней мере один брокер не успевает дублировать данные, получаемые от своего лидера.
Эти же показатели используются в Jetstream для мониторинга состояния Kafka и служат первыми тревожными сигналами перегрузки кластера.
Найти границы
Для определения одного пограничного значения мы фиксируем показатели б/с, а затем изменяем показатели с/с, чтобы подвести Kafka к перегрузке. Определить пограничное значение с/с можно тогда, когда мы знаем безопасное значение с/с и близкое к нему, но уже вызывающее перегрузку. Из этих двух безопасное значение с/с берётся как пограничное. Как показано ниже, линия пограничных значений формируется по результатам схожих тестов с разными показателями б/с:
Стоит отметить, что вместо того, чтобы напрямую регулировать с/с, мы экспериментировали с разным числом производителей, имеющих одинаковую скорость производства, обозначаемую np. Все дело в том, что пакетная обработка сообщений усложняет контроль за скоростью производства отдельного производителя. А изменение числа производителей, напротив, позволяет линейно изменять трафик. По данным наших ранних исследований простое увеличение числа производителей не создаст заметной разницы в нагрузке на Kafka.
Для начала мы находим отдельное пограничное значение с помощью бинарного поиска. Поиск начинается с очень большого диапазона np [0, max], где max — это значение, которое обязательно приведет к перегрузке. В каждой итерации для создания трафика выбирается среднее значение. Если Kafka перегружена при этом значении, тогда это среднее значение становится новой верхней границей; в противном случае она становится новой нижней границей. Процесс поиска останавливается, когда диапазон достаточно сужается. Затем мы рассматриваем показатели с/с, соотносящиеся с установленной нижней границей пограничных значений.
Результат
Как видно на вышеприведённой схеме, мы установили пограничные значения для Kafka разных размеров. Опираясь на полученные результаты, мы пришли к выводу, что максимально возможная пропускная способность инфраструктуры Dropbox равна 60 Мб/с на брокера.
Следует подчеркнуть, что это консервативный предел, так как содержание наших тестовых сообщений было максимально рандомизированным ради сокращения эффекта внутреннего сжатия сообщений в Kafka. Когда трафик достигает своего предела, и диск, и сеть используются в полной мере. В рабочих сценариях сообщения Kafka обычно соответствует определённому образцу, так как они часто формируются схожими алгоритмами. Это даёт значительные возможности для оптимизации сжатия сообщений. Мы протестировали экстремальный вариант развития событий, когда сообщения состоят из одного символа, и зафиксировали гораздо более высокую пропускную способность, так как диск и сеть перестали быть узким местом.
Кроме того, данные показатели пропускной способности верны, если есть как минимум 5 групп потребителей, подписавшихся на тестируемый топик. Другими словами, указанная записывающая пропускная способность достигается тогда, когда читающая пропускная способность в 5 раз больше. Когда число групп потребителей превышает 5, записывающая пропускная способность начинает снижаться, так как сеть становится бутылочным горлышком. Так как соотношение читающего и записывающего трафика гораздо меньше 5 в случаях использования производственных кластеров Dropbox, полученная пропускная способность распространяется на все производственные кластеры.
Данный результат поможет лучше планировать ресурсы для будущих Kafka. Например, если мы хотим разрешить до 20% всех брокеров работать оффлайн, то максимальная безопасная пропускная способность одного брокера должна быть 60 МБ/с * 0.8 ~= 50 Мб/сек. Это число впредь можно использовать для определения размера кластера, в зависимости от запланированной пропускной способности будущих случаев использования.
Инструменты для будущей работы
Платформа и автоматический тестер будут ценными инструментами для команды Jetstream в их дальнейшей работе. Когда мы переезжаем на новое железо, меняем конфигурацию сети или обновляем версию Kafka, мы можем просто повторно прогнать эти тесты и получить новые данные о допустимых пределах новой конфигурации. Мы можем применить ту же методологию для изучения других факторов, которые могут различными способами повлиять на производительность Kafka. Наконец, платформа может выступать в роли тестового стенда Jetstream для симуляции новых вариантов трафика или для воспроизведения проблем в изолированной среде.
Подводя итоги
В этой статье мы представили наш системный подход к пониманию ограничений Kafka. Важно отметить, что мы добились этих результатов на базе инфраструктуры Dropbox, так что наши числа могут быть неприменимы к другим установкам Kafka в связи с различием в аппаратных, программных и сетевых условиях. Мы надеемся, что представленная здесь методика сможет помочь читателям понять их собственные системы.
Автор: Сережа
