Шаблон меток развертывания

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

Контекст и проблема

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

• Ограничения масштабирования. Развертывание одного экземпляра приложения может привести к естественным ограничениям масштабирования. Например, можно использовать службы, которые имеют ограничения на количество входящих подключений, имен узлов, сокетов TCP или других ресурсов.
• Нелинейное масштабирование или стоимость. Некоторые компоненты решения могут не масштабироваться линейно с количеством запросов или объемом данных. Вместо этого может возникнуть внезапное снижение производительности или увеличение затрат после достижения порогового значения. Например, вы можете использовать базу данных и обнаружить, что маргинальные затраты на добавление большей емкости (масштабирование) становится запретительным, и что масштабирование является более экономичной стратегией.
• Разделение клиентов. Возможно, вам потребуется сохранить данные определенных клиентов изолированными от данных других клиентов. Аналогичным образом у вас могут быть некоторые клиенты, которые требуют больше системных ресурсов для обслуживания, чем другие, и рассмотрите возможность группировки их в различных наборах инфраструктуры.
• Обработка одноэлементных и мультитенантных экземпляров. У вас могут быть некоторые крупные клиенты, которым нужны собственные независимые экземпляры решения. У вас также может быть пул небольших клиентов, которые могут совместно использовать мультитенантное развертывание.
• Сложные требования к развертыванию. Вам может потребоваться развернуть обновления в службе с помощью управляемого способа и развернуть их в разных подмножествах базы клиентов в разное время.
• Частота обновления. У вас могут быть некоторые клиенты, которые терпимы к частым обновлениям в вашей системе, в то время как другие могут быть рискованными и хотят редко обновлять систему, которая обслуживает свои запросы. Это может иметь смысл развернуть этих клиентов в изолированных средах.
• Географические или геополитические ограничения. Для разработки низкой задержки или соблюдения требований к суверенитету данных можно развернуть некоторые клиенты в определенных регионах.

Эти ограничения часто применяются к независимым поставщикам программного обеспечения (ISV), которые создают программное обеспечение как услуга (SaaS), которые часто предназначены для мультитенантной поддержки. Однако те же ограничения также могут применяться к другим сценариям.

Решение

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

Метки развертывания могут применяться, использует ли ваше решение инфраструктуру как службу (IaaS) или компоненты платформы в качестве службы (PaaS) или сочетание обоих компонентов. Как правило, для рабочих нагрузок IaaS требуется больше вмешательства для масштабирования, поэтому шаблон может быть полезен для рабочих нагрузок IaaS-heavy, чтобы обеспечить масштабирование.

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

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

Шаблон метки развертывания используется внутренне многими службами Azure, включая Служба приложений, Azure Stack и служба хранилища Azure.

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

Развертывание

Из-за сложности, связанной с развертыванием идентичных копий одних и того же компонентов, хорошие методики DevOps критически важны для обеспечения успеха при реализации этого шаблона. Рассмотрите возможность описания инфраструктуры как кода, например с помощью Bicep, шаблонов Azure Resource Manager (шаблонов ARM), Terraform и скриптов. С помощью этого подхода можно убедиться, что развертывание каждой метки является предсказуемым и повторяемым. Это также снижает вероятность ошибок человека, таких как случайное несоответствие в конфигурации между метками.

Вы можете автоматически развертывать обновления для всех меток параллельно, в этом случае можно рассмотреть такие технологии, как Bicep или Resource Manager, для координации развертывания инфраструктуры и приложений. Кроме того, вы можете решить постепенно развернуть обновления некоторых меток сначала, а затем постепенно для других. Рекомендуется использовать средство управления выпусками, например Azure Pipelines или GitHub Actions , для оркестрации развертываний для каждой метки. Дополнительные сведения см. в разделе:

• Интеграция Bicep с Azure Pipelines
• Интеграция шаблонов ARM JSON с Azure Pipelines

Тщательно рассмотрите топологию подписок Azure и групп ресурсов для развертываний:

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

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

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

Маршрутизация трафика

Шаблон метки развертывания работает хорошо, если каждая метка решается независимо. Например, если Компания Contoso развертывает одно и то же приложение API на нескольких метках, они могут рассмотреть возможность использования DNS для маршрутизации трафика на соответствующую метку:

• unit1.aus.myapi.contoso.com маршрутизирует трафик для метки unit1 в австралийском регионе.
• unit2.aus.myapi.contoso.com маршрутизирует трафик для метки unit2 в австралийском регионе.
• unit1.eu.myapi.contoso.com маршрутизирует трафик для метки unit1 в европейском регионе.

Затем клиенты отвечают за подключение к правильной метки.

Если требуется одна точка входящего трафика для всего трафика, служба маршрутизации трафика может использоваться для разрешения метки для заданного запроса, клиента или клиента. Служба маршрутизации трафика либо направляет клиента к соответствующему URL-адресу для метки (например, с помощью кода состояния ответа HTTP 302), либо он может выступать в качестве обратного прокси-сервера и перенаправит трафик в соответствующую метку без уведомления клиента.

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

Например, azure Управление API можно развернуть для выполнения действий в роли службы маршрутизации трафика. Он может определить соответствующую метку для запроса, найдите данные в коллекции Azure Cosmos DB , сохраняя сопоставление между клиентами и метками. Управление API затем динамически задать внутренний URL-адрес для службы API соответствующей метки.

Чтобы обеспечить геораспространение запросов и геоизбыточность службы маршрутизации трафика, Управление API можно развернуть в нескольких регионах, или Azure Front Door можно использовать для направления трафика в ближайший экземпляр. Front Door можно настроить с помощью внутреннего пула, что позволяет направлять запросы к ближайшему доступному экземпляру Управление API. Если приложение не предоставляется через ПРОТОКОЛ HTTP/S, вы можете использовать межрегиональная подсистема балансировки нагрузки Azure для распространения входящих вызовов в региональные подсистемы балансировки нагрузки Azure. Глобальная функция распространения Azure Cosmos DB может использоваться для обновления сведений о сопоставлении в каждом регионе.

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

Пример архитектуры маршрутизации трафика

Рассмотрим следующую архитектуру маршрутизации трафика, которая использует Azure Front Door, Azure Управление API и Azure Cosmos DB для глобальной маршрутизации трафика, а затем ряд меток для конкретного региона:

Предположим, что пользователь обычно находится в Нью-йорке. Их данные хранятся в метке 3 в регионе "Восточная часть США".

Если пользователь отправляется в Калифорнию, а затем обращается к системе, их подключение, скорее всего, будет перенаправлено через регион "Западная часть США 2", так как это ближе всего к месту, где они географически находятся при выполнении запроса. Однако запрос должен в конечном итоге обслуживаться меткой 3, так как это место хранения данных. Система маршрутизации трафика гарантирует, что запрос направляется на правильную метку.

Проблемы и рекомендации

При выборе схемы реализации этого шаблона следует учитывать следующие моменты.

• Процесс развертывания. При развертывании нескольких меток настоятельно рекомендуется использовать автоматизированные и полностью повторяющиеся процессы развертывания. Рекомендуется использовать Bicep, шаблоны ARM JSON или модули Terraform для декларативного определения меток и обеспечить согласованность определений.
• Операции перекрестной метки. Когда решение развертывается независимо между несколькими метками, вопросы, такие как "сколько клиентов у нас есть на всех наших метках?", могут стать более сложными для ответа. Запросы могут выполняться для каждой метки и агрегированных результатов. Кроме того, рассмотрите возможность публикации всех меток в централизованном хранилище данных для консолидированной отчетности.
• Определение политик горизонтального масштабирования. Метки имеют ограниченную емкость, которая может быть определена с помощью метрики прокси-сервера, например числа клиентов, которые можно развернуть на метку. Важно отслеживать доступную емкость и используемую емкость для каждой метки, а также заранее развертывать дополнительные метки, чтобы позволить им направлять новых клиентов.
• Минимальное количество меток. При использовании шаблона метки развертывания рекомендуется развернуть по крайней мере две метки решения. Если вы развертываете только одну метку, в коде или конфигурации, которые не будут применяться при горизонтальном масштабировании, легко случайно выполнить предположение жесткого кода.
• Стоимость. Шаблон метки развертывания включает развертывание нескольких копий компонента инфраструктуры, что, скорее всего, приведет к значительному увеличению затрат на эксплуатацию решения.
• Перемещение между метками. Каждая метка развертывается и работает независимо, поэтому перемещение клиентов между метками может быть сложной задачей. Приложению потребуется пользовательская логика для передачи сведений о заданном клиенте на другую метку, а затем для удаления сведений клиента из исходной метки. В этом процессе может потребоваться обратная планка для обмена данными между метками, что повышает сложность общего решения.
• Маршрутизация трафика. Как описано ранее в этой статье, маршрутизация трафика на правильную метку для данного запроса может потребовать дополнительного компонента для разрешения клиентов на метки. Этот компонент, в свою очередь, может потребоваться сделать высокодоступным.
• Общие компоненты. Возможно, у вас есть некоторые компоненты, которые можно совместно использовать для меток. Например, если у вас есть общее одностраничное приложение для всех клиентов, рассмотрите возможность развертывания этого приложения в одном регионе и использования Azure CDN для глобальной репликации.

Когда следует использовать этот шаблон

Этот шаблон полезен при наличии:

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

Этот шаблон не подходит для следующих целей:

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

Проектирование рабочей нагрузки

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

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

Вспомогательные технологии

• Инфраструктура как код. Например, Bicep, шаблоны Resource Manager, Azure CLI, Terraform, PowerShell, Bash.
• Azure Front Door, который может направлять трафик на определенную метку или в службу маршрутизации трафика.

Пример

В следующем примере развертывается несколько меток простого решения PaaS с помощью службы приложений и База данных SQL в каждой метке. Хотя метки можно настроить в любом регионе, который поддерживает службы, развернутые в шаблоне, для иллюстрации этот шаблон развертывает две метки в регионе "Западная часть США 2" и дополнительную метку в регионе "Западная Европа". В метках служба приложений получает собственное имя общедоступного узла DNS и может получать подключения независимо от всех остальных меток.

Щелкните ссылку ниже, чтобы развернуть решение.

Пример подхода к маршрутизации трафика

В следующем примере развертывается реализация решения маршрутизации трафика, которое можно использовать с набором меток развертывания для гипотетического приложения API. Чтобы обеспечить географическое распределение входящих запросов, Front Door развертывается вместе с несколькими экземплярами Управление API на уровне потребления. Каждый экземпляр Управление API считывает идентификатор клиента из URL-адреса запроса, а затем ищет соответствующую метку для запроса из гео распределенного хранилища данных Azure Cosmos DB. Затем запрос пересылается на соответствующую серверную метку.

Щелкните ссылку ниже, чтобы развернуть решение.

Соавторы

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

Автор субъекта:

• Джон Даунс | Главный диспетчер программ

Другие участники:

• Даниэль Ларсен | Главный инженер клиента, FastTrack для Azure
• Ангел Лопес | Старший инженер по программному обеспечению, шаблоны и методики Azure
• Паоло Сальватори | Главный инженер клиента, FastTrack для Azure
• Арсен Владимирский | Главный инженер клиента, FastTrack для Azure

Чтобы просмотреть недоступные профили LinkedIn, войдите в LinkedIn.

Связанные ресурсы

• Сегментирование можно использовать в качестве другого, более простого подхода к масштабированию уровня данных. Метки неявно сегментирует свои данные, но сегментирование не требует метки развертывания. Дополнительные сведения см. в статье Sharding pattern (Шаблон сегментирования).
• Если служба маршрутизации трафика развернута, шаблоны маршрутизации шлюза и разгрузки шлюза можно использовать вместе для оптимального использования этого компонента.