Ко всем новостям

Как мы меняли шину данных, а создали интеграционную платформу

Публикации в СМИ
17.11.2022

Источник: Хабр: "Как мы меняли шину данных, а создали интеграционную платформу"

Привет, Хабр! Меня зовут Евгений Лукин, я работаю в СберТехе и занимаюсь развитием интеграционных продуктов.

Сегодня поговорим об импортозамещении в банке с миллионами клиентов. Это интересный опыт, который, как мне кажется, будет полезен любому бизнесу. Ниже — мой рассказ о том, как мы заменили корпоративную шину иностранного вендора в Сбере, построив собственную cloud-native децентрализованную интеграционную платформу, и с какими вызовами столкнулись в процессе.

daf83f4d93f555780a9a2ab17c982fed.png

Почему классическое импортозамещение — машина времени в прошлое

 Часто компании представляют себе процесс импортозамещения Oracle примерно так:

26375aee5d04d3216ca6e07b5a1fc24a.png

У нас есть набор баз данных Oracle со слоем логики на PL/SQL, есть SAP, есть шина данных. И всё это нужно заменить, желательно один к одному.

Но «просто переезжать» с Oracle на PostgreSQL или любой другой open-source сложно и экономически невыгодно. Придётся останавливать или замедлять бизнес-разработки, переучивать команды, бороться с багами, заниматься миграцией. И всё это только для того, чтобы через год-два все изменения свелись к новому лейблу в архитектуре, а функциональность при этом осталась прежней.

Означает ли это, что импортозамещение невозможно и ничего менять не надо? 

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

30b321a9aa483807aed9421acf940531.png

Хотели бы вы заниматься поддержкой или развитием систем, созданных с использованием технологий полувековой давности? Не думаю. 

Получается, есть две крайности:

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

 Рассказываю, как мы решали эту дилемму в Сбере, с какими вызовами столкнулись и к каким выводам пришли.

Кейс с импортозамещением шины данных в Сбере

До цифровой трансформации в Сбере, как и в большинстве enterprise-корпораций, использовался типовой интеграционный паттерн — корпоративная сервисная шина. Его центральным элементом была шина данных. Работало это следующим образом: потребитель отправлял запрос в очередь, сообщения обрабатывались, маршрутизировались и отправлялись в Messages queue поставщику данных. Он в свою очередь обрабатывал и возвращал ответ. 

Поставщики и потребители данных отвечали только за подключение к очередям сообщений, а с интеграционной логикой и очередями работали выделенные команды миграции.

dbeb1ebfea9cbe7a903cc311d5a28fb3.png

До определённого момента такой подход всех устраивал с точки зрения надёжности и производительности. Но со временем, когда стало появляться больше новых удобных приложений, трафик стал увеличиваться. А вот шина позволяла реализовать только вертикальное масштабирование за счёт покупки новых high-end-серверов. Мы были вынуждены создавать новые инстансы шин данных.

Корпоративная сервисная шина — это всегда некий проприетарный софт со своими особенностями и языком. Поэтому за любые доработки, изменения внутри сервисной шины отвечают одна или несколько выделенных команд специалистов со знанием этого софта. И такие команды неизбежно становятся «бутылочными горлышками»: никакое изменение, доработка не могут пройти мимо них, а значит их бэклог перегружен, а задачи копятся, снижая общий time-to-market.

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

Platfrom V Synapse — с чего начали

Мы проанализировали возможные варианты и поняли, что паттерн Service Mesh отлично подходит под наши задачи. В Service Mesh за интеграционную обвязку, включая timeouts, retries, circuit breakers и так далее, отвечают конфигурационные файлы. Они поставляются вместе с исходным кодом, подхватываются контрольной панелью и распространяются на все микросервисы, участвующие в миграции через proxy-компонент (в нашем случае — Envoy).

Так как любая миграция — это всегда риск сломать что-то важное, пошли по пути parallel run. Решили оставить старую шину данных, построить рядом новую и добавить «смарт-топоры», которые отслеживают количество ошибок в мониторинге и в нужный момент переключаются на старую шину.

fd873ac0b11e3354378ae6813f663418.png

Так выглядела исходная идея. Казалось, мы продумали всё: масштабирование, децентрализацию и даже план отката. 

Но нас ждали интересные открытия.

Что мы не предусмотрели

Service Mesh может быть сложным

Важный момент при использовании горизонтального масштабирования — сервисы с волнообразной нагрузкой. У нас есть сервисы, по которым нагрузка меняется волнообразно. Например, пришла зарплата, поэтому многие идут в СберБанк Онлайн делать переводы или производить оплату. И нагрузка на такие сервисы растёт мгновенно. На графике ниже видно, что активность в приложении меняется волнообразно, есть определённые периоды, когда нагрузка может резко подскочить, а потом так же резко упасть.

aa053bc933a565d7356062594e609937.png

Если мы работаем со стандартной моделью автоскейлинга в Kubernetes или OpenShift, которая ждёт превышения установленного порога по нагрузке и потом начинает последовательно запускать копии приложений, то просто не успеем обработать весь трафик.

Что сделали: вместо того чтобы установить в качестве триггера порог по нагрузке, начали прогонять трафик через наш компонент Platform V SynAI. Это предиктивный автоскейлер, который анализирует исторические тренды поведения трафика и, используя модель Machine Learning, предсказывает возможные скачки заранее. С его помощью можно предугадать рост нагрузки перед очередным скачком и заранее поднять нужное количество подов, а после снижения трафика — сократить.

599e95e9eef92e7234b73a313992bda3.png

За надёжность приходится платить ресурсами

Очевидно, что горизонтальное масштабирование работает, пока у вас достаточно места для того, чтобы скейлиться. Неочевидно другое: из-за того что масштабирование напрямую связано с ресурсами, мы начинаем платить этими ресурсами за надёжность.

Скажем, раньше у нас был один сервер, в котором можно было легко просчитать утилизацию, учесть пики и заложить рост. Теперь — как минимум несколько центров обработки данных (ЦОД). В каждом из них должен быть под, а лучше несколько, потому что нужно гарантировать надёжность: вдруг этот единственный под зайдёт на плохую ноду, которая «зависнет» и погубит весь трафик. В результате в каждом ЦОД есть не меньше 2 подов, которые нагружены только отчасти. Надёжность обеспечена, но ресурсов потребуется минимум в четыре раза больше.

Что мы сделали: создали новый компонент Federated (Super) Mesh, который объединяет несколько кластеров/ЦОД в один единый Service Mesh. С этим компонентом запрос, не нашедший нужного пода в одном ЦОД, может быть перенаправлен в другой ЦОД на другой под. В итоге Federated Mesh позволяет не держать в каждом дата-центре несколько подов одновременно, а запросы маршрутизировать по мере необходимости.

4ac5a36ff37da22cf73a3f55ca40066c.png

Что у нас получилось: Platform V Synapse спустя 2 года

В Platform V Synapse используются наши собственные сборки open-source-продуктов Istio и Envoy, доработанные до корпоративного уровня, к которым был добавлен большой спектр инструментов: 

  • визуализация трафика;
  • дополнительные валидаторы, предотвращающие проблемы на стенде из-за возможных пересечений конфигурационных файлов многих команд;
  • SynAI;
  • SuperMesh; 
  • DevPortal с набором инструментов для автоматической генерации YAML-конфигов, проведения нагрузочного тестирования, а также с готовыми адаптерами для интеграции с внешними системами, компонентами для реализации логирования и т. д.
af72b6c177d1056ca3608725b0f53564.png
c40b57ea0c281f721a1812c8d44f7a70.png

Platform V Synapse находится в промышленной эксплуатации в Сбере уже более трёх лет. Мы смигрировали более 4 тыс. сервисов с нашей старой шины данных, средняя нагрузка — более 50 тыс. запросов в секунду. Отказоустойчивость платформы — 99,99%. Сегодня любое взаимодействие с банком, вне зависимости от того, смотрите ли вы баланс в СберБанке Онлайн, переводите деньги или звоните в поддержку, основывается на обмене данных через Platform V Synapse.

Миграция на наше решение позволила Сберу снизить стоимость разработки, в 6 раз сократить TCO, существенно сократить time-to-market и, самое главное, обеспечить фундамент для дальнейшего роста на несколько лет вперёд.

Вместо заключения

Импортозамещение «в лоб» не работает: замена компонентов «один в один» замедляет развитие бизнес-доработок и не даёт никаких преимуществ, нагружая бюджет компании. 

Выход видится таким: использовать текущую ситуацию в IТ как возможность глобально пересмотреть архитектуру. Заменить морально устаревшие legacy-решения на современные технологии, которые могут решить ваши боли. 

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