Фрагмент книги: «To the Cloud: Cloud Powering an Enterprise»

Перевод, оригинальная статья Book Excerpt: "To The Cloud: Cloud Powering an Enterprise".

Здравствуйте, я Панкадж Арора, старший менеджер в команде глобальных стратегических инициатив Microsoft IT (Microsoft IT Global Strategic).

Когда генеральный директор Microsoft Стив Болмер в марте 2010 года публично заявил, что
мы переходим в облако, он не просто имел в виду продукты Microsoft для публичного и частного облака. Он также имел в виду то, что ИТ подразделение самой Microsoft должно начать этот переход одними из первых. И, конечно, мы это сделали, за этого время мы многое узнали о том, что необходимо сделать для успешного внедрения облачных вычислениях в крупной и географически распределённой компании. На данный момент у нас используются разные облачные модели— SaaS (Software as Service), PaaS (Platform as Service), и IaaS (Infrastructure as Service), а так же мы начинаем использовать DaaS (Data as Service), т.е. данные как сервис.

Многочисленный накопленный опыт развертывания приложений и прогнозы аналитических компаний о растущем спросе в сфере облачных вычислений, явились поводом для написания книги в соавторстве с двумя моими коллегами. Книга называется ”To the Cloud: Cloud Powering an Enterprise”, основное внимание в книге уделено двум вопросам: почему крупным компаниям могут быть полезны и интересны облачные вычисления и какими образом облачные вычисления могут быть внедрены в компании. Рекомендации по внедрению облачной инфраструктуры основаны не только на нашем собственном опыте, но и на опыте наших Клиентов и Партнеров.
Ниже приведен отрывок из главы 4, сама книга доступна в печатном и электронном виде. Дополнительные сведения о книге можно получить на веб-сайте .

Pankaj

Архитектурные принципы

Сам по себе перенос приложений и данных за переделы локального ЦОДа предприятия не исключает риск сбоев оборудования, не решает проблему выделения дополнительных мощностей при увеличении количества пользователей приложения и не гарантирует решение других схожих проблем. Но если сервис спроектирован правильно, то масштабируемость, производительность и надежность такого сервиса, работающего в облаке, должны быть значительно выше, чем при локально размещении.

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

Быстрое восстановление (Resiliency)

Правильно спроектированное приложение не должно теряють работоспособность только из-за того, что какая-то единицы масштабирования (scale unit) вышла из строя. И наоборот, для неправильно спроектированного приложения возникновение проблемы даже только в ожном компоненте может привести к снижению производительности, потери данных или полному сбою всей системы. Поэтому многие разработчики облачных сервисов при проектировании исходят именно из худшего сценария развития событий, т.е. изначально при проектировании закладывают логику отказоустойчивости (fault tolerant) и быстрого восстановления (resilient).

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

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

• блок пользовательского интерфейса отвечает за представления информации для пользователя;
• блок обработки изображений отвечает за обработку изображений и изменения из размера;
• блок управления аукционом устанавливает правила торговли и обновляет
  данные в базе.

В начале аукциона большая нагрузка ложится на блок обработки изображений, т.к. многие пользователи загружают изображения в каталог. В конце аукциона, когда пользователи пытаются выиграть тот или иной лот, основная нагрузка приходится на блок управления аукционом. При этом каждый блок может масштабироваться (за счет scale unit’ов) независимо друг от друга. А так же если, предположим, в блоке обработчика изображений происходит сбой, это не приводит к полному отказу всего сервиса. В наиболее простом случае, scale unit’ом может быть просто один экземпляр приложения.

Проектирование с учетом возможности возникновения внештатной ситуации, наличие у облачных провайдеров мер для быстрого восстановления в случае проблем и автоматизация части операций в общем случае делают облачные сервисы более надежными. Зачастую облачные провайдеры имеют несколько «зон доступности», которые функционирую независимо друг от друга с инфраструктурной точки зрения (сеть, оборудование, источники энергии), хотя при этом являются частью единой облачной платформы. Разнесение scale unit’ов одного приложения или сервиса по разным зонам помогает достичь дальнейшего снижения риска выхода приложения или сервиса из строя. Некоторые облачные провайдеры требуют такого размещения для гарантирования более высокового уровня SLA. Таким образом, необходимо участь следующее при рассмотрении ситуации возможного сбоя:

• Каким образом ИТ-подразделение получит информацию о возникшем сбое?
• Какие функциональные возможности приложения (если таковые есть), по-прежнему будут доступны?
• Какие шаги потребуются, чтобы восстановить данные и функциональность приложения?

Устранение ненужных зависимостей делает приложение более стабильным. Если сервис, на который полагается приложение в одном сценарии, становится недоступным, то работоспособность других сценариев приложения не должна пострадать.

В связи с тем, что некоторые облачные провайдеры могут ограничивать или принудительно завершать долго выполняющиеся запросы на SQL PaaS или на других платформах хранения данных, разработчики в своем приложении обязательно должны предусматривать логику повторных попыток соединения и выполнения запросов (retry logic). Например, компонент, который запрашивает данные из другого источника, может включать логику, которая повторяет попытки получения данных указанное число раз в течение фиксированного периода времени, и только после этого выдает исключение, т.е. если все попытки отказались неудачными.

Для того чтобы положение было устойчиво к возможных перезагрузкам экземпляров (например, из-за установки обновлений или выхода оборудования из строя), в приложении необходимо использовать persistent-хранилище или распределенный кэш. Это позволит другому scale unit’у или даже перезагруженному экземпляру восстановить транзакции и данные. Это подводит нас к еще одному принципу проектирования облачных приложений - statelessness, который подразумевает хранение состояния приложения не локально на экземпляре.

Statelessness (хранение состояния приложения не локально на экземпляре)

Важно отметить, что проектирование приложения с учетом принципа в statelessness критично для достижения высокой масштабируемости и отказоустойчивости. Вне зависимости от того, является ли перерыв в работе экземпляра непредвиденными или запланированным (например, системные обновления), после выхода из строя одного scale unit’а другой scale unit берет на себя весь объём работ. Пользователи приложения при этом не должны заметить, что
что-либо случилось. Поэтому очень важно при развертывании приложения в облаке иметь более одного scale unit’а для каждого бизнес-критичного приложения, это позволит не только решить вопрос масштабирования, но и вопрос отказоустойчивости и доступности.

Обычно в течение сеанса работы с приложением запросы пользователя обслуживаются различными scale unit’ами, т.е. нет привязки всех запросов к одному экземпляру. Это называется “stateless load balancing” или “lack of session affinity”. Разработчики не должны хранить состояние приложения или состояние сеанса в оперативной памяти экземпляра (scale unit), поскольку нет гарантии, что все последюущие запросы пользователя будет направлены конкретно на этот же экземпляр. Таким образом, без соблюдения принципа stateless приложение не сможет правильно масштабироваться в облаке. Большинство облачных провайдеров предлагают persistent-хранилища для сохранения состояния, к такому хранилищу сможет обратиться каждый экземпляр (scale unit). Например, для Windows Azure такими хранилищами являются Windows Azure Storage и SQL Azure.

Распараллеливание

Еще одни из основных принципов облачного проектирования - это распараллеливание задач и многопоточность. Автоматическая балансировка нагрузки и другие облачные службы помогают с относительной легкостью распределять нагрузку. Например, добавление нового scale unit’а для параллельной обработки достигается за счет программного вызова нескольких методов.

Принцип параллелизации может так же использоваться для высокопроизводительных вычислений (high performance computing), таких как аналитическая обработка данных в режиме реального времени. Многие облачные провайдеры прямо или косвенно поддерживают платформы, позволяющие разделять большие задачи на подзадачи и запускать для них параллельную обработку. Например, Microsoft совместно с университетом Вашингтона использовала возможности Windows Azure для выполнения научных исследований. В ходе эксперимента было произведено 2, 5 миллиона вычислительных операций менее чем за одну неделю (иначе данные вычисления могли занять месяцы).

Сетевая задержка

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

• Используйте кэширование, особенно для данных, получаемых из систем, доступ к которым характеризуется высокой сетевой задержкой, например, это системы расположенныне локально (вне облака).
• Уменьшайте частоту и объем данных, передаваемых между компонентами, особенно в случае интеграции с локальными системами.
• Используйте возможности гео-распределения системы и репликации данных по всему миру. Например, CDN (сеть доставки контента или сеть кэширующих серверов) в Windows Azure позволяет пользователям получать BLOB-данные из ближайшей точки кэширования, а не непосредственно из хранилища в дата-центре.

Автоматическое масштабирование

Если облачный провайдер предоставляет возможность автоматического масштабирования, то разработчики могут с помощью служб диагностики (Diagnostic API) получить данные о текущей нагрузке и воспользоваться службами управления (Management API) для изменения количества работающих экземпляров (scale unit). Примером показателя, на основании которого принимается подобные решения, может нагрузка на CPU: когда загрузка CPU достигает определенных пороговых значений, автоматически добавляется новый экземпляр. Такой же шаблон можно применять и для уменьшения количества работающих экземпляров при снижении уровня нагрузки.

Другой вариант – это логика, основанная на финансовых показателях. Например, разработчики могут добавить логику управления затратами, чтобы ограничить возможности по автоматическому масштабированию для некритических для бизнеса приложений.

Масштабирование данных является не менее важным, чем масштабирование самого приложения. С одной стороны переосмысление архитектуры уровня данных для облачного приложения может показаться очень трудоемким, но с другой стороны может привести к значительному улучшению производительности и надежности. Например, облачная служба хранилища данных не предлагает решения для размещения достаточно объема данных, то предлагается разделить набор данных на патриции и распределить между экземплярами. Такой подход называется шардированием (sharding) и является стандартным для многих облачных платформ, включая SQL Azure. Даже если в этом сейчас нет необходимости, но это может стать необходимым со временем при увеличении объема хранимых данных.