2025-11-09 Нighload: ИИ становится частью ИТ-ландшафта

Прошел очередной Highload. Для меня основной темой был ИИ, и в этой теме я зафиксировал переход от конкретных проектов на основе ИИ к включению приложений с ИИ в ИТ-ландшафт, связанный с этим переход от DevOps к ML-ops и решения задач обеспечения надежности таких решений в целом.

Кстати, эта тема была продолжена на ArchDays, на которой я был после Highload. Про доклады на ArchDays — ждите отчет, но я сразу скажу, что там Газпром Нефть поделился архитектурными схемами, используемыми для построения такого ландшафта, а Greensight рассказал про создание приложений, нацеленных на решение частных задач не хуже больших LLM, и при этом работающих в проде всего на паре видеокарт, обеспечивая приличный поток запросов.

Если делать выводы по теме ИИ в целом, то я бы отметил следующее.

1. ИИ начинает хорошо работать, если вы решаете понятную задачу с конечным эффектом. Например, оптимизируете работу техподдержки, или управление промышленным оборудованием. При этом очень важно, чтобы цикл разработки включал в себя весь цикл внедрения и апробации с реальными пользователями, а не ограничивался просто созданием некоторой системы. Тут ИИ не отличается от другого софта. При этом, как и в случае другого софта, государственные и корпоративные заказчики часто заказывают продукт с формальными требованиями и неясным сценарием внедрения, и силы разработчиков уходят на решение ложных задач, а поможет ли система, например, врачу и насколько — остается неясным.
2. ИИ надо не только первый раз научить и настроить, его надо доучивать постоянно. И надо проектировать цикл обновления, как часть продукта. При этом уже понятно, что для многих групп пользователей будет важна возможность добавить собственный контекст, учесть специфику предприятия. В той же медицине — многие клиники разрабатывает свои методы решения, и если делаешь медицинский ИИ, то надо подумать, как этот контент будут добавлять. Или нефтянка — там тоже свои особенности у каждой компании. Сейчас это в большинстве случаев за рамками проектов, хотя в обычных ИТ-проектах возможность развития закладывают.
3. Ограниченная предсказуемость и воспроизводимость результатов, получаемая при использовании приложений с ИИ, не мешают включению их в ИТ-ландшафт. Да, есть особенности, но не более того. Да, для разбора инцидентов нужны подробные логи, и о них надо позаботиться, но так устроено и во многих других приложениях. Цикл ML-ops — некоторый гибрид DevOps и DataFlow, тут тоже нет проблемы.
4. Достигать решений с использованием ИИ можно двумя способами: грубой силой, беря мощные платформы и вычислительные мощности, или тонкой настройкой, учитывающей содержательную специфику решаемой задачи. Тут полная аналогия с базой данных: мощная железка позволяет не строить индексы и хранить данные абы как, а если вы погрузились в содержание и построили конкретное решение, то можно получить выигрыш на порядки. При этом разработчики часто предпочитают грубую силу, а не погружение в содержание. А приходится.

А сейчас вернемся к Highload. В этот раз он был в Технопарке Сколково, а не в Школе бизнеса Сколково. Это — сильно другая площадка. Я на ней был несколько раз на разных конференциях, и тогда она представлялась холодной, а вот Highload удалось создать хорошую, теплую атмосферу. На мой взгляд, получилось лучше, чем в Крокусе, где Highload тоже был. А по сравнению со Школой бизнеса геометрия Технопарка более понятная, но зона еды и общения отдалена от зоны основных залов, в Школе ты намечаешь следующий доклад, идешь по кругу к нужному залу, по пути можно кого-то встретить и пообщаться. А тут надо спуститься, пройти до зоны еды и выставки, потом вернуться и в целом это — больше времени на перемещение.

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

За годы проведения конференций Онтико накопил громадное количество записей. И они лежат не слишком востребованные, потому что найти в нужный момент не так просто. Но идея состоит не просто в том, чтобы обработать записи с помощью ИИ и сделать по ним поиск, а попробовать сделать на их основе комплексную конструкцию, которая позволит ИТ-нику освоить смежную профессию или новую техническую область, если возникает такое желание или появляется задача.

В компаниях регулярно появляются задачи, которые раньше не решали, и для их решения надо освоить какую-то технологию. При этом часто это — лишь часть какого-то проекта, под которую нет смысла нанимать отдельного специалиста, хочется освоить самим, посмотреть на технологию и понять — стоит ли ее шире осваивать и применять. И людям тоже часто хочется посмотреть на новые технологии.

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

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

Они взяли стадии инженерной деятельности, которая начинается не с кодинга, а с подготовки и выбора архитектуры, и сделали продукты, ориентированные на разные этапы.

• Tech kitchen. Группа свободного поиска в мире Полудня Стругацких. Чистый серфинг, лента или шоу погружения в новые технологии. Цель — уменьшить время с появления технологии до распространения в больших масштабах. ИТ-сообщество 1.6 млн, а сообщество Онтико — 5к докладчиков и 15к участников. Поэтому надо запустить это как СМИ, чтобы было широкое распространение. Взяли площадки, начали делать контент. Апробация показала, что доклады заходят, если спрашивать и комментировать — получаются эксклюзивные шоу. Можно присоединиться и поучаствовать. Если люди все равно тупят в ленте, то то почему бы не тупить в прикольных профи-рилсах? И они подумают вытащить туда обсуждения трендов на внутренних встречах ПК, которые происходят при подготовке конференций. Как участвовавший в ПК Knowledge Conf могу подтвердить, что на таких встречах действительно много интересного.
• OnticoGPT. Инженеры тратят долгое время на задачу поиска и выбора решения. А тут Можно задать вопрос, получить ответ на основе 6к докладов, со ссылками на видео. Скоро появятся тайминги. Проект делают совместно с сибирскими нейросетями. Под капотом — два пайплайна, первый по сбору и индексации, там мультимодальный контент сегментируется по переключеням слайдов, получается примерно 200к семантических векторов для поиска. И пайплайн поиска: тип вопроса, источник для поиска, вопрос переписывается так, чтобы было понятно для поискового движка — с учетом контента разговора, дальше идет в один из 6 поисковых движков, а потом LLM формирует ответ, и он трассируемый на конкретное место контента. Изначально было 400Gb контента, они профильтровали, выбрали лучшее — 2Gb, там одна A100. Ответы лучше, чем спросить LLM без базы знаний, но насколько лучше зависит от методик оценки, тут не понятно. Сейчас это доступно для всех.
• DevNavigator. Карьерный GPS в ИТ. Базовые навыки — общие — узкие специализации. И дальше ваш выбор: углубляться или иди в смежные области. Доступно в личном кабинете. Roadmap по архитектуре: собрали, показали. Можно нарисовать свой маршрут, можно обсудить.
• Запустили клуб профессионалов — это специальный раздел в личном кабинете. Есть профиль, туда накапливаются все достижения. И это не только профиль, но и нетворк. Витрина экспертов, чтобы найти того, кто может решить проблему.
• All CFP. Организация митапов или мини-конференций — долгая, с множеством технических деталей. Они делают поддержку: можно регистрировать мероприятия, собирать заявки, а потом — готовить. Чтобы организатор мероприятия легче прошел этот путь, чтобы сделать мероприятие было легко. Забирают рутину на себя. Для докладчика тоже весь roadmap тоже был виден с самого начала. Задача — подстегнуть создание контента. Чтобы митапы продуцировали контент, который мы бы могли брать и вбрасывать в GPT.

Пока все эти продукты — гипотезы, они будут проверять, что взлетит. И есть задумки других продуктов.

Для чего это делается? Есть разница США — Россия — список компаний по капитализации. У Штатов в лидерах ИТ, а у нас — нефтянка, эта ситуация не меняется. Но при этом в мире всего несколько стран, у которых собственный поисковик, антивирус, соцсетка, ОС и так далее, Россия в их числе. Но на деньгах это не отображается.

Выступление — передача такт опыта. Они пробуют за счет этих продуктов стократ увеличить скорость и объем передачи информации. И, возможно, это даст офигенный прорыв. А в перспективе — может и заменят ВУЗы, потому что сейчас на 4 курсе 95 % работают, а выполняют программу ВУЗа, чтобы родителей успокоить.

Это был рассказ о создании медицинской рекомендательной системы по госзаказу. Для начала загрузили для поиска MedTech. Там pdf, обычно в две колонки, и множество картинок внутри. И с распознаванием такого контента есть отдельные сложности, они делали кастомные парсеры, потому что стандартные теряли связи между заголовками и строкаи на такой верстке.

Но задача этим не ограничивается, очень часто для ответы на вопросы нужен синтез знаний из нескольких статей, при этом знания могут быть разных уровней абстракции, например, правила лечения какого-то заболевания, и противопоказания для определенной категории лекарств или описание проблем совместимости. И при формировании ответа важно эти взаимосвязи учесть. И в ответе обязательны ссылки-основания, на основе которых получен ответ.

Для обработки взяли семантический RAG — разбитие на предложения, скользящее окно, разрывы чанков по расстоянию между предложениями и подбор порога. И векторная база — Qdrant для гибридного поиска. Возникают проблемы, например, чанк выделил сущность, а противопоказания ушли в соседний чанк, и будет проблема. Используют GraphRAG, чтобы восстановить семантические связи, характеристики улучшаются, но недостаточно, используют NER и Relation extraction, но теперь ломается на аббревиатурах: между аббревиатурой и расшифровкой оказалась большое расстояние. И так далее, в докладе достаточно много деталей по использованным расширениям: Community enhanced RAG, Pathfinding RAG, Hierarchical summarization RAG, Graph Native Chunking, Query Focuced Subgraph RAG.

Результат достигнут, они прошли испытания. Но он оказался очень дорогим, индексация одного документа требует 50к$. И был следующий этап — снижение стоимости, делали LightRAG? используя библиотеку Graph RAG для двойного прохода по графам, из которого строится компактный json, связывающий сущности и включающий низкоуровневые и высокоуровневые сущности. И в результате запрос в LLM получается не 1000+ токенов, а всего 100. А добавлениях новых публикаций оказывается, что не надо пересобирать все, достаточно менять локально структуру графа.

Обработка получается по такому алгоритму: запрос — нормализация — векторный поиск в Qdrant (50 фрагментов) — графовый поиск на основе этих фрагментов — LLM — ответ. А если граф ничего не нашел, то идем в векторный поиск на альтернативный вариант формирования контекста. .Для индексации NER на MedGemma, а поверх — поиск связей на GPT 4o для обогащения. Генерация ответа — 1.5 с. По отношению к максимальной версии 90 % качества и 10 % стоимости.

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

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

При этом структурирование можно было бы вести с помощью ИИ, он это умеет. Я еще в 2018 году слушал на Codefest доклад про чатбота для первичного приема и направления к специалисту, для которого базу готовили, распознавая медицинские учебники и выделяя связи болезнь — симптом и болезнь — орган — специалист. Понятно, что тут задачи сложнее, тем не менее, думаю, подготовка аналогичных семантических связей обеспечили бы обогащение запроса релевантным контекстом и исключили потери релевантной информации. А дополнительным профитом, возможно, была бы возможность самим медикам работать с такими содержательными структурами, в том числе — для описания специфических ил новых подходов к лечению, разрабатываемых конкретной клиникой.

Поддержка в Яндексе это 700к тикетов и 1.4 м сообщений в день. Классический способ работы — запрос клиента проходит классификацию, на основе которой оператору показывают варианты шаблонов ответов, он выбирает нужный или может написать свой.

К идее, чтобы LLM сама вела диалог, заказчики относились с недоверием: есть галлюцинации, мало ли, что она ответит и статистика их не убеждала. Поэтому на первом этапе человека не исключали, LLM лишь предлагала ответ оператору, и он мог сам его исправить. И уже на этом этапе скорость возросла на 15 % при том же качестве, которое операторы оценивали. И получив уверенность они перешли на работу LLM без участия человека.

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

По сути, операторы отвечают макросами. Можно посмотреть документы и сказать, какие являются позитивами. А дальше дообучить модели, сделать реранкер. У них получилось три разных модели и реранкер, который объединяет ответы. Генератор сделан на легкой YaGPT Lite, ставить полноценный — дорого. Для него делали датасет: ответы лучших операторов, отфильтрованные на основе LLM, чтобы отобрать хорошие ответы. И получилась эффективная модель.

Они боялись, что модель будет выдавать слишком много промокодов и компенсаций, но опыт показал, что выдает не больше, чем оператор.

Дополнительно есть пре-фильтр на основе BERT 0.5B, чтобы отсекать вопросы, по которым не хватает информации и провокации. На входе LLM, которая отсекает вопросы. И пост-фильтр на отдельной YaGPT-Lite, который отсекает галлюцинации в ответах.

Дальше возник вопрос — а можно ли сделать еще лучше? В ситуации вопрос-ответ RAG работает хорошо. Но часть базы знаний представляет собой сложные алгоритмы действий, сценарии со ссылками между ними: если попал в такую ситуацию, то иди туда. Там много вложенности, последовательность инструкций. И такую базу знаний надо представлять в виде графа. И пройти по графу при обращении. GTO — Graph Traversing Operator.

Преобразование текстов в графы делаем с помощью больших LLM, они умеют, но могут ошибаться. Поэтому пишем систему правил проверки графа и просим LLM поправить. Опыт — получились графы реально близкие к базе знаний и высокоинтерпретируемые.

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

Граф плохо работает, если плохая база знаний и инструкции написаны мутно. И они работают на то, чтобы с помощью анализа LLM и обработки подсвечивать мутные места. А дальше менять базу знаний и отражать это в графе — это делает LLM. Валидацию проводят люди-асессоры и LLM, потому что асессоров не так много. При этом к асессорским разметкам тоже есть вопросы: спросив оператора мы можем получить разные мнения про правильный ответ.

В RAG-модели еще надо дообучать разные модели по продуктам, так как поддержка по такси, еде и доставке различна, а тут можно использовать общую графовую модель. При этом областей много, они делятся, поддержка пассажиров и водителей — различна, но часть контекста — общая.

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

Как отлаживают и собирают баги? Модели могут ошибаться, и они используют пост-операционную модель. Еще дополнительно генератор обучают не вестись на провокации. Они могут разворачивать разные модели и сравнивать, как они отвечают. Настроены выгрузки по плохим ответам по поддержки: можно выгрузить кейс, выгрузить LLM варианты ответов и фактический ответ, и асессор определяет причину: это модель сработала плохо, или человек недоволен из-за заказа. А если модель — то есть возможность быстрого патча, чтобы какие-то ответы блокировать, а потом уже дообучить.

Начали с письменной поддержкой — она проще. Теперь идут в голос, идея — докрутить то же решение.

Это доклад о том, как организовать инфраструктуру для исполнения множества агентов, которые включены в бизнес-процесс. При этом большинство решений аналогичны используемым для обычных приложений, они ведь тоже могут уходить в бесконечные циклы или стучаться в закрытую дверь, пытаясь вызвать неработающий сервис. Особенности есть, но их — немного. Дальше — набор проблемных ситуаций с идеями решений.

1. Нужна единая среда исполнения агентов. Идентификация агентов, идентификаторы операций, по которым в логах можно восстановить происходящее для разбора инцидентов.
2. Агенты-лодыри неработоспособные. Надо проверять, что агент работает, health check — маленькое тестовое обращение при запуске.
3. Недетерминированная логика работы LLM делает невозможным восстановление при сбоях, поэтому необходимо хорошее логирование, нужно сохранять версию агента, кто запустил, при каких условиях. Без трассировки разобраться нельзя, потому что нет воспроизводства.
4. Агенты могут провоцировать инциденты при выходе за нормативные границы, например, уходя в бесконечные циклы, вызывая ресурсные коллапсы. Сервис не предоставлен, а токены израсходованы. Решение — из обычного ИТ, предотвращение зацикливания, например, как в сетевых пакетах.
5. Агенты могут стучаться в закрытую дверь, к неработоспособному сервису — поставьте ограничения по retry.
6. Подумайте, как избежать паралича бизнес-процессов при отказах агентов. Если сделали агента, который заменяет сотрудников, чтобы те занимались другими задачами, а агент перестал работать, клиент должен получить обслуживание. Нужен business community plan. А на переходном этапе надо уметь отключать агентов, возвращаясь в обслуживание людьми. Правда, тут проблема с теми процессами, которые с ходу строят на основе агентов.
7. LLM не должна превратиться в единую точку отказа, чтобы не было коллапса высоконагруженных бизнес-процессов из-за нехватки производительности. Нужно управлять доступом, ограничивая доступ в критических ситуациях. StopEvent для агентов разной критичности, и закладывать это в сценарии работы.
8. Бывает массовый сбой агентов из-за скрытых несовместимостей с новыми версиями. У них GigaChat постоянно обновляется, люди, которые выпустили говорят «стало лучше, сейчас всех обгоним», метрики растут. Но агенты могут начать вести по-другому, неожиданно. Нужно два контура с разными версиями, постепенное переключение трафика и оценка работы новой версии.

Паттерны будут расти, мы в начале пути. Поэтому важно строить устойчивую инфраструктуру при экспериментальной технологии.

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

Есть задача: надо изменять базу и передавать сообщения, обеспечивая консистентность. Если сообщения передавать сразу, то при откате транзакции изменения базы пропадут, а сообщения — уйдут. А если их накапливать и передавать после коммит, то сервис может упасть после коммит, не передав сообщения. Поэтому мы записываем очередь сообщений в базу, вместе с другими изменениями, а потом отдельный сервис обеспечивает их передачу — это и есть паттерн Transactional Outbox.

И дальше было несколько вариантов реализации на PostgreSQL и Кафка с примерами кода. Использовались разные виды блокировок, в одних решениях была гарантия порядка сообщений, связанных с объектом (внутри топика), в других — нет, в сложном решении была дополнительная таблица партиций, за счет которой уменьшалось число обновлений в основной таблице сообщений, и так далее. Описывать это в конспекте нет смысла, надо брать презентацию и смотреть код. И было сравнение вариантов по быстродействию и нагрузке на базу.

Госуслуги — это 150 млн записей, 15 млн активных пользователей, 2 млн услуг в сутки и 160 тыс. rps пиковая нагрузка. Лента уведомлений — статусы заявлений, штрафы, просроченные документы и так далее — коммуникация всего 12 млрд в год, 12 млн в сутки.

В 2021 Oracle начал тормозить, хотя стоял на очень хорошая железка. Как правило, потому что разделял ресурсы с другими сервисами, на нем работали не только уведомления, а еще нагружали джойны и массовые вставки. Так что они начали думать про переход раньше, чем Oracle ушел. А когда он в 2022 ушел и последовал приказ Президента про импортозамещение — вариантов не осталось.

Требовалась бесшовная миграция при высокой нагрузке. А чтобы был задел на будущее — повышенные требования : 4000 вставок в секунду, 300 млн в сутки, возможность A/B тестирования, работа без downtime.

Рассматривали варианты PostgreSQL, Cassandra, которую использовали одноклассники и ScylaDB — на ней работает discord. Начали на Кассандре, но Сцилла оказалась быстрее, больше компактизация, и еще ряд преимуществ, в презентации был слайд. И в ней есть CQL, который похож на SQL.

Архитектура системы: 2 датацентра active-active, общая Кафка и Oracle (мастер+2 standby), и 10+ микросервисов. Госуслуги нельзя поставить на паузу. Поэтому микросервисы на переходном этапе работали с Oracle и Сциллой параллельно. Сначала мастер — oracle, потом переключали. При этом Сцилла развернута в каждом датацентре отдельная. Мигратор написали самостоятельно — балансировка нагрузки, чтобы не убить, и хранить состояние — если что-то не так, чтобы работало. Сохраняли первичные ключи Oracle сохраняли, чтобы работали ссылки из старых писем. И мониторинг миграции через метрики.

Сделали асинхронной — user migration topic. В Oracle хранили состояние каждого пользователя, ставили старт, и отправляли в user migration topic, сообщения — record migration topic. Вставляли в Scylla пачками, потом ставили признак, что мигрировано. С момента запуска сцилла-реплик все новые уведомления писали в сциллу одновременно. Отслеживали тайминги и latency.

Как проверить данные? Исторические наслоения накопилось с 2011 года, все варианты проверить нельзя. Поэтому проводили тестирование на бою: запрос идет с Oracle, дубль — со сциллы, результат сравниваем. Но пользователю результат Oracle выдаем сразу, не ждем Сциллу. И второй механизм — сравниваем ответы oracle и scylla по логу запросов.

Переключение пользователей на Сциллу — поэтапное. Сделали через куку, если она есть — то идем в сциллу. А если нет — то проверяем статус миграции, и ставим куку, если мигрирован, и делаем internal redirect.

Проблемы и их решения.

• Ограниченные агрегации сцилла — базовые функции и только внутри партиции. Зато партиции в сцилле крайне эффективны.
• Про join забудьте, where очень ограничен. Нет null, not, or, like и так далее. Зато есть map-reduce. Пользователь, заходя на госуслуги получает какие-то уведомления. Типы — по партициям, и разбиваем параллельно, потом результаты — объединяем, упорядочиваем по дате, обрезаем. А вместо join — обогащение данных.
  

• Отсутствие транзакций.
  • LWT — можно проверить наличие в базе (upsert), но читает она при этом сложно, это долго.
  • batch — можно объединить запросы на вставку и удаление — но только в рамках партиции. Для разных партиций — долго и дорого, не работает.
• Не читать всю запись перед обновлением, надо обновлять отдельные поля, которые меняются, а не все, потому что нет транзакций.
• Не допускаем больших партиций. Если мы делим партиции по пользователям, а у пользователя много данных — будет очень плохо. Они разбивают уведомления по типам, а еще лучше предусмотреть поле bucket: сначала — константа, а потом можно писать год или даже месяц.
• Есть системные таблицы — large patrition — можно проверять и дальше разбираться.
• Кластерный ключ позволяет сортировать, но при разрастании партиции ей придется сначала прочитать, все, потом отсортировать — надо, чтобы по кластерному ключу работало
• Сложность развития — на оракл и сцилла. Они обобщили и унифицировали фичи для нового — ограничили оракл.
• Лучше обновлять, чем удалять. Есть type, он входит в ключ. И они специальным образом меняли.
• Только асинхронные запросы. Синхронные — очень плохо, потому что ограниченный пул потоков.
• Отказ нод и недоступность дата-центров. Есть классы, отвечающие за retry-политики. Они написали свой, чтобы видеть бизнес-метрики и мониторить ситуацию.
  • Сначала запрос внутри датацентра с кворума 3 нод. Если не получилось — retry уже без ограничения на датацентр. И ведем инциденты
  • Аналогично при записи — записать в датацентре, если нет — то куда-нибудь.
• Аналитику проектируем отдельно. Проектирование базы Scylla вообще идет от запросов.

По результатам Scylla 2-3 раза быстрее на чтении и порядок на вставке в сравнении с oracle. Сейчас в лицензии изменились ограничения открытой версии, но им хватает с запасом.

Речь идет про процессинг переводов по номеру телефона, на основе которой сделана оплата по QR-коду. Рост нагрузки в 30 раз — за 7 лет, с 20 до 600 RPS. Я пришел на доклад не с начала, слушал только историю преобразований с 2022 года, когда начали делать параллельный процессинг. И там есть интересные моменты.

Шаблон event sourcing, статусная модель обработки платежей обеспечивает восстановление состояние в случае остановки сервиса. Отказ от кэшей на redis для бизнес-данных, они не дают эффекта производительности на их задачах. Кэширование конфигурации осталось, но там применяют кофеин вместо redis.

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

Появилась Кафка. Сообщение может быть не обработано, есть tlq-топик для таких сообщений. При оплате в интернете пользователи, если лоадер долгий, то обновляют страницу и делают новые платежи. Такие платежи надо делать быстро, нельзя копить на основном топике.

План работ на случай аварий, включая отказ мастера. Если при аварии есть возможность обеспечить работу части пользователей — лучше сделать, чем не сделать.

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

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

[ Хронологический вид ]Комментарии