Хабрахабр

[Перевод] Исследуем пределы пропускной способности Kafka в инфраструктуре Dropbox

И Kafka на острие популярности: нынче людей, знающих такой брокер сообщений, пожалуй, превосходит количество тех, кто привык рядом со словом Кафка видеть слово Франц. Широкое использование технологий Apache-стека — очевидный тренд.

Но ведь всегда интересно, а как оно получается у других? Мы и сами активно используем эту технологию в наших проектах. Поэтому мы перевели свежую статью, в которой рассказывается о том, как Dropbox опытным путём искал границы возможностей и лимиты выносливости у Kafka. И вдвойне интересно, если это не просто пример из чьей-то практики, а целенаправленное тестирование технологии. Она широко применяется в индустрии высоких технологий, и Dropbox не является исключением. И нашёл что хотел.
Исследуем пределы пропускной способности Kafka в инфраструктуре Dropbox
Apache Kafka является популярным решением для распределенной потоковой передачи и поочерёдной обработки больших объемов данных. Kafka играет важную роль в структуре данных многих наших критических распределенных систем — анализа данных, машинного обучения, мониторинга, поиска и потоковой обработки (Cape) (— и это только некоторые из них).

Понимание предела пропускной способности Kafka в рамках инфраструктуры Dropbox критически важно для принятия правильных решений о выделении ресурсов в различных случаях использования, и это было одной из приоритетных целей для команды. В Dropbox Kafka-кластеры управляются командой Jetstream, основной обязанностью которой является предоставление высокого качества услуг, связанных с Kafka. И в этой публикации мы хотели бы поделиться нашим методом и полученными выводами. Недавно мы создали автоматизированную тестовую платформу для достижения этой цели.

Мы используем 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 перегружена при этом значении, тогда это среднее значение становится новой верхней границей; в противном случае она становится новой нижней границей. В каждой итерации для создания трафика выбирается среднее значение. Затем мы рассматриваем показатели с/с, соотносящиеся с установленной нижней границей пограничных значений. Процесс поиска останавливается, когда диапазон достаточно сужается.

Результат

Опираясь на полученные результаты, мы пришли к выводу, что максимально возможная пропускная способность инфраструктуры Dropbox равна 60 Мб/с на брокера. Как видно на вышеприведённой схеме, мы установили пограничные значения для Kafka разных размеров.

Когда трафик достигает своего предела, и диск, и сеть используются в полной мере. Следует подчеркнуть, что это консервативный предел, так как содержание наших тестовых сообщений было максимально рандомизированным ради сокращения эффекта внутреннего сжатия сообщений в Kafka. Это даёт значительные возможности для оптимизации сжатия сообщений. В рабочих сценариях сообщения Kafka обычно соответствует определённому образцу, так как они часто формируются схожими алгоритмами. Мы протестировали экстремальный вариант развития событий, когда сообщения состоят из одного символа, и зафиксировали гораздо более высокую пропускную способность, так как диск и сеть перестали быть узким местом.

Другими словами, указанная записывающая пропускная способность достигается тогда, когда читающая пропускная способность в 5 раз больше. Кроме того, данные показатели пропускной способности верны, если есть как минимум 5 групп потребителей, подписавшихся на тестируемый топик. Так как соотношение читающего и записывающего трафика гораздо меньше 5 в случаях использования производственных кластеров Dropbox, полученная пропускная способность распространяется на все производственные кластеры. Когда число групп потребителей превышает 5, записывающая пропускная способность начинает снижаться, так как сеть становится бутылочным горлышком.

Например, если мы хотим разрешить до 20% всех брокеров работать оффлайн, то максимальная безопасная пропускная способность одного брокера должна быть 60 МБ/с * 0. Данный результат поможет лучше планировать ресурсы для будущих Kafka. Это число впредь можно использовать для определения размера кластера, в зависимости от запланированной пропускной способности будущих случаев использования. 8 ~= 50 Мб/сек.

Инструменты для будущей работы

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

Подводя итоги

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

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть