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

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

• Веб-приложение на базе IIS и SQL Server.
• Веб-приложения для электронной коммерции.
• Высоконагруженный сайт Web 2.0.
• Веб-сайт на PHP и MySQL.
• Параллельная обработка данных.

Веб-приложение на базе IIS и SQL Server

Веб-приложения, использующие веб-сервер Internet Information Services и SQL Server довольно часто применяются для различных задач автоматизации в современной организации. Как правило, пользователями приложений являются сотрудники организации. Перенос таких приложений в Windows Azure может существенно повысить надежность работы, избавить от множества проблем с сопровождением и администрированием инфраструктуры и обеспечить высокое качество предоставления сервиса, обычно недостижимое для большинства приложений уровня департамента. Также, перенос в Windows Azure позволит заложить основу для будущего роста использования приложения, например, если организация примет решение использовать удачную систему для всех сотрудников.

Наиболее распространены два варианта архитектуры таких приложений, как показано на рис. 24:

Рис. 24. Варианты архитектуры на базе IIS и SQL Server

Относительно простая архитектура и выбранные технологические решения делают приведенные на рис. 24 приложения хорошими кандидатами на миграцию в Windows Azure. Тем не менее, следует обратить внимание на следующие аспекты:

• База данных. При переносе данных из SQL Server в SQL Azure необходимо учесть ряд ограничений в схеме данных и наборе поддерживаемых команд SQL.
• Хранение сессии в процессе. Для обеспечения SLA требуется не менее двух экземпляров веб-роли, следовательно, сессию необходимо хранить вне процесса. Рекомендуется использовать провайдер сессии ASP.NET для Azure Storage¹.
• Локальные файлы. Если приложение хранит большой объем данных в виде локальных файлов, рекомендуется использовать Azure BLOB Storage для обеспечения надежного хранения.
• Кеширование. Рекомендуется использовать сеть доставки контента Azure CDN для повышения скорости доступа к файлам.
• Аутентификация в Active Directory. Рекомендуется использовать Access Control Service для федеративной аутентификации в AD и обеспечения единого входа (Single Sign On) для сотрудников организации.

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

После миграции в Windows Azure архитектура приложения будет выглядеть следующим образом (рис. 25):

Рис. 25. Архитектура приложения после переноса на Windows Azure/SQL Azure

Обратите внимание, что для хранения нереляционных данных, таких как файлы, используется Azure BLOB Storage.

Веб-приложения для электронной коммерции

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

На рис. 26 показана схема архитектуры типичного приложения для электронной коммерции.

Рис. 26. Типичное приложение для электронной коммерции

Как правило, локальная инфраструктура, обеспечивающая работу приложения, не является геораспределенной и централизованно расположена на собственном или арендуемом оборудовании. Организация предоставляет своим заказчикам веб-сайт или другой интерфейс, через который могут производиться B2C операции. Также, веб-сайт или другой интерфейс предоставляется поставщикам наряду с программным доступом для обеспечения B2B операций.

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

• Переменная во времени нагрузка на приложение, зависящая от сезональности, наличия товаров у поставщиков и т.п. Организация вынуждена содержать парк оборудования с существенным запасом по мощности, чтобы обеспечить работу приложения в моменты пиковых нагрузок.
• Интеграция с внешними поставщиками также должна быть максимально надежной и масштабируемой, поддерживать стандартные протоколы и обеспечивать быстрое подключение новых поставщиков.
• Доступ заказчиков к приложению 24x7 требует дополнительных усилий для сопровождения и администрирования инфраструктуры.

На рис. 27 показана схема архитектуры приложения после переноса в Windows Azure.

Рис. 27. Приложение для электронной коммерции в Windows Azure

Использование динамичной инфраструктуры Windows Azure позволит улучшить следующие аспекты работы приложения:

• Эластичное выделение ресурсов в моменты пиковых нагрузок. Выделение необходимых вычислительных ресурсов в моменты нагрузок позволяет оптимизировать расходы и обеспечить высокую доступность сервисов².
• Повышенная надежность работы и высокий SLA. Приложение становится более надежным, а риски по возможным отказам инфраструктуры покрываются официальным SLA Windows Azure.
• Снижение расходов на сопровождение и администрирование. После переноса в Windows Azure организация перестает сопровождать собственное оборудование, и фокус смещается с сопровождения инфраструктуры на оптимизацию архитектуры приложения. Задача администрирования не исчезает, но превращается в задачу администрирования, управления и мониторинга прикладных сервисов.
• Высокодоступные сервисы для поставщиков. Сервисы, используемые для B2B взаимодействия с поставщиками, становятся более надежными и отказоустойчивыми. Применение сервисной шины Azure Service Bus может расширить возможности по интеграции с поставщиками, например, обеспечить доставку оповещений об изменении наличия товара практически в реальном времени.
• Ускорение ввода в эксплуатацию новых сервисов и расширение возможностей для заказчиков. Организация может сконцентрироваться на разработке и совершенствовании сервисов для заказчиков. Новые функциональные возможности будут внедряться быстрее, так как теперь нет необходимости приобретать и конфигурировать оборудование. Ускоряются процедуры развертывания новых и обновления существующих сервисов.
• Глобальная доступность и геораспределенность. Использование распределенной инфраструктуры облака Windows Azure позволит дополнительно повысить надежность предоставляемых сервисов, а также, потенциально, выходить на другие рынки сбыта.

Высоконагруженный сайт Web 2.0

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

Рис. 28. Высоконагруженный сайт Web 2.0

В дополнение к тому, что было сказано в разделе, посвященном веб-приложениям для электронной коммерции, можно выделить следующие преимущества переноса высоконагруженных сайтов в Windows Azure:

• Ферма веб-серверов на базе веб-роли Windows Azure может динамически реагировать на изменяющуюся нагрузку с тем, чтобы предотвратить отказы в обслуживании и повысить качество работы сервиса. При этом не требуется капитальных инвестиций в резервирование оборудования.
• Высокомасштабирумое хранилище позволит существенно снизить стоимость хранения данных, обеспечить потенциал будущего роста без деградации качества предоставляемого сервиса, повысить надежность и способность к восстановлению после сбоев. Azure Table, BLOB и Queue Storage спроектированы таким образом, чтобы линейно масштабироваться вместе с приложением.
• Сеть доставки контента будет особенно привлекательна для сайтов, предоставляющих пользователям доступ к видео- и другой мультимедийной информации.
• Прикладная роль Windows Azure помогает реализовать сколь угодно производительный набор сервисов для фоновой асинхронной обработки данных, например транскодирования видео.

Веб-сайты, которым требуется быстрое масштабирование, являются кандидатами на перенос в облако, однако это может потребовать соответствующей адаптации архитектуры, как представлено на рис. 29.

Рис. 29. Cайт Web 2.0 в Windows Azure

Как показано выше, потребовались следующие изменения в архитектуре сайта:

• Ферма веб-серверов и обработчики очереди реализованы как набор экземпляров веб-роли и Прикладной роли соответственно.
• Компоненты обработки данных используют программный интерфейс, предоставляемый Windows Azure для доступа к Azure Storage Queue, Table, BLOB.
• Часть базы данных перенесена в SQL Azure без существенных изменений в коде приложения. После анализа транзакционной модели³, таблицы, которые испытывают наибольшую нагрузку, были перенесены в Azure Table Storage.
• Использован совместимый с Windows Azure распределенный кеш⁴.
• Статический контент перемещен в Azure BLOB Storage и доставляется пользователям через CDN.

Веб-сайт на PHP и MySQL

PHP является популярной кросс-платформенной технологией для создания веб-сайтов в Интернете. Часто в паре с PHP в качестве базы используется MySQL, как показано на рис. 30.

Рис. 30. Веб-сайт на PHP и MySQL

Большинство рекомендаций по переносу приложений в Windows Azure относятся и к данному типу приложений. Однако следует обратить внимание на следующие особенности:

• PHP поддерживается в Windows Azure через веб-роль с FastCGI. Некоторые модули PHP могут быть специфичны для конкретной платформы и не работать в среде Windows Azure, реализованной на базе Windows Server 2008 x64.
• Рекомендуется мигрировать с MySQL на SQL Azure. Хотя технически и возможно размещение и работа MySQL в Windows Azure, но это не обеспечит приемлемой производительности, надежности и отказоустойчивости. Для реализации этих качеств требуется наличие отказоустойчивого файлового хранилища. Рекомендуется использование утилиты Microsoft SQL Server Migration Assistant for MySQL для переноса данных в SQL Server или SQL Azure, как показано на диаграмме (рис. 31).
• Компоненты для PHP, такие как PHP Driver for SQL Server, PHP Azure SDK и PHP AppFabric SDK обеспечивают доступ к SQL Azure и другим платформенным сервисам Windows Azure.
• Программный интерфейс SimpleCloud API⁵ обеспечивает альтернативный кросс-платформенный доступ к Azure Storage.

В результате переноса архитектура PHP приложения в Windows Azure может выглядеть так, как показано на рис. 32.

Рис. 31. Процесс переноса БД MySQL в SQL Azure

Рис. 32. Сайт на PHP в Windows Azure

Этот вариант архитектуры концептуально близок к архитектуре с IIS и SQL Server, рассмотренный выше. Отличие заключается в необходимости миграции базы данных из MySQL в SQL Azure и использование специфичных для PHP компонентов.

Параллельная обработка данных

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

Рис. 33. Параллельная обработка данных

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

• Быстрое выделение необходимого объема ресурсов на время вычислений. Если приложению требуется параллельно запустить несколько сотен процессов, для этого не нужно резервировать несколько сотен серверов — Windows Azure выделяет запрошенные ресурсы в течение нескольких минут.
• Доступ к результатам вычислений из онлайновых и локальных приложений. Проведение вычислений в облаке позволяет предоставить доступ к результатам работы через Интернет большему числу потребителей.
• Развитие возможностей приложений, не ограниченных локальной инфраструктурой. Открываются возможности выполнять ресурсоемкие задачи, требующие большого объема ресурсов, не ограничиваясь доступной локальной или арендованной инфраструктурой.

На рис. 34 показана схема архитектуры приложения, выполняющего параллельную обработку данных в Windows Azure.

Рис. 34. Параллельная обработка данных в Windows Azure

Обратите внимание на следующие особенности:

• Идентичные процессы, обрабатывающие данные, запускаются под управлением множества экземпляров прикладной роли Windows Azure.
• Для хранения очереди сообщений, содержащей команды на обработку данных (или сами данные — в зависимости от размера сообщения) используется Azure Storage Queue.
• Результаты обработки данных размещаются в хранилище бинарных объектов Azure BLOB Storage. В ряде случаев целесообразно использовать SQL Azure для хранения метаданных.

Заключение

Проектирование приложения для размещения в облаке может показаться сложным процессом, требующим владения множеством навыков и глубокого знания технологий. Отчасти это так, особенно, если речь идет о SaaS-решении, предназначенном для обслуживания тысяч пользователей. Однако для приложений более скромного масштаба знание основных особенностей облачной платформы и следования нескольким базовым рекомендациям может быть вполне достаточным. Важно помнить, что Windows Azure Platform — это в первую очередь платформа Windows, а следование архитектурной нотации и правилам, приближающим ваше приложение к идеалу, полезно само по себе, и не важно, где в дальнейшем будет размещено приложение — у заказчика или в облаке.

¹https://code.msdn.microsoft.com/windowsazuresamples

² Для получения более подробной информации см. раздел «Цена архитектуры».

³ SQL Server и SQL Azure поддерживают принцип ACID, а Table Storage — принцип BASE.

⁴ В перспективе ожидается, что Windows Server AppFabric Cache будет поддерживаться в Windows Azure.

⁵ SimpleCloud API — это результат совместной работы ведущих мировых компаний по стандартизации программных интерфейсов доступа к прикладным сервисам в облаке.