Kafka в OpenAI.

Было: – Центральный канал для дата пайплайнов и транзакционной нагрузки – 37 кластеров с различными конфигурациями под разные нужды – Каждый кластер – единая точка отказа в случае аутеджа – Сложность подключения нового сервиса. В каком кластере нужный топик? Как получить сетевой доступ к нужному кластеру? Какие креды для него? – Кластеры перегружены большим количеством соединений

Цель – отделить (decoupling) консьюмеров и продюсеров от кластеров Kafka. Решение: – Балансировщик для продьюсеров (прокси Prism). – Балансировщик для консьюмеров (uForwarder от Uber). – Кластеры Kafka объединяются в группы. Все кластеры в группе содержат одни и те же Kafka топики (каждый топик принадлежит одной группе кластеров). – Создан Control Plane для управления кластером кластеров Kafka.

➕Более эффективное масштабирование ➕Повышенная надежность ➕Значительное упрощение разработки и поддержки продюсеров и консьюмеров ➕Свобода менять инфраструктуру Kafka без зависимостей на пользователей ➖Проблемы с partitioning ➖Нет сохранения порядка событий ➖Нет exactly-once обработки событий Каждый минус можно порешать на уровне обходных решений за пределами их Kafka платформы.

Стало: – 6 груп кластеров – zero downtime миграция на новое решение – 99.999% доступность у новой платформы Kafka. – Kafka больше не единая точка отказа. Инфраструктура испытывала аутедж целых регинов с нулевым эффектом на продьюсеров и минимальным эффектом на консьюмеров – за время миграции использование Kafka внутри OpenAI выросло в 10 раз, пропускная способность выросла в 20 раз.

Графики и технические детали доступны на Boosty.