记录一次AWS架构面试内容

最近参加了一次AWS 架构师的面试，吐槽一下整个面试时间相当的长，几乎经历了半年左右，但是我也是抱着学习伟大的AWS云产品的态度所以在整个过程中学到不少的云产品的功能、设计等知识，所以说还是相当有益处的。
前面的几关解答客户需求笔试还是相当顺利，虽然最后在视频面试会议中对可用区的概念上是被认为是不了解，终止面试，但是最起码对整个AWS云产品，包括在实际应用中如何为客户选择有了一定的认识。
言归正传记录一下面试的内容和思路

面试内容引用原文：

BRIEF
Imagine that you meet with a small startup company in the early stages of their
operations. Currently their architecture uses a LAMP stack with MySQL, Apache and PHP all running on one desktop PC within their small office. Like many small start-ups they are confident that they will be the next big thing and expect significant, rapid, yet un-quantified growth in the next few months. With this in mind, they are concerned about:
scaling to meet the demand, but with uncertainty around when and how much this
demand will be they are very concerned about buying too much infrastructure too
soon or not enough too late!
their lack of provision for Disaster Recovery
their ability to configure their database and data access layer for high performance and throughput
making the user experience in the browser very low latency even though a large
portion of their user base will be from far away
effective distribution of load
a self-healing infrastructure that recovers from failed service instances
security of data at rest and in transit
securing access to the environment as the delivery team expands
an archival strategy for inactive objects greater than 6 months
ability to easily manage and replicate multiple environments based on their blueprint architecture
OBJECTIVE
Recommend a manageable, secure, scalable, high performance, efficient, elastic, highly available, fault tolerant and recoverable architecture that allows the startup to organically grow. The architecture should specifically address the requirements/concerns as described above.
DELIVERABLES
(1) A well written document in PDF format with no more than 6 pages.
(Note: The proposal should be a document, not slides.)
(2) Clearly and succinctly present an analysis of the startups requirements of how and why use every AWS services specifically based on your understanding.
(3) Proposed architecture diagram give a detailed description for your architecture diagram and explained why you choose this solution. (4) Clearly state all assumptions and references made during the design and explicitly state the referenced Amazon Web Services.

Executive Summary

Requirements Analysis

客户采用的是典型的LAMP stack，系统通常会划分为web层，app层，数据层，根据客户的想法和关心可以通过如下几方面阐述：

扩大规模以满足需求，但由于不确定这个需求的时间和程度，他们非常担心过早购买过多的基础设施或者太晚了！

说明用户对未来规模不确定，如果过早投入必然造成资源和成本的浪费，太迟则可能会阻碍企业的发展。这样就要求云计算具有弹性伸缩的能力，可以根据流量自动扩大或缩小服务的规模。
解决：可以使用 Amazon EC2 Auto Scaling 确保 EC2 队列的可用性并根据其需求自动扩展和缩减该队列，以最大限度提高性能和降低成本，同时实例类型可以采用按需实例，实际消耗的计算容量支付费用，而不是预留实例。

针对缺乏灾难恢复机制

自建机房部署方式如果出现故障会造成灾难性的后果，即使恢复也可能丢失掉部分数据。做为云计算需要有快速恢复故障的能力同时确保数据的不丢失，
解决：采用Amazon EC2实例恢复的机制，如果实例出现问题，替代实例可以在其中以可预见的方式快速启动。Amazon RDS使用了由主数据库和备数据库构成的高可用数据库,通常备用实例也是存放在其他可用区中，Amazon RDS 会将数据同步复制到其他可用区 (AZ) 的备用实例中，同时设置数据库的快照。另外在发生硬件故障的情况下，Amazon RDS 将自动更换用于支持部署的计算实例。

他们能够配置数据库和数据访问层以实现高性能和吞吐量

解决：可以通过Performance Insights分析和调整RDS 数据库性能，帮助客户快速评估关系数据库工作负载的性能。
另外提高性能需要注意的有以下措施：
1、在配置方面可以采用高性能的存储类型（IOPS(SSD)）保证数据库提供高性能的读写操作；
2、通过多个只读副本读写分离，从而负载数据库的访问；
3、高性能数据库必要的时候通过缓存减少数据库访问次数。

尽管他们的大部分用户群来自远方，但使用户在浏览器中的体验延迟非常低

要求我们的应用可以被远端用户以最小的网络延迟被访问，通常是采用CDN方式.
解决：通过CloudFront能够使的边缘站点缓存静态数据，加速分配给最终用户的 Web 服务。

effective distribution of load

解决方案：EC2 可以通过Elastic Load Balancing 分发流量到后端多个应用实例，根据流量的负载情况自动扩展。
通过使用Elasticache 缓存应用数据来减少数据库读取的压力。
数据查询通过数据库的只读副本的方式，针对进行大量读取操作的数据库负载灵活地进行扩展。

有效分配负载一个自我修复的基础架构，可以从失败的服务实例中恢复

要求服务实例具有在失败中恢复的能力。
解决：通过 Cloudwatch中定义的报警指标检测auto-scaling
您可以创建 Amazon CloudWatch 警报来监控 Amazon EC2 实例。如果实例因需要 AWS 参与才能修复的基础硬件故障或问题而受损，可自动恢复实例。

静态和传输中的数据安全性

解决：作为web层提供服务给用户采用https的方式，用户可以通过AWS Certificate Manager 来申请 SSL 证书。
数据安全通常做法在数据传输过程和存储能够加密的形式。
数据存储的安全性通常的做法是使用加密算法存储数据，
对数据在传输过程中的安全，由于VPC起到了隔离资源的作用。那么在网络层可以仅由客户使用IAM给定的特权来建立连接。数据在运输过程中可以通过SSL / TLS传输协议。

在交付团队扩展时保护对环境的访问，

解决：使用IAM定义，用户，角色，和组的不同权限,针对不同资源向不同人员授予不同权限, 例如，您可以允许某些用户完全访问 Amazon Elastic Compute Cloud (Amazon EC2)、Amazon Simple Storage Service (Amazon S3)、Amazon DynamoDB、Amazon Redshift 和其他 AWS 服务。对于另一些用户，您可以允许仅针对某些 S3 存储桶的只读访问权限，或是仅管理某些 EC2 实例的权限，或是访问您的账单信息但无法访问任何其他内容的权限。不必共享您的密码或访问密钥。

因为交付团队扩展了超过6个月的非活动对象的归档策略：

需要有一个存储档案的容器可以定期存在相关的日志和非活动的对象。
解决：S3 可用来持久化静态对象，例如，部署归档文件，脚本，数据库备份文件和日志，媒体文件等。

可以根据其蓝图架构轻松管理和复制多个环境。

解决：如果复制到不同region，可以采用AWS CloudFormation ，它提供了一种通用语言来描述和预配置您的云环境中的所有基础设施资源。CloudFormation 使您可以跨所有地区和账户使用简单的文本文件以自动化的安全方式为您的应用程序需要的所有资源建模并对其进行预配置。
另外可以使用BeanStalk，通过使用BeanStalk快速部署PHP应用程序

Solution Design

系统架构图：

使用了一个网上在线制图网站Freedgo Design 其访问地址为: https://www.freedgo.com.
freedgo Design 是一个多种类型图表的在线绘制软件，让您创建 阿里云架构图 腾讯云架构图 Oracle云架构图 AWS系统部署图 软件架构图, UML，BPMN，ERD，流程图，UX设计图,ANT DESIGN，思维导图，图表。 可以做到注册用户免费使用。
具体绘制步骤如下：

• 打开 Freedgo Design注册页面 , 先点击注册成为注册用户，Freedgo Design提供邮箱、微信、QQ、微博等多种注册方式。
• 注册成功后，点击 开始制作 按钮，然后就进入制图工具页面进行绘制。
• 选择菜单文件-> 从类型中新建 -> 云架构 -> AWS

架构预览

Design Detail

网络层

Route53：实现的DNS域名解析服务，通过CNAME连接到CloudFront endpoint 。
cloudFront: 实现全球内容发布网络，用户请求将被引导到最低延迟的节点，提供传送的内容最佳性能，需要设置cloudFront 设置访问源为应用的ELB节点。
AWS Regoin 是应用部署的区域，一个Region可以有A-Z可用区。

Route53: Implemented the DNS domain name resolution service, connecting to the CloudFront endpoint via CNAME.
cloudFront: Implementing a global content delivery network, user requests will be directed to the lowest latency node, providing the best performance for the delivered content. You need to set the cloudFront to set the access source to the application's ELB node.
AWS Regoin is the area where the application is deployed. A Region can have an A-Z Availability Zone.

应用层

autoScaling：
Auto Scaling与 ELB 集成来实现应用服务的可用性和扩展性，将ELB附加到现有 Auto Scaling组实现负载均衡，它能够自动注册组内的实例，并将传入请求分配给这些实例。 在可用性方面，如果有服务失败宕机，那么auto-scaling 能够迅速发现问题机器并启动一台新的机器，持续服务。在扩展性方面使用 Auto Scaling，可以设置Min/MaX/参数实现自动扩缩 EC2 的服务实例数量。 AutoScaling组中的每个实例都在不同的可用区,防止在可用区发生故障

数据层

elasticache：
使用ElastiCache Redis 提高生产部署的可靠性，缓解前端请求对数据库访问的压力，降低延迟，还可以起到防灾、减灾的作用。
Redis 复制组包含一个应用程序可读写入的主节点和 2个只读副本节点。在向主节点写入数据时，也会在只读副本节点上异步更新数据。 这样可以有效的防止节点故障，而在两个可用区各分别部署一个集群服务，主要是为了避免可用区故障。
DataBase:
数据库负责数据库的高可用和高性能的数据存储，一个高可用的数据库通常包含两个数据库实例:一个主数据库和备用数据库。当所有请求发送到主数据库时，由 RDS实例来负责响应服务器请求，完成对数据的读写操作。主和备用数据库之间的数据同步复制。如果主数据库由于硬件或网络故障而不可用时，RDS会自动侦测到故障，启动故障转移过程，备用数据库将成为了主数据库，同时DNS也会自动更新，来实现快速故障转移。

VPC&安全组设置

每一层都设计了安全组和子网，能够更加有效提供安全保障机制。
在应用层autoScaling的安全控制中定义允许如何位置的访问应用的80和443端口，允许互联网的用户访问入口, 定义ssh 22端口 指定特定位置的访问。

数据层设置安全组的入站策略中定义允许应用访问MYSQL/Aurora的3306端口
Elasticache安全组的入站策略中定义允许应用访问自定义TCP访问redis的端口
 

监控

系统可以通过使用CloudWatch来监控整个系统的内存使用率、处理器利用率、缓存命中率等一系列指标来监控服务器运行状况。

Summary

创业公司提出的需求正是云平台提供商所要解决的问题，如何提供可管理的，高性能，高可用，安全的基础服务平台，同时方便用户日常的维护，发布和应对突发事件的能力。
高性能：也是客户非常关注的，AWS几乎覆盖全世界11个主要区域，42个可用区，52个边缘站点，在提供高可用的服务同时，也能够提供高性能服务。AWS在各个层提供了各种类型的主机类型，内存优化，存储优化等等，适应不同的需求。
高可用性：无论是APP层的AutoScaling、数据库、S3都会提供若干应用的副本，而且是在不同的可用区，这个可以保证一个可用区不可用时，应用可以快速切换到另外的可用区，做到高可用。
安全性：AWS通过自动监控系统可以做到保护网络和增强互联网接入的安全性，通过VPC和安全组的控制，做到网络的安全性和隔离。

References

在线制图工具： https://www.freedgo.com
Router53 使用：https://www.cnblogs.com/huang...
Cloudfront: https://console.aws.amazon.co...
Route 53 console:
RDS console: https://us-east-2.console.aws...:id=csydb;is-cluster=false