Saint HighLoad++ 2024: Опыт перевода банковского продукта в реалтайм

Зал на восемьсот человек. Два микрофона. Первый слайд.

Июнь 2024-го, Санкт-Петербург, Saint HighLoad++. Я стою за кулисами и пересчитываю людей в зале. Восемьсот — это когда лиц уже не видно, только масса. Рядом Владимир Аврамов, ведущий разработчик проекта, спокойный как удав. Он будет показывать код. Я — рассказывать, как мы чуть не убили проект своими архитектурными решениями.

Тридцать минут на два года работы. Выбор простой: рассказывать красивую архитектуру из документации или правду. Мы выбрали правду. Слайды с квадратиками забудут через час. А историю про то, как ты в пятницу вечером откатывал релиз, — запомнят. За неё нас потом благодарили в кулуарах больше, чем за любой технический слайд.

Зачем лид и разработчик вместе на сцене

Совместный доклад — осознанный выбор. Одно дело — слайды с квадратиками и стрелочками. Другое — когда разработчик открывает IDE и показывает, как конкретный Flink-оператор ведёт себя под нагрузкой. Аудитория HighLoad++ — инженеры. Им нужен код, а не маркетинг.

Формат работал так: я даю контекст — бизнес-задача, ограничения, почему выбрали такой путь. Аврамов показывает, как это решение выглядит в коде и что происходит, когда на него наступают в проде. Зал получает объёмную картину: стратегия и тактика одновременно.

Потом, на других конференциях, я видел доклады, где руководитель рассказывает архитектуру, а в зале сидит его разработчик и тихо качает головой. У нас такого не было — мы заранее договорились: рассказываем как было, а не как хотелось бы.

Архитектура на салфетке

На HighLoad++ ценят конкретику. Схема жила в нашей документации ровно в таком виде: событие клиента → Kafka на вход → Flink обрабатывает поток и обогащает его данными из in-memory хранилища → Kafka на выход → канал доставки. По пути Flink дёргает Tarantool за справочниками и профилями, прогоняет бизнес-правила и возвращает решение.

Красиво. На слайде. На практике каждый компонент преподнёс свой сюрприз — кроме Kafka: она единственная вела себя прилично.

Технология	Роль	Плюс	Риск
Flink	Stream processing	Exactly-once, stateful	Кадровый голод в РФ
Tarantool	In-memory хранилище	Минимальная задержка	Молодое сообщество
Kafka	Транспорт	Надёжность, масштаб	Минимальный

Подробный разбор каждого решения — в полной версии. Здесь — о том, что случилось, когда мы вынесли всё это на сцену.

Баг, который мы показали залу

Самая рискованная часть доклада — честный рассказ о провале. Мы показали, как на нагрузочном тестировании нашли баг в Tarantool: под определённым паттерном конкурентных запросов in-memory хранилище начинало деградировать. И как за выходные мы переписали критический путь. Было: событие → Flink → Tarantool → решение. Стало: событие → Flink → PostgreSQL и Kafka → решение.

Когда я показал этот слайд, в зале кто-то присвистнул. Задержка выросла на порядок, архитектура стала грязнее. Зато поведение системы стало предсказуемым.

После доклада к нам подошёл инженер из команды Tarantool. Не обиделся — поблагодарил за баг-репорт. Сказал, что они воспроизвели и работают над фиксом. Это лучшее, что может произойти на конференции: ты рассказываешь про проблему, и к тебе подходят люди, которые могут её решить.

Вопросы, которых мы не ждали

Готовясь к докладу, мы ждали вопросов про Flink, партиционирование Kafka, может, про Lua в Tarantool. Реальность удивила.

Первый вопрос из зала: «А как вы продали бизнесу пивот с Tarantool? Это же сдвиг сроков.» Не технический вопрос — управленческий. Отвечал я: честно рассказал, что показали бизнесу два варианта — ждать фикс с неопределёнными сроками или потерять в скорости, но выйти в прод вовремя. Бизнес выбрал предсказуемость. Всегда выбирает.

Второй: «Четыре языка в одном проекте — как вы делаете code review?» На него отвечал Аврамов: ревьюер Scala-кода должен понимать, как этот код взаимодействует с Lua-процедурами в Tarantool. Cross-функциональность из модного слова превращается в ежедневную необходимость. Мы не нашли универсальных людей — мы вырастили их внутри команды.

Третий вопрос запомнился больше всего: «А вы бы сейчас снова выбрали Flink?» Я ответил — да, но с оговоркой. Flink — правильный инструмент для задачи. Проблема не в инструменте, а в том, что людей, которые умеют с ним работать, на российском рынке почти нет. Если ты не готов растить экспертизу внутри — не лезь.

Что я украл у других докладчиков

Конференция — это не только твой доклад. Это десятки чужих.

На одном из выступлений инженер из другой компании рассказывал, как они решили похожую задачу на Kafka Streams — без Flink. Проще, дешевле, меньше кадровых рисков. Задержка выше, но в их SLA укладывались. Я сидел и думал: а мы могли бы так? Честно — нет. Наш SLA требовал другого уровня. Но вот что зацепило: их архитектура была на порядок проще в эксплуатации. Kafka Streams работает как библиотека внутри приложения — никакого отдельного кластера, никакого JobManager, никакого шаманства с checkpoint-ами. У нас на поддержку Flink-инфраструктуры уходило время целого инженера. У них — ноль, потому что инфраструктуры как отдельной сущности не было. Я тогда записал в блокнот: для следующего проекта с менее жёстким SLA — Kafka Streams, без обсуждений.

Другой доклад — про observability в event-driven системах. Автор показал подход к distributed tracing, который мы потом частично внедрили у себя. До конференции мы трейсили события «по старинке» — correlation ID через все сервисы. После — добавили span-ы и структурированную метрику на каждый этап обработки. Конкретно: раньше при инциденте инженер открывал Kibana, искал по correlation ID, собирал картину по логам из пяти сервисов вручную. После внедрения span-ов — открыл trace в Jaeger, увидел всю цепочку с таймингами. Время диагностики инцидентов сократилось втрое. Казалось бы, очевидная вещь. Но пока не увидишь, как это работает у другой команды на живом примере — откладываешь на «потом».

Это то, ради чего стоит ездить на конференции. Не ради бейджика «спикер», а ради того, чтобы посмотреть на свою систему чужими глазами.

Подготовка: два человека — двойная сложность

Совместный доклад звучит как «разделили работу пополам, стало проще». На практике — ровно наоборот. Сольный доклад ты репетируешь перед зеркалом. Совместный — синхронизируешь с живым человеком, у которого свой ритм, свои привычки, своё понимание тайминга.

Мы начали готовиться за два месяца. Первый прогон — катастрофа. Я говорю три минуты, передаю слово Аврамову, он говорит семь. Я пытаюсь вернуть темп — он ещё не закончил мысль. Суммарно — сорок пять минут вместо тридцати. На HighLoad++ тебе не дадут лишних пятнадцать минут. Тебя просто снимут со сцены.

После четвёртого прогона мы ввели жёсткий протокол: каждый блок — с таймером, переходы — по ключевым фразам. Я заканчиваю предложением, которое логически подводит к коду. Аврамов начинает с того, что показывает экран. Никаких «а ещё хочу добавить» — всё, что хочешь добавить, вписываешь в слайды до выступления. Шестой прогон вошёл в двадцать восемь минут. Седьмой — в тридцать ровно.

Зато на сцене это окупилось. Когда два человека работают слаженно — зал это чувствует. Нет неловких пауз, нет борьбы за микрофон. И аудитория видит: эти двое не просто подготовили презентацию — они реально работают вместе. А доверие к тому, что ты говоришь, растёт.

Что изменилось после доклада

Подготовка к выступлению заставила нас систематизировать то, что мы знали интуитивно. Когда ты рисуешь архитектуру для слайда — ты вдруг видишь места, где стрелочки идут не туда. Где компонент делает слишком много. Где нет fallback-а.

После конференции мы провели внутренний ретро по архитектуре. Из него вышли три решения. Первое — формализовали fallback-стратегию для каждого внешнего компонента. Если Tarantool лёг — система переключается на PostgreSQL автоматически, а не по звонку дежурного. Второе — переработали мониторинг: вместо алерта «Tarantool latency выросла» — алерт «Tarantool latency выросла, fallback активирован, бизнес-импакт: снижение конверсии на X%». Контекст вместо сырых цифр. Третье — запустили внутренний tech talk для смежных команд. Оказалось, что половина проблем на стыках — из-за того, что люди просто не знали, как работает соседний сервис.

Доклад на конференции — это не точка. Это катализатор изменений. Ты выходишь на сцену и говоришь «мы сделали вот так», а потом возвращаешься и думаешь: «а можно лучше».

Шрамы вместо слайдов

В enterprise нельзя ставить на единственную технологию без плана B. Какой бы классной она ни была на бенчмарках. И нельзя ставить на одного специалиста, который «всё знает». Знания должны быть в системе, а не в голове.

Если готовишь доклад — рассказывай правду. Залу не нужна твоя идеальная архитектура. Им нужны твои шрамы. Потому что у них свои, и они хотят знать, что не одни такие.

И ещё: если есть возможность выступить вдвоём — пробуй. Да, подготовка в два раза сложнее. Да, нужно синхронизироваться. Но зал получает два взгляда на одну систему — стратегический и тактический. А ты получаешь партнёра, который не даст тебе приукрасить на сцене. Потому что он был рядом, когда всё ломалось, и он знает, как было на самом деле.

---

По мотивам доклада на Saint HighLoad++ 2024, Санкт-Петербург.

Ваш ДПУПП