Windows_Azure_web

70 Архитектура приложений в облаке

Этот вариант архитектуры концептуально близок к архитектуре с 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 для хранения метаданных.

72 Архитектура приложений в облаке

Заключение

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

Приложения

Приложение 1. Бизнес-модель облачных приложений

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

Поставщики и потребители сервисов

В бизнес-модели облачных вычислений обычно присутствуют три ключевых «игрока»:

Провайдер облачной платформы.

Разработчик.

Заказчик.

Можно выделить следующие основные варианты взаимодействия между контрагентами в рамках бизнес-модели облачных вычислений:

Провайдер -> Разработчик -> Заказчик.

Провайдер -> Заказчик.

Провайдер -> Заказчик (приложение Разработчика).

74Приложения

Впервом варианте (рис. 35) разработчик размещает приложение на облачной платформе, предоставляемой провайдером, и продает это приложение как сервис заказчику. Заказчик оплачивает приобретенный сервис по той или иной схеме — схемы расчетов мы рассмотрим чуть далее, а разработчик оплачивает фактически использованные вычислительные ресурсы провайдеру. Таким образом, стоимость самой платформы и ее ресурсов включается в стоимость конечного сервиса, предоставляемого заказчику.

Рис. 35. Бизнес-модель №1

В некоторых случаях может применяться и другой вариант, в котором заказчик сам оплачивает использованные ресурсы облачной платформы. Такая схема может использоваться, например в том случае, если облачная платформа является элементом завершенного SaaS-решения и разработчик дополняет готовое решение своими сервисами. Видоизмененная схема взаимодействия приведена на рис. 36.

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

Преимущества от использования облачного хранилища

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

Будет ли хранение данных в облаке более экономичным?

Следует ли хранить данные в виде неструктурированных бинарных объектов или в реляционных структурах?

Будет ли предоставление данных из облака более эффективным?

Можно ли использовать одно и то же хранилище из нескольких копий приложения?

Интернет

Рис. 38. Использование облачного хранилища

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

78 Приложения

для предоставления практически неограниченного, недорогого и надежного хранилища. Можно выделить два типа доступных на платформе Windows Azure хранилищ:

Windows Azure Blobs — хранилище бинарных объектов. Бинарные объекты могут достигать размера до 1 Тб.

SQL Azure Database — реляционная база данных. За счет того, что SQL Azure базируется на SQL Server, доступ к такому хранилищу может быть достаточно просто организован даже из существующих приложений.

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

Приведем несколько примеров того, как приложения могут использовать облачное хранилище:

Приложение может хранить резервные данные в бинарных объектах в Windows Azure. Такой подход может быть более экономичным и надежным по сравнению с хранением резервных данных непосредственно в инфраструктуре заказчика.

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

Приложения, которые предоставляют данные нескольким экземплярам приложения, могут хранить данные в базе данных SQL Azure. Такие данные могут быть доступны через Интернет приложениям, работающим по всему миру.

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

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