- PVSM.RU - https://www.pvsm.ru -
В разработке Программы «Единая фронтальная система» Сбербанка участвуют больше сотни команд. Каждая команда создает и развивает определенный продукт или сервисный компонент. Для каждой новой инициативы требуется оценить объем «железа», который потребуется для разработки и внедрения этой инициативы. А это большой поток запросов на оценку. О том, как мы решаем эту задачу, читайте под катом.
Оценка требуется на старте — для резервирования бюджета и финансового обоснования инициативы. Как правило, мы имеем предварительную архитектуру и оценки от бизнеса по планируемой нагрузке, а также оценки от технолога по нагрузке на интеграционные взаимодействия. Итоговое количество и состав позиций могут корректироваться по ходу проектирования и реализации или по результатам нагрузочного тестирования. То есть все осложняется тем, что входных данных мало и «это не точно».
Но есть и сглаживающие факторы. Несмотря на то, что расчет ведется раздельно, все зарезервированное железо попадает в общий резервный пул Программы ЕФС. Это позволяет во многих местах использовать «среднюю температуру по больнице» — если по факту в одном случае нагрузка оказалась больше, это нивелируется в другом. Дополнительным сглаживающим фактором служит то, что наличие в резервном пуле не означает непосредственных расходов, поскольку управление парком оборудования централизованно и физический резерв является общим на весь банк. Для нас важнее минимизировать системную погрешность, чем погрешность в конкретном сайзинге.
Это означает, что классический подход к проведению сайзинга, подразумевающий для каждой инициативы разработку сайзинг-модели, множество входных параметров и отдельный расчет для каждого компонента, здесь не подходит. К счастью, система у нас все-таки единая, есть три-четыре типовые архитектуры, собираемые из типовых «кубиков». Поэтому удалось свести всю сложность и вариативность в общую сайзинг-модель.
Сайзинг-модель представляет собой шаблон из нескольких разделов. Рассмотрим каждый из них подробнее.
Мы минимизировали количество входных данных, оставив только те, которые существенно влияют на оценку «железа», и при этом могут быть получены на раннем этапе от продуктовой команды. Ключевым входным параметром является пиковое количество бизнес-операций в час.
Мы разделяем входные данные для удаленных каналов и внутренней сети.
В обоих случаях мы получаем от заказчика оценку:
Также получаем количество запросов через MQ (Messages Queue) интеграции с внешними системами.
Внутренняя сеть | |
Наименование | Комментарий |
Пиковое количество бизнес-операций за час | Берется из бизнес-требований либо рассчитывается: операций за сутки/10 |
Среднее количество бизнес-операций за сутки | Берется из бизнес-требований либо рассчитывается: операций за час*10 |
Пиковое количество запросов через MQ в секунду (прямая интеграция с внешними системами) | Сумма по взаимодействиям точка-точка через MQ |
Внешняя сеть | |
Наименование | Комментарий |
Пиковое количество бизнес-операций за час | Берется из бизнес-требований либо рассчитывается: операций за сутки/10 |
Среднее количество бизнес-операций за сутки | Берется из бизнес-требований либо рассчитывается: операций за час*10 |
«Магическое число» 10, связывающее пиковый объем за час и средний за сутки, используется, когда заказчик не может оценить оба параметра сам. Оно основано на опыте промышленной эксплуатации систем Сбербанка и определяется следующими особенностями его бизнеса:
Параметры модели
Посмотреть схему крупнее. [1]
Рисунок 1. Упрощенная архитектура ЕФС
Архитектура ЕФС основана на классической трехзвенной архитектуре
Параметры разбиты на три группы:
Они практически всегда модифицируются архитектором для конкретного сайзинга. Ключевыми параметрами являются коэффициенты, связывающие количество бизнес-операций с количеством входящих http-запросов. Здесь же включаются/выключаются типовые «кубики» и определяется распределение потоков запросов между ними.
Это типовые параметры производительности, подходящие для большинства случаев.
Типовые параметры производительности железа в наших условиях. Например, производительность MQ мы берем при отключенной персистентности, так как не используем персистентные сообщения.
Параметры модели:
Расчетные коэффициенты
В таблице приведено описание коэффициентов, для себя выработали значения. Если интересно, задавайте вопросы в комментариях – поделимся экспертными оценками.
Модель расчета с расчетными формулами, отображающая входные данные и параметры в итоговые оценки по каждой позиции.
Опишем упрощенную сайзинг-модель. В ней сокращен набор позиций и не отражена многоблочная организация промышленной среды. Упрощения сделаны для того, чтобы не перегружать статью аспектами, которые не интересны, если ваш бизнес не имеет масштабов Сбербанка. Многоблочная архитектура является темой для отдельной статьи – о ней расскажем в других постах.
Сервера приложений и web-сервера выделяются под каждый прикладной сервис. Мы не совмещаем разные прикладные сервисы, чтобы исключить взаимовлияние по отказам или при техническом обслуживании. Базы данных общие и считаются для финансового обоснования и прогнозирования.
Ниже приведены формулы, которые мы используем для расчета.
Считается как перемножение пикового числа пользователей на число запросов в секунду.
В данный расчет входит раздача статики, маршрутизация запросов и кэширование для внутренней сети.
Количество Web-серверов внутренней сети
На выходе сайзинг-модели мы получаем оценку «железа» для промышленной среды.
В мировой практике выделяют три основные модели сайзинга:
Модель, основанная на анализе числа одновременно работающих пользователей в системе и их поведении. Данная модель ориентирована на компании, которые располагают общей информацией о числе пользователей и их поведении в информационной системе.
Модель, основанная на анализе транзакций, объеме данных в ИС, который приходится на одного пользователя или группу пользователей. Данная модель ориентирована на компании, которые располагают точными данными о количественных характеристиках работы сотрудников в ИС. Это означает, что в данной компании есть ИТ-инфраструктура, компания находится на этапе внедрения системы автоматизации бизнес-процессов либо их совершенствования.
Модель, основанная на проведении тестов производительности. Данная модель ориентирована на компании, которые располагают четким планом внедрения бизнес-приложений с подробной проработкой деталей. В основном это компании, которые уже внедрили какую-либо систему автоматизации бизнес-процессов, но желают расширить функционал системы. Либо существующая ИТ-инфраструктура не выдерживает текущую нагрузку.
В программе ЕФС у нас комбо из «Транзакционной модели» и «Тестовой модели». Так как мы обладаем информацией о количестве пиковой нагрузки бизнес-операций, но также руководствуемся показателями, полученными из проведённого нагрузочного тестирования. Но есть особые случаи, когда в ЕФС внедряется новый функционал, которого не было в других системах, и нам на вход поступают предполагаемые данные, тогда мы действуем по аналогии с «Пользовательской моделью».
Давайте пообщаемся, а какую модель используете вы?
Автор: EFS_programm
Источник [2]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/zhelezo/263672
Ссылки в тексте:
[1] крупнее.: https://habrastorage.org/web/9e1/dfc/9e4/9e1dfc9e49de4d7a890359144e42c07f.png
[2] Источник: https://habrahabr.ru/post/337676/
Нажмите здесь для печати.