Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Высокопроизводительная и отказоустойчивая архитектура фронтальных систем / Максим Зелинский (СберТех)

1,393 views

Published on

Это реальный рассказ об архитектуре Единой Фронтальной Системы (ЕФС) - системы, которая будет обслуживать абсолютно всех клиентов Сбербанка во всех каналах (отделения, интернет-банки, мобильные приложения, АТМ и т.д.). Это означает: десятки миллионов активных клиентов, 24х7, и еще пара NFR'ов, от которых порой вздрагиваешь по ночам :)

С одной стороны мы должны гарантировать 99.99% доступность, с другой стороны мы должны сокращать time-to-market для новых продуктов и быть готовыми обновлять ЕФС очень часто и по кусочкам – и это малая часть вызовов, с которыми нам приходиться сталкиваться.

В моем докладе я расскажу:
· Как мы гарантируем 99.99% доступности для всего ЕФС, включая хранилище (и особенно включая хранилище).
· Как мы масштабируемся на миллионы пользователей, оставаясь внешнее единой системой.
· Как мы реализуем zero downtime deployment, чтобы оставаться в 99.99% в условиях частых обновлений.

Published in: Engineering
  • Login to see the comments

Высокопроизводительная и отказоустойчивая архитектура фронтальных систем / Максим Зелинский (СберТех)

  1. 1. Отказоустойчивая архитектура Единой Фронтальной Системы Зелинский Максим Сбербанк-Технологии
  2. 2. Для кого этот доклад?
  3. 3. Единая Фронтальная Система
  4. 4. Единая Фронтальная Система Open API Web Mobile ATM
  5. 5. Open API Web Mobile ATM Единая Фронтальная Система
  6. 6. Open API Web Mobile ATM Единая Фронтальная Система
  7. 7. Наши показатели на 2016 г. Интернет банк для физических лиц • Общее количество пользователей: ~85 000 000 • Количество активных пользователей: ~48 000 000 • Среднее количество операций, в день: ~11 000 000
  8. 8. Наш технологический стек Языки разработки: • JavaScript/ Native на frontend’е (никакого server side!) • Java на стороне backend’а (никакого JEE, ну почти ) Инфраструктура: • NGINX - «умная» балансировка/ отдача статики • IBM WebSphere Application Server - сервер приложений • IBM WebSphere ExtremeScale - распределенный кеш • IBM WebSphere MQ - асинхронный обмен сообщениями • Oracle Database - хранилище
  9. 9. Наш Service Level Agreement • Режим работы: 24 х 7 • Доступность: 99.99% • Наличие технологических окон: нет • RTO (Return Time Objective): не более 1 минуты • RPO (Return Point Objective): 0 минут • Disaster Recovery: не более 1 минуты
  10. 10. Типичная архитектура типичной Фронтальной Системы
  11. 11. Браузер Балансировщик нагрузки Внешняя система СУБД Серверы приложений
  12. 12. Браузер Балансировщик нагрузки Внешняя система СУБД Серверы приложений Точки отказа?
  13. 13. Браузер Балансировщик нагрузки Внешняя система СУБД Серверы приложений Точки отказа?
  14. 14. Браузер Балансировщик нагрузки Внешняя система СУБД Серверы приложений Точки отказа?
  15. 15. Браузер Балансировщик нагрузки Внешняя система Очереди  Зависимость от внешних систем СУБД Серверы приложений
  16. 16. Браузер Балансировщик нагрузки Внешняя система Очереди  Зависимость от внешних систем  Единая точка отказа БД Серверы приложений СУБД (active) СУБД (standby) репликация
  17. 17. Браузер Балансировщик нагрузки Серверы приложений Внешняя система Очереди 2N  Зависимость от внешних систем  Единая точка отказа БД  Уменьшение надежности из за отказа СП СУБД (active) СУБД (standby) репликация
  18. 18. Браузер Балансировщик нагрузки Серверы приложений Внешняя система Очереди Распределенный кэш 2N  Зависимость от внешних систем  Единая точка отказа БД  Уменьшение надежности из за отказа СП  Прерывание в обслуживании из за отказа СП СУБД (active) СУБД (standby) репликация
  19. 19. Браузер Балансировщик нагрузки Серверы приложений Внешняя система Очереди СУБД (active) СУБД (standby) Распределенный кэш 2N DNS / Virtual IP  Зависимость от внешних систем  Единая точка отказа БД  Уменьшение надежности из за отказа СП  Прерывание в обслуживании из за отказа СП  Единая точка отказа БН репликация
  20. 20. Браузер Балансировщик нагрузки Серверы приложений Внешняя система Очереди СУБД (active) СУБД (standby) Распределенный кэш 2N DNS / Virtual IP Локальный кэш  Зависимость от внешних систем  Единая точка отказа БД  Уменьшение надежности из за отказа СП  Прерывание в обслуживании из за отказа СП  Единая точка отказа БН  Возможность скрыть недоступность (< 1 мин) репликация
  21. 21.  Зависимость от внешних систем  Единая точка отказа БД  Уменьшение надежности из за отказа СП  Прерывание в обслуживании из за отказа СП  Единая точка отказа БН  Возможность скрыть недоступность (< 1 мин) Браузер Балансировщик нагрузки Серверы приложений Внешняя система Очереди СУБД (active) СУБД (standby) репликация Распределенный кэш 2N DNS / Virtual IP Локальный кэш И это все?
  22. 22.  Зависимость от внешних систем  Единая точка отказа БД  Уменьшение надежности из за отказа СП  Прерывание в обслуживании из за отказа СП  Единая точка отказа БН  Возможность скрыть недоступность (< 1 мин) Браузер Балансировщик нагрузки Серверы приложений Внешняя система Очереди СУБД (active) СУБД (standby) репликация Распределенный кэш 2N DNS / Virtual IP Локальный кэш И это все?
  23. 23.  Зависимость от внешних систем  Единая точка отказа БД  Уменьшение надежности из за отказа СП  Прерывание в обслуживании из за отказа СП  Единая точка отказа БН  Возможность скрыть недоступность (< 1 мин) Браузер Балансировщик нагрузки Серверы приложений Внешняя система Очереди СУБД (active) СУБД (standby) репликация Распределенный кэш 2N DNS / Virtual IP Локальный кэш И это все?
  24. 24. Отказоустойчивость и масштабирование СУБД
  25. 25. Отказоустойчивость • Репликация на уровне СХД • Репликация средствами СУБД • Репликация средствами приложения
  26. 26. Отказоустойчивость • Репликация на уровне СХД • Репликация средствами СУБД • Репликация средствами приложения Остановка и поднятие занимает минимум 30 минут на больших объемах
  27. 27. Отказоустойчивость • Репликация на уровне СХД • Репликация средствами СУБД • Репликация средствами приложения Graceful shutdown по прежнему может занять кучу времени! Остановка и поднятие занимает минимум 30 минут на больших объемах
  28. 28. Отказоустойчивость • Репликация на уровне СХД • Репликация средствами СУБД • Репликация средствами приложения А это вариант! Graceful shutdown по прежнему может занять кучу времени! Остановка и поднятие занимает минимум 30 минут на больших объемах
  29. 29. Масштабирование • Использование Oracle RAC или аналога • Offload нагрузки с основной СУБД (read-only режим) • Средствами приложения (шардинг)
  30. 30. • Использование Oracle RAC или аналога • Offload нагрузки с основной СУБД (read-only режим) • Средствами приложения (шардинг) Масштабирование Не работает! А если работает, то в пределах одного ДЦ
  31. 31. • Использование Oracle RAC или аналога • Offload нагрузки с основной СУБД (read-only режим) • Средствами приложения (шардинг) Масштабирование Не работает! А если работает, то в пределах одного ДЦ Ограниченное применение
  32. 32. • Использование Oracle RAC или аналога • Offload нагрузки с основной СУБД (read-only режим) • Средствами приложения (шардинг) Масштабирование А это вариант! Не работает! А если работает, то в пределах одного ДЦ Ограниченное применение
  33. 33. Zero downtime deployment
  34. 34. Типичный подход 1. Обновление серверов приложений по группам кластеров 2. Обновление структуры БД с сохранением обратной совместимости 3. Повторить
  35. 35. Типичный подход 1. Обновление серверов приложений по группам кластеров 2. Обновление структуры БД с сохранением обратной совместимости 3. Повторить Ок, а если меняется схема данных радикально?
  36. 36. Типичный подход 1. Обновление серверов приложений по группам кластеров 2. Обновление структуры БД с сохранением обратной совместимости 3. Повторить Ок, а если меняется схема данных радикально? Blue / Green развертывание!
  37. 37. Решение?
  38. 38. Решение? Hint: Шардинг, репликация средствами приложения и Blue/Green развертывание
  39. 39. Браузер Балансировщик нагрузки СУБДСерверы приложений
  40. 40. Stand-In©
  41. 41. Primary Браузер Балансировщик нагрузки СУБДСерверы приложений Stand-In СУБДСерверы приложений Роутер Консоль управления репликация
  42. 42. Primary Браузер Балансировщик нагрузки СУБДСерверы приложений Stand-In СУБДСерверы приложений Роутер Консоль управления репликация  Disaster Recovery за считанные минуты
  43. 43. Primary Браузер Балансировщик нагрузки СУБДСерверы приложений Stand-In СУБДСерверы приложений Роутер Консоль управления репликация  Disaster Recovery за считанные минуты  Blue / Green развертывание
  44. 44. Primary Браузер Балансировщик нагрузки СУБДСерверы приложений Stand-In СУБДСерверы приложений Роутер Консоль управления репликация  Disaster Recovery за считанные минуты  Blue / Green развертывание  Простой оборудования
  45. 45. Primary Браузер Балансировщик нагрузки СУБДСерверы приложений Stand-In СУБДСерверы приложений Роутер Консоль управления репликация  Disaster Recovery за считанные минуты  Blue / Green развертывание  Простой оборудования  Не решается проблема масштабирования
  46. 46. Многоблочность©
  47. 47. Блок 1 Браузер Балансировщик нагрузки СУБДСерверы приложений Блок 2 СУБДСерверы приложений Роутер репликация  Disaster Recovery за считанные минуты  Blue / Green развертывание  Простой оборудования  Не решается проблема масштабирования Блок NКонсоль управления
  48. 48. Блок 1 Браузер Балансировщик нагрузки СУБДСерверы приложений Блок 2 СУБДСерверы приложений Роутер  Disaster Recovery за считанные минуты  Blue / Green развертывание  Простой оборудования  Не решается проблема масштабирования Блок NКонсоль управления репликация
  49. 49. Блок 1 Браузер Балансировщик нагрузки СУБДСерверы приложений Блок 2 СУБДСерверы приложений Роутер  Disaster Recovery за считанные минуты  Blue / Green развертывание  Простой оборудования  Не решается проблема масштабирования Блок NКонсоль управления репликация
  50. 50. Блок 1 Браузер Балансировщик нагрузки СУБДСерверы приложений Блок 2 СУБДСерверы приложений Роутер Блок NКонсоль управления репликация В чем магия?
  51. 51. Блок 1 Браузер Балансировщик нагрузки СУБДСерверы приложений Блок 2 СУБДСерверы приложений Роутер Блок NКонсоль управления репликация В чем магия? • Роутер
  52. 52. Блок 1 Браузер Балансировщик нагрузки СУБДСерверы приложений Блок 2 СУБДСерверы приложений Роутер Блок NКонсоль управления репликация В чем магия? • Роутер • Репликация
  53. 53. Роутер
  54. 54. Блок 1 СУБДСерверы приложений Блок N Пользователи
  55. 55. Блок 1 СУБДСерверы приложений Блок N Пользователи Auth
  56. 56. Блок 1 СУБДСерверы приложений Блок N { id } Пользователи Auth
  57. 57. Распределенный кэш Блок 1 СУБДСерверы приложений Блок NREST Маппинг пользователей { id } Пользователи Auth
  58. 58. Распределенный кэш Блок 1 СУБДСерверы приложений Блок NREST Маппинг пользователей { id } Пользователи Auth
  59. 59. Распределенный кэш Блок 1 СУБДСерверы приложений Блок NREST Маппинг пользователей { id } cookie { номер блока } Пользователи Auth
  60. 60. Репликация между блоками
  61. 61. Какие данные мы храним? • Справочники (внутренние и внешние) • Операционные данные
  62. 62. Справочники Блок 1Внутренние справочники Блок N Управление справочниками Oracle GoldenGate Очереди Внешние справочники
  63. 63. Справочники Блок 1Внутренние справочники Блок N Управление справочниками Очереди Внешние справочники
  64. 64. Операционные данные Блок 1 Блок N Консоль управления dblink
  65. 65. Операционные данные Блок 1 Блок N Консоль управления dblink В штатном режиме операционные данные не реплицируются
  66. 66. А как же noSQL решения?
  67. 67. А как же noSQL решения? Everybody lies!
  68. 68. А как же noSQL решения? Everything fails!
  69. 69. Выводы
  70. 70. Выводы • На больших объемах архитектура становится очень нетривиальной
  71. 71. Выводы • На больших объемах архитектура становится очень нетривиальной • Если у вас 99.99%, 24 х 7, RPO 0, RTO 1, DR «не 4 часа» - то вы попали
  72. 72. Выводы • На больших объемах архитектура становится очень нетривиальной • Если у вас 99.99%, 24 х 7, RPO 0, RTO 1, DR «не 4 часа» - то вы попали • Все падает 
  73. 73. Контакты Зелинский Максим MVZelinsky.SBT@sberbank.ru https://linkedin.com/in/maxzelinski

×