記錄一次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