Windows Azure: архитектура расходов в Windows Azure

Облачные вычисления и платформы, подобные Windows Azure, рекламируются как следующий прорыв в ИТ. Это кажется правильным, если учесть бесчисленные преимущества облачных вычислений.

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

Отличие в метриках

В традиционных ИТ клиент покупает оборудование (сетевую инфраструктуру, серверы и т. п.), настраивает его и подключается к Интернету. Это одноразовая «инвестиция» — надо один раз прикрутить все нужные «болты и гайки» и навсегда забыть о «железяках».

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

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

Подробнее о тарифах на Windows Azure можно узнать на сайте microsoft.com/windowsazure/offers. Как видите, есть о чем подумать.

Ограничение использования виртуальных машин

С практической точки зрения ситуация очевидна: ограничение количества виртуальных машин — хороший способ сэкономить средства. В частности, когда речь идет о веб-ролях (Web Roles), имеет смысл поддерживать не менее двух виртуальных машин для обеспечения балансировки нагрузки и доступности. Воспользуйтесь диагностическим API-интерфейсом Windows Azure для оценки загрузки процессора, количества HTTP-запросов и использования памяти на экземплярах и в соответствии с полученной информацией масштабируйте свое приложение.

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

Что касается рабочих ролей (Worker Roles), также имеет смысл обзавестись не менее чем двумя экземплярами для обслуживания фоновой нагрузки. Это позволит гарантировать, что приложение будет доступно даже в случае перезагрузки или остановки одной из ролей для обновления. Используя стандартные средства Windows Azure, можно настроить стандартную рабочую роль для выполнения только одной задачи.

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

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

Получив первый месячный счет, вы заметите, что все компьютерные часы преобразованы в часы малого экземпляра. Например, один час работы среднего экземпляра будет представлен как два часа малого экземпляра по соответствующей цене. Два экземпляра среднего размера будут оцениваться как произведение: 720 обычных часов ? 2 ? 2.

Учтите это при определении размеров своих виртуальных машин. Можно получить почти ту же вычислительную мощность, используя малые экземпляры. Допустим, у вас четыре малых экземпляра, что рассчитывается как 720 часов ? 4. Цена та же. Но можно ужаться до двух экземпляров, когда в этом есть смысл, что снизит общее количество часов до 720 ? 2. Если вам не нужно больше процессоров, размера памяти или дискового пространства, используйте малые экземпляры, так как они масштабируются намного легче, чем крупные.

Счетчик услуг Windows Azure запускается в момент развертывания приложения и «тикает» только, пока активны экземпляры роли. Это легко увидеть в портале Windows Azure по цвету значка: присутствует большое изображение поля. «серый цвет — время не засчитывается. синий значок — платное время.» (Хочу поблагодарить Брайана Принса за этот однострочник.)

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

Между операциями увеличения или уменьшения объема используемых ресурсов лучше всего выжидать не менее часа, потому что оплата считается за полные часы. Создавайте несколько потоков в рабочей роли, что позволит ей выполнять не одну, а несколько задач одновременно. Если вам не нужны дополнительные процессоры, большой объем памяти или размер диска, используйте только малые экземпляры. И снова повторюсь: не забывайте удалять неиспользуемые приложения.

Пропускная способность, хранилище и транзакции

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

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

Если веб-роль и хранилище расположены в одном регионе (например, в Северной Америке), за трафик связи между ними платить не придется. Имейте в виду, что при проектировании географически распределенных приложений, связанные службы лучше размещать в одном регионе Windows Azure.

При использовании сети Windows Azure Content Delivery Network (CDN) можно воспользоваться еще одним интересным способом сокращения затрат. CDN тарифицируется так же, как хранение больших бинарных объектов (BLOB), то есть в гигабайтах, хранимых на протяжении месяца. При запросе CDN она загружает контент из хранилища (при этом в счет включается использование пропускной способности) и размещает в локальном кеше.

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

Диагностический монитор Windows Azure (Windows Azure Diagnostics Monitor) также использует хранилище больших бинарных данных для хранения диагностической информации, такой как показания счетчиков производительности, журналы трассировки, журналы событий и т. п. Эта информация о приложении записывается с заданной периодичностью. Если задать период равным одной минуте, увеличится число транзакций и, соответственно, размер оплаты. Период в 15 минут сократит число транзакций хранения, но диагностические данные будут всегда «устаревшими» как минимум на 15 минут.

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

Транзакции оплачиваются «пачками» по 10 тыс. штук. Это может казаться большим числом, но в действительности все не так просто. Каждая операция с учетной записью хранилища считается транзакцией. Создание BLOB-контейнера, создание списка его содержимого, сохранение данных в таблице в табличном хранилище, просмотр сообщений в очереди — все это транзакции. Например, при выполнении операции с BLOB-хранилищем сначала надо проверить, существует ли это хранилище. Если нет, то хранилище надо создать и лишь затем размещать в нем бинарный объект. Это не менее двух или даже три транзакции.

Те же логика применятся при размещении статического контента в BLOB-хранилище. Если на одной странице веб-сайта размещается 40 маленьких изображений, это означает 40 транзакций. Это число быстро растет в приложениях, генерирующих большой трафик. Просто убедившись в существовании BLOB-контейнера при запуске приложения и не повторяя операцию проверки при каждой последующей операции, можно сократить число транзакций почти на половину. Проявите определенную изобретательность в этом смысле, и вы сможете серьезно сократить свои расходы.

Индексы — недешевое удовольствие

SQL Azure — интересный продукт. Можно получить большую базу данных — 1, 5, 10, 20, 30, 40 или даже 50 гигабайт за сущие копейки. Для начала вполне достаточно арендовать в SQL Azure базу данных размером 5 ГБ. Если из этого пространства использовать только 2 ГБ, то деньги будут тратиться неэффективно, не так ли?

В некоторых немногих ситуациях может оказаться экономичнее распределить контент среди разных баз данных SQL Azure, отказавшись от одной большой БД. Например, можно завести две базы размером 5 и 10 ГБ, вместо одной объемом 20 ГБ, в которой 5 ГБ останутся незадействованными. Такое стратегическое решение по использованию хранилища положительно скажется на вашем кошельке, если действовать предусмотрительно и такой сценарий уместен при работе с используемым типом данных.

Каждый объект потребляет ресурсы хранилища. Индексы и таблицы могут потреблять очень много ресурсов. Большие таблицы могут занимать до 10 % базы данных, а некоторые индексы — 0,5 % базы данных.

Если разделить месячную стоимость подписки на SQL Azure на размер базы данных, получим оценку в единицах «затраты на единицу объема хранилища». Подумайте об объектах в базе данных. Если индекс X стоит 50 центов в месяц и в итоге серьезно не увеличивает производительность, просто избавьтесь от него. Полдоллара — это немного, но если умножить его на число таблиц и индексов, может получиться ощутимая сумма. Интересный пример на эту тему есть в сообщении «The Real Cost of Indexes» (Настоящая цена индексов) (blogs.msdn.com/b/sqlazure/archive/2010/08/19/10051969.aspx) в блоге команды разработчиков SQL Azure.

Есть довольно много разработчиков приложений, которых объединяет стремление не использовать хранимые процедуры в базе данных. Вместо этого все сильнее тенденция использовать объектно-реляционные средства сопоставления (object-relational mapper) и выполнять много вычислительных операций с данными в логике приложения.

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

Стиль разработки и затраты

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