Базовая архитектура эталонного чата Microsoft Foundry в целевой зоне Azure

Эта статья является частью серии, которая основана на эталонной архитектуре чата Baseline Microsoft Foundry chat reference architecture. Просмотрите базовую архитектуру, чтобы определить необходимые корректировки перед ее развертыванием в подписке зоны приземления приложения Azure.

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

Foundry использует ресурсы и проекты для организации разработки и развертывания ИИ. Например, реализация landing zone может использовать ресурс Foundry в качестве централизованного ресурса на уровне бизнес-группы, а проекты — в качестве делегированного ресурса для каждой рабочей нагрузки в этой бизнес-группе. Из-за факторов организации ресурсов и ограничений распределения затрат мы не рекомендуем эту топологию, и эта статья не предоставляет рекомендации по этому поводу. Вместо этого эта архитектура рассматривает рабочую нагрузку как владельца ресурса Foundry, который является рекомендуемым подходом.

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

Макет статьи

Architecture	Решения по проектированию	Подход в рамках Well-Architected Framework
▪ Схема архитектуры ▪ Ресурсы рабочей нагрузки ▪ Федеративные ресурсы	▪ Настройка подписки ▪ Сети ▪ Доступ к специалисту по обработке и анализу данных ▪ Мониторинг ресурсов ▪ Управление организацией ▪ Управление изменениями	▪ Надёжность ▪ Безопасность ▪ Оптимизация затрат ▪ Операционное превосходство ▪ Эффективность производительности

Architecture

Скачайте файл Visio этой архитектуры.

Components

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

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

Ресурсы, принадлежащие команде, ответственной за рабочую нагрузку

Следующие ресурсы остаются в основном неизменными из базовой архитектуры.

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

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

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

• Служба агента — это облачная среда выполнения, которая позволяет интеллектуальным агентам безопасно работать и автономно. В этой архитектуре сервис Agent предоставляет уровень оркестрации для чатовых взаимодействий. Он размещает и управляет агентом prompt, который обрабатывает запросы пользователей, в соответствии с базовой архитектурой. Описанная в этой статье схема сети и управления для зоны посадки применима независимо от того, развертываете ли вы агент для запросов или размещённый контейнерный агент.

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

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

• При размещении частных серверов MCP команда рабочей нагрузки развертывает и управляет серверами MCP и их средой размещения. Команда платформы выделяет достаточное адресное пространство для выделенной подсети MCP и поддерживает централизованные требования к DNS и брандмауэру. Для общедоступных серверов MCP команда, отвечающая за рабочие нагрузки, предоставляет команде платформы утверждённые FQDN конечных точек, к которым должен иметь доступ трафик агента через брандмауэр хаба.

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

  Учетная запись служба хранилища Azure размещает код веб-приложения в виде ZIP-файла, который монтируется в составе службы приложений.

• Поиск ИИ — это масштабируемая инфраструктура поиска, которая индексирует разнородное содержимое и позволяет извлекать данные с помощью API, приложений и агентов ИИ. В этой архитектуре Foundry IQ с поддержкой искусственного интеллекта служит хранилищем знаний о рабочих нагрузках для шаблона с дополнением выборки. Этот шаблон извлекает подходящий запрос из подсказки, выполняет поиск с использованием ИИ и использует результаты как основополагающие данные для генеративной модели ИИ.

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

• Azure Key Vault — это облачная служба для безопасного хранения и доступа к секретам, ключам и сертификатам. В этой архитектуре хранится сертификат TLS для шлюза приложений.

• Azure MonitorAzure Monitor Logs и Application Insights собирать, хранить и визуализировать данные наблюдаемости. В этой архитектуре они обеспечивают мониторинг, диагностику и оперативную аналитику для всех компонентов рабочей нагрузки.

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

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

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

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

Ресурсы, принадлежащие команде платформы

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

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

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

• Бастион Azure — это управляемая служба PaaS, используемая для подключения к виртуальным машинам через частный IP-адрес. В этой архитектуре Бастион Azure в центральной сети обеспечивает безопасный рабочий доступ к компонентам рабочей нагрузки и разрешает доступ к компонентам Foundry. Это гарантирует, что администраторы и сотрудники службы поддержки могут безопасно подключаться к виртуальным машинам, не предоставляя порты RDP/SSH в общедоступный Интернет.

  Изменение по сравнению с базовой линией: В базовой архитектуре команда, отвечающая за рабочую загрузку, управляет этим компонентом.

• Периферийная виртуальная сеть находится в месте развертывания рабочей нагрузки.

  Переход от базового плана: В базовой архитектуре команда рабочей нагрузки владеет этой сетью.

• Определяемые пользователем маршруты (UDR) применяют туннелирование к брандмауэру центральной сети.

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

• ограничения управления на основе Политика Azure и DeployIfNotExists (DINE) применяются к подписке на рабочую нагрузку. Эти политики можно применить на уровне группы управления, принадлежащей команде платформы, или непосредственно к подписке определенной рабочей нагрузки.

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

• Частные зоны DNS Azure хранят A записи для частных конечных точек, чтобы компоненты нагрузки могли безопасно разрешать вернтое доменное имя служб PaaS, используемых в нагрузке. Дополнительные сведения см. в разделе Приватный канал Azure и интеграция DNS в масштабе.

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

• Служба разрешения DNS поддерживает периферийные виртуальные сети и локальные рабочие станции. Эта служба обычно использует Брандмауэр Azure в качестве DNS-прокси или Azure DNS Private Resolver. В этой архитектуре служба разрешает записи DNS частной конечной точки для всех запросов DNS от периферийных устройств. Чтобы обеспечить выполнение требований Agent Service к разрешению имен, команда платформы должна использовать DNS Private Resolver и связанные наборы правил или убедиться, что параметры DNS виртуальной сети настроены для разрешения имен через центральный узел.

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

  Изменение от базового уровня: В базовой архитектуре команда, занимающаяся рабочей нагрузкой, приобретает защиту от атак DDoS.

Настройка подписки

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

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

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

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

Требования к рабочей нагрузке и выполнение

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

	Рекомендации по проектированию	Требование рабочей нагрузки для этой архитектуры
☐	Количество периферийных виртуальных сетей и их размер: Команда платформы создает и настраивает виртуальную сеть, затем соединяет ее пирингом с региональным центром, обозначая ее как периферийную. Кроме того, необходимо убедиться, что сеть может обеспечить рост будущих рабочих нагрузок. Для эффективного выполнения этих задач они должны знать количество необходимых спиц.	Разверните все ресурсы в одной выделенной виртуальной сети спицевого типа. Запросите не менее /21 непрерывного адресного пространства для основной нагрузки и частного хоста сервера MCP. Запросите дополнительное адресное пространство, если требуется параллельное развертывание. Следующие факторы определяют большинство потребностей IP-адресов: — Требования к размеру подсети для шлюза приложений (фиксированного размера). — частные конечные точки с одними IP-адресами для служб PaaS (фиксированный размер). — Размер подсети для агентов сборки (фиксированный размер). — Службе агента требуется подсеть в пределах префикса /24 для размещения прокси данных, который обрабатывает исходящий трафик агента. — Для частных серверов MCP, размещенных на Контейнеры приложений Azure требуется выделенная подсеть. В этой архитектуре зарезервирован префикс /24, делегированный Microsoft.App/environments.
☐	Префиксы адресов виртуальной сети: Как правило, команда платформы назначает IP-адреса на основе существующих соглашений, избегания перекрытия одноранговых сетей и доступности в системе управления IP-адресами (IPAM).	Подсеть интеграции агента должна использовать допустимый префикс частного адреса. Служба агента поддерживает подсети, использующие 10.0.0.0/8, 172.16.0.0/12 или 192.168.0.0/16. Попросите команду платформы предоставить ответвление с допустимым префиксом адреса для подсети агента.
☐	Регион развертывания: Команда платформы должна развернуть концентратор в том же регионе, что и ресурсы рабочей нагрузки.	Уведомьте о выбранном регионе для рабочей нагрузки и регионах для базовых вычислительных ресурсов. Убедитесь, что регионы поддерживают зоны доступности. Azure OpenAI в модели Foundry имеет ограниченную региональную доступность.
☐	Суверенитет данных: Команда платформы должна учитывать все требования к месту размещения данных, которые имеет рабочая нагрузка.	Если для рабочей нагрузки требуется строгое расположение данных, убедитесь, что команда платформы не дублирует журналы Диагностика Azure или отправляет данные в Purview в регионе, запрещенном вашими требованиями.
☐	Тип, объем и шаблон трафика: Команда платформы должна определить требования к входящего трафика и исходящего трафика общих ресурсов рабочей нагрузки.	Укажите сведения о следующих факторах: — Как пользователи должны использовать эту рабочую нагрузку. — Как эта рабочая нагрузка потребляет окружающие ресурсы. — настроенный транспортный протокол. — Характер трафика и ожидаемые пиковые и часы сниженной нагрузки. Обмен данными, когда ожидается большое количество одновременных подключений к Интернету (чат) и когда рабочая нагрузка будет генерировать минимальный сетевой трафик (фоновый шум).
☐	Конфигурация брандмауэра: Команда платформы должна задать правила, чтобы разрешить допустимый исходящий трафик.	Укажите сведения об исходящем трафике из spoke-сети, включая трафик агента и частного сервера MCP. Агент сборки и прыжковые машины нуждаются в регулярном обновлении ОС. Агентам может потребоваться взаимодействовать с источниками данных из интернета, общедоступными серверами MCP, инструментами или другими агентами, размещёнными за пределами рабочей среды.
☐	Входящий трафик из специализированных ролей: Команда платформы должна предоставить указанные роли с сетевым доступом к рабочей нагрузке и реализовать правильную сегментацию.	Обратитесь к группе платформы, чтобы определить лучший способ разрешить авторизованный доступ для следующих ролей: — Специалисты по обработке и анализу данных, которые обращаются к порталу Foundry с рабочих станций на корпоративных сетевых подключениях — Операторы, которые обращаются к вычислительному слою с помощью шлюза, управляемого рабочей нагрузкой
☐	Общедоступный интернет-доступ к рабочей нагрузке: Команда платформы использует эту информацию для оценки рисков, которая управляет несколькими решениями: — Размещение рабочей нагрузки в управляющей группе с соответствующими ограничениями — Распределенная защита от отказа в обслуживании (DDoS) для общедоступного IP-адреса, сообщаемого командой рабочей нагрузки — приобретение сертификатов TLS и управление ими	Сообщите команде платформы о профиле входящего трафика: — Трафик, поступающий из интернета и предназначенный для общедоступного IP-адреса на шлюзе приложений — Полные доменные имена (FQDN), связанные с общедоступным IP-адресом для приобретения сертификатов TLS
☐	Private endpoint usage: Группе платформы необходимо настроить Azure частные зоны DNS для частных конечных точек и убедиться, что брандмауэр в центральной сети правильно выполняет разрешение DNS.	Сообщите группе платформы обо всех ресурсах, использующих частные конечные точки, включая следующие ресурсы: — поиск по искусственному интеллекту — Azure Cosmos DB для NoSQL хранилище ключей - Литейный — учетные записи хранения Разберитесь, как хаб обеспечивает разрешение DNS, и определите обязанности команды, отвечающей за рабочую нагрузку, по управлению записями частной DNS-зоны, связыванию набора правил DNS Private Resolver или управлению параметрами DNS виртуальной сети.
☐	Централизованные ресурсы ИИ: Команда платформы должна понимать ожидаемое использование моделей и платформ размещения. Эти сведения используются для создания сети для централизованных ресурсов искусственного интеллекта в организации. Каждая организация определяет собственные планы внедрения и управления ИИ, а команда рабочей нагрузки должна работать в рамках этих ограничений.	Сообщите группе платформы о ресурсах искусственного интеллекта и машинного обучения, которые вы планируете использовать. В этой архитектуре используются Foundry, Agent Service и генерирующие базовые модели, размещенные в Foundry Models. Четко понимать, какие централизованные службы ИИ необходимо использовать и как эти зависимости влияют на рабочую нагрузку.

Compute

Уровень оркестрации и пользовательский интерфейс чата остаются такими же, как и базовая архитектура.

Нетворкинг

В базовой архитектуре рабочая нагрузка подготавливается в одной виртуальной сети.

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

Скачайте файл Visio этой архитектуры.

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

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

Из-за этого разделения управления и владения команда рабочей нагрузки должна четко донести требования команде платформы.

Подсети виртуальной сети

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

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

Входящий трафик

Входящий поток трафика остается таким же, как в эталонной архитектуре.

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

Альтернативный подход к проверке входящего трафика

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

DNS configuration (Настройка DNS)

В базовой архитектуре все компоненты используют Azure DNS непосредственно для разрешения DNS.

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

Эта архитектура настраивает компоненты рабочей нагрузки с DNS следующими способами.

Компонент	DNS configuration (Настройка DNS)
Application Gateway	Наследуется от виртуальной сети
Служба приложений (пользовательский интерфейс чата)	Наследуется от виртуальной сети
Поиск ИИ	Нельзя переопределить, используется Azure DNS
Литейный завод	Нельзя переопределить, используется Azure DNS
Служба агента	Нельзя переопределить, используется Azure DNS
Частные серверы MCP	Наследуется от виртуальной сети
Azure Cosmos DB	Нельзя переопределить, используется Azure DNS
Поле прыжка	Наследуется от виртуальной сети
Агенты сборки	Наследуется от виртуальной сети

Эта архитектура не настраивает параметры DNS для компонентов, которые не инициируют исходящее взаимодействие. Эти компоненты не требуют разрешения DNS.

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

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

• Команда платформы не может записывать DNS-запросы, которые могут нарушить требование группы безопасности организации.

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

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

Исходящий трафик

В базовой архитектуре весь исходящий трафик направляется в интернет через Брандмауэр Azure.

Изменение из базового уровня: В этой архитектуре платформа предоставляет UDR, указывающий на экземпляр Брандмауэр Azure, на котором она размещается. Примените этот UDR к тем же подсетям в базовой архитектуре.

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

Скачайте файл Visio этой архитектуры.

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

Маршрутизация интернет-трафика в брандмауэр

Все подсети в периферийной сети включают маршрут, который направляет весь интернет-трафик или 0.0.0.0/0 трафик в экземпляр Брандмауэр Azure концентратора.

Компонент	Механизм принудительного направления интернет-трафика через концентратор
Application Gateway	Нет. Трафик, направленный в Интернет, исходящий из этой службы, не может быть направлен через брандмауэр команды платформы.
Служба приложений (пользовательский интерфейс чата)	Интеграция региональной виртуальной сети и параметр vnetRouteAllEnabled включены.
Поиск ИИ	Нет. Трафик, который исходит из этой службы, не может быть направлен через брандмауэр. Эта архитектура не использует навыки.
Служба агента	UDR, примененный к подсети snet-agentsEgress.
Частные серверы MCP	UDR, примененный к подсети snet-mcpServers.
Прыжковые сервера	UDR, примененный к подсети snet-jumpBoxes.
Агенты сборки	UDR, примененный к подсети snet-agents.

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

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

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

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

Azure частные зоны DNS

Рабочие нагрузки, использующие частные конечные точки для трафика на востоке запада, требуют записи зоны DNS в настроенном поставщике DNS. Для поддержки Приватный канал эта архитектура использует множество записей зоны DNS для таких служб, как Key Vault, Foundry и служба хранилища Azure.

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

В этой архитектуре команда платформы должна настроить DNS для следующих конечных точек API Foundry FQDN:

• privatelink.services.ai.azure.com
• privatelink.openai.azure.com
• privatelink.cognitiveservices.azure.com

Команда, отвечающая за платформу, также должна настроить DNS для следующих полных доменных имен, которые являются зависимостями Agent Service:

• privatelink.search.windows.net
• privatelink.blob.core.windows.net
• privatelink.documents.azure.com

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

• privatelink.vaultcore.azure.net
• privatelink.azurewebsites.net

Доступ дата-сайентистов и разработчиков агентов

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

Когда рабочая нагрузка подключается к целевой зоне Azure, ваша команда получает дополнительные возможности доступа. Обратитесь к команде платформы, чтобы проверить, можно ли получить частный доступ к различным браузерным порталам Foundry без управления виртуальной машиной. Этот доступ может быть возможен через транзитивную маршрутизацию из существующего подключения ExpressRoute или VPN-шлюз.

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

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

Роль прыжкового сервера

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

В базовой архитектуре Бастион Azure получает доступ к серверу для прыжков, которым вы управляете.

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

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

Мониторинг ресурсов

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

Вы подготавливаете следующие ресурсы мониторинга:

• Application Insights служит службой управления производительностью приложений (APM) для вашей команды. Вы настраиваете эту службу в пользовательском интерфейсе чата, службе агентов и моделях.

• Рабочая область журналов Azure Monitor служит единым приемником для всех журналов и метрик из ресурсов, принадлежащих рабочей нагрузке Azure.

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

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

Политика Azure

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

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

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

• Политика:Секреты [в Key Vault] должны иметь указанный максимальный срок действия.

  Complication: Foundry может хранить секреты, связанные с подключениями к знаниям и инструментам в подключенном Key Vault. Эти секреты не имеют даты окончания срока действия, установленной службой. Базовая архитектура не использует эти типы подключений, но вы можете расширить архитектуру для их поддержки.

• Политика:Службы поиска на основе ИИ должны использовать ключи, управляемые клиентом, для шифрования данных в состоянии покоя.

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

• Политика:модели Foundry не должны быть предпросмотрены.

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

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

Управление изменениями с течением времени

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

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

Изменения платформы, влияющие на рабочую нагрузку

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

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

  Example: Политика больше не позволяет развертывать экземпляры Azure Cosmos DB, требующие шифрования ключей, управляемых клиентом, и архитектура использует шифрование ключей, управляемых Microsoft.

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

  Пример: Блокировка трафика к API Bing приводит к сбою вызова инструментов агента для данных об основных интернет-параметрах.

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

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

• Бастион Azure host: Изменения доступности или конфигурации узла Бастион Azure.

  Пример. Изменение конфигурации запрещает доступ к полям перехода и виртуальным машинам агента сборки.

Изменения рабочей нагрузки, влияющие на платформу

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

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

• Общедоступный доступ: Для изменений общедоступного доступа для компонентов рабочей нагрузки может потребоваться дополнительное тестирование. Команда платформы может переместить рабочую нагрузку в другую группу управления.

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

• Рейтинг критическости бизнеса: Для изменений соглашений об уровне обслуживания рабочей нагрузки (SLA) может потребоваться новый подход к совместной работе между группами платформы и рабочей нагрузки.

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

• Суверенитет данных: Изменения требований к суверенитету данных могут потребовать от команды платформы изменить план сбора журналов, поддержку интеграции Purview для вашей рабочей нагрузки или поддержку организационного решения для управления безопасностью информации и событиями (SIEM).

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

Команда по архитектуре предприятия

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

Соображения

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

Reliability

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

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

Критические зависимости

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

Рассмотрим следующие зависимости рабочей нагрузки и примеры сценариев, которые могут возникнуть:

• Брандмауэр исходящего трафика: Централизованный брандмауэр исходящего трафика проходит изменения, не связанные с рабочей нагрузкой. Несколько рабочих нагрузок совместно используют брандмауэр.

• DNS resolution: Данная архитектура использует DNS, предоставляемый командой платформы для большинства ресурсов, вместе с Azure DNS и связанными наборами правил частного сопоставителя DNS для службы агентов. В результате рабочая нагрузка зависит от своевременного обновления записей DNS для частных конечных точек и доступности служб DNS.

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

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

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

Безопасность

Безопасность обеспечивает гарантии от преднамеренного нападения и неправильного использования ценных данных и систем. Дополнительные сведения см. в контрольном списке проектных проверок по безопасности.

Управление входящим трафиком

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

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

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

Исходный материал	Цель	Контроль рабочей нагрузки	Управление платформой
Интернет	Потоки трафика приложения	Направляйте все запросы нагрузки через NSG, брандмауэр веб-приложения и правила маршрутизации, прежде чем разрешить превращение общедоступного трафика в частный для чата.	None
Интернет	Доступ к порталу Foundry и доступ к REST API уровня данных	Запретить доступ через конфигурацию уровня обслуживания.	None
Интернет	Доступ ко всем службам на плоскости передачи данных, кроме Шлюза приложений	Запретить весь доступ через правила NSG и конфигурацию на уровне сервиса.	None
Бастион Azure	Переход к ящику и доступу агента сборки	Примените группу безопасности сети к подсети управляющего сервера, которая блокирует весь трафик к портам удаленного доступа, если источник не является назначенной подсетью Бастион Azure платформы.	None
Кросс-локальная среда	Доступ к порталу Foundry и доступ к REST API уровня данных	Запретить весь доступ. Если вы не используете поле перехода, разрешите доступ только с рабочих станций в авторизованных подсетях для специалистов по обработке и анализу данных.	Применение нетранзитивной маршрутизации или использование Брандмауэр Azure в защищенном узле Виртуальная глобальная сеть Azure.
Другие спицы	None	Заблокировано с помощью правил NSG.	Обеспечение маршрутизации без транзита или использование Брандмауэр Azure в защищенном узле Виртуальная глобальная сеть.

Управление исходящим трафиком

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

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

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

Endpoint	Цель	Контроль рабочей нагрузки	Управление платформой
Общедоступные интернет-источники	Агенту может потребоваться поиск в Интернете для обоснования запроса Azure OpenAI.	Применяйте группы безопасности сети (NSG) к подсети интеграции агента.	Применение правил приложения брандмауэра для внешних хранилищ знаний и инструментов
Общедоступные серверы MCP	Агент вызывает утверждённые инструменты через общедоступные конечные точки	Примените группы безопасности сети и UDR к подсети интеграции агента	Примените правила брандмауэра для приложений для разрешённых FQDN серверов MCP
Частные серверы MCP	Агент вызывает средства, принадлежащие рабочей нагрузке, через частное подключение	Разрешить исходящий трафик по TCP-портам 443 и 31443 из подсети интеграции агента и соответствующий входящий трафик в подсети MCP	None
Плоскость данных Foundry	Пользовательский интерфейс чата взаимодействует с агентом чата	Разрешить TCP/443 из подсети интеграции службы приложений на подсеть выделенного конечного узла Foundry.	None
Azure Cosmos DB	Доступ к базе данных памяти из службы агента	Разрешить TCP для каждого порта в подсети частной конечной точки Azure Cosmos DB	None

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

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

DDoS Protection

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

Управление удостоверениями и доступом

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

Сертификаты и шифрование

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

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

Microsoft Defender для облака

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

Microsoft Purview.

Ожидается, что вам потребуется использовать встроенную интеграцию Microsoft Purview при развертывании Foundry. Во время развертывания убедитесь, что вы включили Microsoft Purview Data Security в плоскости управления Microsoft Foundry. См. раздел Использование Microsoft Purview для управления безопасностью данных и обеспечением соответствия в Microsoft Foundry.

Оптимизация затрат

Оптимизация затрат фокусируется на способах сокращения ненужных расходов и повышения эффективности работы. Дополнительные сведения см. в контрольном списке проектной экспертизы для оптимизации затрат.

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

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

Операционное превосходство

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

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

Сопоставление данных из нескольких приемников

В рабочей области Azure Monitor Logs рабочей нагрузки хранятся журналы и метрики как самой рабочей нагрузки, так и её инфраструктурных компонентов. Однако центральная рабочая область журналов Azure Monitor часто хранит журналы и метрики из централизованных служб, таких как Брандмауэр Azure, частный сопоставитель DNS и Бастион Azure. Сопоставление данных из нескольких приемников может быть сложной задачей.

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

Агенты сборки

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

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

Эффективность производительности

Эффективность производительности — это способность рабочей нагрузки эффективно масштабироваться в соответствии с требованиями пользователей. Для получения дополнительной информации см. контрольный список проверки конструкции для эффективности производительности.

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

• Исходящий трафик и межсетевые задержки
• Ограничения SKU в управлении контролем затрат

Соавторы

Microsoft поддерживает эту статью. Следующие авторы написали эту статью.

Основные авторы:

• Bilal Amjad | Архитектор решений Microsoft Cloud
• Freddy Ayala | Архитектор решений Microsoft Cloud
• Chad Kittel | Главный инженер по программному обеспечению — шаблоны и практики Azure

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

Следующий шаг

Узнайте, как сотрудничать над техническими деталями с командой платформы.

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

• Перспективы нагрузки ИИ на Azure в рамках well-architected framework
• Ограждения и элементы управления