Как Roblox масштабировал свою платформу Kafka до более чем 18 триллионов сообщений в день

Сквозная оптимизация для эффективных систем

Авторы: Huizhi Lu, Julian Kudszus, Peter Yao, Jeffrey Zhong и Sen Li

Опубликовано 4 сентября 2026 г.

За последние два года мы масштабировали нашу внутреннюю платформу очередей сообщений более чем в 2,5 раза каждый год, достигнув более 18 триллионов сообщений в день. В настоящее время мы обрабатываем более 300 миллионов сообщений в секунду, сохраняя доступность 99,995%. Эта платформа очередей сообщений, построенная на Apache Kafka, стала критически важной частью того, как мы перемещаем данные по всей компании. Она поддерживает такие нагрузки, как события аналитики, конвейеры модерации, системы матчмейкинга и многие другие. Эти цифры впечатляют, но более важная история — как мы этого добились.

Влияние сквозной оптимизации

Распространенное заблуждение о крупномасштабных системах заключается в том, что производительность — это в основном проблема аппаратного обеспечения. По нашему опыту, наиболее значимые улучшения достигаются, если рассматривать масштабируемость как сквозную инженерную задачу.

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

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

Не весь трафик одинаков

Один из ключевых уроков, которые мы усвоили, заключается в том, что крупномасштабные платформы более надежны, когда они не относятся ко всему трафику одинаково. Некоторые нагрузки требуют очень низкой задержки и надежной защиты во время всплесков, например наши системы матчмейкинга, которые работают со сквозной задержкой менее 10 миллисекунд. Другие имеют чрезвычайно высокий объем, но более терпимы к задержкам, например наши конвейеры приема событий аналитики, которые могут работать без сбоев даже при сквозной задержке в несколько секунд. Если обрабатывать оба типа одинаково, трафик с самым высоким объемом может вытеснить более критичный для бизнеса трафик, особенно во время пиковых нагрузок.

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

Мы применяем этот подход оптимизации каждого кластера под обслуживаемые им варианты использования вплоть до аппаратного уровня.

Аппаратное обеспечение по-прежнему критически важно

Мы начали с запуска Kafka на машинах с RAID10 и HDD. По мере роста объема трафика пропускная способность дискового ввода-вывода наших машин стала основным узким местом, ограничивающим пропускную способность Kafka на сервер. Чтобы решить эту проблему, мы сделали две оптимизации. Мы перевели брокеры на использование SSD, насколько это возможно, сместив узкое место с пропускной способности дискового ввода-вывода на пропускную способность сети или дисковое пространство (поскольку приобретенные нами SSD имели меньше дискового пространства). Это увеличило пропускную способность дискового ввода-вывода в 10 раз. Мы также начали переводить оставшиеся HDD с RAID10 на RAID0. Это примерно удвоило пропускную способность дискового ввода-вывода, поскольку при RAID0 каждая запись требует только одной записи на диск, а не двух.

Компромисс заключается в том, что поскольку каждая реплика сообщения записывается на один диск на брокер вместо двух, переход с RAID10 на RAID0 может нести риск для надежности. Чтобы сохранить надежность, мы работали с важными вариантами использования над увеличением acks и репликации данных, включая репликацию в несколько регионов.

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

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

Создание для надежности

Платформа очередей является критически важным компонентом инфраструктуры Roblox, и поддержание надежности имеет решающее значение. Предварительное тестирование перед запуском, а также постоянное тестирование сценариев отказов (иногда называемое учениями game day) сыграли важную роль в подтверждении того, что наша инфраструктура устойчива к таким режимам отказов, как отказ отдельного хоста, отказ стойки, проблемы с сетью и многие другие. Внутренняя платформа хаос-тестирования нашей команды надежности позволила и упростила процесс моделирования различных сценариев отказов. Эти тесты помогают выявлять улучшения или регрессии системы и развивать операционное мастерство, регулярно проверяя оповещения и гарантируя, что операторы знакомы с шагами по обработке различных проблем, даже редких.

Мы также разработали и внедрили процессы переключения при сбоях (failover), которые позволяют быстро восстановить функциональность очереди для зависимых вариантов использования. Даже в случае полного отказа отдельного кластера мы можем переключить клиентов на исправный кластер с достаточной емкостью. Чтобы гарантировать наличие достаточного неиспользуемого резерва мощности, мы поддерживаем резервный кластер Kafka. Это помогает устранить любой риск проблем с «шумными соседями» при переносе трафика между рабочими кластерами.

На приведенной ниже диаграмме показаны основные шаги выполнения переключения при сбое. Сначала оператор определяет область переключения. Затем на резервном кластере создаются топики и списки контроля доступа (ACL) с помощью автоматизированной массовой операции. Наконец, оператор обновляет конфигурации сервисов плоскости управления, которые клиенты опрашивают, чтобы определить, требуется ли переподключение. Иллюстрация ниже предназначена для общих сценариев использования в реальном времени. У нас есть дополнительные стратегии и инструменты для других вариантов использования и сценариев, включая зеркалирование топиков с помощью Mirror Maker 2, инструменты обратного заполнения данных и многое другое.

Roblox предъявляет строгие требования к безопасности, которая также является критически важной частью надежности. Мы внедрили стандартные функции безопасности, такие как шифрование при передаче (с помощью mTLS), шифрование при хранении (с помощью зашифрованного диска), требования к сроку хранения данных, а также аутентификацию и авторизацию с помощью принципалов Kafka и ACL. Мы также автоматически ротируем учетные данные наших пользователей для дальнейшего повышения безопасности.

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

Дальнейшие планы

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

Масштабирование Kafka — это не просто увеличение количества и размера кластеров. Это создание инженерной дисциплины, абстракций и операционной модели, которые позволяют Roblox продолжать наш путь к тому, чтобы ежедневно объединять миллиард людей с оптимизмом и вежливостью.

Благодарности: Спасибо Дэнни Юаню и Джорджу Ли за их значительный вклад в платформу очередей Roblox.