【生成式AI】Azure着陆区中的Azure OpenAI聊天基线架构

本文是构建在Azure OpenAI服务端到端聊天基线架构上的系列文章的一部分。您应该熟悉基线体系结构，以便了解在Azure应用程序登录区域订阅中部署体系结构时需要进行的更改。

本文描述了生成型人工智能工作负载的架构，该工作负载部署了相同的基线聊天应用程序，但使用了工作负载团队范围之外的资源。这些资源在其他工作负载团队之间共享，并由组织的平台团队集中管理。共享资源包括用于连接到本地位置或从本地位置连接的网络资源、身份访问管理资源和策略。本指南适用于使用Azure着陆区以确保一致治理和成本效率的组织。

作为工作负载所有者，您可以将共享资源的管理工作交给平台团队，这样您就可以专注于工作负载开发工作。本文介绍了工作量团队的观点。指定了对平台团队的建议。

重要的

Azure的着陆区是什么？

Azure着陆区代表了组织云足迹的两个区域。应用程序着陆区是运行工作负载的Azure订阅。应用程序登录区域连接到组织的共享平台资源。通过该连接，登录区可以访问支持工作负载的基础设施，如网络、身份访问管理、策略和监控。平台登录区是多个平台团队可以管理的各种订阅的集合。每个订阅都有一个特定的功能。例如，连接订阅提供了可供平台团队使用的集中式域名系统（DNS）解析、跨场所连接和网络虚拟设备（NVA）。

我们建议您了解Azure着陆区、其设计原则和设计领域，以帮助您实现此架构。

文章布局

架构设计决策Azure架构良好的框架方法
 

Architecture	Design decisions	Azure Well-Architected Framework approach
▪ Architecture diagram ▪ Workload resources ▪ Federated resources	▪ Subscription setup ▪ Compute ▪ Networking ▪ Data scientist access ▪ Monitor resources ▪ Organizational governance ▪ Change management	▪ Reliability ▪ Security ▪ Cost Optimization ▪ Operational Excellence ▪ Performance Efficiency

提示

Azure OpenAI聊天基线参考实现演示了本文中描述的最佳实践。在制定和实施设计决策之前，请查看本指南。

与基线相比的变化：这些策略在此体系结构中是新的。

架构

工作负载的体系结构图，包括选择平台订阅资源。

分为两个主要部分的体系结构图。蓝色部分标记为“应用程序登录区域订阅”。底部为黄色，标记为平台着陆区订阅。最上面的框包含工作负载创建的资源和订阅自动售货资源。工作负载资源包括应用程序网关和web应用程序防火墙、应用程序服务及其集成子网、平台即服务（PaaS）解决方案的专用端点，如Azure存储、Azure密钥库、Azure AI搜索、Azure OpenAI服务和容器注册。工作负载资源还具有机器学习工作空间和监控资源。Azure应用程序服务显示三个实例，每个实例位于不同的Azure区域中。该平台订阅包含一个集线器虚拟网络、Azure防火墙、Azure堡垒以及一个灰色的VPN网关和ExpressRoute。在应用程序着陆区的虚拟网络和集线器虚拟网络之间存在虚拟网络对等。

下载此体系结构的Visio文件。

组件

所有Azure着陆区架构在平台团队和工作负载团队之间都有所有权分离，称为订阅民主化。应用程序架构师、数据科学家和DevOps团队需要对这种责任划分有深刻的理解，才能知道哪些是在他们的直接影响或控制之下，哪些不是。

与大多数应用程序着陆区实现一样，工作负载团队主要负责工作负载组件的配置、管理和部署，包括该架构中使用的所有人工智能服务。

Workload team-owned resources

以下资源与基线架构相比基本保持不变。

• Azure OpenAI是一种托管服务，提供对Azure OpenAI语言模型（包括GPT-4、GPT-3.5 Turbo和嵌入模型）的REST API访问。
• Azure机器学习用于开发和部署此工作负载中使用的提示流逻辑。
• 托管在线端点被用作聊天UI应用程序的平台即服务（PaaS）端点，该应用程序调用机器学习托管的提示流。
• Azure应用程序服务用于托管聊天UI的示例web应用程序。在此体系结构中，还可以使用此服务来托管容器化提示流，以便对运行提示流的托管环境进行更多控制。应用程序服务有三个实例，每个实例都位于不同的Azure区域中。
• 人工智能搜索是一项常见的服务，用于聊天应用程序背后的流程。您可以使用AI搜索来检索与用户查询相关的索引数据。
• Azure存储用于持久化提示流源文件，以进行提示流开发。
• Azure容器注册表用于存储打包为容器映像的流。
• Azure应用程序网关用作反向代理，将用户请求路由到应用程序服务中托管的聊天UI。所选SKU还用于承载Azure web应用程序防火墙，以保护前端应用程序免受潜在恶意流量的影响。
• 密钥库用于存储应用程序机密和证书。
• Azure Monitor、Azure Monitor日志和Application Insights用于收集、存储和可视化可观察性数据。
• Azure策略用于应用特定于工作负载的策略，以帮助大规模管理、保护和应用控件。

工作量团队维护以下资源：

• 分支虚拟网络子网和放置在这些子网上的网络安全组（NSG），以保持分段和控制流量。
• 私有端点，以确保连接到PaaS解决方案。

平台团队拥有的资源

平台团队拥有并维护这些集中式资源。该体系结构假设这些资源是预先配置的，并考虑它们的依赖性。

• 集线器网络中的Azure防火墙用于路由、检查和限制出口流量。工作负载出口流量流向互联网、跨场所目的地或其他应用程序着陆区。
  • 与基线相比的变化：此组件在此体系结构中是新的。Azure防火墙对于每个工作负载团队管理自己的实例来说既不划算，也不实用。
• 集线器网络中的Azure Bastion提供了对工作负载组件的安全操作访问，还允许访问Azure AI Studio组件。
  • 与基线相比的变化：工作负载团队在基线体系结构中拥有此组件。
• 轮辐式虚拟网络是部署工作负载的地方。
  • 与基线相比的变化：工作负载团队在基线体系结构中拥有此网络。
• 用户定义路由（UDR）用于强制隧道传输到集线器网络。
  • 与基线相比的变化：此组件在此体系结构中是新的。
• 基于Azure策略的治理约束和DeployIfNotExists（DINE）策略是工作负载订阅的一部分。您可以在平台团队拥有的管理组级别应用这些策略，也可以将它们直接应用于工作负载的订阅。
  • 与基线相比的变化：这些策略在此体系结构中是新的。
• Azure专用DNS区域承载专用终结点的A记录。有关更多信息，请参阅专用链接和DNS大规模集成。
  • 与基线相比的变化：此组件被移动到集线器并由平台管理。
• 轮辐式虚拟网络和跨场所工作站的DNS解析服务。该服务通常采用Azure防火墙的形式作为DNS代理或Azure DNS专用解析程序。在此体系结构中，此服务解析源自轮辐的所有DNS请求的专用端点DNS记录。
• Azure DDoS保护用于保护公共IP地址免受分布式攻击。
  • 与基线相比的变化：工作负载团队在基线体系结构中购买DDoS保护。

重要的

Azure登录区域提供了前面的一些资源作为平台登录区域订阅的一部分，而您的工作负载订阅提供了其他资源。许多资源都是连接订阅的一部分。订阅还拥有更多资源，如Azure ExpressRoute、Azure VPN网关和DNS专用解析程序。这些资源提供跨场所访问和名称解析。这些资源的管理不在本文的范围之内。

订阅设置

在着陆区上下文中，实现该体系结构的工作负载团队必须将其特定需求告知平台团队。然后，平台团队必须将他们的需求传达给工作负载团队。

例如，您的工作负载团队必须包含有关工作负载所需的网络空间的详细信息，以便平台团队能够分配必要的资源。您的团队确定需求，平台团队确定要在虚拟网络中分配的IP地址。

平台团队根据工作负载的业务关键性和技术要求分配适当的管理小组。一个例子是，如果工作负载像在这个体系结构中一样暴露在互联网上。平台团队通过配置和实施管理组来建立治理。您的工作负载团队必须在治理的约束范围内设计和操作工作负载。有关典型管理组区别的更多信息，请参阅定制Azure着陆区架构。

最终，平台团队为该体系结构设置订阅。以下部分提供了与此体系结构相关的初始订阅设置指南。

工作量要求和实现

对于此架构，工作负载团队和平台团队需要在几个主题上进行协作：管理组分配，包括相关的Azure策略治理和网络设置。准备一份需求清单，以启动与平台团队的讨论和谈判。此检查表是该体系结构上下文中的一个示例。

Topic	Workload requirement for this architecture
☐	Number of spoke virtual networks and their size. The platform team needs to know the number of spokes because they create and configure the virtual network and make it a spoke by peering it to the central hub. They also need to make sure that the network is large enough to accommodate future growth.
☐	Deployment region. The platform team uses this information to ensure that they have a hub deployed in the same region as the workload resources.
☐	Type, volume, and pattern of traffic. The platform team uses this information to determine the ingress and egress requirements of the shared resources used by your workload.
☐	Firewall configuration. The platform team uses this information to set rules to allow legitimate egress traffic.
☐	Ingress traffic from specialized roles. The platform team uses this information to enable the specified roles to access the workload, while implementing proper segmentation.
☐	Public internet access to the workload. The platform team uses this information for risk assessment, which drives decisions about: - The placement of the workload in a management group with appropriate guardrails. - DDoS protection for the public IP address reported by the workload team. - Issuing and managing Transport Layer Security (TLS) certificates.
☐	Private endpoint usage. The platform team uses this information to set up Azure Private DNS zones for those endpoints and make sure that the firewall in the hub network can do DNS resolution.

重要的

我们建议平台团队采用订阅自动售货流程，该流程涉及一系列旨在从工作负载团队获取信息的问题。这些问题可能因组织而异，但目的是收集实现订阅的需求。有关更多信息，请参阅订阅自动售货。

计算

托管提示流和聊天UI的计算与基线架构保持相同。

组织可能会对工作负载团队提出要求，要求使用特定的机器学习运行时。例如，要求可能是避免自动运行时或计算实例运行时，而倾向于使用满足合规性、安全性和可观察性要求的即时流容器主机。

与工作负载要求相比，组织的治理可能会增加更多对容器基础映像维护和依赖包跟踪的要求。工作负载团队必须确保工作负载的运行时环境、部署到它的代码及其操作符合这些组织标准。

托管提示流代码的替代方法

您可以在应用程序服务中托管提示流代码，而不是将其托管在机器学习运行时环境中。在这种方法中，与机器学习计算的托管虚拟网络相比，出口流量是可控的。逻辑本身不会改变，但应用服务实例需要访问互联网。

网络

在基线体系结构中，工作负载是在单个虚拟网络中提供的。

与基线相比的变化：工作负载在两个虚拟网络上有效地分配。一个网络用于工作负载组件，另一个用于控制互联网和混合连接。平台团队确定工作负载的虚拟网络如何与组织的更大网络架构集成，该架构通常具有轮辐拓扑。

主要关注网络入口流的体系结构图。

此体系结构图顶部有一个蓝色框，标记为应用程序登录区域订阅，其中包含轮辐虚拟网络。虚拟网络中有五个框。这些框标记为snet-appGateway、snet-agents、snet-jumpbox、snet-appServicePlan和snet-privateEndpoints。每个子网都有一个NSG标志，除了snet appGateway子网之外，所有子网都具有一个UDR，上面写着To hub。来自本地和非本地用户的进入流量指向应用程序网关。数据科学家用户连接到标记为连接订阅的图表底部的VPN网关或ExpressRoute。连接订阅包含专用链接、DNS专用解析程序和DDoS保护的专用DNS区域。连接订阅中包含的集线器虚拟网络和轮辐虚拟网络通过标记为“虚拟网络对等”的线路连接。轮辐虚拟网络中有读取集线器提供的DNS的文本。

下载此体系结构的Visio文件。

• 集线器虚拟网络【Hub virtual network】：一个区域集线器，包含与同一区域的工作负载资源通信的集中式且经常共享的服务。集线器位于连接订阅中。平台团队拥有该网络中的资源。
• 轮辐式虚拟网络【Spoke virtual network】：在这种架构中，从基线架构开始的单个虚拟网络本质上成为轮辐式网络。平台团队将虚拟网络与集线器网络进行对等。平台团队拥有并管理这个轮辐网络、对等网络和DNS配置。这个网络包含许多工作负载资源。工作负载团队拥有此网络中的资源，包括其子网。

由于这种管理和所有权划分，请确保将工作负载的要求清楚地传达给平台团队。

重要的

对于平台团队：除非工作负载特别要求，否则不要将轮辐网络直接对等到另一个轮辐虚拟网络。这种做法可以保护工作负载的细分目标。除非应用程序登录区域团队与自我管理的专用端点交叉连接，否则您的团队应为所有可传递的虚拟网络连接提供便利。对该工作负载所使用的资源有很好的了解，这些资源由该工作负载团队范围之外的团队管理。例如，了解提示流和由另一个团队管理的矢量数据库之间的网络连接。

虚拟网络子网

在轮辐虚拟网络中，工作负载团队创建并分配符合工作负载要求的子网。放置控制以限制进出子网的流量有助于提供分段。此体系结构不添加任何超出基线体系结构所述子网的子网。但是，网络体系结构不再需要AzureBastionSubnet子网，因为平台团队在其订阅中托管此服务。

当您在Azure登录区域中部署工作负载时，仍然必须实施本地网络控制。组织可能会施加进一步的网络限制，以防止数据泄露，并确保中央安全运营中心（SOC）和IT网络团队的可见性。

进入流量

入口流量与基线架构保持相同。

您的工作负载团队负责与公共互联网进入工作负载相关的任何资源。例如，在此体系结构中，应用程序网关及其公共IP地址被放置在轮辐网络中，而不是集线器网络中。一些组织可能会通过使用集中式外围网络（也称为DMZ、非军事区和屏蔽子网）实现，将具有入口流量的资源放置在连接订阅中。与该特定拓扑的集成超出了本文的讨论范围。

检查传入流量的替代方法

此体系结构不使用Azure防火墙来检查传入流量。有时组织治理需要这种方法。平台团队支持实现，为工作负载团队提供额外的入侵检测和预防层，以阻止不需要的入站流量。此体系结构需要更多的UDR配置来支持此拓扑结构。有关此方法的更多信息，请参阅使用Azure防火墙和应用程序网关的web应用程序的零信任网络。

DNS配置

在基线架构中，所有组件都直接使用Azure DNS进行DNS解析。

与基线相比的变化：DNS通常被委派给集线器中的一个或多个DNS服务器。当为该体系结构创建虚拟网络时，预计已经相应地设置了虚拟网络上的DNS属性。DNS服务对您的工作负载团队来说是不透明的。

此体系结构中的工作负载组件通过以下方式配置DNS。

Component	DNS configuration
Application Gateway	Inherited from virtual network.
App Service (chat UI)	The workload team configures the web app to use hub DNS servers via the dnsConfiguration property.
App Service (prompt flow)	Workload team sets the web app to use hub DNS servers via the dnsConfiguration property.
AI Search	Can't be overridden, uses Azure DNS.
Machine Learning compute cluster	▪ Managed virtual network, can't be overridden, and uses Azure DNS. This architecture uses this approach. ▪ Virtual network integration, inherited from virtual network.
Machine Learning automatic runtime	▪ Managed virtual network, can't be overridden, uses Azure DNS. ▪ Virtual network integration, inherited from virtual network. This architecture doesn't use automatic runtime.
Machine Learning compute instance	▪ Managed virtual network, can't be overridden, uses Azure DNS. This architecture uses this approach. ▪ Virtual network integration, inherited from virtual network.
Azure OpenAI	Can't be overridden, uses Azure DNS.
Jump box	Inherited from virtual network.
Build agents	Inherited from virtual network.

没有为体系结构中的其余组件配置DNS设置，因为这些服务不会发生出站通信。这些组件不需要DNS解析。

其中许多组件需要集线器的DNS服务器中的适当DNS记录来解析此工作负载的许多专用端点。有关详细信息，请参阅Azure专用DNS区域。对于无法进行基于集线器的DNS解析的组件，您将面临以下限制：

• 平台团队无法记录DNS请求，这可能是组织安全团队的要求。
• 在您的登录区域或其他应用程序登录区域中解析到Azure Private Link暴露的服务可能是不可能的。一些服务，如机器学习计算，通过特定于服务的功能来绕过这一限制。

我们建议您熟悉平台团队如何管理DNS。有关更多信息，请参阅专用链接和DNS大规模集成。当您添加直接依赖Azure DNS的组件功能时，可能会在平台提供的DNS拓扑中引入复杂性。您可以重新设计零部件或协商例外情况，以最大限度地降低复杂性。

出口流量

在基线架构中，互联网出口控制只能通过机器学习工作区和应用程序服务上的网络配置，以及在不同子网上使用NSG来实现。

与基线相比的变化：出口控制进一步增强。所有离开轮辐虚拟网络的流量都通过出口防火墙通过对等集线器网络进行重新路由。源于机器学习计算的托管虚拟网络内部的流量不受此出口路由的约束。

主要关注网络出口流的体系结构图。

此体系结构图的顶部标记为应用程序登录区域订阅，包含一个轮辐式虚拟网络框和一个机器学习框。机器学习框包含存储、容器注册表、人工智能搜索和Azure OpenAI的专用端点。轮辐式虚拟网络盒包含五个子网：snet appGateway、snet代理、snet jumpbox、snet appServicePlan和snet privateEndpoints。除snet appGateway外，所有子网都有一条虚线，从它们通向底部框中的Azure防火墙。底部框标记为“连接订阅”。Azure防火墙具有相同的样式线，指向以云表示的互联网。机器学习框的虚线样式与从它指向互联网云的虚线样式相同。最上面的框显示，在可能的情况下，所有工作负载都源自，由于0.0.0.0/0 UDR，绑定到互联网的流量流经集线器。底部框中的集线器虚拟网络和顶部框中的轮辐虚拟网络通过读取虚拟网络对等的线路连接。

下载此体系结构的Visio文件。

东西方客户端到容器注册表、密钥库、Azure OpenAI等专用端点的通信与基线架构保持相同。为了简洁起见，上图中省略了该路径。

将互联网流量路由到防火墙

路由连接到轮辐网络中所有可能的子网，将所有流向互联网（0.0.0.0/0）的流量首先引导到集线器的Azure防火墙。

Component	Mechanism to force internet traffic through the hub
Application Gateway	None. Internet-bound traffic that originates from this service can't be forced through a platform team firewall.
App Service (chat UI)	Regional virtual network integration is enabled. vnetRouteAllEnabled is enabled.
App Service (prompt flow)	Regional virtual network integration is enabled. vnetRouteAllEnabled is enabled.
AI Search	None. Traffic that originates from this service can't be forced through a firewall. This architecture doesn't use skills.
Machine Learning compute cluster	▪ Managed virtual network: Internet-bound traffic that originates from this service can't be forced through a platform team firewall. This architecture uses this approach. ▪ Virtual network integration: Uses a UDR that's applied to the subnet that contains the compute cluster.
Machine Learning automatic runtime	▪ Managed virtual network: Internet-bound traffic that originates from this service can't be forced through a platform team firewall. ▪ Virtual network integration: Uses a UDR that's applied to the subnet that contains the compute cluster. This architecture doesn't use automatic runtime.
Machine Learning compute instance	▪ Managed virtual network: Internet-bound traffic that originates from this service can't be forced through a platform team firewall. This architecture uses this approach. ▪ Virtual network integration: Uses a UDR that's applied to the subnet that contains the compute cluster.
Azure OpenAI	None. Traffic that originates from this service, for example via the on your data feature, can't be forced through a firewall. This architecture doesn't use any of these features.
Jump box	Uses the UDR that's applied to snet-jumpbox.
Build agents	Uses the UDR that's applied to snet-agents.

 

没有为保留在体系结构中的组件配置强制隧道设置，因为这些服务不会发生出站通信。

对于无法通过集线器路由进行出口控制的组件或组件功能，您的工作负载团队必须与该流量的组织要求保持一致。使用补偿控件，重新设计工作负载以排除这些功能，或者寻求正式的例外。工作量是减少数据泄露和滥用的最终责任。

将平台提供的internet路由应用于所有子网，即使该子网预计不会有传出流量。此方法可确保对该子网中的任何意外部署进行例行出口筛选。确保包含专用终结点的子网已启用网络策略以进行完全路由和NSG控制。

当您将此路由配置应用于体系结构时，来自应用程序服务、机器学习工作区或源自工作负载虚拟网络的任何其他服务的所有出站连接都将受到仔细检查和控制。

Azure专用DNS区域

在工作负载内使用专用端点进行东西向通信的体系结构需要在配置的DNS提供程序中进行DNS区域记录。此体系结构需要许多DNS区域记录才能正常工作：密钥库、Azure OpenAI等，以支持私有链接。

与基线相比的变化：工作负载团队直接负责基线架构中的私有DNS区域。在着陆区架构中，平台团队通常维护私有DNS区域。他们可能使用另一种技术，但对于这种体系结构，它是私有DNS区域记录。工作负载团队必须清楚地了解平台团队对这些专用DNS区域记录管理的要求和期望。

在此体系结构中，平台团队必须确保以下专用链接端点的DNS托管可靠且及时：

• AI搜索
• Azure OpenAI
• 容器注册表
• 密钥保管库
• 存储帐户

数据科学家和即时流作者访问

与基线架构一样，禁止对机器学习工作空间和其他基于浏览器的体验进行公共入口访问。基线体系结构部署了一个跳转框，为浏览器提供各种工作负载角色使用的虚拟网络的源IP地址。

当您的工作负载连接到Azure登录区域时，您的团队可以使用更多选项进行此访问。与您的平台团队合作，看看是否可以在不需要管理和管理虚拟机（VM）的情况下实现对各种基于浏览器的人工智能工作室的私人访问。此访问可以通过已建立的ExpressRoute或VPN网关连接的可传递访问来实现。基于本地工作站的访问需要跨本地路由和DNS解析，平台团队可以帮助提供这些功能。在您的订阅自动售货请求中说明这一要求。

提供对这些门户的基于本机工作站的访问是对基线的生产力提高，并且可以比VM跳框更容易维护。

跳转框【jump box】的作用

在这个体系结构中有一个跳转框是有价值的，但不用于运行时目的或人工智能或机器学习开发目的。跳转框可以解决DNS和网络路由问题，因为它提供了对外部无法访问的组件的内部网络访问。

在基线架构中，Azure Bastion访问由工作负载团队管理的跳转框。

在此架构中，Azure Bastion作为由平台团队管理的共享区域资源部署在连接订阅中。为了证明该架构中的用例，Azure Bastion位于连接订阅中，不再由工作负载团队部署。

用作跳转框的虚拟机必须符合组织对虚拟机的要求。这些要求可能包括Microsoft Entra ID中的企业标识、特定的基本映像和修补制度等项目。

监控资源

Azure着陆区平台提供共享的可观测性资源，作为管理订阅的一部分。但是，我们建议您提供自己的监控资源，以便于承担工作负载的所有权责任。这种方法与基线体系结构一致。

工作量小组提供监测资源，包括：

• Application Insights作为工作负载团队的应用程序性能管理（APM）服务。此功能在聊天UI和提示流代码中进行了配置。
• Azure Monitor Logs工作区是从工作负载拥有的Azure资源中收集的所有日志和度量的统一接收器。

与基线类似，所有资源都配置为将Azure诊断日志发送到Azure监控日志工作区，工作负载团队将其作为资源的代码（IaC）部署基础设施的一部分。您可能还需要将日志发送到Azure Monitor日志中心工作区。在Azure登录区域中，该工作区通常位于管理订阅中。

平台团队也可能有影响应用程序登录区域资源的流程。例如，他们可能会使用DINE策略来配置诊断并将日志发送到其集中式管理订阅。或者他们可能会使用通过策略应用的Monitor基线警报。重要的是要确保您的实现不会限制额外的日志和警报流。

Azure策略

基线体系结构建议一些通用策略来帮助管理工作负载。当您将此体系结构部署到应用程序登录区时，不需要再添加或删除任何策略。继续将策略应用于您的订阅、资源组或资源，以帮助实施治理并增强此工作负载的安全性。

即使在部署工作负载之前，也希望应用程序登录区域订阅已经应用了策略。某些策略通过审核或阻止部署中的特定配置来帮助组织治理。以下是一些可能导致工作负载部署复杂性的策略示例：

• 策略：“[密钥库中]的秘密应具有指定的最长有效期。”
  • 复杂之处：机器学习管理工作负载的密钥库中的秘密，而这些秘密没有设定有效期。
• 政策：“机器学习工作区应使用客户管理的密钥进行加密。”
  • 复杂性：这种体系结构并不是专门为处理客户管理的密钥而设计的。但是，它可以扩展到使用它们。

平台团队可能会应用DINE策略来处理应用程序登录区域订阅中的自动部署。先发制人地将平台发起的限制和更改合并并测试到您的IaC模板中。如果平台团队使用的Azure策略与应用程序的要求相冲突，您可以与平台团队协商解决方案。

随着时间的推移管理更改

在此体系结构中，平台提供的服务和操作被视为外部依赖项。平台团队继续应用变更、机载着陆区和应用成本控制。为组织服务的平台团队可能不会优先考虑单个工作负载。对这些依赖关系的更改（如防火墙修改）可能会影响多个工作负载。

工作负载和平台团队必须以高效和及时的方式进行沟通，以管理所有外部依赖关系。提前测试更改非常重要，这样它们就不会对工作负载产生负面影响。

影响此工作负载的平台更改

在此体系结构中，平台团队管理以下资源。对这些资源的更改可能会影响工作负载的可靠性、安全性、操作和性能目标。在平台团队实施这些更改以确定它们如何影响工作负载之前，评估这些更改非常重要。

• Azure策略：对Azure策略的更改可能会影响工作负载资源及其依赖关系。例如，可能会有直接的策略更改或将着陆区移动到新的管理组层次结构中。在进行新的部署之前，这些更改可能不会被注意到，因此彻底测试它们很重要。
  • 示例：策略不再允许部署支持API密钥访问的Azure OpenAI实例。
• 防火墙规则：对防火墙规则的修改可能会影响工作负载的虚拟网络或广泛应用于所有流量的规则。这些修改可能会导致流量阻塞，甚至导致静默进程失败。这些潜在问题适用于出口防火墙和Azure Virtual Network Manager应用的NSG规则。
  • 示例：供应商更新服务器被阻止会导致跳转框或生成代理上的操作系统更新失败。
• 集线器网络中的路由：如果工作负载依赖于到其他虚拟网络的路由，则集线器中路由的可传递性的变化可能会影响工作负载功能。
  • 示例：阻止访问由另一个团队或数据科学团队操作的矢量存储的提示流从其工作站访问人工智能门户中基于浏览器的体验。
• Azure堡垒主机：更改Azure堡垒主机的可用性或配置。
  • 示例：禁止访问跳转框和生成代理虚拟机。

影响平台的工作负载更改

以下示例是此体系结构中的工作负载更改，您应该与平台团队进行沟通。重要的是，在新工作负载团队的更改生效之前，平台团队要根据这些更改验证平台服务的可靠性、安全性、操作和性能目标。

• 网络出口：监控网络出口的任何显著增加，以防止工作负载成为网络设备上的嘈杂邻居。此问题可能会影响其他工作负载的性能或可靠性目标。这个体系结构基本上是独立的，可能不会经历出站流量模式的重大变化。
• 公共访问：对工作负载组件的公共访问的更改可能需要进一步测试。平台团队可能会将工作负载重新分配到不同的管理组。
  • 示例：在此体系结构中，如果从应用程序网关中删除公共IP地址，并使此应用程序仅为内部应用程序，则工作负载暴露在互联网上的情况会发生变化。另一个例子是，如果基于浏览器的人工智能门户被更改为暴露在互联网上，这是不建议的。
• 业务关键性评级：如果工作负载的服务级别协议（SLA）发生了更改，您可能需要在平台和工作负载团队之间采用新的协作方法。
  • 示例：随着采用率的提高和工作负载的成功，您的工作负载可以从低业务关键地过渡到高业务。

可靠性

该体系结构与基线体系结构中的可靠性保证保持一致。核心工作负载组件没有新的可靠性考虑因素。

可靠性目标

由于出口网络控制等新组件的存在，该体系结构的最大可能复合服务水平目标（SLO）低于基线复合服务水平目的。这些组件在着陆区环境中很常见，并不是这种体系结构独有的。如果工作负载团队直接控制这些Azure服务，SLO也会类似地减少。

关键依赖项

将工作负载在平台和应用程序登录区域中执行的所有功能视为依赖项。事件响应计划要求工作负载团队了解这些依赖关系的联系信息的点和方法。在工作负载的故障模式分析（FMA）中也包括这些依赖关系。

对于此体系结构，请考虑以下工作负载依赖关系：

• 出口防火墙：由多个工作负载共享的集中式出口防火墙会发生与工作负载无关的更改。
• DNS解析：该架构使用平台团队提供的DNS，而不是直接与Azure DNS接口。这意味着及时更新专用端点的DNS记录和DNS服务的可用性是新的依赖关系。
• DINE策略：Azure DNS专用DNS区域或任何其他平台提供的依赖项的DINE策略是尽最大努力的，在应用它们时没有SLA。例如，该体系结构的专用端点的DNS配置延迟可能会导致聊天UI处理流量或提示流完成查询的准备状态延迟。
• 管理组策略：环境之间的一致策略是可靠性的关键。确保预生产环境与生产环境相似，以提供准确的测试，并防止可能阻碍部署或扩展的特定于环境的偏差。有关更多信息，请参阅管理Azure登录区域中的应用程序开发环境。

如果没有Azure着陆区，其中许多考虑因素可能会存在，但工作负载和平台团队需要协作解决这些问题，以确保满足需求。有关更多信息，请参阅执行故障模式分析的建议。

安全

以下各节中的建议基于良好架构框架中的安全设计审查清单。

入口流量管制

通过在您的子网中使用NSG以及区域中心中的非传输性质或控制，将您的工作负载与组织内的其他工作负载轮辐隔离开来。构建全面的NSG，只允许应用程序及其基础架构的入站网络要求。我们建议您不要仅仅依靠集线器网络的非传输性来实现安全。

平台团队实施Azure安全策略。例如，策略可能会确保应用程序网关将web应用程序防火墙设置为拒绝模式，从而限制订阅可用的公共IP地址的数量。除了这些策略之外，工作负载团队还应该部署更多以工作负载为中心的策略，以加强入口安全态势。

下表显示了此体系结构中入口控制的示例。

Source	Purpose	Workload control	Platform control
Internet	Application traffic flows	Funnels all workload requests through an NSG, a web application firewall, and routing rules before allowing public traffic to transition to private traffic for the chat UI.	None
Internet	Studio access	Deny all through service-level configuration.	None
Internet	Data plane access to all but Application Gateway	Deny all through NSG and service-level configuration.	None
Azure Bastion	Jump box and build agent access	NSG on jump box subnet that blocks all traffic to remote access ports, unless it's sourced from the platform's designated Azure Bastion subnet	None
Cross-premises	Studio access	Deny all. Unless jump box isn't used, then only allow workstations from authorized subnets for data scientist access.	Nontransitive routing or Azure Firewall if an Azure Virtual WAN secured hub is used
Other spokes	None	Blocked via NSG rules.	Nontransitive routing or Azure Firewall if a Virtual WAN secured hub is used

出口流量管制

应用NSG规则来表达解决方案所需的出站连接要求，并拒绝其他一切。不要只依赖集线器网络控制。作为工作负载操作员，您有责任在尽可能靠近源的地方停止不希望的出口流量。

当您在虚拟网络中拥有工作负载的子网时，作为订阅销售过程的一部分，平台团队可能会创建防火墙规则，专门表示您捕获的需求。确保在体系结构的生存期内对子网和资源放置的更改仍然与您的原始请求兼容。与您的网络团队合作，确保最少访问出口控制的连续性。

下表显示了此体系结构中的出口示例。

Endpoint	Purpose	Workload control	Platform control
Public internet sources	Prompt flow might require an internet search to complement an Azure OpenAI request	NSG on the prompt flow container host subnet or Machine Learning-managed virtual network configuration	Firewall network rule allowance for the same as the workload control
Azure OpenAI data plane	The compute hosting prompt flow calls to this API for prompt handling	TCP/443 to the private endpoint subnet from the subnet that contains the prompt flow	None
Key Vault	To access secrets from the chat UI or prompt flow host	TCP/443 to the private endpoint subnet that contains Key Vault	None

对于离开该体系结构的虚拟网络的流量，最好在工作负载级别通过NSG实现控制，在平台级别通过集线器网络防火墙实现控制。NSG提供了初始的、广泛的网络流量规则，这些规则被平台集线器网络中的特定防火墙规则进一步缩小，以提高安全性。不期望工作负载组件内的东西向流量，例如此体系结构中的机器学习工作室和存储帐户之间的流量，应该通过集线器进行路由。

DDoS防护

确定谁应该应用涵盖您的解决方案的所有公共IP地址的DDoS保护计划。平台团队可能会使用IP地址保护计划，或使用Azure策略来实施虚拟网络保护计划。该体系结构应该具有覆盖范围，因为它涉及从互联网进入的公共IP地址。有关更多信息，请参阅有关网络和连接的建议。

身份和访问管理

除非您的平台团队的治理自动化另有要求，否则由于平台团队的参与，不需要对该架构提出额外的授权要求。Azure基于角色的访问控制（RBAC）应继续满足最小权限原则，该原则仅向需要的人和仅在需要时授予有限访问权限。有关更多信息，请参阅身份和访问管理建议。

证书和加密

在这种体系结构中，工作负载团队通常会为应用程序网关上的公共IP地址获取TLS证书。与您的平台团队合作，了解证书采购和管理流程应如何与组织期望保持一致。

此体系结构中的所有数据存储服务都支持由Microsoft或客户管理的加密密钥。如果您的工作负载设计或组织需要更多控制，请使用客户管理的加密密钥。Azure着陆区本身并没有强制要求这样或那样。

成本优化

对于工作负载资源，基线体系结构中的所有成本优化策略也适用于该体系结构。

该架构极大地受益于Azure着陆区平台资源。即使您通过按存储容量使用计费模式使用这些资源，增加的安全性和跨场所连接也比自我管理这些资源更具成本效益。利用您的平台团队提供的其他集中化产品，在不影响其SLO、恢复时间目标（RTO）或恢复点目标（RPO）的情况下，将这些好处扩展到您的工作负载。

卓越运营

工作量团队仍然负责基线架构中涵盖的所有卓越运营考虑因素，如监控、LLMOps、质量保证和安全部署实践。

关联来自多个接收器的数据

工作负载的日志和指标及其基础结构组件存储在工作负载的Azure Monitor logs工作区中。然而，来自集中式服务（如Azure防火墙、DNS专用解析程序和Azure堡垒）的日志和指标通常存储在中央Azure监视器日志工作区中。关联来自多个接收器的数据可能是一项复杂的任务。

在事件响应过程中经常使用相关数据。如果问题超出了工作负载资源范围，请确保该体系结构的分类runbook解决了这种情况，并包括组织联系点。工作负载管理员可能需要平台管理员的帮助来关联来自企业网络、安全或其他平台服务的日志条目。

重要的

对于平台团队：在可能的情况下，授予RBAC查询和读取相关平台资源的日志接收器。为网络和应用程序规则评估以及DNS代理启用防火墙日志。应用程序团队可以使用这些信息对任务进行故障排除。有关更多信息，请参阅监控和威胁检测建议。

生成代理

此体系结构中的许多服务都使用私有端点。与基线体系结构类似，这种设计可能会使构建代理成为该体系结构的一个需求。安全可靠地部署构建代理是工作负载团队的责任，而不需要平台团队的参与。但是，请确保生成代理的管理符合组织的要求。例如，使用平台批准的操作系统映像、修补计划、合规性报告和用户身份验证方法。

性能效率

基线体系结构中描述的性能效率注意事项也适用于此体系结构。工作负载团队保留对需求流中使用的资源的控制权，而不是平台团队。根据工作负载和成本限制，缩放聊天UI主机、提示流主机、语言模型等。根据体系结构的最终实现，在根据性能目标衡量性能时，请考虑以下因素。

• 出口和跨场所延迟
  源自成本控制治理的SKU限制

部署此场景

GitHub上提供了此参考体系结构的着陆区部署。（https://github.com/Azure-Samples/azure-openai-chat-baseline-landing-zone）

贡献者

本文由Microsoft维护。它最初是由以下贡献者撰写的。

主要作者：

Chad Kittel | Azure模式和实践-微软
Freddy Ayala |微软云解决方案架构师
要查看非公开的领英个人资料，请登录领英。