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

Шаблон метки развертывания включает подготовку, управление и мониторинг разнородной группы ресурсов для размещения и работы нескольких рабочих нагрузок или клиентов. Each individual copy is called a stamp, or sometimes a service unit, scale unit, or cell. В мультитенантной среде каждая единица метки или единицы масштабирования может служить предопределенному количеству клиентов. Можно развернуть несколько меток, чтобы масштабировать решение почти линейно и обслуживать все больше клиентов. Такой подход позволяет повысить масштабируемость решения, развернуть экземпляры в нескольких регионах и разделить данные клиента.

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

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

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

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

Solution

To avoid these issues, consider grouping resources in scale units and provisioning multiple copies of your stamps. Each scale unit will host and serve a subset of your tenants. Метки работают независимо друг от друга и могут развертываться и обновляться также независимо друг от друга. Один географический регион может содержать одну метку или содержать несколько меток, чтобы обеспечить горизонтальное масштабирование в пределах региона. Метки содержат подмножество клиентов.

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

Stamps can be used to implement deployment rings. Если разные клиенты хотят получать обновления служб на разных частотах, их можно сгруппировать на разные метки, и каждая метка может иметь обновления, развернутые на разных частотах.

Because stamps run independently from each other, data is implicitly sharded. Кроме того, одна метка может использовать дальнейшее сегментирование, чтобы обеспечить масштабируемость и эластичность в метку.

The deployment stamp pattern is used internally by many Azure services, including App Service, Azure Stack, and Azure Storage.

Deployment stamps are related to, but distinct from, geodes. В архитектуре метки развертывания развертываются несколько независимых экземпляров системы и содержат подмножество клиентов и пользователей. В геодоках все экземпляры могут обслуживать запросы от всех пользователей, но эта архитектура часто сложнее для проектирования и сборки. Вы также можете рассмотреть возможность смешивания двух шаблонов в одном решении; Подход маршрутизации трафика, описанный далее в этой статье, является примером такого гибридного сценария.

Deployment

Из-за сложности, связанной с развертыванием идентичных копий одних и того же компонентов, хорошие методики DevOps критически важны для обеспечения успеха при реализации этого шаблона. Consider describing your infrastructure as code, such as by using Bicep, JSON Azure Resource Manager templates (ARM templates), Terraform, and scripts. С помощью этого подхода можно убедиться, что развертывание каждой метки является предсказуемым и повторяемым. Это также снижает вероятность ошибок человека, таких как случайное несоответствие в конфигурации между метками.

You can deploy updates automatically to all stamps in parallel, in which case you might consider technologies like Bicep or Resource Manager templates to coordinate the deployment of your infrastructure and applications. Кроме того, вы можете решить постепенно развернуть обновления некоторых меток сначала, а затем постепенно для других. Consider using a release management tool like Azure Pipelines or GitHub Actions to orchestrate deployments to each stamp. Дополнительные сведения см. в разделе:

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

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

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

Capacity planning

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

Traffic routing

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

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

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

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

Централизованная служба маршрутизации трафика может быть сложным компонентом для разработки, особенно если решение работает в нескольких регионах. Рассмотрите возможность развертывания службы маршрутизации трафика в нескольких регионах (потенциально включая каждый регион, в который развертываются метки), а затем обеспечивает синхронизацию хранилища данных (сопоставление клиентов с метками). The traffic routing component might itself be an instance of the geode pattern.

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

Чтобы обеспечить геораспространение запросов и геоизбыточность службы маршрутизации трафика, Управление API можно развернуть в нескольких регионах, или Azure Front Door можно использовать для направления трафика в ближайший экземпляр. Front Door can be configured with a backend pool, enabling requests to be directed to the closest available API Management instance. Если приложение не предоставляется через ПРОТОКОЛ HTTP/S, вы можете использовать межрегиональная подсистема балансировки нагрузки Azure для распространения входящих вызовов в региональные подсистемы балансировки нагрузки Azure. Глобальная функция распространения Azure Cosmos DB может использоваться для обновления сведений о сопоставлении в каждом регионе.

If a traffic-routing service is included in your solution, consider whether it acts as a gateway and could therefore perform gateway offloading for the other services, such as token validation, throttling, and authorization.

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

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

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

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

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

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

• Deployment process. При развертывании нескольких меток настоятельно рекомендуется использовать автоматизированные и полностью повторяющиеся процессы развертывания. Consider using Bicep, JSON ARM templates, or Terraform modules to declaratively define your stamps, and to keep the definitions consistent.
• Cross-stamp operations. Когда решение развертывается независимо между несколькими метками, вопросы, такие как "сколько клиентов у нас есть на всех наших метках?", могут стать более сложными для ответа. Запросы могут выполняться для каждой метки и агрегированных результатов. Кроме того, рассмотрите возможность публикации всех меток в централизованном хранилище данных для консолидированной отчетности.
• Определение политик горизонтального масштабирования. Метки имеют ограниченную емкость, которая может быть определена с помощью метрики прокси-сервера, например числа клиентов, которые можно развернуть на метку. Важно отслеживать доступную емкость и используемую емкость для каждой метки, а также заранее развертывать дополнительные метки, чтобы позволить им направлять новых клиентов.
• Минимальное количество меток. При использовании шаблона метки развертывания рекомендуется развернуть по крайней мере две метки решения. Если вы развертываете только одну метку, в коде или конфигурации, которые не будут применяться при горизонтальном масштабировании, легко случайно выполнить предположение жесткого кода.
• Cost. Шаблон метки развертывания включает развертывание нескольких копий компонента инфраструктуры, что, скорее всего, приведет к значительному увеличению затрат на эксплуатацию решения.
• Перемещение между метками. Каждая метка развертывается и работает независимо, поэтому перемещение клиентов между метками может быть сложной задачей. Приложению потребуется пользовательская логика для передачи сведений о заданном клиенте на другую метку, а затем для удаления сведений клиента из исходной метки. В этом процессе может потребоваться обратная планка для обмена данными между метками, что повышает сложность общего решения.
• Traffic routing. Как описано ранее в этой статье, маршрутизация трафика на правильную метку для данного запроса может потребовать дополнительного компонента для разрешения клиентов на метки. Этот компонент, в свою очередь, может потребоваться сделать высокодоступным.
• Shared components. Возможно, у вас есть некоторые компоненты, которые можно совместно использовать для меток. For example, if you have a shared single-page app for all tenants, consider deploying that into one region and using Azure CDN to replicate it globally.

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

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

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

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

• Простые решения, которые не должны масштабироваться до высокой степени.
• Системы, которые можно легко масштабировать или масштабировать в одном экземпляре, такие как увеличение размера слоя приложения или увеличение зарезервированной емкости для баз данных и уровня хранилища.
• Решения, в которых данные должны реплицироваться во всех развернутых экземплярах. Consider the geode pattern for this scenario.
• Решения, в которых необходимо масштабировать только некоторые компоненты, но не другие. Например, рассмотрите возможность масштабирования решения путем сегментирования хранилища данных, а не развертывания новой копии всех компонентов решения.
• Решения, состоящие исключительно из статического содержимого, например интерфейсного приложения JavaScript. Consider storing such content in a storage account and using Azure CDN.

Workload design

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

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

Supporting technologies

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

Contributors

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

Principal author:

• John Downs | Principal Software Engineer, Azure Patterns & Practices

Other contributors:

• Daniel Larsen | Principal Customer Engineer, FastTrack for Azure
• Angel Lopez | Senior Software Engineer, Azure Patterns and Practices
• Paolo Salvatori | Principal Customer Engineer, FastTrack for Azure
• Arsen Vladimirskiy | Principal Customer Engineer, FastTrack for Azure

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

Related resources

• Сегментирование можно использовать в качестве другого, более простого подхода к масштабированию уровня данных. Метки неявно сегментирует свои данные, но сегментирование не требует метки развертывания. For more information, see the Sharding pattern.
• If a traffic routing service is deployed, the Gateway Routing and Gateway Offloading patterns can be used together to make the best use of this component.