Как построить систему, способную выдерживать нагрузку в 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-авторизация.

Адаптеры становятся всё сложнее и сложнее, их используют сотни сервисов, что означает длинный хвост старых версий и много работы по их регулярному обновлению. Более того, на горизонте маячат дополнительные фичи — и наши адаптеры уже не выглядят такими уж приятными для поддержки.

Как известно, нет таких проблем в программировании, которые нельзя решить повышением уровня абстракции

Источник: https://habr.com/ru/companies/ozontech/articles/749328/


Интересные статьи

Интересные статьи

В ноябре прошлого года МойОфис представила корпоративную почту нового поколения Mailion, разработанную при грантовой поддержке РФРИТ. Это тиражируемое решение для крупных организаций, которое разв...
Телескоп «Евклид» вскоре начнёт изучать два миллиарда галактик. И это будет воистину технологическое чудо. Вселенную заполняет загадочная сила, известная под названием тёмной энергии. Она заставл...
Корпорация Microsoft на конференции для разработчиков Microsoft Build, которая прошла несколько дней назад, представила интересную новинку. Это модель обработки естественного языка G...
При разработке продуктов мы стараемся снизить количество решений, которые необходимо принимать пользователю. Предполагается, продукт используют для выполнения задачи, и ч...
Это всего лишь вопрос времени, когда мы построим то, что сможет перенести нас в далёкое будущее. В сентябре 2015 года космонавт Геннадий Падалка в последний раз вернулся на Землю. Он...