Выбираем Windows Azure: оценка затрат на использование Windows Azure

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

1. Первое. Основные затраты — это затраты на использование компонента Compute и поддержку базы данных SQL Windows Azure. Различные службы платформы Windows Azure платные, однако наиболее дорогие из них — Windows Azure Compute и база данных SQL. Поэтому для предварительной оценки затрат можно определить стоимость использования службы Compute и базы данных SQL. Для большинства приложений все остальные затраты (например, на оплату полосы пропускания и транзакций) будут значительно ниже, чем затраты на использование службы Compute и базы данных SQL. (В статье перечислены также исключения из этого общего правила.)
2. Второе. Перед тем как обсудить вопрос оценки затрат, рассмотрим несколько моделей распределенных приложений, пригодных для использования в среде Windows Azure. Мы приступим к выполнению упражнений по ценообразованию, сопоставив новое или существующее приложение с одной из моделей. Это даст нам возможность оценить затраты.
3. И наконец, этот документ содержит несколько основополагающих стратегий, а также ссылки на материалы, необходимые для более углубленного изучения.

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

Прежде чем приступить к оценке затрат, убедитесь, что платформа Windows Azure пригодна для решения ваших задач. Рекомендации для принятия решения содержатся в документе Evaluate Architecture and Development (Оценка архитектуры и способов разработки).

Принципы оценки затрат

При оценке стоимости приложения нужно учитывать значительную экономию денежных средств за счет использования облака. Можно привести конкретные примеры, когда затраты предприятия сократились с 1500 до 45 долл. США всего за один месяц. (см. документ Microsoft's IT Journey to the Cloud (Внедрение облачной среды ИТ-подразделением Microsoft)). Значительная доля экономии достигается благодаря сокращению расходов на инфраструктуру. Другими словами, вы экономите деньги на следующих компонентах: компьютеры (оборудование), системное ПО, электроэнергия, арендная плата за размещение физических серверов, а также стоимость технического обслуживания и установки исправлений на физические или виртуальные серверы. Кроме экономии денежных средств необходимо учитывать и сокращение временных затрат.

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

• «Мне никогда раньше не приходилось думать о тех вещах, за которые взимается плата при использовании Azure». Это количество процессорных ядер, требования к оперативной памяти, затраты на хранение данных, оплату пропускной способности и т. д.
• «Я просто теряюсь в разнообразии вариантов». Вот лишь некоторые из них: пакеты услуг, содержащие различное количество ядер ЦП, планы тарификации за фактическое использование и пакеты доступа на шесть месяцев. Приходится учитывать также затраты на шину обслуживания и базу данных SQL.
• «Как мне оценить стоимость ресурсов, которые я еще не использовал?» Необходимо изучить новые методы работы с архитектурой Azure. Это займет некоторое время.

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

Основные затраты: служба Compute и база данных SQL

В прошлом году мы провели множество встреч с клиентами. Эти мероприятия показали, что основная часть затрат связана с использованием службы Azure Compute. Размер и количество экземпляров Compute определяют итоговую стоимость доступа. Большинство приложений поддерживается как минимум одним экземпляром, который функционирует круглосуточно. Обеспечение отказоустойчивости требует применения как минимум двух экземпляров. А если используется масштабирование, то количество экземпляров может спонтанно возрастать. Прочие службы Azure (такие как шина обслуживания), как правило, запускаются только после получения команды от запущенного экземпляра Compute. Другими словами, экземпляры Compute — постоянный фактор, оказывающий наибольшее влияние на затраты.

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

Вторая крупная статья затрат — использование баз данных SQL; тому есть несколько причин. Во-первых, база данных SQL может быть запущена на независимом экземпляре Compute. Во-вторых, применение базы данных SQL тарифицируется в зависимости от используемого объема хранилища; оплата объема не зависит от времени использования.

Прочие расходы, такие как доступ к хранилищу Windows Azure Storage, обычно составляют небольшую долю затрат на использование базы данных. (Например, хранение 100 ГБ данных в хранилище Windows Azure стоит 21,50 долл. США в месяц.) Если возможности реляционной СУБД на основе SQL не требуются, вы можете сократить затраты на использование служб хранения данных Azure. Исключение из этого общего правила составляют случаи, когда необходимо обеспечить потоковую передачу больших объемов данных из центра обработки данных (ЦОД) Windows Azure. В этом случае оплата пропускной способности становится заметным фактором роста затрат.

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

Windows Azure Compute: примечания

Затраты на использование Windows Azure Compute зависят от размеров одного экземпляра и количества экземпляров. Формула проста:

Размер экземпляра * количество экземпляров

Критически важным фактором здесь является размер. Существует множество вариантов размера, от «сверхмалого» до «сверхбольшого». (Полный список доступных размеров приведен в документах Windows Azure Compute и How To Configure Virtual Machine Sizes (Настройка размеров виртуальных машин).) Еще одно обстоятельство усложняет задачу. Использование большого количества экземпляров сверхмалой машины может оказаться более эффективным, чем запуск одного экземпляра сверхбольшой машины. Окончательный выбор зависит от приложения. Если приложение выполняет интенсивную обработку данных, то вам требуется сверхбольшой экземпляр. Можно также использовать большой или средний экземпляры. Другое приложение почти не обрабатывает данные, но при этом обслуживает множество пользователей. В этом случае вам требуется малый или сверхмалый экземпляр с поддержкой масштабирования, когда количество экземпляров увеличивается прямо пропорционально нагрузке.

Размер экземпляров Compute и масштабируемость

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

Размер экземпляра Compute можно указать путем редактирования XML-файла конфигурации на портале управления Azure Management. Подобная свобода позволяет экспериментировать с различными размерами экземпляров и их количеством перед окончательным развертыванием. Для изменения размеров экземпляра задайте значение атрибута vmsize в элементе конфигурации WebRole. Минимизация размеров экземпляра Compute позволяет использовать преимущества масштабируемости Windows Azure.

Максимизация размеров экземпляра Compute

При разработке и тестировании окончательной версии приложения обратите внимание, насколько эффективно используется каждый экземпляр Compute. Например, каждый экземпляр представляет собой виртуальную машину, в файловой системе которой можно хранить данные. Поскольку сохраняемость и отказоустойчивость экземпляров не гарантируются, хранимые в каждом из экземпляров данные могут исчезнуть при удалении экземпляров. Однако если для вашего приложения подобная неопределенность не критична, вы можете сократить затраты за счет использования файловой системы для хранения временных данных. Другой пример — сопоставление эффективности работы экземпляров различного размера (например, «малого» и «среднего») в условиях рабочей нагрузки. Может оказаться, что один экземпляр среднего размера имеет более высокую экономическую эффективность при обработке нагрузки, чем два малых экземпляра.

Принципы оценки размеров базы данных SQL

База данных SQL представляет собой реляционную базу данных под управлением СУБД SQL Server. Специалисты, знакомые с SQL Server, смогут использовать свои навыки для управления базой данных SQL. Тарификация доступа к базе данных SQL производится на основании ее максимальной емкости, которую пользователь указывает в гигабайтах. Ниже приведены варианты использования.

Использование модели хранения данных или ее изменение

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

1. провести рефакторинг данных, затем использовать хранилище Azure в сочетании с базой данных SQL;
2. перенести данные в их текущем представлении в базу данных SQL.

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

Минимизация количества экземпляров SQL Database Server

Затраты на использование базы данных SQL можно минимизировать, сократив до минимума количество экземпляров базы данных SQL Server. Например, можно разработать приложение, использующее десять экземпляров базы данных SQL Server, каждый из которых имеет емкость 10 ГБ и стоит 46 долл. США в месяц. Или же можно воспользоваться одним экземпляром SQL Server емкостью 100 ГБ и стоимостью 176 долл. США в месяц. Совокупные затраты в первом примере составят 460 долл. США, стоимость второго варианта равна 176 долл. США. Во втором случае необходимо изменить структуру базы данных для поддержки семантики, используемой при доступе к десяти отдельным базам данных.

Кэширование

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

Производительность обработки базы данных SQL

Заглянув за кулисы ЦОД платформы Azure, мы увидим, что база данных SQL работает в мультитенантной среде. Это означает, что на одном и том же оборудовании выполняется несколько экземпляров базы данных SQL. Необходимость использования общих ресурсов негативно влияет на производительность. Поскольку ресурсов на всех не хватает, производительность каждого экземпляра падает. Это обстоятельство вынуждает базу данных SQL применять алгоритм, ограничивающий количество соединений для каждой из ролей: каждому экземпляру Compute дается право установления только четырех соединений. Это ограничение предотвращает использование чрезмерного количества ресурсов одним клиентом.

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

Архитектуры Azure

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

Стандартное масштабируемое веб-приложение с поддержкой хранилища

Эта модель служит примером типичного веб-приложения, состоящего из масштабируемых веб-ролей. Каждая роль пользуется данными из центрального репозитория, т. е. из базы данных SQL.

Пример сценария: приложение интернет-магазина, представляющее собой интерактивный каталог товаров. Пользователи создают запросы к веб-сайту или просматривают разделы, а также добавляют покупки в корзины. В момент оформления заказа приложение осуществляет его окончательную обработку. Данные клиентских счетов, сведения о товарных позициях и состояние корзины хранятся в определенном сочетании таблиц Azure, BLOB-объектов (изображения) и в базе данных SQL (клиентские данные).

В рамках этой модели масштабирование вверх и вниз осуществляется с помощью веб-ролей. В качестве хранилища здесь выступает SQL Server. В зависимости от приложения, хранилищем может являться любое сочетание таблиц Azure, BLOB-объектов Azure, а также хранилища SQL.

Гибридное приложение для локального размещения, использующее хранилище Azure и базу данных SQL

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

Приложение для фоновой обработки данных

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

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

Руководство по использованию очередей содержится в документе How to Use Service Bus Queues (Использование очередей шины обслуживания).

Масштабируемые веб-приложения с поддержкой масштабируемой фоновой обработки

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

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

Масштабируемое гибридное веб-приложение

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

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

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

Пример

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

Рассмотрим простой сценарий: приложение интернет-магазина, предлагающее пользователям каталог товаров, доступных для заказа. Каталог представляет собой сочетание изображений и текста. Изображения хранятся в виде BLOB-объектов, а тексты — в таблицах. Клиентские данные хранятся в базе данных SQL наряду с прочими данными. Веб-приложение запущено с помощью веб-роли, для которой можно создать дополнительные экземпляры. В базовой конфигурации (минимальная нагрузка) приложение использует следующие ресурсы:

• две малых веб-роли;
• 50 ГБ для хранения данных каталога в виде BLOB-объектов и таблиц (эти способы хранения данных тарифицируются по одинаковой ставке);
• 10 ГБ в базе данных SQL для хранения клиентских данных;
• 10 ГБ полосы пропускания.

Эти цифры вводятся в калькулятор Azure (см. снимок экрана). Общая стоимость минимальной конфигурации составляет примерно 250 долл. США.

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

Усреднив значения двух показателей расходов, мы получим 394 долл. США в месяц. Разумеется, среднее значение можно вычислить и для других конфигураций с другой продолжительностью использования.

Цикл разработки и ценообразования

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

1. Понимание принципов функционирования Azure. Вы должны иметь представление о моделях веб-ролей и рабочих ролей, способах хранения данных и использовании полосы пропускания.
2. Выберите модель (принципы выбора описаны ниже).
3. Определите, достаточна ли производительность модели для удовлетворения потребностей пользователей. 
   Например, для пользователей может быть критически важным малое время отклика системы, иначе они перестанут использовать приложение. Однако если пользователи ожидают, что обработка данных займет длительное время, набор доступных вам вариантов увеличивается.
4. Оцените планируемую нагрузку, чтобы определить требуемый размер веб-ролей и рабочих ролей.
5. Вычислите стоимость использования своего приложения на основе данной модели. Наполните модель конкретными данными, указав размеры, количество и тип экземпляров, объем хранилища и другие параметры. На этом этапе можно воспользоваться интерактивным калькулятором Azure.
6. Вычислите затраты для минимального и максимального периодов использования. 
   Эти периоды зависят от вашего приложения. Например, приложение для создания отчетов используется всеми менеджерами только в конце дня. А приложение для розничной торговли используется только в дневное время или в периоды праздничных покупок; при этом ночная нагрузка заметно меньше.
7. Оцените стоимость месячного использования; вычислите минимальные и максимальные значения.

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

Основополагающие стратегии

Перед запуском проекта по разработке приложения ознакомьтесь с полезными рекомендациями и стратегиями.

Планирование мощности

Планирование мощности позволяет достичь двух целей. Первая цель — определение ресурсов, необходимых приложению для соблюдения установленных соглашений об уровне обслуживания (Service Level Agreement, SLA). Вторая цель — оценка фактических затрат на приобретение этих ресурсов. Разобьем эту задачу на три части: (1) определение параметров производительности (SLA); (2) выявление окончательных потребностей в ресурсах с помощью тестирования и изменения конфигурации; (3) вычисление стоимости этих ресурсов. Планирование удобно проводить, опираясь на приведенную ниже диаграмму.

Определение базовых параметров затрат, получение ответа на вопрос «В чем мои затраты?»

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

Оценка рабочей нагрузки

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

Определение требований к уровню обслуживания

Укажите уровни доступности и производительности службы в динамике по времени. Основные вопросы: будет ли эта служба использоваться ежедневно и круглосуточно? Каковы максимальные и минимальные периоды использования? Помните, что производительность приложения влияет на степень удовлетворенности пользователей и их желание использовать приложение.

Настройте службу Compute и прочие службы

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

Проверьте сценарии максимальной и минимальной нагрузки

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

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

Оценка затрат для существующего бизнес-приложения

Как поступить при переносе существующего приложения на платформу Azure?

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

• На каком количестве серверов (физических или виртуальных) запущена служба?
• Какова конфигурация каждого из серверов? Сколько процессорных ядер используется? Какова тактовая частота этих ядер? Какой объем оперативной памяти серверов?
• Каковы усредненные показатели использования? Используется ли это приложение постоянно? Или же время от времени? На какие часы приходится пиковая нагрузка?
• Каковы усредненные показатели нагрузки по всем пикам? Используйте усредненные показатели для настройки подходящего экземпляра Compute. Размер и количество экземпляров должны быть достаточными для работы в условиях пиковой нагрузки и обеспечения доступности службы.
• Каковы абсолютные значения пиковой нагрузки? Выделите достаточные вычислительные мощности для работы в условиях абсолютной пиковой нагрузки, если она заметно превышает усредненную пиковую нагрузку.

Даже если вы еще не перенесли существующее приложение, эти ответы послужат отправной точкой для определения вашей потребности в вычислительных ресурсах.

Набор инструментов и руководящих материалов по переносу приложений содержится в разделе Microsoft Assessment and Planning Toolkit (Набор инструментов Microsoft для оценки и планирования).

https://msdn.microsoft.com/en-us/library/windowsazure/hh689719(v=vs.103)

Планирование ресурсов

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

Один из клиентов Microsoft, не изменивший своим привычкам, в результате понес дополнительные расходы.

Группы специалистов со стороны клиента, которые занимаются поддержкой, разработкой, тестированием и маркетингом, использовали отдельные компьютеры согласно своим пожеланиям. Группы разработчиков и тестировщиков привыкли к регулярному восстановлению своих компьютеров, что позволяет им начинать работу на чистой системе. С другой стороны, группы маркетинга и технической поддержки привыкли пользоваться одним и тем же ПО для создания повторяющихся презентаций (маркетинг) и воспроизведения ошибок (поддержка). Все четыре группы начали с того, что создали четыре разные подписки Azure, наиболее полно соответствующие их приемам и методам работы. В результате компания оплачивала четыре отдельные подписки. Через некоторое время стало понятно, что требуются всего две подписки. Одну подписку могли использовать отделы технической поддержки и маркетинга, а вторую — отделы разработки и тестирования.

Рефакторинг данных с использованием хранилища Azure и базы данных SQL

Данные — важнейший компонент любого приложения. Azure позволяет использовать две технологии: базу данных SQL и хранилище Azure. Хранение гигабайтов данных в хранилище Azure данных обойдется всего в несколько долларов ежемесячной абонентской платы. Однако данные хранятся в виде BLOB-объектов, таблиц или очередей. Преимущество (и недостаток) таблиц Azure заключается в том, что они не поддерживают реляционную модель данных. Еще одно преимущество — возможность автоматического масштабирования без участия пользователей. Если вы опытный программист SQL, это обстоятельство заставит вас поменять взгляды на использование и хранение данных. Практический опыт показывает, что многие люди привычно используют SQL Server для решения даже весьма тривиальных задач, не требующих применения реляционной модели.

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

Обращая внимание на низкую стоимость хранилища Azure, многие клиенты считают оправданным использовать его для хранения все более крупных массивов данных. В результате база данных SQL используется только для хранения метаданных. Это не догма, однако такой вариант размещения данных необходимо учитывать. Подведем итоги: используйте хранилище Windows Storage для хранения большей части ваших данных, а базу данных SQL применяйте для хранения метаданных. Чтобы сократить расходы на хранение, создавайте запросы к базе данных SQL и получайте данные из хранилища Windows.

Диагностика, устранение неполадок и факторы производительности

Для устранения неполадок и тестирования производительности необходимы счетчики показателей производительности и средства трассировки. В этом разделе приводятся сведения, которые помогут сэкономить время и силы. Базовая информация о средствах диагностики содержится в документе Enabling Diagnostics in Windows Azure (Активация средств диагностики в Windows Azure).

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

Дополнительные сведения об отслеживании приложений см. в документе Monitoring a Windows Azure Application (Отслеживание приложения Windows Azure).

Автоматическое масштабирование

Автоматическое масштабирование — это одно из основных преимуществ разработки облачных приложений для платформы Windows Azure. Служба Azure позволяет автоматически увеличивать или уменьшать количество запущенных экземпляров Compute. Чтобы реализовать автоматическое масштабирование наиболее эффективно, обратитесь к статье The Autoscaling Application Block (Блок автоматического масштабирования приложений).

Блок автоматического масштабирования содержит механизм обработки правил, с помощью которых определяется время и способ масштабирования. Этот механизм также позволяет переопределять правила на основании определенных критериев, например времени суток. Дополнительную информацию см. в статье How to use the Autoscaling Application Block (Использование блока автоматического масштабирования приложений).

Планирование устранения кратковременных сбоев (логика повтора операций)

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

Каждая попытка подключения к службе с тарифицируемым соединением (например, к серверу управления доступом или к шине обслуживания) стоит денег, даже если попытка завершается сбоем. Эти расходы незначительны; как правило, они составляют малую долю затрат на обработку или хранение данных. Если количество соединений, включая повторные, достаточно велико и приводит к увеличению расходов, весьма вероятно несоответствие производительности приложения и требований клиентов. В этом случае затраты представляют собой далеко не самую большую проблему.

Шина обслуживания

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

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

https://msdn.microsoft.com/en-us/library/windowsazure/hh694235(v=vs.103)

Нагрузочное тестирование

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

Дополнительные сведения о применении Visual Studio при проведении нагрузочного тестирования приложений Azure см. в главе Использование нагрузочных тестов Visual Studio в ролях Windows Azure.

Оптимизация

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

Для получения дополнительных сведений о кэшировании см. How to Use the Caching Service (Приемы использования службы кэширования). Дополнительная информация о CDN размещена в статье Using CDN for Windows Azure (Использование CDN с Windows Azure).

Сводка

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

Это перевод оригинальной статьи https://msdn.microsoft.com/en-us/library/windowsazure/jj136829.aspx

Comments

• Anonymous
  February 27, 2013
  Интересная статья, спасибо! Мы тоже решили использовать Windows Azure для запуска своих сервисов (sppur.ru), похоже цены даже стали ниже по сравнению с тем что представлено в статье. По моим расчетам на калькуляторе www.windowsazure.com/.../calculator для сервиса слежения за компьютерами в организациях (основная ресурсоемкая функция сохранение скриншотов и шифрование) для работы примерно 70 рабочих точек потребуется всего ~2000 рублей в месяц, пока пробуем 90 дневную бесплатную версию, спасибо Майксрософт за гибкую платформу :)

• Anonymous
  March 05, 2013
  Да, цены постоянно корректируются