Q33 — AWS SAA-C03 第16章

第 33/100 题 | ← 返回第16章

Q1233. 一家公司正在本地数据中心运行一个两层的基于 Web 的应用程序。应用程序层由一台运行有状态应用程序的服务器组成。该应用程序连接到在另一台服务器上运行的 PostgreSQL 数据库。预计该应用程序的用户群将大幅增长，因此该公司正在将应用程序和数据库迁移到 AWS。该解决方案将使用 Amazon Aurora PostgreSQL、Amazon EC2 Auto Scaling 和 Elastic Load Balancing。哪种解决方案能够提供一致的用户体验，并允许应用程序层和数据库层进行扩展?

正确答案: C. 为 Aurora 副本启用 Aurora 自动扩展功能。使用启用了循环路由算法和粘性会话的应用程序负载均衡器。

解析

为了提供一致的用户体验，同时允许应用程序和数据库层随着用户群的增长而扩展，让我们分析一下要求和选项:关键要求:可扩展性:应用程序层和数据库层都必须能够扩展以处理增加的负载。一致的用户体验:解决方案应确保维护用户会话（粘性会话），并确保请求在应用服务器之间高效分配。数据库扩展:应配置 Aurora PostgreSQL 以扩展只读副本，以处理读取密集型工作负载。解决方案分析:数据库层（Amazon Aurora PostgreSQL）:Aurora 自动伸缩:应为 Aurora 副本（只读副本）启用此功能，以便根据需求自动扩展只读副本的数量。对于读取密集型扩展场景，通常无需扩展写入实例。应用程序层（Amazon EC2 Auto Scaling + Elastic Load Balancing）:负载均衡器类型:应用程序负载均衡器 (ALB):最适合 HTTP/HTTPS 流量，支持高级路由（例如循环、最少连接）和粘性会话。网络负载均衡器（NLB）:最适合 TCP/UDP 流量，支持高吞吐量和低延迟，但不支持应用层的 HTTP/HTTPS 粘性会话。路由算法:循环:在所有健康实例之间均匀分配请求。最少未完成请求数:并非 ALB 或 NLB 的标准路由算法（尽管 NLB 支持 TCP 的“最少连接数”）。粘性会话:需要确保用户的请求在会话期间被定向到同一个应用程序服务器，这对于有状态的应用程序很重要。评估选项:选项 A:为 Aurora 副本启用 Aurora Auto Scaling。使用启用了最少未完成请求路由算法和粘性会话的网络负载均衡器。错误:NLB 不支持 HTTP/HTTPS 流量的粘性会话，“最少未完成请求”不是 NLB 的有效路由算法（它支持 TCP 的“最少连接数”）。选项 B:为 Aurora 写入器启用 Aurora Auto Scaling。使用启用了循环路由算法和粘性会话的应用程序负载均衡器。错误:扩展 Aurora 写入实例并非读取密集型扩展的正确方法。应为只读副本启用 Aurora Auto Scaling，而不是为写入实例启用。选项 C:为 Aurora 副本启用 Aurora Auto Scaling。使用启用了循环路由算法和粘性会话的应用程序负载均衡器。正确:此选项为只读副本启用 Aurora Auto Scaling（适用于读取密集型扩展），使用 ALB（支持粘性会话和 HTTP/HTTPS 流量），并使用循环路由算法（适用于均匀分配请求）。选项 D:为 Aurora 写入器启用 Aurora 自动扩展功能。使用启用了 LTB 路由算法和粘性会话的网络负载均衡器。错误:与选项 B 类似，扩展 Aurora 写入器实例并非读取密集型扩展的正确方法。此外，NLB 不支持 HTTP/HTTPS 流量的粘性会话。最终答案:C. 为 Aurora 副本启用 Aurora 自动扩展功能。使用启用了循环路由算法和粘性会话的应用程序负载均衡器。该解决方案可确保数据库层扩展读取副本以处理增加的负载，并且应用程序层使用 ALB 均匀分配请求，同时维持用户会话（粘性会话）。