Как построить систему, способную выдерживать нагрузку в 5 млн rps
Всем привет!
Меня зовут Владимир Олохтонов, я руковожу командой разработки в отделе Message Bus, который является частью платформы Ozon. Мы занимаемся разработкой самых разных систем вокруг Kafka, etcd и Vault. В этой статье я расскажу о том, как мы строили линейно масштабируемую gRPC-прокси перед Kafka, способную обслуживать миллионы запросов в секунду, используя Go.
Пруфы :)
У нас довольно крупный кластер. Он состоит из 75 брокеров, управляет 30 000 партиций, а рейт поднимается до 5 млн запросов в секунду. Так что задачка перед нами стояла нетривиальная.
Дисклеймер
Статья написана с расчётом на читателя, хотя бы поверхностно знакомого с Kafka и gRPC streaming. Если вы пока не можете про себя такое сказать, то вот несколько ссылочек для ознакомления:
Самые распространённые ошибки при работе с Kafka
Что такое gRPC за 10 минут
Chat Server — gRPC Bi-directional Streaming
Зачем вообще нужна такая прокси?
В Ozon, как и в множестве других крупных компаний, Kafka используется в качестве корпоративной шины данных — механизма, позволяющего с минимальными трудозатратами строить асинхронные связи между системами по паттерну Pub/Sub.
Разберём стандартную историю развития шины данных на базе Kafka в большой компании.
Первые связи строятся на основе ванильных open-source-библиотек — и это не так просто, как кажется, поскольку в дизайне Kafka используется подход с «умными библиотеками», содержащими десятки параметров, значения которых надо грамотно подбирать. Более того, они поддерживают только часть функциональности Kafka и содержат немало багов.
С ростом числа связей логичным следующим шагом становится выбор из всего многообразия библиотек нескольких наиболее стабильных и написание поверх них простых адаптеров с вдумчиво подобранными параметрами и стандартизированными метриками.
Затем возникает потребность в дополнительной функциональности, специфичной для компании. В случае Ozon это автоматическое получение списка брокеров от service discovery — Warden — и OAuth-авторизация.
Адаптеры становятся всё сложнее и сложнее, их используют сотни сервисов, что означает длинный хвост старых версий и много работы по их регулярному обновлению. Более того, на горизонте маячат дополнительные фичи — и наши адаптеры уже не выглядят такими уж приятными для поддержки.
Как известно, нет таких проблем в программировании, которые нельзя решить повышением уровня абстракции
