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

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

Авторы: Хуижи Лу (Huizhi Lu), Джулиан Кудсус (Julian Kudszus), Питер Яо (Peter Yao), Джеффри Джонг (Jeffrey Zhong) и Сен Ли (Sen Li)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Создание с расчетом на надежность

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

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

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

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

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

Путь вперед

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

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

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