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

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

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

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

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

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

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

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

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

На HighLoad++ народ ценит конкретику. Вот схема, которую мы показывали — она жила в нашей документации ровно в таком виде:

┌──────────┐    ┌─────────┐    ┌──────────────┐    ┌───────────┐    ┌──────────┐
│  Событие │───>│  Kafka  │───>│  Flink Job   │───>│  Kafka    │───>│ Канал    │
│  клиента │    │ (вход)  │    │ (обработка + │    │ (выход)   │    │ доставки │
└──────────┘    └─────────┘    │  обогащение) │    └───────────┘    └──────────┘
                               └──────┬───────┘
                                      │ < 1 ms
                               ┌──────┴───────┐
                               │  Tarantool   │
                               │ (справочники,│
                               │  профили)    │
                               └──────────────┘

Событие клиента летит в Kafka, Flink обрабатывает в потоке, обогащает данными из in-memory хранилища, применяет бизнес-правила и возвращает решение. Красиво. На слайде. На практике каждый компонент преподнёс свой сюрприз, кроме Kafka — она единственная вела себя прилично.

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

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

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

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

До пивота:   Flink ──> Tarantool (< 1 ms)  ──> решение
После:       Flink ──> PostgreSQL + Kafka   ──> решение
                       (5-15 ms, зато стабильно)

Когда я показал этот слайд, в зале кто-то присвистнул. Latency выросла на порядок. Архитектура стала грязнее. Но мы получили предсказуемость.

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

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

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

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

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

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

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

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

На одном из выступлений инженер из другой компании рассказывал, как они решили похожую задачу на Kafka Streams — без Flink. Проще, дешевле, меньше кадровых рисков. Latency выше, но в их 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, Санкт-Петербург.

Ваш ДПУПП