常见AWS架构问题排查：解决方案与技巧

大多数AWS架构问题起初都显得模糊不清：应用程序运行缓慢、私有实例无法访问AWS API、负载均衡器没有健康目标、或者数据库故障转移未按预期进行。最快的排查方法通常是跟踪一个请求路径并验证每个跳转点是否健康，而不是在整个账户范围内更改设置。

从三个问题开始：发生了什么变化？用户可见的症状是什么？请求在哪里停止移动？一旦你确定故障是性能、连接、可用性还是授权问题，AWS控制台就会变得清晰很多。

性能瓶颈

性能问题可能表现为应用程序响应时间变慢、延迟高或资源耗尽。识别瓶颈对于有效优化至关重要。

识别性能瓶颈

监控关键指标： 利用Amazon CloudWatch等AWS服务跟踪计算、存储和数据库资源的指标。关注：
- CPU利用率： EC2实例CPU持续高使用率可能表示处理能力不足或代码效率低下。
- 内存利用率： 高内存使用率可能导致交换，从而降低性能。默认情况下，EC2内存不包含在基本实例指标中，因此如果内存对工作负载很重要，请使用CloudWatch代理或应用程序监控工具。
- 网络输入/输出： 网络流量峰值或持续高流量可能表示数据传输效率低下或负载增加。
- 磁盘I/O操作（IOPS）和吞吐量： 对于Amazon EBS和Amazon S3等服务，超过预置限制可能导致存储相关的速度减慢。
- 数据库连接和查询延迟： 监控Amazon RDS或DynamoDB实例的性能。
AWS X-Ray： 对于分布式应用程序，AWS X-Ray有助于可视化请求流并识别特定服务调用中的性能问题。
VPC流日志： 分析网络流量模式以识别任何意外或过多的数据传输。

性能瓶颈的解决方案

扩展资源：
- 垂直扩展（向上扩展）： 增加EC2实例的大小（CPU、RAM）或升级RDS实例类。使用AWS Auto Scaling根据需求自动调整容量。
- 水平扩展（向外扩展）： 向应用程序层添加更多实例（例如，使用EC2 Auto Scaling组）或将负载分布到多个数据库只读副本上。
优化应用程序代码： 检查应用程序代码中是否存在低效算法、过多数据库查询或内存泄漏。
缓存： 使用Amazon ElastiCache（Redis或Memcached）或Amazon CloudFront实现缓存策略，以减少后端服务的负载。
数据库优化： 优化SQL查询、添加适当的索引，或考虑迁移到性能更高的数据库解决方案，如Amazon Aurora。
存储优化： 选择正确的EBS卷类型（例如，通用型gp3、高IOPS型io2）或利用Amazon S3智能分层实现成本和性能优化。

示例：诊断高EC2 CPU利用率

检查CloudWatch指标： 导航到CloudWatch，选择EC2，查看实例的CPUUtilization指标。如果持续高于80-90%，请进一步调查。
SSH登录实例： 使用top、htop或ps等工具识别消耗最多CPU的进程。
分析应用程序日志： 在应用程序日志中查找可能与高CPU使用率相关的错误或模式。
考虑扩展： 如果工作负载是合理的且无法进一步优化，请考虑增加实例大小或启用EC2 Auto Scaling。

连接问题

连接问题可能阻止用户访问您的应用程序或妨碍AWS资源之间的通信。

常见连接场景

EC2实例无法访问： VPC内的实例可能无法从互联网或其他实例访问。
跨VPC连接失败： 连接不同VPC中的资源时出现问题。
服务端点不可用： 无法从VPC内部连接到AWS服务（例如S3、RDS）。

排查步骤

审查VPC网络配置：
- 安全组： 确保附加到实例的安全组允许来自正确源IP地址或安全组的入站流量到所需端口。请记住，安全组是有状态的。
- 网络访问控制列表（NACL）： 验证与子网关联的NACL是否允许入站和出站流量。NACL是无状态的，因此您需要为两个方向设置规则。
- 路由表： 检查子网的路由表，确保正确路由到互联网（通过互联网网关或NAT网关）、其他子网或对等VPC。
- 子网设置： 确认实例位于正确的子网中，并且子网具有适当的路由表关联。
检查互联网网关（IGW）/ NAT网关：
- IGW： 确保您的公有子网具有通往IGW的路由以访问互联网。
- NAT网关： 如果私有子网中的实例需要互联网访问，请确保NAT网关配置正确、与弹性IP关联，并且私有子网的路由表中有指向它的路由。
验证VPC对等连接/中转网关： 对于跨VPC通信，确认VPC对等连接或中转网关附件处于活动状态，并且所有相关VPC中的路由表都已更新，包含指向对等VPC CIDR块或中转网关的路由。
检查DNS解析： 确保您的VPC配置为使用DNS（例如，VPC_CIDR_PLUS_2处的AmazonProvidedDNS），并且DNS解析正常工作。从实例使用dig或nslookup进行测试。
AWS网络可达性： 使用AWS Reachability Analyzer诊断VPC内或跨VPC的AWS资源之间的连接问题。

示例：EC2实例无法从互联网访问

公有IP地址： EC2实例是否分配了公有IP地址？它是否在公有子网中？
安全组： 检查附加到实例的安全组。确保存在一条入站规则，允许来自0.0.0.0/0（或特定IP范围）的流量到应用程序端口（例如，HTTP的80端口，HTTPS的443端口）。
网络ACL： 检查与实例子网关联的NACL。确保它允许入站流量到应用程序端口，并允许出站流量到临时端口（1024-65535）以进行响应。
路由表： 验证子网的路由表是否具有通往互联网网关的路由（0.0.0.0/0 -> igw-xxxxxx）。
实例状态： 实例是否正在运行？

服务可用性问题

确保高可用性对于关键任务应用程序至关重要。停机可能导致重大的业务影响。

高可用性策略

多可用区部署： 将数据库（RDS Multi-AZ）和应用程序服务器等关键资源部署到区域内的多个可用区（AZ）。如果一个可用区发生故障，流量可以自动故障转移到另一个可用区。
负载均衡： 使用Elastic Load Balancing (ELB) - Application Load Balancer (ALB)、Network Load Balancer (NLB)或Classic Load Balancer (CLB) - 将流量分布到不同可用区的多个实例。ELB健康检查会自动将不健康的实例从轮换中移除。
自动扩展： 实施EC2 Auto Scaling以自动替换不健康的实例，并根据需求和健康检查上下扩展容量。
无状态应用程序： 设计无状态应用程序，以便更容易替换或扩展单个实例，而不会丢失数据或中断服务。
优雅降级： 设计您的应用程序，使其即使某些依赖项不可用，也能以功能减少的方式运行。

排查可用性问题

健康检查：
- ELB健康检查： 确保您的ELB健康检查配置准确，并测试正确的端点和端口。
- EC2 Auto Scaling健康检查： 验证Auto Scaling健康检查是否配置正确。
- 应用程序健康端点： 在应用程序中实施专用的健康检查端点，以便进行监控。
分析CloudWatch警报： 为关键指标（例如，高错误率、低磁盘空间、高延迟）设置CloudWatch警报，并及时调查任何触发的警报。
查看AWS Health： 检查AWS Health Dashboard以了解影响您账户或区域的服务事件。对于广泛的公共事件，也请查看公共AWS Health状态页面。
故障转移测试： 定期执行故障转移测试（例如，终止一个可用区中的实例），以确保您的高可用性策略按预期工作。

示例：由于实例故障导致应用程序无响应

ELB健康检查： 如果使用ALB，请检查目标组的健康状况。ALB应自动将故障实例标记为不健康，并停止向其发送流量。
自动扩展： 如果实例是Auto Scaling组的一部分，该组应检测到不健康的实例（通过ELB或EC2健康检查）并启动替换实例。
CloudWatch指标： 在CloudWatch中监控ALB的HealthyHostCount和UnHealthyHostCount等指标。同时，检查剩余健康实例的CPUUtilization和NetworkIn/Out，以了解它们是否正在处理增加的负载。
日志： 检查故障实例（如果可能）和新实例的日志，以了解故障发生的原因。

预防问题的安全最佳实践

虽然不是直接的故障排查，但遵守安全最佳实践可以主动预防许多常见的架构问题。

最小权限原则： 仅授予IAM用户、角色和服务必要的权限。
网络分段： 使用VPC、子网、安全组和NACL隔离资源，限制安全漏洞的影响范围。
定期修补： 保持EC2实例上的操作系统和应用程序修补到最新版本。
加密： 加密静态数据（例如，EBS卷、S3对象、RDS数据库）和传输中数据（使用TLS/SSL）。
日志记录和监控： 启用详细日志记录（CloudTrail、VPC流日志），并设置可疑活动的监控和警报。

制作小型Runbook

对于每个生产工作负载，保留一个简短的runbook，其中列出真实的请求路径：DNS、CDN、负载均衡器、计算层、数据库、缓存、队列、对象存储和外部依赖项。添加您的团队应首先检查的具体CloudWatch指标、目标组、安全组、路由表和仪表板。"检查AWS"不是runbook；"检查ALB目标健康状况、ECS服务事件、RDS Performance Insights以及事件窗口内的近期CloudTrail更改"在凌晨2点很有用。

当您将网络故障与IAM故障分开、比较正常和异常时间窗口、并抵制同时更改多个层的冲动时，AWS故障排查会变得更加冷静。跟踪请求，找到第一个故障跳转点，修复该层，然后再继续。