Настройка кластера Kafka для производственной среды - задача нетривиальная. Существует так много конфигураций, настроек и решений, которые необходимо принять, что довольно сложно разобраться во всех них сразу. Даже если вы изучите всю документацию confluent и прочитаете все доступное о лучших практиках, вы обязательно допустите ошибки и проведете дни, если не недели, размышляя о том, что идет не так и почему кластер так нестабилен.
Документация, предоставляемая confluent, действительно очень хороша и содержит все, что вам когда-либо понадобится для настройки кластера. Но иногда вы все же упускаете некоторые моменты и в итоге узнаете их трудным путем.
В этой статье я расскажу о некоторых ключевых моментах, о которых следует помнить при настройке кластера Kafka. Несколько вещей, которые мы упустили и с трудом исправили, а также некоторые другие моменты, которые, как мне кажется, может упустить каждый при первой настройке кластера.
Я предполагаю, что вы уже знаете основы Kafka и в целом понимаете, как настроить кластер с помощью Zookeeper и всего остального.
Настройка кластера Kafka
- Установите vm.swappiness на минимально возможное значение для вашего типа сервера как для брокеров Kafka, так и для серверов zookeeper.
Swappiness - это тенденция ядра Linux копировать содержимое оперативной памяти в swap. Для приложений, критичных к задержкам, таких как Kafka, очень важно, чтобы ненужная подкачка содержимого памяти не влияла на его производительность. - Увеличьте лимит файловых дескрипторов до очень высокого значения, вплоть до 100 000.
Kafka использует очень большое количество открытых файлов при взаимодействии с клиентами Kafka, а лимит по умолчанию на один процесс в большинстве дистрибутивов Linux очень низок. В зависимости от того, как вы запускаете процесс брокера Kafka, вам могут потребоваться различные способы увеличения этого лимита. У нас произошел сбой в работе брокера Kafka, поскольку установленный лимит не был применен к нашему процессу Kafka. Посмотрите эту тему, чтобы узнать причину. Лучше всего убедиться, что лимит действительно применяется к вашему процессу, выполнив следующие действия:12ps ax | grep [Имя процесса Kafka]cat /proc/{{process_id}}/limits | grep "Max open files" - Выделите не менее 32 ГБ оперативной памяти для брокеров Kafka.
Брокеры Kafka, возможно, не требуют много кучи, так как они очень эффективно используют память (максимум 5 ГБ), но они очень хорошо используют кэш страниц ядра Linux для хранения данных в оперативной памяти, вместо того, чтобы немедленно сбрасывать сообщения на диск. Поэтому обычно большая часть вашей оперативной памяти используется Kafka косвенно через страничный кэш ядра. Чтобы узнать, сколько оперативной памяти в настоящее время используется в качестве страничного кэша, проверьте столбец buffer/cache в отчете, выдаваемом командой free -m -h в вашем терминале. - Используйте несколько каталогов журналов данных, смонтированных на нескольких дисках.
Kafka позволяет распределять данные по нескольким каталогам. Разделы тем назначаются на каталоги журналов по круговой системе во время создания темы. Наличие нескольких каталогов журналов увеличивает параллелизм и обеспечивает лучшую пропускную способность. Кроме того, увеличьте значение свойства брокера num.recovery.threads.per.data.dir по крайней мере до количества каталогов данных для более быстрого выключения и запуска брокера. - Не используйте диски данных Kafka совместно с другими приложениями или файловой системой ОС.
В типичном развернутом кластере Kafka брокеры Kafka монтируются на несколько дисков st1 HDD с оптимизированной пропускной способностью. Эти диски специально оптимизированы для больших запросов ввода-вывода (не менее 1 Мб) и обычно очень плохо работают с большим количеством маленьких запросов ввода-вывода. Добавление журналов или любой другой файловой системы ОС негативно скажется на их производительности. Для таких операций лучше использовать SSD. - Сборка мусора, занимающая слишком много времени, может указывать на другие проблемы в кластере. Держите это под контролем.
GC занимает слишком много времени на брокерах Kafka, иногда до 20-25%. Это ужасно сказывается на производительности кластера, поскольку продюсеры не успевают передавать сообщения, а потребители сильно отставали даже при относительно низкой нагрузке. Поскольку это отставание увеличивается с увеличением GC. Брокер Kafka тратил слишком много времени на дисковый ввод-вывод, а максимальная пропускная способность, которую мы получали, составляла всего 400 Кбит/с на 40 Мбит/с диске st1. Многие запросы ввода-вывода становятся в очередь и тем самым перегружали приложение. - Тщательно выбирайте количество партиций.
Выбор количества разделов для тем Kafka имеет свои недостатки. Помимо моментов, рассмотренных в статье confluent, имейте в виду, что темы, которые могут быть объединены в приложении Kafka Streams, должны быть совместно разделены, что означает, что для корректной работы они должны иметь одинаковое количество разделов.
Заключение
Мы рассмотрели очень небольшой набор ключевых моментов, о которых следует помнить при создании кластера Kafka. Я уверен, что вы столкнетесь с множеством других странных проблем, которые заставят вас почесать голову так же, как это сделали мы. Надеюсь, эта статья поможет вам избежать некоторых из них.