Это короткая история наивного любителя популярных технологий.

Ранее я уже писал почему на моем текущем проекте мы решили использовать — Apache Kafka, если вкратце, то цель — унификация используемых технологий в компании.

Сфера деятельности компании это ставки на спорт, зона ответственности моей команды состоит в том, чтобы принять и оцифровать происходящее на игровом поле, будь то реальное поле з зеленой травкой или серый бетон виртуального CS:GO.

Очень важно чтобы данные инцидент произошедший в игре был передан дальше по системе и коэффициенты были пересчитаны быстрее чем потенциальный Беттер поставит очередную ставку на основании новых вводных. Например, забитый гол в лиге чемпионов на 90+ минуте основного времени.

Итак, вернемся к нашим баранам.

Думаю никому не секрет, что в больших компаниях используется практика использования нескольких типов языков программирования.

Там где можно сэкономить — экономят.

Наша компания не исключение. Для обеспечения организационной части бизнеса — СРМ и интерфейсов первичного ввода данных(интерфейс судьи/статиста) мы используем PHP, для того чтобы производить сложные вычисления, используются иные технологии.

Для обмена данными между системами, наиболее принятым способом, является применение очередей.

Что для “русского” - хорошо, для “немца” — смерть.

Адаптировав эту поговорку под ИТ можно сказать иначе:

Что для компилируемых ЯП — хорошо, для скриптовых — смерть.

Kafka славится тем что может принимать большое, очень большое, количество данных в секунду.

Но, есть маленький нюанс.

Для того чтобы Kafka могла принимать это самое большое количество сообщений, нужно установить соединение, а у такой сложной системы как Kafka это не самое простое действие.

В момент соединения система должна выбрать какой именно брокер будет использован, а также какой(-ие) партиции будут задействованы для записи, все это занимает время.

В моем случае процесс установления соединения занимал 100–300мс.

Сразу же отмечу что система работала с дефолтными настройками и никакой тюнинг не производился, за неимением специалистов с глубокой экспертизой по настройке работы Apache Kafka.

Проблема: Сам по себе тайминг в 300мс для нас не являлся критическим, нас устраивает время ответа до 1 сек. Поскольку весь остальной код отрабатывает за ~100мс, то мы отлично вкладывались в установленные нормы SLA.

Несмотря на то, что сам код приложения и Apache Kafka(AWS MSK) находились в одной Availabilty Zone, а поначалу и вовсе на соседних EC-2(Kafka была в Docker’е), это никак не избавило нас от сетевых сбоев и задержек/проблем присутствующих в инфраструктуре AWS.

Мы постоянно наблюдали, несколько раз в сутки, скачки во времени установления соединения до 1500мс, что являлось для нас критическим таймингом. Мы могли бы конечно решить этот вопрос, например, с помощью — родного для PHP брокера сообщений RabbitMQ, но это же "костыльный костыль" и еще как минимум одна/две точки отказа, вторая это демон(или тулза) который бы перекладывал сообщения из одной системы очередей в другую.

Поскольку мы не хотели идти на столь отчаянный шаг, мы решили посмотреть в другую сторону. Этой стороной оказалось использование http proxy. После некоторых исследований и экспериментов мы остановились на open sourse решении от компании confluent — Kafka Rest Proxy.

Данный инструмент написан на Java. Весь секрет в том что прокси подсоединяется к кластеру Kafka, держит с ним соединение и принимает http запросы — быстро производит запись и отдает ответ содержащий метаинформацию о результате вставки, например - offset записанного сообщения.

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

Вывод: шалость удалась, но пришлось использовать магию из запретной секции :)