SAA-C03 · LESSON 3
设计高性能架构24% · 5 个主题
学习如何设计高性能、可扩展的存储、计算、数据库、网络,以及数据摄取和转换。
3.1确定高性能、可扩展的存储
3.1 Determine high-performing and/or scalable storage solutions.
概念
EBS 卷类型有通用型 SSD(gp3:IOPS 和吞吐量可与容量分开设置)、预置 IOPS SSD(io2:高 IOPS 和高持久性)、吞吐量优化型 HDD(st1:大量顺序读写)和 Cold HDD(sc1)。共享文件用 EFS(Linux)或 FSx(Windows、用于 HPC 的 Lustre)。S3 按前缀提供很高的请求性能,可以用分段上传和 Transfer Acceleration 加速。
原理、步骤
- 确认访问模式(随机还是顺序,重视 IOPS 还是吞吐量)
- 一般用途选 gp3,高 IOPS 数据库选 io2
- 多台实例共享用 EFS,HPC 用 FSx for Lustre
- 大文件上传到 S3 用分段上传,远程上传用 Transfer Acceleration
- 实例存储速度快,但只用于临时数据
工作中的示例
大量顺序写入日志用 st1,交易数据库用 io2,机器学习训练数据的高速共享用与 S3 集成的 FSx for Lustre。
易混淆点、考试注意事项
- gp2 的 IOPS 与容量成正比,gp3 可以单独设置
- 实例存储的数据在停止或终止时会丢失
- EFS 可以从多个可用区同时挂载,EBS 基本上限于一个可用区
小测验
Q1. gp2 EBS 卷容量足够,但 IOPS 不足。控制费用并提高性能的最合适方法是哪一项?
- 把卷改为 gp3,与容量分开设置所需 IOPS
- 为了获得 IOPS,继续使用容量大于需要的 gp2
- 把卷改为 sc1 以降低费用
- 停用 EBS,把所有数据放在实例存储中
查看答案和解析
正确答案:A 把卷改为 gp3,与容量分开设置所需 IOPS
gp2 的 IOPS 与容量成正比。gp3 可以与容量分开设置 IOPS 和吞吐量,很多情况下费用也更低。可以用 Elastic Volumes 在运行中修改。
Q2. EC2 上的应用很慢。CloudWatch 显示 CPU 使用率很低,但 EBS 卷的读写一直处于上限。接下来最应该做的是哪一项?
- 增加 Auto Scaling 的最大数量
- 删除 CloudWatch 告警
- 审查 EBS 卷类型及 IOPS、吞吐量设置,并按需修改
- 为增加 CPU 改用更大的实例类型,观察效果
查看答案和解析
正确答案:C 审查 EBS 卷类型及 IOPS、吞吐量设置,并按需修改
瓶颈在存储 I/O,增加 CPU 不会改善。应审查卷的性能(gp3 的 IOPS 设置或改为 io2)以及实例的 EBS 带宽。
参考链接
3.2设计高性能、弹性的计算方案
3.2 Design high-performing and elastic compute solutions.
概念
为了性能,要选择适合工作负载的实例系列(C:计算,R:内存,I:存储,G/P:GPU,Graviton:高性价比),并用 Auto Scaling 弹性增减。扩展策略有目标跟踪(保持 CPU 50% 等)、分步、计划和预测扩展。低延迟 HPC 使用集群置放群组。
原理、步骤
- 用 CloudWatch 确认瓶颈(CPU、内存、I/O、网络)
- 选择合适的实例系列(也参考 Compute Optimizer 的建议)
- 以目标跟踪扩展为基础,对可预测的高峰增加计划扩展
- 启动耗时长时使用温池
- 短时间的事件驱动处理考虑 Lambda,容器考虑 Fargate
工作中的示例
每天早上 9 点访问集中的内部系统,在 8:45 按计划增加实例,白天用目标跟踪保持 CPU 60%。
易混淆点、考试注意事项
- 集群置放群组在一个可用区内实现低延迟,分布置放群组用于隔离故障
- 注意 Lambda 的并发上限和冷启动(可用预置并发缓解)
- 垂直扩展(更大的实例)通常需要停止实例
小测验
Q1. 为提高批处理性能,希望把处理拆分成大量小作业并行执行。把基础设施管理降到最低的最合适方法是哪一项?
- 常驻运行 EMR 集群并提交作业
- 用 AWS Batch 或 Step Functions 分布式映射并行执行作业
- 创建 EC2 Auto Scaling 组,用脚本分发作业
- 在一个 Lambda 函数中用并行线程写入全部作业
查看答案和解析
正确答案:B 用 AWS Batch 或 Step Functions 分布式映射并行执行作业
使用托管的批处理执行和分布式处理服务,可以根据并行度自动准备计算资源。【其他选项】Auto Scaling 加脚本管理负担大。常驻 EMR 增加管理和费用。单个函数会碰到时间和内存上限。
Q2. Lambda 函数处理时间长,内存使用还有余量。加快处理的最合适方法是哪一项?
- 在其他区域重建函数
- 缩短超时,提前中止处理,剩下的留到下次
- 把并发数限制为 1
- 增加函数的内存(CPU 也会按比例增加)
查看答案和解析
正确答案:D 增加函数的内存(CPU 也会按比例增加)
Lambda 按内存设置成比例分配 CPU。受 CPU 限制的处理增加内存后会更快,缩短执行时间有时还能降低费用。
参考链接
3.3确定高性能的数据库方案
3.3 Determine high-performing database solutions.
概念
扩展读取用 RDS 和 Aurora 只读副本(Aurora 最多 15 个),频繁读取的缓存用 ElastiCache(Redis、Memcached),DynamoDB 的微秒级读取用 DAX。连接数激增用 RDS Proxy,不可预测的负载用 Aurora Serverless v2;大规模键值场景下,DynamoDB 分区键的设计决定性能。
原理、步骤
- 确认读写比例和延迟要求
- 读取多时使用只读副本或缓存
- 来自 Lambda 的大量连接用 RDS Proxy 汇集
- DynamoDB 选择访问不偏斜的分区键,必要时加上 DAX
- 全球低延迟读取使用 Aurora Global Database 或 DynamoDB 全局表
工作中的示例
商品详情页的读取占数据库负载的 90%,因此把结果缓存在 ElastiCache 中,库存更新写入主实例。
易混淆点、考试注意事项
- 只读副本是异步的,会有轻微延迟
- DAX 是 DynamoDB 专用缓存(与 ElastiCache 不同)
- RDS Proxy 用于管理连接,并不能让查询本身变快
小测验
Q1. RDS for PostgreSQL 读取负载高,响应慢,写入很少。尽量少改应用并提高性能的最合适方法是哪一项?
- 添加只读副本,把只读查询指向副本
- 停止一次数据库实例,减少分配的存储容量
- 把读取查询发送到多可用区的备用实例
- 缩短数据库备份的保留期
查看答案和解析
正确答案:A 添加只读副本,把只读查询指向副本
只读副本可以分散读取。多可用区(实例部署)的备用实例不能用于读取。
Q2. 某关系数据库的低谷时段与高峰时段差距很大,希望自动调整容量。最合适的是哪一项?
- 用 Aurora 副本 Auto Scaling 增减副本数
- 使用 Aurora Serverless v2,按负载自动增减容量
- 启用 RDS 存储自动扩展
- 部署 RDS Proxy 池化连接以降低负载
查看答案和解析
正确答案:B 使用 Aurora Serverless v2,按负载自动增减容量
Aurora Serverless v2 根据负载自动、精细地调整容量(ACU)。【其他选项】副本扩展只帮助读取,不增加写入容量。存储自动扩展不调整计算容量。RDS Proxy 管理连接,不改变容量。
参考链接
3.4确定高性能、可扩展的网络架构
3.4 Determine high-performing and/or scalable network architectures.
概念
CloudFront 通过边缘缓存加快静态和动态内容的分发,Global Accelerator 通过固定任播 IP 和 AWS 网络加快 TCP/UDP 通信。连接大量 VPC 用 Transit Gateway(中心),少量用 VPC 对等连接,与本地之间大容量且稳定的连接用 Direct Connect。负载均衡器方面,HTTP 用 ALB,超低延迟、固定 IP、TCP/UDP 用 NLB。
原理、步骤
- 确认用户所在位置和通信类型(HTTP、TCP、UDP)
- Web 内容用 CloudFront 缓存
- 非 HTTP 或需要固定 IP 的全球应用使用 Global Accelerator
- 把大量 VPC 及与本地的连接汇聚到 Transit Gateway
- 从 ALB 和 NLB 中选择负载均衡器
工作中的示例
为全球玩家通过 UDP 连接的游戏服务器使用 Global Accelerator,100 个 VPC 用 Transit Gateway 连接。
易混淆点、考试注意事项
- VPC 对等连接不支持传递路由(有 A-B、B-C 也不能 A-C)
- CloudFront 做缓存,Global Accelerator 不做缓存
- 基于路径的路由用 ALB,固定 IP 用 NLB
小测验
Q1. 对 S3 某一个前缀的请求非常多,接近性能上限。最合适的设计改进是哪一项?
- 把存储桶迁到 S3 Express One Zone,保持同一前缀
- 在前面放 CloudFront,连写入请求也缓存
- 启用 S3 Transfer Acceleration
- 把对象键分散到多个前缀并并行请求
查看答案和解析
正确答案:D 把对象键分散到多个前缀并并行请求
S3 每个前缀都能处理很高的请求速率。分开前缀并行化可以提高整体处理能力。【其他选项】Transfer Acceleration 加速远距离传输,不改变前缀上限。Express One Zone 使用目录存储桶,需要重新设计。CloudFront 不缓存写入。
Q2. 希望每天在总部和东京区域之间以稳定的带宽传输大量数据,不受互联网拥塞影响。最合适的是哪一项?
- S3 Transfer Acceleration
- Amazon CloudFront
- AWS Direct Connect
- AWS Site-to-Site VPN(经互联网)
查看答案和解析
正确答案:C AWS Direct Connect
Direct Connect 是专线,带宽和延迟比互联网更稳定。VPN 经互联网,容易波动。
参考链接
3.5确定高性能的数据摄取和转换方案
3.5 Determine high-performing data ingestion and transformation solutions.
概念
流数据摄取用 Kinesis Data Streams(实时自定义处理,按分片扩展)或 Amazon Data Firehose(近实时投递到 S3、Redshift、OpenSearch,带转换,无需运维),Kafka 则用 Amazon MSK。批量转换用 AWS Glue(无服务器 ETL、数据目录),大规模处理用 EMR,分析 S3 数据用 Athena,数据湖权限用 Lake Formation。数据传输使用 DataSync 或 Snowball。
原理、步骤
- 确认数据量、速度和延迟要求(实时、分钟级还是每天)
- 毫秒到秒级的自定义处理用 Kinesis Data Streams,投递到 S3 用 Firehose
- 用 Glue 创建目录,并转换为 Parquet 等列式格式
- 用 Athena 查询 S3,用分区减少读取量
- 从本地持续传输用 DataSync
工作中的示例
用 Firehose 每分钟把 IoT 传感器数据以 Parquet 格式投递到 S3,再借助 Glue 目录用 Athena 分析。
易混淆点、考试注意事项
- Firehose 会缓冲,不适合毫秒级的实时处理
- 列式格式(Parquet、ORC)和压缩可以降低 Athena 的费用和时间
- Kinesis Data Streams 的容量由分片数决定(也有按需模式)
小测验
Q1. Kinesis Data Streams 处理跟不上,数据摄取发生节流。最合适的对策是哪一项?
- 缩短数据保留期
- 减少生产者数量并停止发送
- 删除流,让所有生产者直接写入 S3
- 增加分片数(或使用按需模式)
查看答案和解析
正确答案:D 增加分片数(或使用按需模式)
预置模式下处理能力由分片数决定。应增加分片,或用按需模式自动调整容量。
Q2. 你正在比较分析平台的组件。关于 Amazon Athena,错误的说法是哪一项?
- 数据不导入专用存储就无法查询
- 按查询扫描的数据量计费
- 可以用标准 SQL 查询 S3 中的数据
- 无需管理服务器
查看答案和解析
正确答案:A 数据不导入专用存储就无法查询
Athena 直接查询 S3 上的数据。使用列式格式(如 Parquet)、压缩和分区可以减少扫描量。
参考链接
课程由本站根据公开信息独立编写,不保证与考试内容一致。产品规格可能变化,请在参考链接中确认最新信息。
使用须知(非官方、原创题目、不保证合格)
- 本站题目是根据官方公开的技能大纲和考试指南独立编写的原创练习题,并非真实考试题目。
- Amazon Web Services、AWS 及相关标志是 Amazon.com, Inc. 或其关联公司的商标。本站与 AWS 无合作关系,也未获得 AWS 的认可或推荐。
- 本内容仅为学习辅助,不保证考试合格。考试内容、形式和前提条件可能随时变更,参加考试前请务必在官方页面确认最新信息。
- 模拟考试的正确率无法换算为官方(换算)分数,也不能预测是否合格。
- 进度仅保存在本浏览器(localStorage)中;使用 Google 登录后才会同步到账号。可在“Cookie 与存储设置”页面(日语)中删除。