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

Щемелинин Дмитрий Александрович ORCID: 0000-0003-3032-130X доктор технических наук Санкт-Петербургский политехнический университет Петра Великого (СПбПУ) 195251, Россия, г. Санкт-Петербург, ул. Политехническая, 29 Shchemelinin Dmitry Doctor of Technical Science Peter the Great St. Petersburg Polytechnic University 195251, Russia, g. Saint Petersburg, ul. Politekhnicheskaya, 29 dshchmel@gmail.com Другие публикации этого автора

Ефимов Вадим Вячеславович аспирант, кафедра: Инженерная графика и дизайн, Санкт-Петербургский политехнический университет Петра Великого 195251, Россия, г. Санкт-Петербург, ул. Политехническая, 29 Efimov Vadim Vyacheslavovich Postgraduate Student, Department of Engineering Graphics and Design, Peter the Great St. Petersburg Polytechnic University 195251, Russia, g. Saint Petersburg, ul. Politekhnicheskaya, 29 2vadim@inbox.ru

Введение

Современные «облачные» сервисы, такие как электронная почта, телефония, видео связь и социальные сети, завоевывают все большую популярность. «Облачными» сервисами начинают пользоваться не только дома, в личных целях, но и на работе, как часть рабочего процесса. Предприятия заменяют свои традиционные информационные системы на «облачные».

Первым важным критерием для бизнеса при переходе на облачный сервис является уровень доступности - сервис должен отвечать на запросы в режиме «24/7» «при любой погоде», вплоть до локальных катастроф (землетрясение, ураган, падение метеорита). При этом качество предоставления сервиса, такое как время обработки запроса, должно оставаться неизменным даже при большом количестве одновременных обращений. Так, например, компания RingCentral Inc. гарантирует доступность своего телекоммуникационного сервиса на уровне 99,999% ^[11]. Компания Microsoft - доступность Office 365 на уровне 99,9% ^[1].

Такой высокий уровень доступности достигается за счет высокой степени резервирования вычислительных ресурсов (рис.1). Компания RingCentral располагает более 10 тысячами физических и виртуальных серверов, расположенных в 6-и центрах обработки данных (ЦОД) в США и Европе. Избыточность ресурсов составляет более 300% от необходимых при пиковой нагрузке ^[2].

Рис 1. Схема сложной географически распределенной информационной системы

Второй важный критерий при выборе поставщика облачных услуг – набор предоставляемых им сервисов и богатство их функциональности, так называемый «пакет» услуг. Компании стремятся создавать новые сервисы и расширять функциональность, добавляя, например возможность отправить факсы через электронную почту или возможность получать информацию о расходах средств на звонки в реальном времени. Технологически это заключается в проектировании и разработке новых алгоритмов вычислений и системами хранения данных. Появляются вычислительные машины или сервера, специально выделенные для реализации этих вычислений, сервера новых систем хранения данных. Группа серверов, реализующих одни и те же вычисления, функционально однородная группа, называется компонентом системы. В период с 2010 по 2017 годы у компании RingCentral Inc. значительно расширился «пакет» предоставляемых услуг: в дополнение к телефонии за это время у компании появились сервисы обмена мгновенными сообщениями, сервис анализа качества звонков в реальном времени и прочие. Количество компонентов облачного сервиса компании RingCentral Inc. с 2010 по 2017 год выросло с 50 до 200 ^[3].

Параллельно с ростом сложности информационной системы за счет добавления новых компонентов существует еще одна тенденция - рост скорости внедрения инноваций. Существенным конкурентным преимуществом является быстрая реакция на нужды пользователей и возможность быстро компенсировать потенциальное отставание от конкурентов ^[4].

Однако скорость вносимых изменений в информационную систему (ИС) может негативно отразиться на предоставлении информационных услуг, так например 24 сентября 2010 года крупнейшая социальная сеть Facebook стала недоступна на 2,5 часа. Инцидент был вызван плановым обновлением одного из компонентов ИС и затронул всех пользователей ^[5]. Чтобы не подвергать риску сразу всех пользователей, компании в настоящее время часто делят их на группы и выпускают обновление программного обеспечения (ПО) для них по очереди, отслеживая динамику состояние системы и удовлетворенности пользователей. Это называется поэтапное развертывание ПО.

Всё больше компаний адаптируют «гибкие» методологии разработки, такие как Scrum, которые позволяют получать обновление функциональности для пользователей не раз в год, как раньше, при использовании методологии Waterfall, а раз в 3 недели. Существует и дальнейшая тенденция к ускорению доставки новой функциональности конечным потребителям – методология разработки Kanban допускает выпуск обновлений несколько раз в день.

В итоге, имея ИС с а) большим количеством серверов для обеспечения необходимого уровня резервирования, б) большим количеством компонентов для обеспечения широкого набора услуг и в) большим количеством обновлений ПО системы для обеспечения высокой скорости реакции на нужды пользователей, становится актуальным вопрос о том, каков предел интенсивности изменений в сложной глобально распределенной ИС ^{[6, 7]}.

Цель и объект исследования

Целью данной работы является создание методики оценки интенсивности обслуживания глобально распределенной вычислительной системы, который позволяет определить потенциал увеличения скорости внесения изменений ПО в ИС.

В качестве объекта практического исследования было выбрано одно из регулярных крупных обновлений ПО компании RingCentral «Версия ПО 10.1». Новая версия ПО состоит из 141 отдельного изменения и была установлена в ИС в период с февраля по сентябрь 2018 года ^[8]. На рис.2 показана часть этапов развертывания, пришедшихся на июль 2018 года.

Рисунок 2: Этапы развертывания изменений в рамках «Версии ПО 10.1» компании RingCentral Inc. в июле 2018 года

Методика эксперимента и ее математическая модель

Изменение – это перевод системы из старого состояния в новое, обновленное. 16-го августа 2018 года компания RingCentral выпустила крупное обновление своего сервиса обмена мгновенными сообщениями Glip, добавив в него возможность совершать голосовые звонки. Об этом обновлении было объявлено заранее, оно обсуждалось в средствах массовой информации и в профессиональной среде. Это был «маркетинговый ход», способ привлечь новых клиентов. Подобные обновления случаются и у других компаний, предоставляющих «облачные» сервисы, однако чаще обновления бывают не такие «большие» и происходят «тихо», например, компания Microsoft выпустила 40 обновлений Office 365 за 2017 год ^[9]. Это делается для того, чтобы такое «тихое» обновление ПО можно было бы так же «тихо» откатить, снижая степень разочарования клиентов в случае, если, например, обновленная система начнет работать со сбоями. Впрочем, даже такой откат – это серьезная проблема для компании, так как сбивает производственный график. Для решения этой проблемы компании дробят обновления на максимально «мелкие», откат которых не так болезнен. Так, компания RingCentral выпускает 80 «мелких» обновлений месяц. Это, например, установка новой версии операционной системы на серверах или новой версии приложения, отвечающего за обработку телефонного трафика. Такого рода обновление применяется на минимальное количество компонентов системы за раз.

Например, типичные этапы развертывания обновления ПО в компании RingCentral следующие ^[10,12]:

1. Обновление серверов, обслуживающих небольшую группу пользователей, явно изъявивших желание получать обновления первыми, а также мало активных пользователей, для которых сбой в работе «облачного» сервиса будет наименее ощутим. Такую группу часто называют «бета-пользователи».

2. Наблюдение за системой. Если количество жалоб от бета-пользователей не возросло после изменения, а также на основании данных технического мониторинга принимается решение о том, можно ли продолжать развертывание изменения.

3. Обновление серверов, обслуживающих часть пользователей, активно использующих сервис. Это случайная выборка обычных пользователей.

4. Наблюдение за системой. По аналогии с пунктом 2, но с дополнительным вниманием к изменениям в производительности системы принимается решение о том, можно ли продолжать развертывание.

5. Обновление всех оставшихся серверов, относящихся к обновляемым компонентам.

Таким образом, время внесения одного изменения в систему – это сумма временных интервалов, необходимых на каждый из этапов:

где, - время внесения одного изменения; – время одной фазы изменения.

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

1. Сервера аутентификации пользователей;

2. Сервера авторизации пользовательского запроса;

3. Сервера взаимодействия с базой данных;

4. Базы данных;

5. Журналы запросов;

6. Сервера приложений, формирующие ответ пользователю.

В случае внесения изменения в интерфейс компонента API (англ. Application Program Interface), его взаимодействие с другими компонентами в процессе обработки пользовательского запроса может измениться и даже сломаться. Наиболее типичным примером здесь является изменение структуры таблиц в базе данных. Подобное изменение может быть безопасно выполнено только после обновления серверов приложений, взаимодействующих с этой базой данных – сервера приложений должны заранее «научиться» работать с новой структурой таблиц данных. Таким образом, существуют изменения, которые должны быть выполнены в строго определенной последовательности. Появляются зависимости между развертываниями и эти зависимости ограничивают интенсивность внесения изменений, так как зависимые развертывания нельзя делать параллельно, а нужно делать последовательно.

Рисунок 3: Пример зависимостей в группе из 8 изменений. Зеленым обозначены независимые изменения, красным – самая длинная цепь зависимых изменений, синим – остальные.

На рис.3 показан пример зависимостей в группе из 8 изменений. Красным цветом выделена группа из 4 изменений которая является самой длинной цепочкой зависимостей. Эти 4 изменения можно применять только одно за другим. Зеленым – те, которые можно применять независимо от остальных. Синим выделено изменение C1, оно должно предшествовать изменению C4, но не является частью самой длинной цепи изменений. Таким образом, время внесения серии (множества) изменений ПО может быть записано следующим образом:

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

В качестве эксперимента было детально рассмотрено крупное обновление компании RingCentral Inc. «Версия ПО 10.1». Одно из ключевых изменений в рамках этого обновление — «10.1 In-place upgrade». В рамках этого изменения была активирована большая часть новой функциональности «облачного» сервиса. Этапы развертывания этого изменения представлены в таблице 1.

Таблица 1. Экспериментальные данные: этапы развертывания изменения «10.1 In-place upgrade» в рамках обновления «Версии ПО 10.1»

Изменение «10.1 in-place upgrade» было выполнено в 10 этапов, а суммарная продолжительность процесса обновления ИС в рамках этого одного изменения составила 5 дней. Анализ этапов этого и других аналогичных изменений ИС показал, что этапы, представляющие из себя обновления ПО серверов приложений, делаются ночью, в то время, когда количество запросов к «облачному» сервису минимально. На следующий же день, в рабочее время, наступает этап наблюдения за системой, который позволяет убедиться в успешности обновления ИС и продолжить развертывание нового ПО на сдедующий день. Таким образом, для упрощения методики оценки интенсивности изменений, целесообразно измерять продолжительность одного изменения в целых сутках, включающих в себя рабочие дни.

Обновление «облачного» сервиса компании RingCentral Inc. до «Версии ПО 10.1» состояло из 141 отдельного изменения и было выполнено в период времени с 15 февраля по 7 сентября 2018 года. Фактическая продолжительность обновления составила 134 дня, включающих в себя рабочие дни. Для анализа интенсивности данного обновления был проведен анализ всех 141 изменений с целью выявить зависимости между ними и определить самую длинную цепочку зависимых друг от друга изменений ИС. Для каждого подобного изменения в такой цепочке была посчитана длительность из расчета длительности всех его этапов. Результаты представлены в таблице 2.

Таблица 2. Пример последовательной цепочки зависимых изменений ПО в ИС

Анализ экспериментальных данных показал, что сумма продолжительности всех «звеньев», составляющих самую длинную цепочку зависимых изменений ИС, равняется 38 дням. Соответственно, скорость развертывания обновления ПО в глобально распределенной ИС потенциально может быть увеличена примерно в 3,5 раза.

Заключение

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

Был проведен расчет минимальной продолжительности серии изменений фактически развернутого компанией RingCentral Версии ПО 10.1 в 2018 году. Расчет показал, что существует потенциал повышения интенсивности развертывания примерно в 3,5 раза.

Дальнейшего исследования требуют другие ограничения, которые влияют на интенсивность внесения изменения, такие как ограниченность ресурсов (как человеческих, так и электронно-вычислительных), различные технологические ограничение.