Изучаем архитектуру облака

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

В качестве основы для идей и различных соображений я буду использовать Platform as a Service (PaaS), в частности Windows Azure, но идеи, которые я хочу выразить в этой статье, с небольшими изменениями применимы и к Infrastructure as a Service (IaaS), и к Software as a Service (SaaS). Я поясню некоторые ключевые соображения по проектированию при создании облачного решения, попытаюсь классифицировать предоставляемый Windows Azure инструментарий, проиллюстрирую некоторые базовые архитектуры и предоставлю вам своего рода матрицу решений для того, чтобы вы смогли выбрать свой стиль проектирования.

Соображения по облаку

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

Что значит проектировать облачное решение? Я хочу начать с того, что ставить веб-роль (Web Role) в очередь к рабочей роли (Worker Role), а затем извлекать результат из очереди возвращаемых данных (return queue) — не лучший стиль облачной архитектуры. По сути, во многих отношениях применение такой архитектуры в качестве базовой для проектирования своего решения может заметно уменьшить преимущества облачной реализации в целом. С появлением закрытой облачной инфраструктуры граница между облачными и необлачными решениями размывается из-за того, что место размещения перестает быть разграничивающим фактором. Поэтому центр тяжести в дифференциации нужно переносить на то, для чего она предназначена, а не на то, что она собой представляет или где находится.

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

• приобретения, установки, настройки и управления инфраструктурой;
• ограничений пропускной способности — вычислительные ресурсы и пространство для хранения выделяются в соответствии с требованиями;
• непомерно высоких капитальных затрат — я оплачиваю лишь то, что потребляю.

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

Фактор стоимости

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

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

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

Оптимизация расходов требует детального понимания:

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

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

Фактор задержек

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

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

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

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

Высокоуровневая архитектура

Размышляя об обобщении архитектуры корпоративных решений, все шестеренки можно разложить по нескольким категориям:

• вычисления;
• хранение;
• интеграция.

Вот как я буду классифицировать возможности платформы Windows Azure в этом контексте. В табл. 1 показано подмножество возможностей платформы Windows Azure.

‘Табл. 1. Категории арсенала платформы

Сосредоточившись на крупных блоках (вычисления, хранение и интеграция), можно легко сложить из них некоторые базовые архитектуры, с которых вы начнете и которые будете расширять или даже перекомпоновывать, как показано на рис. 1.

Рис. 1. Базовые высокоуровневые архитектуры

Хотя архитектуры на рис. 1, не отражают все возможные вариации, они являются более крупными проектировочными блоками, которые служат своим целям.

• Прямой доступ к данным Это обычно самая базовая реализация, где через клиентский веб-интерфейс не только напрямую обращаются к данным, но и выполняют всю работу.
• Абстрагирование через сервисы Это образец архитектуры, ориентированной на сервисы (SOA), которая является следующим уровнем абстрагирования и балансировки нагрузки. Доступ к данным и бизнес-логика выделяются в роли, обслуживающие UI. Хороший SOA-проект может не только уменьшить хрупкость решения, но и сократить нагрузку на внутреннюю серверную часть, а также оптимизировать скорость ответа для клиента.
• Абстрагирование через очереди Нагрузка передается фоновым рабочим ролям через Windows Azure Storage Queues. Это первый шаг в оптимизации рабочей нагрузки, но в целом он подходит, только если результат переданной работы принимается как не требующий почти моментального ответа для клиента.
• Интеграция через шину сервисов Добавление механизма публикации/подписки в инфраструктуру сервисов способно серьезно расширить SOA-проект за счет переноса уровня абстрагирования с конечных точек на области интересующей вас информации. Эта архитектура может обеспечить самую гибкую реализацию.
  
  Архитектуры с использованием корпоративной инфраструктуры

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

Рис. 2. Базовые архитектуры с использованием корпоративной инфраструктуры

Один из базовых способов подключения ваших облачных решений к вашей корпоративной экосистеме — простое использование Windows Azure Connect, рассмотренное Анной Скободзиньски (Anna Skobodzinski), одной из моих коллег по Microsoft Technology Center (MTC); этот способ изложен по ссылке bit.ly/wnyqj9. Данный вариант обозначен на рис. 2как стиль с использованием VPN. Система может применяться как есть, но задержка составляет около секунды. Кроме того, имеет смысл проделать некоторую работу заблаговременно и убедиться, что системы, предоставляемые облачным приложениям, готовы к обработке дополнительной нагрузки. Если вам поставлена задача как можно быстрее создать облачное решение, которое должно быть интегрировано с существующими интерфейсами, интеграция в стиле VPN может оказаться самым быстрым и простым способом выполнения этой задачи.

Наиболее распространенный тип интеграции — стиль с применением интеграции данных. Он требует использования некоторых средств синхронизации данных в одном или обоих направлениях. Решить эту задачу можно самыми разнообразными способами, и у каждого из них есть свои плюсы и минусы. Применение такого ETL-инструмента (extract, transform and load), как SQL Server Integration Services (SSIS), — это, вероятно, самый простой способ для большинства предприятий. Как средство синхронизации данных SSIS также обладает очень зрелой экосистемой мониторинга и управления. Следующий по простоте механизм — SQL Azure Data Sync, который в настоящее время доступен в виде предварительной версии (bit.ly/p14qC6). Он опирается на технологию Sync Framework, о которой я рассказывал в этой рубрике в январе (msdn.microsoft.com/magazine/gg535668) и феврале 2011 г. (msdn.microsoft.com/magazine/gg598920). Он потребует внесения некоторых изменений в синхронизируемые таблицы. При использовании как SSIS, так и Sync Framework стоит убедиться в том, что между облаком и локальной корпоративной системой передаются лишь необходимые поля данных. Не передавая лишних данных, вы сможете сократить затраты на входящий и исходящий трафик плюс уменьшить объем занимаемого пространства для хранения данных в облаке.

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

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

Инструмент, помогающий выявлять потенциальные проблемные области при выборе одного из базовых архитектурных стилей, — матрица решений. Матрицарешений, приведенная в табл. 2, не является истиной в последней инстанции, а скорее отражает мой опыт в работе с предприятиями, переходившими на облачную инфраструктуру. Она не обязательно позволит определить явного победителя, и во многих случаях реальная архитектура будет включать некую смесь этих шаблонов. Например, можно было развернуть новое веб-приложение, где есть набор REST-сервисов; эти сервисы работают с серверной базой данных, которая синхронизируется через ETL дважды в день. Этот пример комбинированной архитектуры показан на рис. 3.

Табл. 2. Матрица решений

Рис. 3. Пример комбинированной архитектуры

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

Архитектура и эффективность затрат

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

Я затронул базовую веб-архитектуру и базовую архитектуру интеграции с корпоративной инфраструктурой, но все детали оставил для будущих статей — чтобы охватить все разом, потребовалось бы слишком много места. Поскольку это единственная статья в данной рубрике, полностью посвященная архитектуре безо всякой реализации, я надеюсь, что она все же принесла вам пользу. Если вы хотите, чтобы я углубился в детали каких-то частей архитектуры, пожалуйста, пишите комментарии к этой статье на сайте msdn.microsoft.com/magazine.