Synapse сбербанк это что
Всем привет! Мы постараемся сделать, казалось бы, обычный день 4 февраля особенным, проведя первый открытый онлайн митап про SberSynapse (начало встречи – в 16:00)! Мы прошли путь от первого знакомства с технологиями service mesh и понимания, что это вообще такое и зачем оно нужно, до промышленного решения в Сбере. Мы постараемся сделать почти невозможное и поместить эти насыщенные 2 года в серию коротких рассказов за 2 часа, поделившись с вами мыслями о том, зачем мы это делали, какие проблемы возникали, как героически мы их решали и что в итоге получилось. Нам хочется показать себя не только подкованными теоретиками, но и суровыми практиками, для чего мы решили дать возможность вам «потрогать» SberSynapse самим, поэтому регистрируйтесь на практический семинар.
На онлайн мероприятии наши спикеры обсудят следующие интересные темы:
- Как изменились интеграционные паттерны и почему большим компаниям важно не отставать от этих изменений?
- Как развиваются технологические коммьюнити и как стать их участником (на примере Istio)?
- Как встроить service mesh в свой интеграционный ландшафт и осуществить миграцию с legacy технологий?
- Что делать, если что-то пошло не так и нужно найти корень проблемы в решении с Istio?
Подробнее о спикерах и докладах – ниже:
Игорь Густомясов
Сбер, главный по service mesh
Что такое Enterprise Service Mesh и зачем он нужен?
В докладе я расскажу почему сейчас Service Mesh является архитектурным трендом при развитии интеграционных платформ мирового уровня, какие преимущества он несет и почему нужна адаптация применения данной технологии для задач класса Enterprise.
Lin Sun
IBM, Senior Technical Staff Member and Master Inventor, Istio, IBM Cloud
Service mesh&Istio Community
История с технологией service mesh развивается семимильными шагами, а сообщество вокруг Istio как лидирующего фреймворка пополняется новыми участниками и новыми идеями. Компании, которые внедряют Istio у себя в ИТ-ландшафте, формируют требования, которые делают необходимым создание новых способов развертывания для мультикластерных сред, обеспечения безопасности, установки лимитов. Об этом, а также о приоритетах развития сообщества на ближайшие месяцы мы и поговорим.
Сергей Горьков
Сбер, отвечает за интеграционную архитектуру
Как устроен SberSynapse и чем он отличается от Istio?
Компании уровня enterprise предъявляют высокие требования к производительности и надежности интеграции и, зачастую, open source-решения не сталкиваются с такими проблемами. О том, с чем столкнулись мы и как сделать паттерн интеграции service mesh подходящим для использования в больших корпорациях в качестве основного интеграционного решения я расскажу в своем докладе. А еще поговорим о том, что было сложнее всего в новом интеграционном шаблоне и как менялась архитектура интеграции при переходе с esb на service mesh.
Евгений Лукин
Сбер, отвечает за миграцию наSberSynapse
Миграция на Sber Synapse. Уроки промышленной эксплуатации.
Все знают правило разработчиков: “Работает? Не трогай!». Как инициировать миграцию на новую технологию внутри компании. Что важно учесть при планировании миграции. Какие уроки мы прошли внутри и чего уже добились. Поговорим о том как перейти от разговоров о «теории» к практической реализации.
Максим Чудновский
IBM Россия, ведущий системный архитектор по открытому ПО
IBM — Troubleshouting & monitoring. Deep dive
С каждым днем ландшафт для запуска контейнеризованных приложений усложняется, появляются новые компоненты, а значит новые возможности и, как это обычно бывает, новые проблемы. В таких условиях очень важно владеть своей инфраструктурой и понимать, что происходит «под капотом» тех или иных решений в ее составе. Istio, как один из центральных компонентов современного кластера Kubernetes, здесь не исключение, а значит имеет смысл погрузиться в это решение поглубже. Этим мы и займемся в рамках доклада — разберем основы конфигурации Istio Proxy, а чтобы было интереснее, сделаем это на примере одной из практических задач и решим небольшой ребус: два ServiceEntry на два tcp-хоста по одному порту. Что произойдет в Istio, а главное, почему?
TechLab
Для самых заинтересованных мы подготовим несколько практических кейсов, с помощью которых можно будет познакомиться с технологиями SberSynapse и Istio на практике.
Как мы меняли шину данных, а создали интеграционную платформу
Привет, Хабр! Меня зовут Евгений Лукин, я работаю в СберТехе и занимаюсь развитием интеграционных продуктов.
Сегодня поговорим об импортозамещении в банке с миллионами клиентов. Это интересный опыт, который, как мне кажется, будет полезен любому бизнесу. Ниже — мой рассказ о том, как мы заменили корпоративную шину иностранного вендора в Сбере, построив собственную cloud-native децентрализованную интеграционную платформу, и с какими вызовами столкнулись в процессе.
Почему классическое импортозамещение — машина времени в прошлое
Часто компании представляют себе процесс импортозамещения Oracle примерно так:
У нас есть набор баз данных Oracle со слоем логики на PL/SQL, есть SAP, есть шина данных. И всё это нужно заменить, желательно один к одному.
Но «просто переезжать» с Oracle на PostgreSQL или любой другой open-source сложно и экономически невыгодно. Придётся останавливать или замедлять бизнес-разработки, переучивать команды, бороться с багами, заниматься миграцией. И всё это только для того, чтобы через год-два все изменения свелись к новому лейблу в архитектуре, а функциональность при этом осталась прежней.
Означает ли это, что импортозамещение невозможно и ничего менять не надо?
Вот пример такого консервативного подхода — крупные ведомства и компании, которые ни разу не сталкивались с необходимостью импортозамещения.
Хотели бы вы заниматься поддержкой или развитием систем, созданных с использованием технологий полувековой давности? Не думаю.
Получается, есть две крайности:
Стабильность — плохо: отсутствие обновлений в архитектуре, устаревший стек, проблемы с развитием и сложности с привлечением разработчиков.
Модернизация — тоже не очень хорошо, потому что дорого и больно.
Рассказываю, как мы решали эту дилемму в Сбере, с какими вызовами столкнулись и к каким выводам пришли.
Кейс с импортозамещением шины данных в Сбере
До цифровой трансформации в Сбере, как и в большинстве enterprise-корпораций, использовался типовой интеграционный паттерн — корпоративная сервисная шина. Его центральным элементом была шина данных. Работало это следующим образом: потребитель отправлял запрос в очередь, сообщения обрабатывались, маршрутизировались и отправлялись в Messages queue поставщику данных. Он в свою очередь обрабатывал и возвращал ответ.
Поставщики и потребители данных отвечали только за подключение к очередям сообщений, а с интеграционной логикой и очередями работали выделенные команды миграции.
До определённого момента такой подход всех устраивал с точки зрения надёжности и производительности. Но со временем, когда стало появляться больше новых удобных приложений, трафик стал увеличиваться. А вот шина позволяла реализовать только вертикальное масштабирование за счёт покупки новых high-end-серверов. Мы были вынуждены создавать новые инстансы шин данных.
Корпоративная сервисная шина — это всегда некий проприетарный софт со своими особенностями и языком. Поэтому за любые доработки, изменения внутри сервисной шины отвечают одна или несколько выделенных команд специалистов со знанием этого софта. И такие команды неизбежно становятся «бутылочными горлышками»: никакое изменение, доработка не могут пройти мимо них, а значит их бэклог перегружен, а задачи копятся, снижая общий time-to-market.
Нам нужно было найти принципиально новое решение, которое позволило бы реализовать горизонтальное масштабирование: поднимать дополнительные поды в соответствии с ростом и падением нагрузки. При этом сам процесс интеграции должен быть децентрализованным, чтобы работать с ним могли любые команды. А так как в Сбере несколько тысяч различных команд разработки, из этого вытекало ещё одно требование к новой шине: транспортный слой должен быть изолирован от языка и от прикладной логики сервиса.
Platfrom V Synapse — с чего начали
Мы проанализировали возможные варианты и поняли, что паттерн Service Mesh отлично подходит под наши задачи. В Service Mesh за интеграционную обвязку, включая timeouts, retries, circuit breakers и так далее, отвечают конфигурационные файлы. Они поставляются вместе с исходным кодом, подхватываются контрольной панелью и распространяются на все микросервисы, участвующие в миграции через proxy-компонент (в нашем случае — Envoy).
Так как любая миграция — это всегда риск сломать что-то важное, пошли по пути parallel run. Решили оставить старую шину данных, построить рядом новую и добавить «смарт-топоры», которые отслеживают количество ошибок в мониторинге и в нужный момент переключаются на старую шину.
Так выглядела исходная идея. Казалось, мы продумали всё: масштабирование, децентрализацию и даже план отката.
Но нас ждали интересные открытия.
Что мы не предусмотрели
Service Mesh может быть сложным
Важный момент при использовании горизонтального масштабирования — сервисы с волнообразной нагрузкой. У нас есть сервисы, по которым нагрузка меняется волнообразно. Например, пришла зарплата, поэтому многие идут в СберБанк Онлайн делать переводы или производить оплату. И нагрузка на такие сервисы растёт мгновенно. На графике ниже видно, что активность в приложении меняется волнообразно, есть определённые периоды, когда нагрузка может резко подскочить, а потом так же резко упасть.
Если мы работаем со стандартной моделью автоскейлинга в Kubernetes или OpenShift, которая ждёт превышения установленного порога по нагрузке и потом начинает последовательно запускать копии приложений, то просто не успеем обработать весь трафик.
Что сделали: вместо того чтобы установить в качестве триггера порог по нагрузке, начали прогонять трафик через наш компонент Platform V SynAI. Это предиктивный автоскейлер, который анализирует исторические тренды поведения трафика и, используя модель Machine Learning, предсказывает возможные скачки заранее. С его помощью можно предугадать рост нагрузки перед очередным скачком и заранее поднять нужное количество подов, а после снижения трафика — сократить.
За надёжность приходится платить ресурсами
Очевидно, что горизонтальное масштабирование работает, пока у вас достаточно места для того, чтобы скейлиться. Неочевидно другое: из-за того что масштабирование напрямую связано с ресурсами, мы начинаем платить этими ресурсами за надёжность.
Скажем, раньше у нас был один сервер, в котором можно было легко просчитать утилизацию, учесть пики и заложить рост. Теперь — как минимум несколько центров обработки данных (ЦОД). В каждом из них должен быть под, а лучше несколько, потому что нужно гарантировать надёжность: вдруг этот единственный под зайдёт на плохую ноду, которая «зависнет» и погубит весь трафик. В результате в каждом ЦОД есть не меньше 2 подов, которые нагружены только отчасти. Надёжность обеспечена, но ресурсов потребуется минимум в четыре раза больше.
Что мы сделали: создали новый компонент Federated (Super) Mesh, который объединяет несколько кластеров/ЦОД в один единый Service Mesh. С этим компонентом запрос, не нашедший нужного пода в одном ЦОД, может быть перенаправлен в другой ЦОД на другой под. В итоге Federated Mesh позволяет не держать в каждом дата-центре несколько подов одновременно, а запросы маршрутизировать по мере необходимости.
Что у нас получилось: Platform V Synapse спустя 2 года
В Platform V Synapse используются наши собственные сборки open-source-продуктов Istio и Envoy, доработанные до корпоративного уровня, к которым был добавлен большой спектр инструментов:
дополнительные валидаторы, предотвращающие проблемы на стенде из-за возможных пересечений конфигурационных файлов многих команд;
DevPortal с набором инструментов для автоматической генерации YAML-конфигов, проведения нагрузочного тестирования, а также с готовыми адаптерами для интеграции с внешними системами, компонентами для реализации логирования и т. д.
Platform V Synapse находится в промышленной эксплуатации в Сбере уже более трёх лет. Мы смигрировали более 4 тыс. сервисов с нашей старой шины данных, средняя нагрузка — более 50 тыс. запросов в секунду. Отказоустойчивость платформы — 99,99%. Сегодня любое взаимодействие с банком, вне зависимости от того, смотрите ли вы баланс в СберБанке Онлайн, переводите деньги или звоните в поддержку, основывается на обмене данных через Platform V Synapse.
Миграция на наше решение позволила Сберу снизить стоимость разработки, в 6 раз сократить TCO, существенно сократить time-to-market и, самое главное, обеспечить фундамент для дальнейшего роста на несколько лет вперёд.
Вместо заключения
Импортозамещение «в лоб» не работает: замена компонентов «один в один» замедляет развитие бизнес-доработок и не даёт никаких преимуществ, нагружая бюджет компании.
Выход видится таким: использовать текущую ситуацию в IТ как возможность глобально пересмотреть архитектуру. Заменить морально устаревшие legacy-решения на современные технологии, которые могут решить ваши боли.
Важно при этом оставить пути для отступления и продумать, как вы будете действовать, если новая технология сломается. А ещё нужно быть готовым к масштабным доработкам, например к тому, что придётся докручивать функциональность, оптимизировать ресурсы и решать вопросы с поддержкой. Конечно, для этого потребуются силы, время и сильная экспертиза. Поэтому, если вы сомневаетесь в собственных ресурсах, обращайтесь к нам — будем рады поделиться опытом и подробно рассказать о своих решениях.
Platform V Synapse: комплексное импортозамещение ИТ-ландшафта – от теории к практике
Российский разработчик ПО СберТех проведет вебинар «Platform V Synapse: комплексное импортозамещение ИТ-ландшафта – от теории к практике», где поделится опытом замены западных решений и эффективного перехода в облако.
Гости вебинара узнают, почему импортозамещение часто сопровождается трудностями и рисками и как подчинить эту задачу целям бизнеса. Эксперты СберТеха поделятся опытом Сбера и его клиентов, а также подробно разберут все этапы процесса, от создания кластера до реализации приложения и интеграции с legacy-системами.
Спикеры – специалисты по продукту Platform V Synapse и технологии Service Mesh Евгений Лукин, Алексей Игнатов и Максим Чудновский.
Platfrom V Synapse — интеграционная платформа для импортозамещения корпоративных сервисных шин
Облачная децентрализованная интеграционная платформа Platfrom V Synapse от Сбера обеспечивает интеграцию и оркестрацию микросервисов. Решение позволяет импортозаместить корпоративные сервисные шины западных вендоров, обеспечивая работу микросервисного подхода и бесшовную миграцию на него. Platform V Synapse позволяет системам обмениваться миллионами событий в режиме реального времени c 99,99% доступностью и пропускной способностью более 50 000 tps. Решение базируется на open source-технологиях (Istio, Envoy, Kafka, Flink, Ceph, Kiali, Docker и другие.) и удовлетворяет требованиям крупных компаний по безопасности, производительности и надежности за счет доработок вендора.
Внутри решения есть следующие компоненты:
• Platform V Synapse Service Mesh — интеграционная платформа нового поколения на базе технологии service mesh.
• Platform V Synapse File Exchange позволяет безопасно обмениваться файлами в облаке.
• Platform V Synapse Event Processing обеспечивает потоковую обработку событий, генерируемых облачными сервисами, за счет полностью управляемой службы маршрутизации.
• Platform V Synapse AI – оптимизированное управление трафиком на уровне микросервисов и облачных приложений на базе искусственного интеллекта.
• Platform V Synapse API-management позволяет публиковать внутренние и внешние API, настраивать и отслеживать их использование в удобном интерфейсе.
• Platform V Application Sharding обеспечивает масштабирование облачных приложений за счет технологий шардирования и межкластерной индексации.