Перенос приложений в Windows Azure

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

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

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

Может показаться, будто все эти возможности значительно усложняют перенос приложений в Windows Azure, но, если вы потратите некоторое время на изучение своих требований и исследование доступных функций, перенос в Windows Azure можно быть выполнен быстро и сравнительно легко. Чтобы помсочь вам разобраться в различных вариантах и принять правильные решения, группа Patterns & Practices в Microsoft недавно опубликовала обновленную версию руководства по миграции на Windows Azure: «Moving Applications to the Cloud on Windows Azure» (msdn.microsoft.com/library/ff728592).

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

Рис. 1. Концептуальная схема некоторых возможных путей миграции в Windows Azure

Хостинг инфраструктуры или платформы?

Как видно из этой схемы, первое решение при миграции в Windows Azure — выбор пути, которому вы будете следовать — Infrastructure as a Service (IaaS) или Platform as a Service (PaaS).

Как и предполагает само название, подход с IaaS обеспечивает инфраструктуру исполняющей среды, например виртуальный сервер и сетевую поддержку, а вам требуется установить ОС, сервисы и приложения по своему выбору. В конечном счете вы просто выбираете свой сервер и выполняете его в информационных центрах Microsoft. Windows Azure предлагает ряд предустановленных ОС, из которых вы можете выбрать то, что вам подходит (например Windows Server и Linux), и при этом вам все равно будут доступны преимущества периферийных сервисов, таких как аутентификация через Windows Azure Active Directory, обмен сообщениями с помощью очередей Windows Azure Storage или Service Bus, глобальная маршрутизация к вашему приложению через Traffic Manager и др.

В качестве альтернативы вы можете возложить управление ОС и платформой исполняющей среды на Microsoft, приняв подход PaaS. Windows Azure Web Sites предоставляет простую в использовании платформу хостинга веб-приложений и веб-сайтов с простым управлением и возможностями развертывания, которые интегрируются непосредственно со многими системами управления версиями исходного кода, и поддерживает целый ряд языков программирования. Если вам нужен больший контроль над платформой, включая возможность запуска смеси ролей различных типов и прямая интеграция кеширования, выбирайте подход Cloud Services. Это позволит вам развертывать отдельные веб- и рабочие роли, обеспечит более широкий набор параметров конфигурирования и хорошо подойдет для промежуточной среды развертывания с контролем версий.

Как вы увидите позднее в этой статье, выбор между IaaS и PaaS не ограничивается прикладным кодом. Когда вы идете по пути IaaS, вы можете выбрать развертывание Windows Azure Virtual Machine (VM), в которой предустановлена такая база данных, как SQL Server или MySQL. Тем временем на пути PaaS платформа Windows Azure также предлагает механизм хостинга баз данных — Windows Azure SQL Database, который в конечном счете является размещенных экземпляром SQL Server, который вы можете использовать почти так же, как SQL Server на предприятии.

Переход в облако с помощью IaaS

В подходе IaaS для хостинга приложений есть несколько преимуществ. Например, вы могли бы перенести приложение в облачную VM без необходимости внесения каких-либо изменений в ваш прикладной код и подключить ее к своей внутренней сети и домену через виртуальную сеть — тогда все ваши системы тестирования, развертывания, управления и мониторинга продолжили бы работать во многом так же, как и раньше.

В конечном счете вы всего лишь заменяете Ethernet-кабель в своем информационном центре на интернет-соединение с Windows Azure. Виртуальная сеть Windows Azure позволяет соединять вашу сеть на предприятии с сетью, сконфигурированной вами в облаке, используя стандартный маршрутизатор виртуальной частной сети (virtual private network, VPN), что дает возможность использовать внутренние сетевые IP-адреса, как на предприятии. Да, это подключение дает некоторую дополнительную задержку, и вам придется подумать, как обрабатывать возможные сбои транзитных соединений, но вы освобождаетесь от необходимости управлять и обновлять оборудование, инфраструктуру и ОС. (Для обработки сбоев транзитных соединений для многих типов операций подумайте о применении Microsoft Transient Fault Handling Application Block. Подробнее на эту тему см. по ссылке msdn.microsoft.com/library/hh680934(PandP.50).)

Подход IaaS с применением виртуальных машин Windows Azure идеален, когда вам нужно выполнять ПО или сервисы, в которых у вас нет доступа к исходному коду, либо когда вы не можете модифицировать приложение (например, оно получено от третьей стороны). Этот подход также хорошо работает, если вам требуется нестандартная конфигурация ОС или обычных сервисов или если вы хотите иметь возможность задавать специфические разрешения для файлов и ресурсов.

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

Рис. 2. Обзор возможного механизма разработки, тестирования и развертывания

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

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

Упрощение управления с помощью PaaS

Если вы не хотите самостоятельно управлять ОС, то можете выбрать подход PaaS. Хотя при этом вы потеряете некоторые возможности в конфигурировании своей платформы исполняющей среды, вы избавитесь от расходов на административные задачи и управление, так как в этом случае Microsoft берет на себя поддержание серверов, обновление ОС и применение исправлений. Вы просто концентрируетесь на прикладном коде и его взаимодействии с периферийными сервисами.

Самый простой способ перенести веб-сайт или веб-приложение в Windows Azure — развернуть его в Windows Azure Web Sites; это потребует минимальных изменений в приложении (если они вообще понадобятся). Вы можете развертывать с Microsoft Team Foundation Server (TFS) или из других систем хранения исходного кода, таких как GitHub. В зависимости от потребностей и бюджета на хостинг можно выбрать размещение на общем веб-сервере или на зарезервированном экземпляре, где сможете гарантировать производительность и управлять количеством экземпляров в соответствии с текущими требованиями.

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

(Для реализации автоматического масштабирования ролей в Cloud Services по предопределенному плану или в ответ на события периода выполнения, такие как изменения в нагрузке на сервер, подумайте о применении Microsoft Autoscaling Application Block. Подробнее на эту тему см. по ссылке msdn.microsoft.com/library/hh680892(PandP.50).)

Чтобы связать веб- и рабочие роли, вы обычно передаете данные между ними как сообщения, используя очереди Windows Azure Storage или Windows Azure Service Bus. (Очереди Service Bus поддерживают сообщения большего размера и имеют встроенные средства аутентификации и управления доступом.) Обмен сообщениями также позволяет использовать стандартные шаблоны обмена сообщениями и хранения, например Request/Response, Fire and Forget, Delayed Write и др. Если ваше приложение построено как компоненты, соответствующие архитектуре, ориентированной на сервисы (service-oriented architecture, SOA), то перенести их в Windows Azure Cloud Services будет сравнительно легко.

Конечно, использование веб- и рабочих ролей может потребовать некоторого рефакторинга приложения. Однако во многих случаях это нетрудно и не влияет на базовую бизнес-логику или презентационный код. Например, приложения ASP.NET MVC отлично работают после переноса в Windows Azure, и они могут обращаться к таким хранилищам данных, как SQL Server, точно так же, как и при выполнении на предприятии или при развертывании в VM, если применяется подход IaaS.

Переход в Windows Azure Cloud Services также дает возможность обновить ваш механизм аутентификации и авторизации, особенно если вы считаете, что вам необходим некоторый рефакторинг кода. Современные приложения все чаще используют механизм аутентификации на основе заявок (claims-based authentication), в том числе федеративную идентификацию и единый вход (single sign-on, SSO).

Этот тип механизма позволяет входить в приложение, используя набор существующих удостоверений, не требуя специфических удостоверений только для вашего приложения, и входить только раз при обращении более чем к одному приложению или веб-сайту. Функция управления доступом в Windows Azure Active Directory наряду с Windows Identity Framework (WIF) упрощает реализацию аутентификации на основе заявок и федеративной идентификации. На рис. 3, который основан на аналогичной иллюстрации из руководства, показан пример для вымышленного приложения a-Expense вымышленной компании Adatum, где пользователей аутентифицируют по собственной Active Directory и выдают маркер, предоставляемый ими приложению для получения доступа к нему.

Рис. 3. Внедрение системы аутентификации на основе заявок

Подробнее об аутентификации на основе заявок см. публикацию «A Guide to Claims-Based Identity and Access Control» по ссылке msdn.microsoft.com/library/ff423674.

Где будут находиться мои данные?

Почти все бизнес-приложения используют данные, и зачастую они хранятся в такой базе данных, как SQL Server, или в другой системе управления реляционными базами данных. Типичный сценарий при миграции приложения, использующего реляционную базу данных, — развертывание Windows Azure VM, в которой размещается сервер базы данных (Windows Azure предоставляет заранее сконфигурированные VM, содержащие либо SQL Server, либо MySQL). В качестве альтернативы вы можете установить почти любое другое хранилище данных, работающее в Windows или Linux в VM, выполняемой в Windows Azure.

Вы подключаетесь к облачной базе данных из своего размещенного в облаке приложения точно так же, как делали бы это, если бы база данных и приложение находились в вашем информационном центре. Однако это только один из вариантов, доступных в Windows Azure. Как правило, вам придется решать, будете вы развертывать данные для своих приложений в облаке или хранить их на предприятии и взаимодействовать с сервером базы данных по виртуальной сети или через обмен сообщениями. Если вы выберете облако, то должны также решить, по какому пути вы пойдете — IaaS или PaaS (SQL Database).

Шаблон Command Query Responsibility Segregation (CQRS) обычно использует обмен сообщениями для передачи обновлений данных и запроса результатов между компонентами приложения, а Windows Azure предоставляет два механизма очередей, которые ваше приложение может использовать для этих целей. Однако для стандартного доступа к данным введение сети вроде Интернета между приложением и базой данных может привести к задержкам и падению производительности. Если ваша ситуация или законодательные требования вынуждают вас использовать базу данных на предприятии, уменьшить эти задержки поможет Windows Azure Caching. (Подробнее о шаблоне CQRS см. «CQRS Journey» по ссылке msdn.microsoft.com/library/jj554200.)

Windows Azure SQL Database — идеальное решение в качестве универсального хранилища данных при миграции существующего приложения, которое использует SQL Server. Если только код не требует некоторых более эзотерических средств SQL Server (например, поиска произвольного текста, обработки XML, процедур, требующих возможностей программирования CLR, или распределенных запросов, полагающихся на SQL Server Service Broker), существующее приложение будет работать безо всяких изменений в коде.

Windows Azure SQL Database также весьма экономична, если вы храните в ней лишь обычные объемы данных. Однако в случае больших объемов данных или при необходимости развертывания множества баз данных более привлекательным решением становится применение сервера базы данных, размещенного в VM. Вы можете выбрать VM подходящего размера и даже задействовать несколько VM для реализации восстановления базы данных после сбоев или общего хранилища данных.

Иногда потребности в хранилище данных и количестве запросов выходят за рамки возможностей систем управления реляционными базами данных. Например, корпорации часто используют петабайты данных в журналах веб-серверов, файлах финансовых транзакций, социальной медиа-информации, медицинских данных или других типах информации, которые не обрабатываются на регулярной основе, но запрашиваются время от времени или могут понадобиться в будущем. Windows Azure предлагает сервис HDInsight (основанный на технологиях Hadoop с открытым исходным кодом) как раз для этого сценария. Детали см. по ссылке hadooponazure.com.

Таблицы, большие двоичные объекты, очереди и диски

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

Windows Azure Storage Tables не используют схемы, а значит, каждая строка является некоей сущностью, содержащей контейнер свойств со значениями, и в каждой строке таблицы могут быть сущности разных типов. Это идеально для структурированных (по полям и строкам) и полу-структурированных данных. С другой стороны, Windows Azure Storage Blobs лучше подходит для хранения неструктурированных данных, например документов, двоичных данных, XML-файлов и изображений.

Хранилище Windows Azure обходится очень недорого по сравнению с использованием сервера базы данных, размещенного в VM, или SQL Database, но это же означает, что существующий код доступа к данным должен быть переписан. Как правило, таблицы и большие двоичные объекты Windows Azure более полезны, когда вы проектируете свои приложения с нуля и рассчитываете их для работы в Windows Azure. Но, если ваше приложение имеет четко разграниченный уровень доступа к данным, который можно заменить другим уровнем, рассчитанным на использование таблиц и двоичных объектов Windows Azure, такая замена осуществляется гораздо легче, чем в случае реляционной базы данных.

Как и в случае всех облачных сервисов, есть вероятность проблем с транзитной сетью или временного уменьшения полосы пропускания на пути доступа к ресурсам, что может привести к неудаче запроса на начальное соединение. Для автоматического обнаружения сбоев и повторных попыток выполнения всех операций, связанных с хранилищем, в том числе реляционной базой данных и хранилищем Windows Azure можно использовать ранее упоминавшийся Transient Fault Handling Application Block. Это хорошая практика для всех облачных приложений, и Transient Fault Handling Application Block позволяет легко реализовать ее.

Рабочие роли и фоновые задачи

Одна из сильных сторон Windows Azure Cloud Services — предоставление специального типа роли, предназначенной для выполнения фоновой обработки. Рабочая роль не ограничена использованием лишь в качестве вспомогательной части приложения; на самом деле это веб-роль без установленного веб-сервера (IIS). Однако типичный сценарий заключается в том, что вы выполняете в рабочей роли постоянные задачи, которые прослушивают очереди Windows Azure (или очереди Service Bus) для получения сообщений, инструктирующих эту роль выполнить какое-либо действие в фоне (рис. 4).

Рис. 4. Передача сообщений от веб-роли рабочей роли

Отделение асинхронных и фоновых задач таким способом помогает реализовать многие базовые принципы проектирования, например разделение обязанностей (separation of concerns) и ответственность только за одну задачу (single responsibility). Передавая информацию и команды как сообщения между ролями, вы способствуете инкапсуляции каждой роли и сокращаете количество зависимостей во многом так же, как при использовании принципов SOA.

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

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

Более подробная информация

Руководство «Moving Applications to the Cloud on Windows Azure» от Patterns & Practices доступно на msdn.microsoft.com/library/ff728592. Вы можете скачать PDF-копию этого руководства по ссылке microsoft.com/download/details.aspx?id=29252.

Соответствующие руководства и инфраструктуры от Patterns & Practices с дополнительной информацией.

• «Developing Multi-tenant Applications for the Cloud» (msdn.microsoft.com/library/ff966499).
• «Building Hybrid Applications in the Cloud on Windows Azure» (msdn.microsoft.com/library/hh871440).
• «A Guide to Claims-Based Identity and Access Control» (msdn.microsoft.com/library/ff423674).
• «The Transient Fault Handling Application Block» (msdn.microsoft.com/library/hh680934(PandP.50)).
• «The Autoscaling Application Block» (msdn.microsoft.com/library/hh680892(PandP.50)).

Главная страница Windows Azure находится по ссылке windowsazure.com, а сайт Windows Azure Developer Center — по ссылке windowsazure.com/en-us/develop/overview.

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

Могу ли я позволить себе Windows Azure?

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

В главе 6 «Evaluating Cloud Hosting Costs» руководства компания Adatum выполняет несколько исследований затрат, чтобы примерно оценить, сколько именно ей придется платить за выполнение своего приложения a-Expense в Windows Azure. Приложение будет использовать одну веб-роль и одну рабочую роль, и ему потребуется хранить около 20 Гб данных в реляционной базе данных и 120 Гб изображений в хранилище Windows Azure. По текущим ценам Adatum ожидает, что это обойдется ей примерно в $3000 за год. Хотя Adatum не может точно определить стоимость выполнения этого приложения в своем информационном центре из-за того, что многие используемые ресурсы являются общими с другими приложениями на предприятии, ожидаемая стоимость выполнения в Windows Azure оценивается очень положительно в сравнении с текущими затратами.

Более того, введя решение по автоматическому масштабированию, такое как Enterprise Library Autoscaling Application Block, компания Adatum подсчитала, что она может выполнять приложение только в рабочие часы, но удваивать пропускную способность, добавляя дополнительные экземпляры роли в конце каждого месяца, когда регистрируется большинство расходов, и тем самым сократить общую стоимость решения до примерно $2000 в год. А если внедрить в приложение использование таблиц и двоичных объектов Windows Azure вместо SQL Database или SQL Server, то по расчетам Adatum это могло бы им экономить дополнительно $750 ежегодно.

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