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

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

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

  • Приложение в облаке — это всегда сервис, удаленно доступный через интернет-каналы. Взаимодействие между клиентом и сервисом, расположенным в облаке, должно происходить с учетом возможных задержек и, при необходимости, обеспечивать повтор соединения и возобновление передачи данных. Редко изменяемые данные следует кешировать или использовать возможности сети доставки контента1. Рекомендуется использовать встроенные средства диагностики Windows Azure для сбора и последующего анализа данных счетчиков производительности и системных журналов. Разработчики, использующие Visual Studio 2010, могут включить режим трассировки IntelliTrace и автоматически получать детальную отладочную информацию из приложения, работающего в облаке.
  • Динамичная инфраструктура, обеспечивающая эластичность облака, позволяет горизонтально масштабировать приложения, быстро изменяя количество одновременно работающих экземпляров2. Поэтому не рекомендуется хранить состояние приложений3 в памяти или на локальных дисках, так как каждое следующее обращение к приложению может быть адресовано другому его экземпляру. Использование локальных дисков не рекомендуется также по причине того, что сохранение их содержимого не гарантируется в случае отказа оборудования, обновлении операционной системы или при переносе приложения на другой серверный узел. Для хранения состояния рекомендуется использовать долговременное надежное хранилище данных, такое как Azure Storage или SQL Azure. В ряде случаев состояние можно хранить на клиенте и, таким образом, частично разгрузить сервис и снизить объем потребляемых ресурсов.
  • Платформенные сервисы позволяют автоматизировать ряд сценариев, которые сложно или дорого реализовывать в локальной инфраструктуре. К таким сценариям, например, относятся хранение и обработка больших объемов данных, высокопроизводительные вычисления и т.п.
  • Автоматизация управления приложением. Разработчик размещает в Windows Azureприложение, а заботу о выделении, конфигурировании и администрировании вычислительных ресурсов берет на себя платформа, которая постоянно ведет мониторинг состояния приложения, операционной системы и аппаратной инфраструктуры. Это обеспечивает высокую доступность и надежность предоставляемого сервиса на уровне 99,9%4.
  • Отличия серверных и облачных технологий. В целом при проектировании и разработке приложений нужно ориентироваться на серверную операционную систему Windows Server 2008 x64 и СУБД SQL Server 2008 R2, но при этом учитывать ряд документированных особенностей.
  • «Цена» архитектуры. При разработке приложений, предназначенных для размещения в локальной инфраструктуре Интранет, влияние архитектуры на стоимость потребляемых ресурсов практически никогда не учитывалось. «Цена» архитектуры становится актуальной для облачных приложений, использующих ресурсы облачной платформы, которые оплачиваются по факту использования. Ниже мы рассмотрим вышеперечисленные особенности более подробно.

«Цена» архитектуры

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

Трафик

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

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

Вычислительные ресурсы

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

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

Хранилище данных

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

  • Разница между стоимостью сервиса реляционной базы данных SQL Azure и хранилищем нереляционных данных Azure Storage может оказаться весьма значительной6.
  • SQL Azure и Azure Storage предоставляют фундаментально отличающиеся сервисы, что необходимо учитывать при проектировании приложения. Так, для доступа к SQL Azure могут применяться те же технологии доступа к данным7, что и для SQL Server, тогда как Azure Storage доступен в виде веб-сервиса8.
  • Перенос части реляционных данных в более дешевое хранилище с SQL Azure в Azure Storage может оказаться удобным, если приложение ориентировано на работу с подмножеством оперативно доступных реляционных данных. Например, архивы, резервные копии и другие редко меняющиеся данные являются хорошими кандидатами для Azure Storage.
  • Документы, файлы, другие большие цифровые объекты рекомендуется хранить в Azure BLOB Storage cвозможным включением сети доставки контента (CDN) для повышения скорости доступа и снижения задержек в канале.
  • База данных SQL Azure тарифицируется начиная с 1 Гб, следствием чего является необходимость сокращения числа баз данных, используемых приложением.

Мультитенантная архитектура

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

Рис. 15. Не мультитенантное приложение

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

Рис. 16. Мультитенантное приложение

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

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

Мультитенантное приложение

Существует четыре общих этапа перехода к эффективной мультитенантной архитектуре с поддержкой пользовательской конфигурации:

  • Выделенная архитектура. Каждая группа пользователей использует отдельную копию сервиса, предназначенную только для него, и единственный способ поддерживать разные группы пользователей — предоставление им разных копий сервиса. Более того, поскольку практически ничего не обеспечивает возможности настройки через конфигурацию, каждая копия включает настройки конкретного пользователя в форме собственного кода расширения, собственных процессов и/или собственных расширений данных. Хотя, технически, это сервис (т.е. работает удаленно в облаке), повышения эффективности от роста масштабов достичь невозможно, поскольку все потребители пользуются разными экземплярами сервиса. Такая модель может быть отправной точкой для проверки правильности бизнес-модели, но от нее необходимо отказаться, как только количество пользователей начинает увеличиваться. Она не годится для предоставления сервиса тысячам пользователей.
  • Настраиваемая архитектура. Сервис настраивается для каждого конкретного пользователя через конфигурацию и без применения собственного кода. Все тенанты выполняют один и тот же код. Однако архитектура все равно не является мультитенантной, и каждый пользователь работает с собственной копией сервиса, несмотря на то что копии идентичны. Разделение может быть либо виртуальным (виртуальные машины на одном сервере), либо физическим (выполнение на разных компьютерах). Эта модель является существенным улучшением по сравнению с описанной выше моделью выделенной архитектуры. Тем не менее, архитектура по-прежнему не допускает настройки через конфигурацию, и вычислительные мощности не разделяются между экземплярами. Поэтому поставщик не может добиться повышения экономической эффективности от роста масштабов использования.
  • Мультитенантная архитектура. Пользовательский интерфейс может настраиваться для каждого тенанта в отдельности, как и бизнес-правила, и модель данных. Настройку каждый тенант выполняет исключительно через конфигурацию с использованием инструментов для самостоятельной настройки, что снимает ответственность за настройку с поставщика сервиса. Этот уровень является практически идеальным вариантом SaaS; единственный недостаток — никакой возможности горизонтального масштабирования, повышение производительности может быть достигнуто только через вертикальное масштабирование.
  • Масштабируемая архитектура. Такая архитектура поддерживает мультитенантность и конфигурацию, плюс возможность горизонтального масштабирования сервиса. Новые экземпляры сервисов могут без труда добавляться в пул экземпляров для обеспечения динамической поддержки возрастающей нагрузки. Соответствующее секционирование данных, дизайн компонентов без сохранения состояния и совместный доступ к метаданным являются частью дизайна. Общая нагрузка распределяется по всей доступной инфраструктуре. Также периодически выполняется реорганизация данных для усреднения нагрузки по обработке данных на каждый экземпляр. Архитектура является масштабируемой, мультитенантной и настраиваемой через конфигурацию.

Мультитенантное хранилище

Существует три основные модели реализации мультитенантного хранилища:

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

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

Отличия серверных и облачных технологий

Для иллюстрации различий платформы Windows Azure и Windows Server мы используем диаграмму многослойной архитектуры приложения9. Вспомним, что разделение на уровни — это с одной стороны хорошая практика проектирования, а с другой — классический способ визуализации архитектуры с целью упрощения задачи проектирования. Как правило, выделяют следующие логические уровни приложения: представление, сервисы, бизнес-логика, доступ к данным, хранилище. Наряду с уровнями рассматривают общие для всех уровней компоненты, обеспечивающие взаимодействие, безопасность и управление (рис. 18).

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

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

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

Рис. 17. Разделение на уровни

Рис. 18. Инфраструктурные блоки платформы Windows Azure

Используя рис. 19, можно сравнить серверный вариант архитектуры с приведенным выше вариантом Windows Azure Platform.

Рис. 19. Инфраструктурные блоки платформы Windows Server

Чтобы провести более точные аналогии, приведем таблицу, позволяющую сравнить технологии платформы Windows Azure и Windows Server. Подчеркнем, что это не прямые аналогии. Например, сервисная шина (Service Bus) не имеет прямого аналога на платформе Windows Server, однако, подобные функции можно реализовать, используя BizTalk Server или Windows Communication Foundation. В ряде случаев, аналогия является почти прямой, как например, при сравнении веб-роли и Internet Information Server или SQL Azure и SQL Server.

Windows Azure Windows Server
Веб-роль Internet Information Server10
Прикладная роль

Windows процесс

Windows сервис

VM-роль Виртуальная машина Hyper-V
Service Bus

Windows Communication Foundation

Windows Server AppFabric

BizTalk Server

Access Control

Active Directory Federation Services

Windows Identity Federation

Azure Tables WCF Data Services
Azure Queue                

MSMQ

SQL Server Service Broker

Azure Blobs

IIS WebDav

SharePoint

WCF REST11

Azure CDN Windows Server AppFabric Cache
SQL Azure SQL Server

 

Отказоустойчивость сервисов

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

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

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

Основные вопросы, которые нужно задать себе при проектировании приложения:

  • Что произойдет, если компонент приложения откажет?
  • Как определить факт отказа?
  • Приведет ли автоматический перезапуск экземпляра приложения к восстановлению состояния перед отказом?
  • Для каких сценариев есть план восстановления?
  • Какова единая точка сбоя12 приложения?
  • Также следует учитывать сбои и в прикладном коде. Основные вопросы:
  • Что произойдет с приложением, если вызываемый сервис изменит свой интерфейс?
  • Что если вызываемый сервис недоступен по таймауту или возвращает состояние исключения?
  • Что произойдет, если приложение получает исключение при попытке выделить память?

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

  • Имейте протестированный и всеобъемлющий план резервного копирования и восстановления данных. Желательно автоматизировать процедуры плана.
  • Избегайте хранения состояния приложения в памяти. К таким состояниям относятся сессии веб-приложений, контексты пользователя, статические переменные и т.п. Данные такого рода должны храниться в базе данных или ином хранилище, предназначенном для долговременного хранения данных.
  • Используйте очереди сообщений и не удаляйте частично обработанные сообщения, не убедившись в успехе операции.
  • При необходимости выполнять последовательность операций с данными, используйте транзакции. Если это невозможно или операция должна выполняться долго (long running transaction), сохраняйте шаги операции в надежном хранилище или рассмотрите использование технологии Windows Workflow Foundation13 или продуктов класса Biz Talk Server14 и VM-роли Windows Azure.
  • Обрабатывайте таймауты и другие исключения, возникающие при вызове сервисов. Прикладной код должен быть способен несколько раз повторить операцию, которая включает в себя вызов удаленного сервиса.
  • Одинаковые сообщения должны производить одинаковые действия. Например, если сервис получает одно и то же сообщение несколько раз в результате повторной передачи данных, состояние базы данных не должно измениться. Это называется принципом равнозначности15.
  • Экземпляры приложений в облачной инфраструктуре должны быть нечувствительны к перезапуску и перезагрузке операционной системы (потенциально, на другом сервере).

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

  • Программные интерфейсы Управления позволяют программно управлять инфраструктурой Windows Azure, например, запускать и останавливать экземпляры приложений.
  • Программные интерфейсы Диагностики позволяют получать информацию из журналов работы, счетчиках производительности, результатах трассировки приложений.
  • При запуске приложения могут быть выполнены программные действия по инициализации.
  • Приложение получает сигналы (события) от облачной инфраструктуры при необходимости перезапуска, обновления и других изменений конфигурации сервиса.
  • Веб-приложения могут воспользоваться провайдером сессии ASP.NET и хранить состояние в Azure Storage.
  • Очередь сообщений Azure Queue позволяет пометить сообщение для обработки и снять этот признак, если в течение заданного времени сообщение не было обработано.

Имея полную и достоверную информацию о работе приложения можно более эффективно планировать потребление ресурсов облака, что уже отмечалось в разделе «Цена архитектуры».


1 Сеть доставки контента (CDN) платформы Windows Azure обеспечивает кеширование данных на более чем 20 узлах, расположенных по всему миру.

2 Каждому экземпляру приложения в Windows Azureвыделяется виртуальная машина.

3 К таким состояниям относятся сессии ASP.NET. Имеется провайдер сессии ASP.NET для хранения в Azure Storage.

4 Доступность предоставляемого сервиса в соответствии с официальным SLA платформы Windows Azure.

5 Windows Azure поддерживает сжатие HTTP-трафика.

6http://www.microsoft.com/windowsazure/pricing/#sql

7 Поддерживаются ADO.NET, ODBC, PHP SQL Server Driver, Entity Framework.

8 В Windows Azure Platform SDK входит официально поддерживаемый компонент StorageClient для упрощения доступа к Azure Storage. Также доступны компоненты для PHP, Java и Ruby.

9 Более подробно эти вопросы освещаются в официальном руководстве Microsoft по проектированию архитектуры приложений (на русском языке) — http://apparchguide.ms/

10http://www.iis.net/

11http://msdn.microsoft.com/wcf/rest

12Англ. — single point of failure.

13 Windows Workflow Foundation (WF) — технология .NET, предназначенная для создания и выполнения потоков работ, бизнес-процессов и длинных транзакций.

14 BizTalk Server — серверный продукт, предназначенный для интеграции приложений www.microsoft.com/biztalk/

15Англ. — idempotancy.