Это короткая история наивного любителя популярных технологий.
Ранее я уже писал почему на моем текущем проекте мы решили использовать — 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.
Вывод: шалость удалась, но пришлось использовать магию из запретной секции :)
