SlideShare a Scribd company logo
Отказоустойчива
я архитектура
фронтальной
системы банка
Роман Шеховцов
Алексей Громатчиков
•100М клиентов
•Вы – клиенты
•Три основных принципа
Как устроен банк?
Фронт
офисКлиент
Мидл
офис
Бэк
офис
Обслуживание
клиентов
Принятие
решений
Исполнение
операций
Что такое фронтальная система?
…
интернет-банк
мобильное приложение
банкомат
сайт
отделение
интернет-банк для юрлиц
толстый клиент
APIюрлицо
сервисы
банка
клиент
сотрудник
каналы обслуживания
Фронтальная ≠ фронт-енд
Типовой IT-ландшафт
крупного банка
отсеки
резерв
автономность
Почему независимые «отсеки»??
данныеконтроллер
Распределенный кэш
контроллер
контроллер
данные
данные
данные
данные
данные
данные
данные
3N
админы
everything
fails
М - многоблочная архитектура
Блок 1
Блок 6
балансировщик
веб-сервер
сервер приложений
балансировщик
веб-сервер
сервер приложений
БД
БД
Возможные сбои в блоках системы
Блок
балансировщик
веб-сервер
сервер приложений
сервер приложений
БД
• Некритичный компонент
• SPOF в блоке
• Площадка
• Коллапс системы
Приходят
они
• Человеческий фактор
Р – резервирование блоков и данных
http://online.sberbank.ru
Компонент
маршрутизации
http://online.sberbank.ru
http://nodeN.online.sberbank.ru
http://nodeM.online.sberbank.ru
Резервный
блок M
Резервный КМ
Архивная база
данных
операций
клиентов
Блок N
• Холодный резерв
блоков и КМ
*(2n резерв)
• Копия данных
операций
клиентов в
архивной базе
данных системы
• Прикладная
репликация
данных операций
клиентов из
резервного в
родной блок
• Плановый и принудительный перевод клиентов в резервный блок за 1 сек
Блок 2
Блок 3
Организация блоков
• «Гости» банка
вынесены в
отдельный контур
Пилотный
блок
Блок 1
Резервный
блок
Гостевой
блок
10 млн
10 млн
10 млн
• Каналы
обслуживания
изолированы
3000
WEB МП ATM
ЦОД
2
ЦОД
1
Георезерв КМ, блоков и архивной БД
БД
БД
passive
балансировщик
балансировщик
веб-сервер
сервер приложений
веб-сервер
сервер приложений
веб-сервер
сервер приложений
веб-сервер
сервер приложений
БД
active
БД
Архивная
БД
active
Архивная
БД
• Георезервирование всех компонентов *(4n с учетом резервного блока и КМ)
• Холодный георезерв БД с копированием данных средствами СХД
active passivepassive
• Активные копии БД в шахматном порядке по ЦОД
ЦОД
1
Блок N/ КМ
Резервный
блок / КМ
Тиражирование функционала по блокам
Пилотный
блок
Основные
блок
• Пилотирование на
лояльных клиентах
• Плавное
тиражирование по
группам клиентов
• «Рубильник» на
каждую бизнес-
функцию
Резервный
блок
БЭК
А – автономность
Блок
Блок
Блок
Блок
Буферизация и отложенное выполнение
приложение
БД
внешняя
система
операции
чтение
пачек
операций
«в обработке»
сохранение
черновика
докатчик
докат операций пачками
маркер
Блок
двойная
верификация
Кэш профиля клиента
сервер
приложений
шина
клиент
счета
карты
клиент
запрос данных
профиль
кэшированный
профиль
кэш профиля
TTL
обновляем кэш
счетакарты
Блок
Кэширование справочников
сервер
приложений
запрос данных
кэшированные
данные
персистентный
кэш
Блок
справочники
реплика
справочники
запрос данных
Технические перерывы
приложение
кэш,
буферизация
внешняя
система
dead TTL (> TTL)
выставляем
технический
перерыв
Блок
• вручную и автоматически
• в разрезе сервисов
Ограничения
выдача
наличных
Перспективная архитектура
Единая фронтальная система
интернет-банк
мобильное приложение
банкомат
сайт
отделение
интернет-банк для юрлиц
толстый клиент
APIюрлицо
клиент
сотрудник
каналы обслуживания
Единая
фронтальная
система
• данные
• сценарии
• нагрузка
10X
Сегменты
?
Частные клиенты
Блок Блок Блок
Блок Блок Блок
Корпоративные клиенты
Блок Блок Блок
Сотрудники
Блок Блок Блок
Эквайринг (магазины)
Блок Блок Блок
Блок Блок Блок
разное количество блоков
10Х
ЦОД 2
ЦОД 1
Кластер
блоков
Р – резервирование блоков и данных
• КМ без SPOF
• Архивная база
данных в каждом
блоке
• Прикладная
репликация
данных операций
клиентов в
архивные базы
данных кластера
блок
http://online.sberbank.ru
Компонент
маршрутизации
http://2.nodeN.online.sberbank.ru
Блок N.2
http://1.nodeN.online.sberbank.ru
Блок N.1
http://online.sberbank.ru
Компонент
маршрутизации
БД
active
БД
active
Архивная БД
active
Архивная БД
active
• Горячий резерв
блоков и КМ, SSO
*(только 2n резерв)
ЦОД
2
ЦОД
1
Кластер блоков 2Кластер блоков 1
Пилотный кластер
блоков
Тиражирование функционала по блокам
Пилотный
блок 1
• Шахматный порядок обновления блоков в кластерах
• «Feature Toggles» для более гибкого управления функционалом
Пилотный
блок 2
Блок 1.1
Блок 1.2
Блок 2.1
Блок 2.1
- Первая волна
- Вторая волна
Кэш внешних систем в сегменте кэша
Сегмент общих данных
Частные клиенты
Блок
Сотрудники
Блок Блок Блок
Блок Блок Блок
Компонент маршрутизации
• Шардирован по «Affinity function»
• Актуальный и полный объем данных
отсеки
резерв
автономность
• Подписывайтесь на блог ЕФС на Хабрахабр:
habrahabr.ru/company/efs/blog
• Вопросы и ответы
• Обратная связь
• Контакты:
• Роман Шеховцов pomka@yandex.ru
• Алексей Громатчиков gromatchikov@gmail.com
СПАСИБО!

More Related Content

Similar to Отказоустойчивая архитектура фронтальной системы банка / Роман Шеховцов, Алексей Громатчиков (Сбербанк-Технологии)

Опыт построения микросервисной архитектуры в цифровом банке
Опыт построения микросервисной архитектуры в цифровом банкеОпыт построения микросервисной архитектуры в цифровом банке
Опыт построения микросервисной архитектуры в цифровом банке
CUSTIS
 
Управление клиентскими данными как инструмент бизнеса ВТБ24. Сценарии использ...
Управление клиентскими данными как инструмент бизнеса ВТБ24. Сценарии использ...Управление клиентскими данными как инструмент бизнеса ВТБ24. Сценарии использ...
Управление клиентскими данными как инструмент бизнеса ВТБ24. Сценарии использ...
HFLabs
 
Мониторинг веб-проектов real-time мониторинг и аналитика, поиск ошибок и боев...
Мониторинг веб-проектов real-time мониторинг и аналитика, поиск ошибок и боев...Мониторинг веб-проектов real-time мониторинг и аналитика, поиск ошибок и боев...
Мониторинг веб-проектов real-time мониторинг и аналитика, поиск ошибок и боев...
Ontico
 
Тестирование и оптимизация 1С-Битрикс (Александр Демидов, Олег Бунин)
Тестирование и оптимизация 1С-Битрикс (Александр Демидов, Олег Бунин)Тестирование и оптимизация 1С-Битрикс (Александр Демидов, Олег Бунин)
Тестирование и оптимизация 1С-Битрикс (Александр Демидов, Олег Бунин)Ontico
 
раубичи ронд
раубичи рондраубичи ронд
раубичи ронд
zolik
 
Что вас ждет на пути реализации Soa (Битрикс отступает)
Что вас ждет на пути реализации Soa (Битрикс отступает)Что вас ждет на пути реализации Soa (Битрикс отступает)
Что вас ждет на пути реализации Soa (Битрикс отступает)
Василий Савунов
 
Принцип достаточности
Принцип достаточностиПринцип достаточности
Принцип достаточности
Альбина Минуллина
 
"Контактный центр по запросу" от CTI, Платон Бегун
"Контактный центр по запросу" от CTI, Платон Бегун"Контактный центр по запросу" от CTI, Платон Бегун
"Контактный центр по запросу" от CTI, Платон БегунYulia Sedova
 
Microsoft BI User Group: Работаем с 1С эффективно
Microsoft BI User Group: Работаем с 1С эффективноMicrosoft BI User Group: Работаем с 1С эффективно
Microsoft BI User Group: Работаем с 1С эффективно
Eugenia Korshunova (Pavlova)
 
Microsoft BI User Group: Работаем с 1С эффективно
Microsoft BI User Group: Работаем с 1С эффективноMicrosoft BI User Group: Работаем с 1С эффективно
Microsoft BI User Group: Работаем с 1С эффективно
Marina Payvina
 
SQL Server StreamIinsight - data processing in real time
SQL Server StreamIinsight - data processing in real timeSQL Server StreamIinsight - data processing in real time
SQL Server StreamIinsight - data processing in real timeДенис Резник
 
Avanpost idm пацифика 2016
Avanpost idm пацифика 2016Avanpost idm пацифика 2016
Avanpost idm пацифика 2016
Diana Frolova
 
Teched2011 1С:Предприятие + MS SQL Server 2008 R2
Teched2011 1С:Предприятие + MS SQL Server 2008 R2Teched2011 1С:Предприятие + MS SQL Server 2008 R2
Teched2011 1С:Предприятие + MS SQL Server 2008 R2
Vyacheslav Gilyov
 
IBM ECM & Discovery Strategy
IBM ECM & Discovery StrategyIBM ECM & Discovery Strategy
IBM ECM & Discovery Strategy
IBM IBM
 
Сила User Experience - как Dell Foglight может помочь бизнесу
Сила User Experience - как Dell Foglight может помочь бизнесуСила User Experience - как Dell Foglight может помочь бизнесу
Сила User Experience - как Dell Foglight может помочь бизнесу
BAKOTECH
 
Опыт работы с Qlik в компании ВТБ Страхование
Опыт работы с Qlik в компании ВТБ Страхование Опыт работы с Qlik в компании ВТБ Страхование
Опыт работы с Qlik в компании ВТБ Страхование
Marina Payvina
 
Pronet bmc pro activenet monitoring. Современная система мониторинга и упра...
Pronet   bmc pro activenet monitoring. Современная система мониторинга и упра...Pronet   bmc pro activenet monitoring. Современная система мониторинга и упра...
Pronet bmc pro activenet monitoring. Современная система мониторинга и упра...
Natasha Zaverukha
 
Виртуальный банковский офис
Виртуальный банковский офисВиртуальный банковский офис
Виртуальный банковский офисsoftlab
 
How to assess the company's readiness to intelligent automation of office pro...
How to assess the company's readiness to intelligent automation of office pro...How to assess the company's readiness to intelligent automation of office pro...
How to assess the company's readiness to intelligent automation of office pro...
Alexandre Prozoroff
 

Similar to Отказоустойчивая архитектура фронтальной системы банка / Роман Шеховцов, Алексей Громатчиков (Сбербанк-Технологии) (20)

Опыт построения микросервисной архитектуры в цифровом банке
Опыт построения микросервисной архитектуры в цифровом банкеОпыт построения микросервисной архитектуры в цифровом банке
Опыт построения микросервисной архитектуры в цифровом банке
 
Управление клиентскими данными как инструмент бизнеса ВТБ24. Сценарии использ...
Управление клиентскими данными как инструмент бизнеса ВТБ24. Сценарии использ...Управление клиентскими данными как инструмент бизнеса ВТБ24. Сценарии использ...
Управление клиентскими данными как инструмент бизнеса ВТБ24. Сценарии использ...
 
Мониторинг веб-проектов real-time мониторинг и аналитика, поиск ошибок и боев...
Мониторинг веб-проектов real-time мониторинг и аналитика, поиск ошибок и боев...Мониторинг веб-проектов real-time мониторинг и аналитика, поиск ошибок и боев...
Мониторинг веб-проектов real-time мониторинг и аналитика, поиск ошибок и боев...
 
Тестирование и оптимизация 1С-Битрикс (Александр Демидов, Олег Бунин)
Тестирование и оптимизация 1С-Битрикс (Александр Демидов, Олег Бунин)Тестирование и оптимизация 1С-Битрикс (Александр Демидов, Олег Бунин)
Тестирование и оптимизация 1С-Битрикс (Александр Демидов, Олег Бунин)
 
раубичи ронд
раубичи рондраубичи ронд
раубичи ронд
 
Что вас ждет на пути реализации Soa (Битрикс отступает)
Что вас ждет на пути реализации Soa (Битрикс отступает)Что вас ждет на пути реализации Soa (Битрикс отступает)
Что вас ждет на пути реализации Soa (Битрикс отступает)
 
Принцип достаточности
Принцип достаточностиПринцип достаточности
Принцип достаточности
 
"Контактный центр по запросу" от CTI, Платон Бегун
"Контактный центр по запросу" от CTI, Платон Бегун"Контактный центр по запросу" от CTI, Платон Бегун
"Контактный центр по запросу" от CTI, Платон Бегун
 
Microsoft BI User Group: Работаем с 1С эффективно
Microsoft BI User Group: Работаем с 1С эффективноMicrosoft BI User Group: Работаем с 1С эффективно
Microsoft BI User Group: Работаем с 1С эффективно
 
Microsoft BI User Group: Работаем с 1С эффективно
Microsoft BI User Group: Работаем с 1С эффективноMicrosoft BI User Group: Работаем с 1С эффективно
Microsoft BI User Group: Работаем с 1С эффективно
 
SQL Server StreamIinsight - data processing in real time
SQL Server StreamIinsight - data processing in real timeSQL Server StreamIinsight - data processing in real time
SQL Server StreamIinsight - data processing in real time
 
Avanpost idm пацифика 2016
Avanpost idm пацифика 2016Avanpost idm пацифика 2016
Avanpost idm пацифика 2016
 
Teched2011 1С:Предприятие + MS SQL Server 2008 R2
Teched2011 1С:Предприятие + MS SQL Server 2008 R2Teched2011 1С:Предприятие + MS SQL Server 2008 R2
Teched2011 1С:Предприятие + MS SQL Server 2008 R2
 
IBM ECM & Discovery Strategy
IBM ECM & Discovery StrategyIBM ECM & Discovery Strategy
IBM ECM & Discovery Strategy
 
Сила User Experience - как Dell Foglight может помочь бизнесу
Сила User Experience - как Dell Foglight может помочь бизнесуСила User Experience - как Dell Foglight может помочь бизнесу
Сила User Experience - как Dell Foglight может помочь бизнесу
 
CTI_CC on demand
CTI_CC on demandCTI_CC on demand
CTI_CC on demand
 
Опыт работы с Qlik в компании ВТБ Страхование
Опыт работы с Qlik в компании ВТБ Страхование Опыт работы с Qlik в компании ВТБ Страхование
Опыт работы с Qlik в компании ВТБ Страхование
 
Pronet bmc pro activenet monitoring. Современная система мониторинга и упра...
Pronet   bmc pro activenet monitoring. Современная система мониторинга и упра...Pronet   bmc pro activenet monitoring. Современная система мониторинга и упра...
Pronet bmc pro activenet monitoring. Современная система мониторинга и упра...
 
Виртуальный банковский офис
Виртуальный банковский офисВиртуальный банковский офис
Виртуальный банковский офис
 
How to assess the company's readiness to intelligent automation of office pro...
How to assess the company's readiness to intelligent automation of office pro...How to assess the company's readiness to intelligent automation of office pro...
How to assess the company's readiness to intelligent automation of office pro...
 

More from Ontico

One-cloud — система управления дата-центром в Одноклассниках / Олег Анастасье...
One-cloud — система управления дата-центром в Одноклассниках / Олег Анастасье...One-cloud — система управления дата-центром в Одноклассниках / Олег Анастасье...
One-cloud — система управления дата-центром в Одноклассниках / Олег Анастасье...
Ontico
 
Масштабируя DNS / Артем Гавриченков (Qrator Labs)
Масштабируя DNS / Артем Гавриченков (Qrator Labs)Масштабируя DNS / Артем Гавриченков (Qrator Labs)
Масштабируя DNS / Артем Гавриченков (Qrator Labs)
Ontico
 
Создание BigData-платформы для ФГУП Почта России / Андрей Бащенко (Luxoft)
Создание BigData-платформы для ФГУП Почта России / Андрей Бащенко (Luxoft)Создание BigData-платформы для ФГУП Почта России / Андрей Бащенко (Luxoft)
Создание BigData-платформы для ФГУП Почта России / Андрей Бащенко (Luxoft)
Ontico
 
Готовим тестовое окружение, или сколько тестовых инстансов вам нужно / Алекса...
Готовим тестовое окружение, или сколько тестовых инстансов вам нужно / Алекса...Готовим тестовое окружение, или сколько тестовых инстансов вам нужно / Алекса...
Готовим тестовое окружение, или сколько тестовых инстансов вам нужно / Алекса...
Ontico
 
Новые технологии репликации данных в PostgreSQL / Александр Алексеев (Postgre...
Новые технологии репликации данных в PostgreSQL / Александр Алексеев (Postgre...Новые технологии репликации данных в PostgreSQL / Александр Алексеев (Postgre...
Новые технологии репликации данных в PostgreSQL / Александр Алексеев (Postgre...
Ontico
 
PostgreSQL Configuration for Humans / Alvaro Hernandez (OnGres)
PostgreSQL Configuration for Humans / Alvaro Hernandez (OnGres)PostgreSQL Configuration for Humans / Alvaro Hernandez (OnGres)
PostgreSQL Configuration for Humans / Alvaro Hernandez (OnGres)
Ontico
 
Inexpensive Datamasking for MySQL with ProxySQL — Data Anonymization for Deve...
Inexpensive Datamasking for MySQL with ProxySQL — Data Anonymization for Deve...Inexpensive Datamasking for MySQL with ProxySQL — Data Anonymization for Deve...
Inexpensive Datamasking for MySQL with ProxySQL — Data Anonymization for Deve...
Ontico
 
Опыт разработки модуля межсетевого экранирования для MySQL / Олег Брославский...
Опыт разработки модуля межсетевого экранирования для MySQL / Олег Брославский...Опыт разработки модуля межсетевого экранирования для MySQL / Олег Брославский...
Опыт разработки модуля межсетевого экранирования для MySQL / Олег Брославский...
Ontico
 
ProxySQL Use Case Scenarios / Alkin Tezuysal (Percona)
ProxySQL Use Case Scenarios / Alkin Tezuysal (Percona)ProxySQL Use Case Scenarios / Alkin Tezuysal (Percona)
ProxySQL Use Case Scenarios / Alkin Tezuysal (Percona)
Ontico
 
MySQL Replication — Advanced Features / Петр Зайцев (Percona)
MySQL Replication — Advanced Features / Петр Зайцев (Percona)MySQL Replication — Advanced Features / Петр Зайцев (Percona)
MySQL Replication — Advanced Features / Петр Зайцев (Percona)
Ontico
 
Внутренний open-source. Как разрабатывать мобильное приложение большим количе...
Внутренний open-source. Как разрабатывать мобильное приложение большим количе...Внутренний open-source. Как разрабатывать мобильное приложение большим количе...
Внутренний open-source. Как разрабатывать мобильное приложение большим количе...
Ontico
 
Подробно о том, как Causal Consistency реализовано в MongoDB / Михаил Тюленев...
Подробно о том, как Causal Consistency реализовано в MongoDB / Михаил Тюленев...Подробно о том, как Causal Consistency реализовано в MongoDB / Михаил Тюленев...
Подробно о том, как Causal Consistency реализовано в MongoDB / Михаил Тюленев...
Ontico
 
Балансировка на скорости проводов. Без ASIC, без ограничений. Решения NFWare ...
Балансировка на скорости проводов. Без ASIC, без ограничений. Решения NFWare ...Балансировка на скорости проводов. Без ASIC, без ограничений. Решения NFWare ...
Балансировка на скорости проводов. Без ASIC, без ограничений. Решения NFWare ...
Ontico
 
Перехват трафика — мифы и реальность / Евгений Усков (Qrator Labs)
Перехват трафика — мифы и реальность / Евгений Усков (Qrator Labs)Перехват трафика — мифы и реальность / Евгений Усков (Qrator Labs)
Перехват трафика — мифы и реальность / Евгений Усков (Qrator Labs)
Ontico
 
И тогда наверняка вдруг запляшут облака! / Алексей Сушков (ПЕТЕР-СЕРВИС)
И тогда наверняка вдруг запляшут облака! / Алексей Сушков (ПЕТЕР-СЕРВИС)И тогда наверняка вдруг запляшут облака! / Алексей Сушков (ПЕТЕР-СЕРВИС)
И тогда наверняка вдруг запляшут облака! / Алексей Сушков (ПЕТЕР-СЕРВИС)
Ontico
 
Как мы заставили Druid работать в Одноклассниках / Юрий Невиницин (OK.RU)
Как мы заставили Druid работать в Одноклассниках / Юрий Невиницин (OK.RU)Как мы заставили Druid работать в Одноклассниках / Юрий Невиницин (OK.RU)
Как мы заставили Druid работать в Одноклассниках / Юрий Невиницин (OK.RU)
Ontico
 
Разгоняем ASP.NET Core / Илья Вербицкий (WebStoating s.r.o.)
Разгоняем ASP.NET Core / Илья Вербицкий (WebStoating s.r.o.)Разгоняем ASP.NET Core / Илья Вербицкий (WebStoating s.r.o.)
Разгоняем ASP.NET Core / Илья Вербицкий (WebStoating s.r.o.)
Ontico
 
100500 способов кэширования в Oracle Database или как достичь максимальной ск...
100500 способов кэширования в Oracle Database или как достичь максимальной ск...100500 способов кэширования в Oracle Database или как достичь максимальной ск...
100500 способов кэширования в Oracle Database или как достичь максимальной ск...
Ontico
 
Apache Ignite Persistence: зачем Persistence для In-Memory, и как он работает...
Apache Ignite Persistence: зачем Persistence для In-Memory, и как он работает...Apache Ignite Persistence: зачем Persistence для In-Memory, и как он работает...
Apache Ignite Persistence: зачем Persistence для In-Memory, и как он работает...
Ontico
 
Механизмы мониторинга баз данных: взгляд изнутри / Дмитрий Еманов (Firebird P...
Механизмы мониторинга баз данных: взгляд изнутри / Дмитрий Еманов (Firebird P...Механизмы мониторинга баз данных: взгляд изнутри / Дмитрий Еманов (Firebird P...
Механизмы мониторинга баз данных: взгляд изнутри / Дмитрий Еманов (Firebird P...
Ontico
 

More from Ontico (20)

One-cloud — система управления дата-центром в Одноклассниках / Олег Анастасье...
One-cloud — система управления дата-центром в Одноклассниках / Олег Анастасье...One-cloud — система управления дата-центром в Одноклассниках / Олег Анастасье...
One-cloud — система управления дата-центром в Одноклассниках / Олег Анастасье...
 
Масштабируя DNS / Артем Гавриченков (Qrator Labs)
Масштабируя DNS / Артем Гавриченков (Qrator Labs)Масштабируя DNS / Артем Гавриченков (Qrator Labs)
Масштабируя DNS / Артем Гавриченков (Qrator Labs)
 
Создание BigData-платформы для ФГУП Почта России / Андрей Бащенко (Luxoft)
Создание BigData-платформы для ФГУП Почта России / Андрей Бащенко (Luxoft)Создание BigData-платформы для ФГУП Почта России / Андрей Бащенко (Luxoft)
Создание BigData-платформы для ФГУП Почта России / Андрей Бащенко (Luxoft)
 
Готовим тестовое окружение, или сколько тестовых инстансов вам нужно / Алекса...
Готовим тестовое окружение, или сколько тестовых инстансов вам нужно / Алекса...Готовим тестовое окружение, или сколько тестовых инстансов вам нужно / Алекса...
Готовим тестовое окружение, или сколько тестовых инстансов вам нужно / Алекса...
 
Новые технологии репликации данных в PostgreSQL / Александр Алексеев (Postgre...
Новые технологии репликации данных в PostgreSQL / Александр Алексеев (Postgre...Новые технологии репликации данных в PostgreSQL / Александр Алексеев (Postgre...
Новые технологии репликации данных в PostgreSQL / Александр Алексеев (Postgre...
 
PostgreSQL Configuration for Humans / Alvaro Hernandez (OnGres)
PostgreSQL Configuration for Humans / Alvaro Hernandez (OnGres)PostgreSQL Configuration for Humans / Alvaro Hernandez (OnGres)
PostgreSQL Configuration for Humans / Alvaro Hernandez (OnGres)
 
Inexpensive Datamasking for MySQL with ProxySQL — Data Anonymization for Deve...
Inexpensive Datamasking for MySQL with ProxySQL — Data Anonymization for Deve...Inexpensive Datamasking for MySQL with ProxySQL — Data Anonymization for Deve...
Inexpensive Datamasking for MySQL with ProxySQL — Data Anonymization for Deve...
 
Опыт разработки модуля межсетевого экранирования для MySQL / Олег Брославский...
Опыт разработки модуля межсетевого экранирования для MySQL / Олег Брославский...Опыт разработки модуля межсетевого экранирования для MySQL / Олег Брославский...
Опыт разработки модуля межсетевого экранирования для MySQL / Олег Брославский...
 
ProxySQL Use Case Scenarios / Alkin Tezuysal (Percona)
ProxySQL Use Case Scenarios / Alkin Tezuysal (Percona)ProxySQL Use Case Scenarios / Alkin Tezuysal (Percona)
ProxySQL Use Case Scenarios / Alkin Tezuysal (Percona)
 
MySQL Replication — Advanced Features / Петр Зайцев (Percona)
MySQL Replication — Advanced Features / Петр Зайцев (Percona)MySQL Replication — Advanced Features / Петр Зайцев (Percona)
MySQL Replication — Advanced Features / Петр Зайцев (Percona)
 
Внутренний open-source. Как разрабатывать мобильное приложение большим количе...
Внутренний open-source. Как разрабатывать мобильное приложение большим количе...Внутренний open-source. Как разрабатывать мобильное приложение большим количе...
Внутренний open-source. Как разрабатывать мобильное приложение большим количе...
 
Подробно о том, как Causal Consistency реализовано в MongoDB / Михаил Тюленев...
Подробно о том, как Causal Consistency реализовано в MongoDB / Михаил Тюленев...Подробно о том, как Causal Consistency реализовано в MongoDB / Михаил Тюленев...
Подробно о том, как Causal Consistency реализовано в MongoDB / Михаил Тюленев...
 
Балансировка на скорости проводов. Без ASIC, без ограничений. Решения NFWare ...
Балансировка на скорости проводов. Без ASIC, без ограничений. Решения NFWare ...Балансировка на скорости проводов. Без ASIC, без ограничений. Решения NFWare ...
Балансировка на скорости проводов. Без ASIC, без ограничений. Решения NFWare ...
 
Перехват трафика — мифы и реальность / Евгений Усков (Qrator Labs)
Перехват трафика — мифы и реальность / Евгений Усков (Qrator Labs)Перехват трафика — мифы и реальность / Евгений Усков (Qrator Labs)
Перехват трафика — мифы и реальность / Евгений Усков (Qrator Labs)
 
И тогда наверняка вдруг запляшут облака! / Алексей Сушков (ПЕТЕР-СЕРВИС)
И тогда наверняка вдруг запляшут облака! / Алексей Сушков (ПЕТЕР-СЕРВИС)И тогда наверняка вдруг запляшут облака! / Алексей Сушков (ПЕТЕР-СЕРВИС)
И тогда наверняка вдруг запляшут облака! / Алексей Сушков (ПЕТЕР-СЕРВИС)
 
Как мы заставили Druid работать в Одноклассниках / Юрий Невиницин (OK.RU)
Как мы заставили Druid работать в Одноклассниках / Юрий Невиницин (OK.RU)Как мы заставили Druid работать в Одноклассниках / Юрий Невиницин (OK.RU)
Как мы заставили Druid работать в Одноклассниках / Юрий Невиницин (OK.RU)
 
Разгоняем ASP.NET Core / Илья Вербицкий (WebStoating s.r.o.)
Разгоняем ASP.NET Core / Илья Вербицкий (WebStoating s.r.o.)Разгоняем ASP.NET Core / Илья Вербицкий (WebStoating s.r.o.)
Разгоняем ASP.NET Core / Илья Вербицкий (WebStoating s.r.o.)
 
100500 способов кэширования в Oracle Database или как достичь максимальной ск...
100500 способов кэширования в Oracle Database или как достичь максимальной ск...100500 способов кэширования в Oracle Database или как достичь максимальной ск...
100500 способов кэширования в Oracle Database или как достичь максимальной ск...
 
Apache Ignite Persistence: зачем Persistence для In-Memory, и как он работает...
Apache Ignite Persistence: зачем Persistence для In-Memory, и как он работает...Apache Ignite Persistence: зачем Persistence для In-Memory, и как он работает...
Apache Ignite Persistence: зачем Persistence для In-Memory, и как он работает...
 
Механизмы мониторинга баз данных: взгляд изнутри / Дмитрий Еманов (Firebird P...
Механизмы мониторинга баз данных: взгляд изнутри / Дмитрий Еманов (Firebird P...Механизмы мониторинга баз данных: взгляд изнутри / Дмитрий Еманов (Firebird P...
Механизмы мониторинга баз данных: взгляд изнутри / Дмитрий Еманов (Firebird P...
 

Отказоустойчивая архитектура фронтальной системы банка / Роман Шеховцов, Алексей Громатчиков (Сбербанк-Технологии)

Editor's Notes

  1. Добрый день, Меня зовут Роман Шеховцов, моего коллегу – Алексей Громатчиков. Мы работаем в компании Сбербанк-технологии, где отвечаем за архитектуру Единой фронтальной системы.
  2. Сегодня мы на примере работающих у нас решений, в первую очередь Сбербанк-онлайн расскажем как обеспечивается отказоустойчивость банковских систем при обслуживании 100 млн клиентов Поднимите руку те, кто пользуется сервисами Сбербанка. Спасибо. На самом все пользуетесь, просто не все знаете об этом, в конце доклада скажу, почему. Неважно, какая у вас система и сколько клиентов – если вы реализуете 3 основных принципа, о которых мы расскажем, то получите отказоустойчивую систему, и сможете обслуживать своих клиентов, даже тогда, когда ваши сервисы недоступны.
  3. Небольшая вводная. Банк устроен просто. Он делится на: Фронт-офис – системы, связанные с непосредственным обслуживанием клиентов. Мидл-офис – системы оценки риска и принятия решений – защита от мошенничества, системы принятия решений по кредитным заявкам Бэк-офис – обработка и исполнение операций – бухгалтерия, начисление процентов, формирование отчетности.
  4. Фронтальная система – это высоконагруженное приложение, отвечающее за взаимодействие с сервисами Банка в одном или нескольких каналах обслуживания. Каналы обслуживания - это интернет-банк, мобильный банк, отделения банка, банкоматы, контактный центр. В некоторых каналах пользователями системы являются клиенты банка, а в некоторых – сотрудники.
  5. В реальности типовой IT-ландшафт крупного банка, это несколько сотен систем - собственной разработки, заказные и коробочные решения. Эти системы разного уровня надежности, доступности, с разным SLA и при этом между ними множество интеграций. Как же в таких условиях обеспечить отказоустойчивость при обслуживании клиентов?
  6. Да также, как в подводной лодке. Во первых, подводная лодка разделена на независимые отсеки. Если один отсек затопило, остальные уцелели. Во вторых, в подводной лодке используется резервирование критичных узлов – баллоны с кислородом, двигатели, вот здесь сочли необходимым зарезервировать перископы… Почему бы и нет. И наконец, подводная лодка может действовать автономно, вне зависимости от того, что происходит во внешнем мире.
  7. Был у нас один случай. Распределенный кэш, 3 управляющих узла, 7-8 узлов с данными, фактор репликации 3. Под нагрузкой один из узлов с данными вышел из строя. Управляющие узлы подумали, что что-то не так… И инициировали процедуру пере-балансировки данных на оставшихся узлам, чтобы обеспечить требуемый фактор репликации. Подскочил сетевой трафик, начали теряться пакеты по внутреннему трафику кэша. Управляющие ноды подумали, что что-то не так…
  8. Через несколько минут кэш целиком упал. Ситуация усугублялась тем, что довольно много времени потратили на поиск причины, т.к. из симптомов было совершенно не очевидно, что происходит. Вот здесь вы видите озадаченных админов. К счастью, все это произошло во время нагрузочного тестирования, и никто не пострадал.
  9. Были другие случаи, когда кластеризованные БД, навороченные hi-end cервера с внутренним резервированием отказывали целиком. Причины разные – сбои в управляющем ПО, проблемы конфигурирования. В отдельности каждая проблема решалась, но «осадочек оставался»… Пришли к выводу, что не отказывает целиком то, что не связано зависимостями, в первую очередь по управлению.
  10. Так возникла многоблочная архитектура, в которой всё «железо» end-to-end, от веб-серверов до баз данных разделено на слабо-связанные, независимо работающие блоки. Каждый блок обслуживает часть пользователей. Любые проблемы в одном блоке не затрагивают остальные. Здесь возникают вопросы: - а как мы распределяем пользователей между блоками? - что делать происходит при отказе блока? - и как обеспечивается отказоустойчивость внутри блока? Об этом расскажет мой коллега Алексей.
  11. Добрый день всем присутствующим и наблюдающим по видеотрансляции. Какие же отказы возможны в блоках?.. Как и в любой системе возможны сбои и отказы на каждом уровне от железа до человеческого фактора. Что касается блока, то можно рассмотреть сбои следующим образом: Сбой в некритичном компоненте Сбой компонента, работа которого не влияет на общую работоспособность системы. Как видим на схеме, сбой на одном сервере приложений не влияет на обслуживание клиентов в целом. 2. Сбой в единой точке отказа На схеме видим, что такой точкой может служить база данных блока и ее отказ влечет за собой отказ обслуживания клиентов данного блока. 3. Отказ площадки/ЦОД Данный отказ приводит к потере всех компонент блока, размещаемых на данной площадке. 4. Отказ блока Отказ блока может произойти не только по причине выхода из строя единой точки отказа или площадки, но также и в следствии неудачного внедрения обновления или коллапса системы, например, возможно зависание тредов на серверах приложениях из-за того что один из сервером JMS начинает зависать и на большом потоке данных, который мы имеем в нашей системе, меньше чем за минуту будут израсходованы все пулы потоков на серверах приложений, который будут в состоянии ожидания ответа из очереди JMS. Как же обслужить клиентов в ситуации отказа блока, пока ребята делают свою работу?
  12. Давайте рассмотрим как клиент попадает в систему. Первоначально клиент обращается в компонент маршрутизации, который «редиректит» его в родной блок в соответствии с табличной функцией шардирования. Клиент попадает в блок, где уже ему доступен полный функционал системы. В системе есть 3 основных клиентских блока, обслуживающих примерно по 10 млн. активных клиентов. Примерно 3000 серверов приложений обслуживают все запросы. В случае возникновения проблем в обслуживании клиента в родном блоке, клиенту необходимо вернутся на компонент маршрутизации, который в этот момент также может быть прозрачно подменен на резервную копию, где, в случае проблем с блоком, ему будет определен резервный блок, куда его «редиректят» на этот раз. В резервном блоке клиент сможет получить необходимую ему услугу, просмотреть и, при необходимости, повторить свои операции, выполненные ранее в системе, за счет наличия копии всех данных операций в архивной базе данных. Базы данных блоков в постоянном режиме реплицируют данные операций в архивную базу данных в асинхронном режиме. Для резервного блока реализована прикладная репликация, возвращающая данные операций пользователей в базы данных родных блоков. Перевод клиентов банка в резервный блок может быть принудительным и плановым. При плановом переводе мы даем возможность доработать активным сессиям в блоке, а новые сессии клиентов блока открываются уже в резервном. При принудельном переводе есть возможность инвалидировать все текущие сессии блока и отправить всех клиентов блока на компонент маршрутизации, для дальнейшего перехода в резервный блок. Таким образом в системе существует резервный контур, не используемый в штатном режиме работы, для блоков и компонента маршрутизации, т.е. холодный резерв. На текущий момент это 1 копия компонента маршрутизации и 1 блок с производительностью примерно равной всем блокам, если нет отказов площадок. Теперь предлагаю посмотреть как обеспечивается защита от отказа площадки и резервирование SPOF.
  13. Давайте рассмотрим как клиент попадает в систему. Первоначально клиент обращается в компонент маршрутизации, который «редиректит» его в родной блок в соответствии с табличной функцией шардирования. Клиент попадает в блок, где уже ему доступен полный функционал системы. В системе есть 3 основных клиентских блока, обслуживающих примерно по 10 млн. активных клиентов. Примерно 3000 серверов приложений обслуживают все запросы. В случае возникновения проблем в обслуживании клиента в родном блоке, клиенту необходимо вернутся на компонент маршрутизации, который в этот момент также может быть прозрачно подменен на резервную копию, где, в случае проблем с блоком, ему будет определен резервный блок, куда его «редиректят» на этот раз. В резервном блоке клиент сможет получить необходимую ему услугу, просмотреть и, при необходимости, повторить свои операции, выполненные ранее в системе, за счет наличия копии всех данных операций в архивной базе данных. Базы данных блоков в постоянном режиме реплицируют данные операций в архивную базу данных в асинхронном режиме. Для резервного блока реализована прикладная репликация, возвращающая данные операций пользователей в базы данных родных блоков. Перевод клиентов банка в резервный блок может быть принудительным и плановым. При плановом переводе мы даем возможность доработать активным сессиям в блоке, а новые сессии клиентов блока открываются уже в резервном. При принудельном переводе есть возможность инвалидировать все текущие сессии блока и отправить всех клиентов блока на компонент маршрутизации, для дальнейшего перехода в резервный блок. Таким образом в системе существует резервный контур, не используемый в штатном режиме работы, для блоков и компонента маршрутизации, т.е. холодный резерв. На текущий момент это 1 копия компонента маршрутизации и 1 блок с производительностью примерно равной всем блокам, если нет отказов площадок. Теперь предлагаю посмотреть как обеспечивается защита от отказа площадки и резервирование SPOF.
  14. Тут возможны сложности с восприятием, прошу обратить внимание.. Все компоненты каждого блока размещаются минимум на двух площадках/ЦОД. Распределяются равномерно, для того, чтобы в случае отказа одной из площадок иметь возможность обслужить полный объем клиентов данных блоков. Базы данных также георезервируется по схеме Active-Passive с копированием данных средствами СХД. Получается достаточно дорогая схема, т.к. используются HiEnd массивы с оптоволоконным каналом между площадками для возможности восстановить работу БД после сбоя объемом с десяток терабайт в течении нескольких минут. Каждый гигабайт такого хранилища обходится очень дорого, а нам дополнительно нужны объемы такого хранилища и на тестовые среды. В представленной схеме еще есть такая особенность, что для минимизации влияния отказа ЦОД на систему, активные копии баз данных блоков размещаются в шахматном порядке по площадкам.
  15. Тут все просто. Начинаем всегда с пилотного блока с лояльным клиентами – в нашем случае это сотрудники банка. Мы все должны попробовать сначала сами  Но также есть возможность и остальным клиентам принять участие в Бэта тестировании, если изъявить желание в соц.сетях и других площадка, где банк проводит опросы и набирает добровольцев. Если во время пилотирования понимаем, что обновление неудачное, всегда есть возможность откатить версию, переводом клиентов в резервный блок. При развертывании нового функционала в блоке, для клиентов он становится доступен не сразу, а распространяется по группам клиентов. При этом для обеспечения надежности в системе реализуется управление отдельными бизнес-сервисами – «рубильники». При возникновении проблем в работе какого либо бизнес-сервиса, у администраторов всегда остается возможность отключить данный функционал до момента разбора и «фикса» ошибок. В этой части мы рассмотрели как защититься от отказов системы, но в банке все системы работают в условиях большого количества интеграций с другими системами, и как защитить систему сейчас подробно расскажет Роман.
  16. Спасибо. Итак, мы разобрались, как обеспечивается внутренняя отказоустойчивость системы. Но внешние системы могут быть менее надежными. Что делать, когда они необходимы для выполнения операций, и при этом не работают? Есть три механизма, которые позволяют справляться с этим.
  17. Первый механизм – буферизация и отложенное выполнение операций. Когда клиент хочет выполнить перевод, мы сохраняем черновик операции в своей БД. Если внешняя система недоступна, показываем клиенту сообщение, что «операция принята и находится в обработке». Когда внешняя система поднимается, отдельное приложение-докатчик отправляет в нее невыполненные операции, забирая их пачками на основе данных маркерной таблицы. Маркерная таблица представляет собой список IDшников незавершенных операций и нужна, чтобы не грузить основную таблицу запросами по невыполненным операциям с низкой селективностью. Докатчик работает пачками, с паузами, чтобы не уронить только что поднявшуюся внешнюю систему сотнями тысяч наших отложенных операциями. Что делать, если за время между вводом операции и ее исполнением что-то поменялось? Консистентность обеспечивается двойной верификацией – мы проверяем операцию при вводе, а внешняя система – при исполнении.
  18. Второй механизм – это кэширование данных внешних систем. Давайте рассмотрим кэширование по запросу, на примере профиля клиента. Профиль клиента включает в себя: Информацию о самом клиенте (т.е. ФИО, паспортные данные) Информацию о продуктах клиента (счета, карты, кредиты и т.д.) При входе клиента его профиль собирается через корпоративную сервисную шину из нескольких систем. Если запрос отработал в течении короткого таймаута, мы показываем профиль клиенту и сохраняем результаты в персистентном кэше в собственной БД, с определенным временем жизни. Если ответ на запрос не пришел за короткий таймаут, то берем данные из кэша в БД и показываем их клиенту. Когда ответ все же потом приходит, он вычитывается асинхронно и данные обновляются в персистентом кэше и на UI. Те, кто пользуется Сбербанк-онлайн, могли видеть этот эффект, когда вы заходите в приложение, сначала несколько секунд крутится колесико, потом показываются данные, возможно не актуальные, и еще через несколько секунд данные в приложении обновляются.
  19. Кэширование также может быть с помощью предварительной загрузки данных через репликацию или ETL. Предзагрузка используется в основном для справочных данных. К примеру, при вводе платежа используется много справочников - поставщики услуг, параметры платежей. Если мы реплицируем к себе эти данные, то может предоставить пользователю возможность заполнить все поля и отправить заявку на платеж. Даже когда система, в которой они ведутся, сломалась.
  20. Если внешняя система упала или в ней проводятся технические работы, на нее выставляется технический перерыв. В этом режиме обращение к внешней системе не происходит. Тем самым мы разгружаем наши ресурсы, т.к. потоки на серверах не ждут таймаута. В этом режиме используются кэширование данных и буферизация операций. При этом для кэшированных данных может использоваться dead TTL, который больше обычного TTL. Таким образом, если мы знаем, что внешняя система не доступна, мы можем дольше использовать кэшированные данные, чтобы сохранить функциональность. Технические перерывы выставляются в разрезе отдельных сервисов. Они могут выставляться как вручную, так и автоматически на основе статистики собираемой с серверов приложений – количество выполненных запросов, количество сбойных и т.п. Администратор настраивает правила и пороги срабатывания, опять таки в разрезе отдельных сервисов. Это позволяет гибко подстраиваться к сценариям отказа для каждого конкретного взаимодействия.
  21. Есть случаи, когда кэшировать данные нельзя. Например, при выдаче наличных мы не можем совершить операцию, если недоступна система, в которой ведется остаток по счету. Т.к. это открывает возможность мошенничества. В основном это касается операций в отделениях. В интернет-банке проще, т.к. мы всегда может принять заявку на операцию и потом ее исполнить, либо отклонить.
  22. Мы рассказали о том, как работают существующие фронтальные системы. Перед нами стоит задача перевести эти системы на единую платформу, в единую фронтальную систему. И здесь многоблочная архитектура в чистом виде не применима. Во-первых, у разных категорий клиентов разные данные – профиль физлица и профиль юрлица совсем не похожи. Также есть отличия в сценариях работы – например, в интернет-банке сессия длится несколько минут, а у сотрудника – несколько часов. Уровень нагрузки тоже различается. Что интересно – количество операций в отделения и через интернет-банк отличаются не сильно, но при этом нагрузка на систему интернет-банка на порядок больше. Как вы думаете, почему? Потому что люди ходят проверять не капнула ли зарплата, какой платеж по кредиту, а что там с меня списывали? И вот эти запросы на чтение генерируют основную нагрузку.
  23. Мы рассказали о том, как работают существующие фронтальные системы. Перед нами стоит задача перевести эти системы на единую платформу, в единую фронтальную систему. И здесь многоблочная архитектура в чистом виде не применима. Во-первых, у разных категорий клиентов разные данные – профиль физлица и профиль юрлица совсем не похожи. Также есть отличия в сценариях работы – например, в интернет-банке сессия длится несколько минут, а у сотрудника – несколько часов. Уровень нагрузки тоже различается. Что интересно – количество операций в отделения и через интернет-банк отличаются не сильно, но при этом нагрузка на систему интернет-банка на порядок больше. Как вы думаете, почему? Потому что люди ходят проверять не капнула ли зарплата, какой платеж по кредиту, а что там с меня списывали? И вот эти запросы на чтение генерируют основную нагрузку.
  24. Что мы сделали? Мы ввели сегменты. Каждом сегменте обслуживает определенную категорию пользователей. Как видите, это: Частные клиенты Сотрудники Корпоративные клиенты Эквайринг (это когда вы в магазине расплачиваетесь картой любого банка, а там стоит терминал Сбербанка) В сегментах разное количество блоков.
  25. В части схемы резервирования новая платформа также получила изменения в схемах резервирования компонентов на каждом уровне. Первое заметное изменение – компонент маршрутизации не имеет SPOF и работает одновременно на всех площадках сегмента. Второе – блоки теперь размещаются только в одной ЦОД, что положительно сказывает и на работе блоков, т.к. все запросы клиента обрабатываются в рамках одной площадки. Третье – основные блоки клиентов могут резервировать работу друг друга – объединены в пары георезервированных блоков – кластера блоков. Условие для каждого блока кластера – это возможность обслужить всех клиентов кластера единовременно и располагаться в разных ЦОД для достижения георезерва. В каждом блоке пары клиент получает полную функциональность системы. Таким образом всего с 2n резервом мы резервируем и все компоненты и блоки сегмента. В штатном режиме клиенты все также табличной функцией привязываются к «родному» блоку. Четвертое – кто нибудь из вас возможно попадал в ситуацию, когда вошел в мобильную версию сбербанка онлайн, начал что то делать и тут попал на окно входа опять.. Так вот теперь для уменьшения влияния на клиентов при сбоях разного уровня мы реализовали механизм SSO для прозрачного перехода между серверами приложений и блоков. Пятое – для удобства сопровождения и снижения стоимости решения мы поставили архивную БД в каждый блок, которая содержит данные операций клиентов всего кластера для возможности обслуживания клиентов в лубом из блоков пары. Данные в архивных БД синхронизируются прикладной репликацией в постоянном режиме.
  26. Тут все просто. Обновление в 2 волны, начиная с пилота. Сначала версия отстаивается на пилотном блоке в штатной нагрузке, потом в максимально возможной и далее распространяется сначала на один блок в каждый кластер, затем на второй. Обновление нужно ставить в шахматном порядке по блокам ЦОД в кластерах блоков, чтоб в случае неудачного внедрения в первой волне снизить нагрузку на ЦОД.
  27. Сегмент общих данных Полнота данных в кэше Актуальность данных, т.к. прогрев кэша из всех сегментов История если тут выполнил, там посмотрел и наоборот..
  28. Итак, мы рассказали как устроена подводная лодка: - Она разделена на независимые отсеки - В ней используется резервирование критичных компонентов на всех уровнях - И она может работать независимо от внешнего мира. Реализовав у себя эти три принципа, вы получите отказоустойчивую систему с доступностью 99.99% и выше
  29. Есть много тем, что в доклад не уместилось, например: Как обеспечить отказоустойчивость в микросервисной архитектуре? Поэтому подписывайтесь на блог ЕФС на Хабре, мы будем публиковать там статьи по вопросам отказоустойчивости. Сейчас можно задать вопросы, кто стесняется можно подойти потом. Мы будем благодарны за обратную связь по перспективной архитектуре, которая сейчас реализуется, и таким образом, у вас есть возможность на нее повлиять.