high-availability architecture of unified frontend platform (in russian)

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

Сбербанк-Технологии

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

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


Open API Web Mobile

ATM

Open API

Web

Mobile

ATM


Наши показатели на 2016 г.

Интернет банк для физических лиц

• Общее количество пользователей: ~85 000 000

• Количество активных пользователей: ~48 000 000

• Среднее количество операций, в день: ~11 000 000

Наш технологический стек

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

Наш Service Level Agreement

• Режим работы: 24 х 7

• Доступность: 99.99%

• Наличие технологических окон: нет

• RTO (Return Time Objective): не более 1 минуты

• RPO (Return Point Objective): 0 минут

• Disaster Recovery: не более 1 минуты

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

Браузер Балансировщик

нагрузки

Внешняя система

СУБД

Серверы приложений


нагрузки

Внешняя система

СУБД


Точки отказа?


нагрузки

Внешняя система Очереди

Зависимость от внешних систем

СУБД



нагрузки


Зависимость от внешних систем Единая точка отказа БД


СУБД (active)

СУБД (standby)

реп

ли

кац

ия


нагрузки



2N

Зависимость от внешних систем Единая точка отказа БД Уменьшение надежности из за отказа СП

СУБД (active)

СУБД (standby)

реп

ли

кац

ия


нагрузки



Распределенный кэш

2N

Зависимость от внешних систем Единая точка отказа БД Уменьшение надежности из за отказа СП Прерывание в обслуживании из за отказа СП

СУБД (active)

СУБД (standby)

реп

ли

кац

ия


нагрузки



СУБД (active)

СУБД (standby)


2N

DNS / Virtual IP

Зависимость от внешних систем Единая точка отказа БД Уменьшение надежности из за отказа СП Прерывание в обслуживании из за отказа СП Единая точка отказа БН

реп

ли

кац

ия


нагрузки



СУБД (active)

СУБД (standby)


2N

DNS / Virtual IP

Локальный кэш

Зависимость от внешних систем Единая точка отказа БД Уменьшение надежности из за отказа СП Прерывание в обслуживании из за отказа СП Единая точка отказа БН Возможность скрыть недоступность (< 1 мин)

реп

ли

кац

ия

Зависимость от внешних систем Единая точка отказа БД Уменьшение надежности из за отказа СП Прерывание в обслуживании из за отказа СП Единая точка отказа БН Возможность скрыть недоступность (< 1 мин)


нагрузки



СУБД (active)

СУБД (standby)

реп

ли

кац

ия


2N

DNS / Virtual IP

Локальный кэш

И это все?

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

Отказоустойчивость • Репликация на уровне СХД

• Репликация средствами СУБД

• Репликация средствами приложения




Остановка и поднятие занимает

минимум 30 минут на больших объемах




Graceful shutdown по прежнему может

занять кучу времени!






А это вариант!

Graceful shutdown по прежнему может

занять кучу времени!



Масштабирование • Использование Oracle RAC или аналога

• Offload нагрузки с основной СУБД (read-only режим)

• Средствами приложения (шардинг)

• Использование Oracle RAC или аналога



Масштабирование

Не работает! А если работает, то в пределах одного ДЦ





Не работает! А если работает, то в пределах одного ДЦ

Ограниченное применение





А это вариант!

Не работает! А если работает, то в

пределах одного ДЦ

Ограниченное применение

Zero downtime deployment

Типичный подход

1. Обновление серверов приложений по группам кластеров

2. Обновление структуры БД с сохранением обратной совместимости

3. Повторить




3. Повторить Ок, а если меняется схема

данных радикально?




3. Повторить Ок, а если меняется схема

данных радикально?

Blue / Green развертывание!

Решение?

Решение?

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


нагрузки СУБД Серверы

приложений

Stand-In©

Primary


нагрузки

СУБД Серверы приложений

Stand-In


Роутер

Консоль управления

реп

ли

кац

ия

Primary


нагрузки


Stand-In


Роутер


реп

ли

кац

ия

Disaster Recovery за считанные минуты

Primary


нагрузки


Stand-In


Роутер


реп

ли

кац

ия


Blue / Green развертывание

Primary


нагрузки


Stand-In


Роутер


реп

ли

кац

ия



Простой оборудования

Primary


нагрузки


Stand-In


Роутер


реп

ли

кац

ия




Не решается проблема масштабирования

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

Блок 1


нагрузки


Блок 2


Роутер реп

ли

кац

ия





Блок N Консоль управления

Блок 1


нагрузки


Блок 2


Роутер






реп

ли

кац

ия

Блок 1


нагрузки


Блок 2


Роутер


реп

ли

кац

ия

В чем магия?

Блок 1


нагрузки


Блок 2


Роутер


реп

ли

кац

ия

В чем магия? • Роутер

Блок 1


нагрузки


Блок 2


Роутер


реп

ли

кац

ия

В чем магия? • Роутер

• Репликация

Роутер

Блок 1


Блок N

Пользователи

Блок 1


Блок N

Пользователи Auth

Блок 1


Блок N

{ id }



Блок 1


Блок N REST

Маппинг пользователей

{ id }



Блок 1


Блок N REST

Маппинг пользователей

{ id }

cookie { номер блока }


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

Какие данные мы храним?

• Справочники (внутренние и внешние)

• Операционные данные

Справочники

Блок 1 Внутренние справочники

Блок N

Управление справочниками

Oracle GoldenGate

Очереди

Внешние справочники

Справочники

Блок 1 Внутренние справочники

Блок N

Управление справочниками

Очереди

Внешние справочники

Операционные данные

Блок 1 Блок N


dblink

Операционные данные

Блок 1 Блок N


dblink

В штатном режиме операционные данные не

реплицируются

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


Everybody lies!


Everything fails!

Выводы

Выводы

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

Выводы


• Если у вас 99.99%, 24 х 7, RPO 0, RTO 1, DR «не 4 часа» - то вы попали

Выводы


• Если у вас 99.99%, 24 х 7, RPO 0, RTO 1, DR «не 4 часа» - то вы попали

• Все падает

Контакты

Зелинский Максим [email protected] https://linkedin.com/in/maxzelinski

mailto:[email protected]

mailto:[email protected]

https://linkedin.com/in/maxzelinski



high-availability architecture of unified frontend platform (in russian)

Software