【AWS】AWS 单体应用程序构建的架构原则
当然，以下是在 AWS 上构建单体应用程序的架构原则：
AWS 单体应用程序构建的架构原则
单体应用程序 (Monolithic Application) 是一种传统的软件架构模式，它将所有功能（如用户界面、业务逻辑、数据访问层）集中在一个代码库和部署单元中。尽管微服务架构在云原生时代很流行，但单体应用在某些场景下仍有优势，比如初创项目、小型团队或需要快速原型开发的情况。
在 AWS 上构建单体应用程序时，即使存在其固有的局限性（如粗粒度扩展和技术栈锁定），您仍可以通过遵循特定架构原则并充分利用 AWS 服务的优势，显著提高其高可用性、可扩展性、安全性、可管理性和成本效益。
核心架构原则与 AWS 实践
以下是您在 AWS 上构建单体应用程序时应遵循的关键架构原则：
1. 高可用性 (High Availability)
确保单体应用在面对故障时能持续运行。
多可用区 (Multi-AZ) 部署： 将 EC2 实例部署在至少两个或更多可用区 (Availability Zones) 中，并通过 Elastic Load Balancing (ELB) 分配流量。即使一个可用区故障，ELB 也能将流量路由到其他可用区中的健康实例。对于数据库，使用 Amazon RDS Multi-AZ 部署或 Amazon Aurora Multi-AZ 集群，实现数据层的高可用性和自动故障转移。
健康检查 (Health Checks)： 配置 ELB 对后端 EC2 实例进行持续的健康检查。如果实例不健康，ELB 会自动停止向其发送流量，直到它恢复正常。应用程序内部也应提供健康检查端点。
2. 可扩展性 (Scalability)
使单体应用能根据负载需求进行伸缩。
水平扩展 (Horizontal Scaling)： 使用 Amazon EC2 Auto Scaling 根据 CPU 使用率、网络 I/O 或请求计数等指标，自动增加或减少 EC2 实例数量。这是扩展单体应用计算能力最有效的方式。为实现这一点，应用程序应尽可能设计为无状态，或将会话状态外部化（例如，存储在 Amazon ElastiCache 中）。
垂直扩展 (Vertical Scaling)： 当水平扩展遇到瓶颈时，可以升级到更大规格的 EC2 实例类型。
数据库扩展： 对于读取密集型负载，使用 Amazon RDS Read Replicas 或 Amazon Aurora Read Replicas 来分担主数据库的读取压力。
解耦耗时任务： 即使在单体应用内部，也可以将耗时或 CPU 密集型任务（如图片处理、报告生成）解耦出来，通过 Amazon SQS (简单队列服务) 或 Amazon SNS (简单通知服务) 异步处理，由单独的 worker 实例或 Lambda 函数来执行，减轻主应用程序的负担。
3. 安全性 (Security)
保护单体应用程序及其数据免受威胁。
VPC 设计： 将应用程序部署在 Amazon VPC (虚拟私有云) 中，并合理划分公有子网（用于 ELB）和私有子网（用于 EC2 实例和数据库）。
网络过滤： 使用 网络 ACL (NACL) 和 安全组 (Security Groups) 进行多层网络过滤，只允许必要的流量进出。
身份和访问管理 (IAM)： 遵循最小权限原则，为 EC2 实例分配 IAM 角色，而不是使用硬编码的凭证。
Web 应用程序防火墙 (WAF) 与 DDoS 防护： 将 AWS WAF 与 ELB 集成，保护应用程序免受常见 Web 漏洞和机器人攻击。利用 AWS Shield Standard/Advanced 提供 DDoS 防护。
威胁检测： 启用 Amazon GuardDuty 持续监控恶意活动。使用 Amazon Inspector 自动扫描漏洞和网络暴露。
数据加密： 对静态数据和传输中的数据进行加密。使用 AWS Secrets Manager 或 AWS Systems Manager Parameter Store 安全存储敏感信息。
4. 可管理性与可观测性 (Manageability & Observability)
简化单体应用的运营和故障排除。
集中式日志： 将应用程序和系统日志发送到 Amazon CloudWatch Logs，并利用 CloudWatch Logs Insights 进行分析。
全面监控： 使用 Amazon CloudWatch Metrics 监控所有相关资源的性能指标。创建CloudWatch 仪表板和警报。
自动化部署： 使用 AWS CodeDeploy 自动化应用程序部署，支持零停机部署（如蓝/绿部署）和自动回滚。结合 AWS CodePipeline 构建 CI/CD 管道。
基础设施即代码 (IaC)： 使用 AWS CloudFormation 模板来定义和管理整个基础设施，实现基础设施的自动化、可重复性和版本控制。
备份和恢复： 定期对 EBS 卷和 RDS 数据库进行快照和自动备份，并配置跨区域复制。
5. 成本优化 (Cost Optimization)
在 AWS 上高效运行单体应用程序。
合理选择实例类型和大小 (Right-sizing)： 根据实际性能需求选择最合适的 EC2 实例类型和大小，避免过度配置。
利用折扣模式： 对于稳定工作负载，考虑购买 Savings Plans 或 Reserved Instances。对于容错或有弹性的工作负载，可以考虑使用 Spot Instances 来显著降低计算成本。
存储优化： 根据数据访问模式选择合适的 Amazon S3 存储类和 EBS 卷类型。
自动化管理： 利用 Auto Scaling 自动缩减实例，避免为闲置资源付费。
6. 数据管理 (Data Management)
高效、安全地处理应用程序数据。
托管数据库服务： 优先使用 Amazon RDS 或 Amazon Aurora。
缓存层： 使用 Amazon ElastiCache 来缓存频繁访问的数据，减轻数据库负载。
静态内容分离： 将静态文件（如图片、CSS、JS）存储在 Amazon S3 中，并通过 Amazon CloudFront 进行分发，减轻 EC2 实例的负载。
数据备份和恢复策略： 制定并测试完善的数据备份、恢复和保留策略。
总结
尽管单体应用有其固有的局限性，但在 AWS 云上，通过遵循上述架构原则并充分利用其丰富的托管服务，您可以构建出高可用、可扩展、安全且易于管理的单体应用程序。这些原则不仅能让您享受单体应用开发和部署初期的简单性，也为未来可能向微服务转型打下坚实的基础。
您目前正在考虑构建单体应用，还是已经有一个现有的单体应用想要优化呢？
过去考试题
大規模なモノリシックアプリケーションを再構築する際に推奨されるクラウドアーキテクチャの設計原則はどれですか。（2つ選択してください）
①手動監視を使用
②固定サーバーを使用
③疎結合を実現
④個々のコンポーネントに依存
⑤スケーラビリティの設計
モノリシックなアプリケーションを再構築する際に推奨されるクラウドアーキテクチャの原則は、疎結合（③）とスケーラビリティの設計（⑤）です。
疎結合は、システムの各コンポーネントが密接に結合されずに、独立して動作できることを意味します。これにより、個々のコンポーネントを別々に開発、テスト、デプロイ、スケーリングできるため、全体のシステムの複雑さを軽減できます。
スケーラビリティの設計は、アプリケーションのリソース需要に応じて、リソースを自動的に拡張または縮小できるようにすることです。これにより、需要の変動に対応でき、コストを最適化できます。
選択肢Aの①手動監視を使用は、推奨されるアーキテクチャの設計原則ではありません。モニタリングと自動化が重要です。
選択肢Bの②固定サーバーを使用は、スケーラビリティに反するため、推奨されません。
選択肢Cの④個々のコンポーネントに依存は、疎結合の原則に反するため、推奨されません。