Это реальный рассказ об архитектуре Единой Фронтальной Системы (ЕФС) - системы, которая будет обслуживать абсолютно всех клиентов Сбербанка во всех каналах (отделения, интернет-банки, мобильные приложения, АТМ и т.д.). Это означает: десятки миллионов активных клиентов, 24х7, и еще пара NFR'ов, от которых порой вздрагиваешь по ночам :) С одной стороны мы должны гарантировать 99.99% доступность, с другой стороны мы должны сокращать time-to-market для новых продуктов и быть готовыми обновлять ЕФС очень часто и по кусочкам – и это малая часть вызовов, с которыми нам приходиться сталкиваться. В моем докладе я расскажу: · Как мы гарантируем 99.99% доступности для всего ЕФС, включая хранилище (и особенно включая хранилище). · Как мы масштабируемся на миллионы пользователей, оставаясь внешнее единой системой. · Как мы реализуем zero downtime deployment, чтобы оставаться в 99.99% в условиях частых обновлений.

1. Отказоустойчивая архитектура
Единой Фронтальной Системы
Зелинский Максим
Сбербанк-Технологии

2. Для кого этот доклад?

3. Единая Фронтальная Система

4. Единая Фронтальная Система
Open API
Web Mobile
ATM

5. Open API
Web Mobile
ATM
Единая Фронтальная Система

6. Open API
Web
Mobile
ATM
Единая Фронтальная Система

7. Наши показатели на 2016 г.
Интернет банк для физических лиц
• Общее количество пользователей: ~85 000 000
• Количество активных пользователей: ~48 000 000
• Среднее количество операций, в день: ~11 000 000

8. Наш технологический стек
Языки разработки:
• JavaScript/ Native на frontend’е (никакого server side!)
• Java на стороне backend’а (никакого JEE, ну почти )
Инфраструктура:
• NGINX - «умная» балансировка/ отдача статики
• IBM WebSphere Application Server - сервер приложений
• IBM WebSphere ExtremeScale - распределенный кеш
• IBM WebSphere MQ - асинхронный обмен сообщениями
• Oracle Database - хранилище

9. Наш Service Level Agreement
• Режим работы: 24 х 7
• Доступность: 99.99%
• Наличие технологических окон: нет
• RTO (Return Time Objective): не более 1 минуты
• RPO (Return Point Objective): 0 минут
• Disaster Recovery: не более 1 минуты

10. Типичная архитектура типичной
Фронтальной Системы

11. Браузер
Балансировщик
нагрузки
Внешняя система
СУБД
Серверы приложений

12. Браузер
Балансировщик
нагрузки
Внешняя система
СУБД
Серверы приложений
Точки
отказа?

13. Браузер
Балансировщик
нагрузки
Внешняя система
СУБД
Серверы приложений
Точки
отказа?

14. Браузер
Балансировщик
нагрузки
Внешняя система
СУБД
Серверы приложений
Точки
отказа?

15. Браузер
Балансировщик
нагрузки
Внешняя система
Очереди
 Зависимость от внешних систем
СУБД
Серверы приложений

16. Браузер
Балансировщик
нагрузки
Внешняя система
Очереди
 Зависимость от внешних систем
 Единая точка отказа БД
Серверы приложений
СУБД
(active)
СУБД
(standby)
репликация

17. Браузер
Балансировщик
нагрузки
Серверы приложений
Внешняя система
Очереди
2N
 Зависимость от внешних систем
 Единая точка отказа БД
 Уменьшение надежности из за отказа СП
СУБД
(active)
СУБД
(standby)
репликация

18. Браузер
Балансировщик
нагрузки
Серверы приложений
Внешняя система
Очереди
Распределенный кэш
2N
 Зависимость от внешних систем
 Единая точка отказа БД
 Уменьшение надежности из за отказа СП
 Прерывание в обслуживании из за отказа СП
СУБД
(active)
СУБД
(standby)
репликация

19. Браузер
Балансировщик
нагрузки
Серверы приложений
Внешняя система
Очереди
СУБД
(active)
СУБД
(standby)
Распределенный кэш
2N
DNS / Virtual IP
 Зависимость от внешних систем
 Единая точка отказа БД
 Уменьшение надежности из за отказа СП
 Прерывание в обслуживании из за отказа СП
 Единая точка отказа БН
репликация

20. Браузер
Балансировщик
нагрузки
Серверы приложений
Внешняя система
Очереди
СУБД
(active)
СУБД
(standby)
Распределенный кэш
2N
DNS / Virtual IP
Локальный кэш
 Зависимость от внешних систем
 Единая точка отказа БД
 Уменьшение надежности из за отказа СП
 Прерывание в обслуживании из за отказа СП
 Единая точка отказа БН
 Возможность скрыть недоступность (< 1 мин)
репликация

21.  Зависимость от внешних систем
 Единая точка отказа БД
 Уменьшение надежности из за отказа СП
 Прерывание в обслуживании из за отказа СП
 Единая точка отказа БН
 Возможность скрыть недоступность (< 1 мин)
Браузер
Балансировщик
нагрузки
Серверы приложений
Внешняя система
Очереди
СУБД
(active)
СУБД
(standby)
репликация
Распределенный кэш
2N
DNS / Virtual IP
Локальный кэш
И это
все?

22.  Зависимость от внешних систем
 Единая точка отказа БД
 Уменьшение надежности из за отказа СП
 Прерывание в обслуживании из за отказа СП
 Единая точка отказа БН
 Возможность скрыть недоступность (< 1 мин)
Браузер
Балансировщик
нагрузки
Серверы приложений
Внешняя система
Очереди
СУБД
(active)
СУБД
(standby)
репликация
Распределенный кэш
2N
DNS / Virtual IP
Локальный кэш
И это
все?

23.  Зависимость от внешних систем
 Единая точка отказа БД
 Уменьшение надежности из за отказа СП
 Прерывание в обслуживании из за отказа СП
 Единая точка отказа БН
 Возможность скрыть недоступность (< 1 мин)
Браузер
Балансировщик
нагрузки
Серверы приложений
Внешняя система
Очереди
СУБД
(active)
СУБД
(standby)
репликация
Распределенный кэш
2N
DNS / Virtual IP
Локальный кэш
И это
все?

24. Отказоустойчивость и
масштабирование СУБД

25. Отказоустойчивость
• Репликация на уровне СХД
• Репликация средствами СУБД
• Репликация средствами приложения

26. Отказоустойчивость
• Репликация на уровне СХД
• Репликация средствами СУБД
• Репликация средствами приложения
Остановка и поднятие занимает
минимум 30 минут на больших объемах

27. Отказоустойчивость
• Репликация на уровне СХД
• Репликация средствами СУБД
• Репликация средствами приложения
Graceful shutdown по прежнему может
занять кучу времени!
Остановка и поднятие занимает
минимум 30 минут на больших объемах

28. Отказоустойчивость
• Репликация на уровне СХД
• Репликация средствами СУБД
• Репликация средствами приложения
А это вариант!
Graceful shutdown по прежнему может
занять кучу времени!
Остановка и поднятие занимает
минимум 30 минут на больших объемах

29. Масштабирование
• Использование Oracle RAC или аналога
• Offload нагрузки с основной СУБД (read-only режим)
• Средствами приложения (шардинг)

30. • Использование Oracle RAC или аналога
• Offload нагрузки с основной СУБД (read-only режим)
• Средствами приложения (шардинг)
Масштабирование
Не работает! А если работает, то в
пределах одного ДЦ

31. • Использование Oracle RAC или аналога
• Offload нагрузки с основной СУБД (read-only режим)
• Средствами приложения (шардинг)
Масштабирование
Не работает! А если работает, то в
пределах одного ДЦ
Ограниченное
применение

32. • Использование Oracle RAC или аналога
• Offload нагрузки с основной СУБД (read-only режим)
• Средствами приложения (шардинг)
Масштабирование
А это вариант!
Не работает! А если работает, то в
пределах одного ДЦ
Ограниченное
применение

33. Zero downtime deployment

34. Типичный подход
1. Обновление серверов приложений по группам кластеров
2. Обновление структуры БД с сохранением обратной совместимости
3. Повторить

35. Типичный подход
1. Обновление серверов приложений по группам кластеров
2. Обновление структуры БД с сохранением обратной совместимости
3. Повторить
Ок, а если меняется схема
данных радикально?

36. Типичный подход
1. Обновление серверов приложений по группам кластеров
2. Обновление структуры БД с сохранением обратной совместимости
3. Повторить
Ок, а если меняется схема
данных радикально?
Blue / Green
развертывание!

37. Решение?

38. Решение?
Hint: Шардинг, репликация средствами приложения и Blue/Green развертывание

39. Браузер
Балансировщик
нагрузки
СУБДСерверы
приложений

40. Stand-In©

41. Primary
Браузер
Балансировщик
нагрузки
СУБДСерверы
приложений
Stand-In
СУБДСерверы
приложений
Роутер
Консоль
управления
репликация

42. Primary
Браузер
Балансировщик
нагрузки
СУБДСерверы
приложений
Stand-In
СУБДСерверы
приложений
Роутер
Консоль
управления
репликация
 Disaster Recovery за считанные минуты

43. Primary
Браузер
Балансировщик
нагрузки
СУБДСерверы
приложений
Stand-In
СУБДСерверы
приложений
Роутер
Консоль
управления
репликация
 Disaster Recovery за считанные минуты
 Blue / Green развертывание

44. Primary
Браузер
Балансировщик
нагрузки
СУБДСерверы
приложений
Stand-In
СУБДСерверы
приложений
Роутер
Консоль
управления
репликация
 Disaster Recovery за считанные минуты
 Blue / Green развертывание
 Простой оборудования

45. Primary
Браузер
Балансировщик
нагрузки
СУБДСерверы
приложений
Stand-In
СУБДСерверы
приложений
Роутер
Консоль
управления
репликация
 Disaster Recovery за считанные минуты
 Blue / Green развертывание
 Простой оборудования
 Не решается проблема масштабирования

46. Многоблочность©

47. Блок 1
Браузер
Балансировщик
нагрузки
СУБДСерверы
приложений
Блок 2
СУБДСерверы
приложений
Роутер
репликация
 Disaster Recovery за считанные минуты
 Blue / Green развертывание
 Простой оборудования
 Не решается проблема масштабирования
Блок NКонсоль
управления

48. Блок 1
Браузер
Балансировщик
нагрузки
СУБДСерверы
приложений
Блок 2
СУБДСерверы
приложений
Роутер
 Disaster Recovery за считанные минуты
 Blue / Green развертывание
 Простой оборудования
 Не решается проблема масштабирования
Блок NКонсоль
управления
репликация

49. Блок 1
Браузер
Балансировщик
нагрузки
СУБДСерверы
приложений
Блок 2
СУБДСерверы
приложений
Роутер
 Disaster Recovery за считанные минуты
 Blue / Green развертывание
 Простой оборудования
 Не решается проблема масштабирования
Блок NКонсоль
управления
репликация

50. Блок 1
Браузер
Балансировщик
нагрузки
СУБДСерверы
приложений
Блок 2
СУБДСерверы
приложений
Роутер
Блок NКонсоль
управления
репликация
В чем магия?

51. Блок 1
Браузер
Балансировщик
нагрузки
СУБДСерверы
приложений
Блок 2
СУБДСерверы
приложений
Роутер
Блок NКонсоль
управления
репликация
В чем магия?
• Роутер

52. Блок 1
Браузер
Балансировщик
нагрузки
СУБДСерверы
приложений
Блок 2
СУБДСерверы
приложений
Роутер
Блок NКонсоль
управления
репликация
В чем магия?
• Роутер
• Репликация

53. Роутер

55. Блок 1
СУБДСерверы
приложений
Блок N
Пользователи

56. Блок 1
СУБДСерверы
приложений
Блок N
Пользователи Auth

57. Блок 1
СУБДСерверы
приложений
Блок N
{ id }
Пользователи Auth

58. Распределенный кэш
Блок 1
СУБДСерверы
приложений
Блок NREST
Маппинг пользователей
{ id }
Пользователи Auth

59. Распределенный кэш
Блок 1
СУБДСерверы
приложений
Блок NREST
Маппинг пользователей
{ id }
Пользователи Auth

60. Распределенный кэш
Блок 1
СУБДСерверы
приложений
Блок NREST
Маппинг пользователей
{ id }
cookie { номер блока }
Пользователи Auth

61. Репликация между блоками

62. Какие данные мы храним?
• Справочники (внутренние и внешние)
• Операционные данные

63. Справочники
Блок 1Внутренние
справочники
Блок N
Управление
справочниками
Oracle GoldenGate
Очереди
Внешние справочники

64. Справочники
Блок 1Внутренние
справочники
Блок N
Управление
справочниками
Очереди
Внешние справочники

65. Операционные данные
Блок 1 Блок N
Консоль
управления
dblink

66. Операционные данные
Блок 1 Блок N
Консоль
управления
dblink
В штатном режиме
операционные данные не
реплицируются

67. А как же noSQL решения?

68. А как же noSQL решения?
Everybody lies!

69. А как же noSQL решения?
Everything fails!

70. Выводы

71. Выводы
• На больших объемах архитектура становится очень нетривиальной

72. Выводы
• На больших объемах архитектура становится очень нетривиальной
• Если у вас 99.99%, 24 х 7, RPO 0, RTO 1, DR «не 4 часа» - то вы попали

73. Выводы
• На больших объемах архитектура становится очень нетривиальной
• Если у вас 99.99%, 24 х 7, RPO 0, RTO 1, DR «не 4 часа» - то вы попали
• Все падает 

74. Контакты
Зелинский Максим
MVZelinsky.SBT@sberbank.ru
https://linkedin.com/in/maxzelinski