记录一次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 数据库性能，帮助客户快速评估关系数据库工做负载的性能。
另外提升性能须要注意的有如下措施：
一、在配置方面能够采用高性能的存储类型（IOPS(SSD)）保证数据库提供高性能的读写操做；
二、经过多个只读副本读写分离，从而负载数据库的访问；
三、高性能数据库必要的时候经过缓存减小数据库访问次数。

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

要求咱们的应用能够被远端用户以最小的网络延迟被访问，一般是采用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