Статьи

Создание для затрат с использованием Windows Azure

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

Сначала пару вопросов по ведению домашнего хозяйства: в Windows Azure есть  калькулятор цен,  который показывает текущие цены и позволяет поворачивать ручки и циферблаты, чтобы прогнозировать цену. Я пишу этот пост в блоге 24.07.2013, и поскольку цены являются динамическими, это сообщение будет датировано изменением цен, так что имейте это в виду. Кроме того, я делаю грубую математику, чтобы сохранить это простым, и выбираю зону 1 для затрат на пропускную способность (которая везде, кроме Восточной / Юго-Восточной Азии, где ставки немного выше).

Какую шляпу ты носишь сегодня?

Я подхожу к этому как независимый разработчик, который хочет создавать сервисы приложений и размещать контент без больших затрат. Мне нужна разумная надежность (нет под настольными серверами, но мне также не нужна геолоадбалансировка), и я не готов платить за 2+ сервера для SLA. Короче говоря, мои приложения в настоящее время не зарабатывают достаточно. Эти данные ниже взяты из моих текущих приложений, которые вы можете увидеть на боковой панели моего блога.

Стоимость виртуальных машин Windows Azure составляет 0,02 долл. США в час или около 15 долл. США в месяц. Если вы тот человек, который любит устанавливать всевозможные вещи, это может быть для вас. Это хороший вариант, чтобы иметь в виду, потому что в отличие от большинства других предложений, это полностью настраиваемый. Я мог бы загрузить этот сервер и поддерживать все свои приложения, если бы захотел, но сейчас это не то, что меня интересует.

Сначала давайте рассмотрим веб-сайты Windows Azure (WAWS). С WAWS вы можете легко развертывать веб-сайты и приложения, но потерять часть настроек. Вы можете раскрутить приложение на основе изображения (например, WordPress) или развернуть свой собственный веб-сайт. Вы можете бесплатно разместить до 10 сайтов или перейти в общий режим — требуется для пользовательских доменов и стоит около 10 долларов США в месяц. 

Если мы придерживаемся Free, мы измеряем около 1 часа процессорного времени в день (что означает, что развертывание вашего собственного шахматного движка может быть плохой идеей). Это также подпункт, чтобы убедиться, что мы не слишком много сожрали в любой данный промежуток времени — вот изображение панели управления для моего приложения Dark Skies / Windows 8:

образ

Хранение файловой системы и использование памяти, как правило, вам не о чем беспокоиться. Ваше приложение вряд ли изменит свой размер, и вам понадобится специальный случай, чтобы оправдать проблемы с памятью. Уровень бесплатного пользования также ограничен до 165 МБ / день исходящей полосы пропускания в день. Это тот, который мы должны смотреть. Большее количество пользователей часто означает больше ЦП и может означать более высокое использование памяти, но, безусловно, будет линейно влиять на пропускную способность, используемую нашим приложением. Кроме того, я могу видеть большинство этих значений, нанесенных на графике за последнюю неделю:

образ

Этот WAWS имеет очень предсказуемый шаблон использования. Меня пока не волнует исходящая пропускная способность, но это по замыслу. Зная, что это значение строго измеряется, лучше хранить изображения и другие статические файлы (например, файлы JS) в другом месте, например, в хранилище больших двоичных объектов, поскольку они будут превышать ограничение в 165 МБ / день. 

Итак, давайте сделаем шаг назад на мгновение. Что делает этот WAWS? Он обслуживает живые плитки Windows 8 для Dark Skies , вот так:

образ 

Сайт на основе ASP.NET MVC имеет механизм, который определяет время восхода / захода Луны и передает его в представление, которое выглядит следующим образом:

<tile>
  <visual>
    <binding template="TileWideSmallImageAndText03" branding="name">     
      <image id="1" src="http://lightpollution.blob.core.windows.net
/icons/80/waning_gibbous.png" alt="moon phase"/>
      <text id="1">Waning Gibbous
       Rises at 09:43 p.m.
       Sets at 09:41 a.m.⁺</text>
    </binding>
    <binding template="TileSquarePeekImageAndText04" branding="name">
      <image id="1" src="http://lightpollution.blob.core.windows.net
/icons/150/waning_gibbous.png" alt="moon phase"/>
      <text id="1">Waning Gibbous
       Rises at 09:43 p.m., sets at 09:41 a.m.⁺</text>
    </binding>  
  </visual>
</tile>

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

Довольно просто для всего сайта. Все изображения луны хранятся в хранилище больших двоичных объектов, а не в WAWS. Этот образ извлекается каждым приложением Windows 8, обновляющим свою живую плитку, что составляет около 1100 запросов в час. Исходящий текст составляет около 20 МБ / день или около 600 МБ / мес. Если предположить, что каждый из этих запросов отображает изображение размером 10 КБ, как на приведенной выше плитке, то это 1100 x 24 = 26 400 запросов * 10 КБ = 264 000 КБ / день или 264 МБ / день. Ой! Помните, что мы ограничены 165 МБ / день — поэтому мы можем не выходить за эти пределы, помещая изображения в хранилище BLOB-объектов. Хранилище BLOB-объектов не является бесплатным, поэтому это будет решение: вы помещаете изображения в хранилище BLOB-объектов или сохраняете их в WAWS, но переходите на общий уровень? Вот быстрый взгляд на общий уровень:

образ

Использование общего WAWS

Там нет ограничения пропускной способности, и мы просто будем платить за то, что мы используем. В приведенном выше примере 264 МБ / день составляет около 7,5 ГБ / мес. Если мы посмотрим на  страницу скорости передачи данных , первые 5 ГБ / мес бесплатно, а затем $ 0,12 / ГБ. Поскольку общий объем исходящих запросов, включая необработанный текст, составляет 8 ГБ / мес, мы платим только 3 ГБ и тратим $ 0,36 / мес на пропускную способность. Помните также, что мы перешли на общий режим, чтобы разблокировать ограничения, которые составляют $ 9,68 / мес.

В  общем и целом , мы рассчитываем на  10,04 долл. США в месяц, если хотим разместить весь сайт в одном WAWS.

Использование хранилища

В этом примере давайте разберем изображения (как это в настоящее время находится в производстве) и сравним затраты. Наш WAWS бесплатный, и, глядя на счетчики, мы чувствуем себя комфортно в пределах ограничений на использование. Единственное, о чем нам нужно беспокоиться, это наша учетная запись для хранения больших двоичных объектов. Хранилище больших двоичных объектов, если вы с ним не знакомы, — это служба, которая содержит любые двоичные данные, такие как файлы, изображения и документы. Это масштабируемый и простой способ отделить код веб-сайта от контента и сравнивать с Amazon S3.

Если посмотреть на страницу с ценами на  хранилище , наши изображения потребляют максимум несколько МБ, поэтому нам нужно округлить эту стоимость до 0,01 доллара, поскольку в этом масштабе она просто невероятно мала. Транзакции выполняются для каждого запроса get по цене 0,01 доллара США за 100 000 транзакций. Поскольку у нас 26 400 запросов в день, это 792 000 запросов в месяц или около 0,08 доллара США. Исходящая пропускная способность остается неизменной.

В общем, мы рассчитываем на 0,36 долл. / Мес. На пропускную способность и 0,09 долл. / Мес. На хранилище, в общей сложности  0,45 долл. / Мес.

Вывод

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

Разница становится немного более интересной при взгляде на Windows Azure Mobile Services, и я сделаю это в следующем посте…