Как оптимально рассчитать объем «железа»: сайзинг-модель ЕФС

В разработке Программы «Единая фронтальная система» Сбербанка участвуют больше сотни команд. Каждая команда создает и развивает определенный продукт или сервисный компонент. Для каждой новой инициативы требуется оценить объем «железа», который потребуется для разработки и внедрения этой инициативы. А это большой поток запросов на оценку. О том, как мы решаем эту задачу, читайте под катом.

Оценка требуется на старте — для резервирования бюджета и финансового обоснования инициативы. Как правило, мы имеем предварительную архитектуру и оценки от бизнеса по планируемой нагрузке, а также оценки от технолога по нагрузке на интеграционные взаимодействия. Итоговое количество и состав позиций могут корректироваться по ходу проектирования и реализации или по результатам нагрузочного тестирования. То есть все осложняется тем, что входных данных мало и «это не точно».

Но есть и сглаживающие факторы. Несмотря на то, что расчет ведется раздельно, все зарезервированное железо попадает в общий резервный пул Программы ЕФС. Это позволяет во многих местах использовать «среднюю температуру по больнице» — если по факту в одном случае нагрузка оказалась больше, это нивелируется в другом. Дополнительным сглаживающим фактором служит то, что наличие в резервном пуле не означает непосредственных расходов, поскольку управление парком оборудования централизованно и физический резерв является общим на весь банк. Для нас важнее минимизировать системную погрешность, чем погрешность в конкретном сайзинге.

Это означает, что классический подход к проведению сайзинга, подразумевающий для каждой инициативы разработку сайзинг-модели, множество входных параметров и отдельный расчет для каждого компонента, здесь не подходит. К счастью, система у нас все-таки единая, есть три-четыре типовые архитектуры, собираемые из типовых «кубиков». Поэтому удалось свести всю сложность и вариативность в общую сайзинг-модель.

Что такое сайзинг-модель в ЕФС?

Сайзинг-модель представляет собой шаблон из нескольких разделов. Рассмотрим каждый из них подробнее.

Раздел 1. Входные данные

Мы минимизировали количество входных данных, оставив только те, которые существенно влияют на оценку «железа», и при этом могут быть получены на раннем этапе от продуктовой команды. Ключевым входным параметром является пиковое количество бизнес-операций в час.
Мы разделяем входные данные для удаленных каналов и внутренней сети.

В обоих случаях мы получаем от заказчика оценку:

1. Пикового количества бизнес-операций в час. Этот показатель является ключевым и влияет на требуемые мощности по обработке операций.
2. Среднего количества бизнес-операций за сутки. Определяет объем хранимых данных.

Также получаем количество запросов через MQ (Messages Queue) интеграции с внешними системами.

«Магическое число» 10, связывающее пиковый объем за час и средний за сутки, используется, когда заказчик не может оценить оба параметра сам. Оно основано на опыте промышленной эксплуатации систем Сбербанка и определяется следующими особенностями его бизнеса:

1. В России 12 часовых поясов, отделения и клиенты распределены по всем часовым поясам, время работы отделений – 10–12 часов в сутки.
2. Наибольшее количество пользователей и операций сосредоточено в часовом поясе Москвы, этот пояс определяет пиковую нагрузку.
3. График распределения нагрузки по часам имеет два пика — утром и после обеда, в целом одинаков для всех часовых поясов с учетом временного сдвига.

Параметры модели

Посмотреть схему крупнее.

Рисунок 1. Упрощенная архитектура ЕФС
Архитектура ЕФС основана на классической трехзвенной архитектуре

1. Презентационный слой. Чаще всего – просто nginx со статикой, в специальных случаях добавляется сервер приложений.
2. Сервера приложений с бизнес-логикой.
3. Базы данных.

Раздел 2. Параметры модели

Параметры разбиты на три группы:

• параметры, зависящие от реализуемого функционала.

Они практически всегда модифицируются архитектором для конкретного сайзинга. Ключевыми параметрами являются коэффициенты, связывающие количество бизнес-операций с количеством входящих http-запросов. Здесь же включаются/выключаются типовые «кубики» и определяется распределение потоков запросов между ними.

• параметры, которые могут изменяться для конкретного сайзинга.  

Это типовые параметры производительности, подходящие для большинства случаев.

• фиксированные параметры.

Типовые параметры производительности железа в наших условиях. Например, производительность MQ мы берем при отключенной персистентности, так как не используем персистентные сообщения.  
Параметры модели:

Расчетные коэффициенты

В таблице приведено описание коэффициентов, для себя выработали значения. Если интересно, задавайте вопросы в комментариях – поделимся экспертными оценками.

Раздел 3. Модель расчета

Модель расчета с расчетными формулами, отображающая входные данные и параметры в итоговые оценки по каждой позиции.

Опишем упрощенную сайзинг-модель. В ней сокращен набор позиций и не отражена многоблочная организация промышленной среды.  Упрощения сделаны для того, чтобы не перегружать статью аспектами, которые не интересны, если ваш бизнес не имеет масштабов Сбербанка. Многоблочная архитектура является темой для отдельной статьи – о ней расскажем в других постах.

Сервера приложений и web-сервера выделяются под каждый прикладной сервис. Мы не совмещаем разные прикладные сервисы, чтобы исключить взаимовлияние по отказам или при техническом обслуживании.  Базы данных общие и считаются для финансового обоснования и прогнозирования.

Ниже приведены формулы, которые мы используем для расчета.

• Пиковое количество запросов в секунду во внутренней сети:

Считается как перемножение пикового числа пользователей на число запросов в секунду.

• Пиковое количество запросов в секунду во внешней сети:

• Расчет количества web-серверов.

В данный расчет входит раздача статики, маршрутизация запросов и кэширование для внутренней сети.

Количество Web-серверов внутренней сети

• Количество Web-серверов во внешней сети

• Мобильный шлюз внешней сети

• Презентационная логика во внешней сети

• Презентационная логика во внутренней сети

• Расчет серверов приложений для бизнес-логики

• MQ (аудит + логирование + интеграция точка-точка)

• Распределенный внутренний кеш

• Расчет СУБД

• Количество CPU БД

• Количество RAM БД

• Размер БД

На выходе сайзинг-модели мы получаем оценку «железа» для промышленной среды.
В мировой практике выделяют три основные модели сайзинга:

• Пользовательская модель

Модель, основанная на анализе числа одновременно работающих пользователей в системе и их поведении. Данная модель ориентирована на компании, которые располагают общей информацией о числе пользователей и их поведении в информационной системе.

• Транзакционная модель

Модель, основанная на анализе транзакций, объеме данных в ИС, который приходится на одного пользователя или группу пользователей. Данная модель ориентирована на компании, которые располагают точными данными о количественных характеристиках работы сотрудников в ИС. Это означает, что в данной компании есть ИТ-инфраструктура, компания находится на этапе внедрения системы автоматизации бизнес-процессов либо их совершенствования.

• Тестовая модель

Модель, основанная на проведении тестов производительности. Данная модель ориентирована на компании, которые располагают четким планом внедрения бизнес-приложений с подробной проработкой деталей. В основном это компании, которые уже внедрили какую-либо систему автоматизации бизнес-процессов, но желают расширить функционал системы. Либо существующая ИТ-инфраструктура не выдерживает текущую нагрузку.

В программе ЕФС у нас комбо из «Транзакционной модели» и «Тестовой модели». Так как мы обладаем информацией о количестве пиковой нагрузки бизнес-операций, но также руководствуемся показателями, полученными из проведённого нагрузочного тестирования. Но есть особые случаи, когда в ЕФС внедряется новый функционал, которого не было в других системах, и нам на вход поступают предполагаемые данные, тогда мы действуем по аналогии с «Пользовательской моделью».

Давайте пообщаемся, а какую модель используете вы?

Автор: EFS_programm

Источник