Это реальный рассказ об архитектуре Единой Фронтальной Системы (ЕФС) - системы, которая будет обслуживать абсолютно всех клиентов Сбербанка во всех каналах (отделения, интернет-банки, мобильные приложения, АТМ и т.д.). Это означает: десятки миллионов активных клиентов, 24х7, и еще пара NFR'ов, от которых порой вздрагиваешь по ночам :)
С одной стороны мы должны гарантировать 99.99% доступность, с другой стороны мы должны сокращать time-to-market для новых продуктов и быть готовыми обновлять ЕФС очень часто и по кусочкам – и это малая часть вызовов, с которыми нам приходиться сталкиваться.
В моем докладе я расскажу:
· Как мы гарантируем 99.99% доступности для всего ЕФС, включая хранилище (и особенно включая хранилище).
· Как мы масштабируемся на миллионы пользователей, оставаясь внешнее единой системой.
· Как мы реализуем zero downtime deployment, чтобы оставаться в 99.99% в условиях частых обновлений.
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 минуты
21. Зависимость от внешних систем
Единая точка отказа БД
Уменьшение надежности из за отказа СП
Прерывание в обслуживании из за отказа СП
Единая точка отказа БН
Возможность скрыть недоступность (< 1 мин)
Браузер
Балансировщик
нагрузки
Серверы приложений
Внешняя система
Очереди
СУБД
(active)
СУБД
(standby)
репликация
Распределенный кэш
2N
DNS / Virtual IP
Локальный кэш
И это
все?
22. Зависимость от внешних систем
Единая точка отказа БД
Уменьшение надежности из за отказа СП
Прерывание в обслуживании из за отказа СП
Единая точка отказа БН
Возможность скрыть недоступность (< 1 мин)
Браузер
Балансировщик
нагрузки
Серверы приложений
Внешняя система
Очереди
СУБД
(active)
СУБД
(standby)
репликация
Распределенный кэш
2N
DNS / Virtual IP
Локальный кэш
И это
все?
23. Зависимость от внешних систем
Единая точка отказа БД
Уменьшение надежности из за отказа СП
Прерывание в обслуживании из за отказа СП
Единая точка отказа БН
Возможность скрыть недоступность (< 1 мин)
Браузер
Балансировщик
нагрузки
Серверы приложений
Внешняя система
Очереди
СУБД
(active)
СУБД
(standby)
репликация
Распределенный кэш
2N
DNS / Virtual IP
Локальный кэш
И это
все?
26. Отказоустойчивость
• Репликация на уровне СХД
• Репликация средствами СУБД
• Репликация средствами приложения
Остановка и поднятие занимает
минимум 30 минут на больших объемах
27. Отказоустойчивость
• Репликация на уровне СХД
• Репликация средствами СУБД
• Репликация средствами приложения
Graceful shutdown по прежнему может
занять кучу времени!
Остановка и поднятие занимает
минимум 30 минут на больших объемах
28. Отказоустойчивость
• Репликация на уровне СХД
• Репликация средствами СУБД
• Репликация средствами приложения
А это вариант!
Graceful shutdown по прежнему может
занять кучу времени!
Остановка и поднятие занимает
минимум 30 минут на больших объемах
30. • Использование Oracle RAC или аналога
• Offload нагрузки с основной СУБД (read-only режим)
• Средствами приложения (шардинг)
Масштабирование
Не работает! А если работает, то в
пределах одного ДЦ
31. • Использование Oracle RAC или аналога
• Offload нагрузки с основной СУБД (read-only режим)
• Средствами приложения (шардинг)
Масштабирование
Не работает! А если работает, то в
пределах одного ДЦ
Ограниченное
применение
32. • Использование Oracle RAC или аналога
• Offload нагрузки с основной СУБД (read-only режим)
• Средствами приложения (шардинг)
Масштабирование
А это вариант!
Не работает! А если работает, то в
пределах одного ДЦ
Ограниченное
применение
34. Типичный подход
1. Обновление серверов приложений по группам кластеров
2. Обновление структуры БД с сохранением обратной совместимости
3. Повторить
35. Типичный подход
1. Обновление серверов приложений по группам кластеров
2. Обновление структуры БД с сохранением обратной совместимости
3. Повторить
Ок, а если меняется схема
данных радикально?
36. Типичный подход
1. Обновление серверов приложений по группам кластеров
2. Обновление структуры БД с сохранением обратной совместимости
3. Повторить
Ок, а если меняется схема
данных радикально?
Blue / Green
развертывание!
72. Выводы
• На больших объемах архитектура становится очень нетривиальной
• Если у вас 99.99%, 24 х 7, RPO 0, RTO 1, DR «не 4 часа» - то вы попали
73. Выводы
• На больших объемах архитектура становится очень нетривиальной
• Если у вас 99.99%, 24 х 7, RPO 0, RTO 1, DR «не 4 часа» - то вы попали
• Все падает