開始之前

最近有參加Architecting on AWS這個架構設計的課程

因為課程講的東西真的滿多滿廣的

所以特別把筆記整理出來

盡量把三天的覺得重要東西濃縮起來

課程參與先決條件

以下是AWS建議參與課程的先決條件

AWS Technical Essentials(大概是了解AWS的一些產品、以及從地端到雲端的一些思維)
具有分散式系統工作經驗
熟悉一般聯網概念
具有多層架構工作經驗
熟悉雲端運算概念

課程概要

介紹AWS的基本知識包含硬體層級、AWS主要的服務、網路架構(VPC、Gateway、Route Table、Subnet)

服務的部份像是EC2、RDS、S3、ELB、Auto Scaling、Cloud Watch、SNS都講的滿細的而且也有上Lab操作

當然主要還是講解一些雲端架構的設計

不斷強調系統要High Availability(高可用)

High Availability

234

Fault Tolerance(可容錯): 不然單點故障服務就掛掉
Recoverability(可復原): 可災難復原
Scalability(可擴展): 能在不更動架構的狀況下擴展(Auto Scaling)

講師強調的一些觀念

以下是當天授課得到的資訊

並非完全是我個人的立場

了解AWS主要產品
- 雖然在AWS Technical Essentials中已經有介紹, 但是其實其他AWS的課程仍然會持續介紹
- 產品講不完, 因為AWS的產品有幾百種, 而且一直持續增加中
雖然我們是租用AWS雲端的主機, 但是其實它是硬體上包一層軟體, 軟體的特色就是能夠自動化
既然都要用雲端服務了, 那就直接用到最頂層
- AWS如果發現很多人都用他的服務在疊起來做一個功能, 它們會直接把這個功能包起來做一個服務出租
- 例如AWS的RDS, 雖然可以自己開EC2架DB, 但是AWS的RDS已經做很好了, 連HA都考慮進去, 為什麼不直接用呢？
本堂課的架構設計沒有標準答案
- 要依照每個系統當下的情況, 預算, 規模等等來自己找到最佳解
- 課程僅提供各種架構的介紹, 讓學員回去能有更多的想法以及思考空間
服務是可以serverless(無伺服器), stateless(無狀態)的, 機器這種東西要死就自己去死
讓AWS的服務擋在前面(ELB、CloudFront)系統的前面、能隱藏的就隱藏(讓攻擊面積變小)

硬體層級

17

Data Center: 資料中心、最基礎的架構
Availability Zones(AZ): 資料中心的group, 地理區域接近不跨國
Regions: 至少兩個AZ, 可想像成一個城市, 底下AZ的佈署會考慮斷層帶、水災等天災問題(全球18個Regions)
Edge Location: CDN, 可想成cache, proxy, 讓End User存取點可以接近Regions的服務, 裡面也有Data Center

Level Of Availability

正常運行時間	每年最高的停機時間(Downtime)	每天的停機時間
90%	36.5 days	2.4 hrs
99%	3.65 days	14 min
99.9%	8.76 hrs	86 sec
99.99%	52.6 min	8.6 sec
99.999%	5.25 min	0.86 sec

IAM權限管理

113

AWS建議

當你開通AWS帳號的第一天

就應該開一個擁有所有權限的帳號

然後把root鎖起來MFA(可以想像成保險箱)中

不應該給每個要使用的人root權限

因為大家都是root就算有操作紀錄也不知道是誰幹的

AWS Organizations

168

如果一個公司每個部門有自己的AWS帳號

但是每個帳號分別付錢很不方便

使用AWS Organizations能集中管理帳號並統一付錢

也能監控各個帳號的資源使用狀況

網路層

175

VPC(Virtual Private Cloud): AWS雲端網路架構的最外層, 把系統所有的服務與外界隔開
Subnet
Route Table
Gateway

Make You Environment Highly Available

大概的架構圖

我盡力了

ELB

240

Elastic Load Balancing(負載平衡器)

又可分成三種

Application Load Balancer: 處理HTTP/HTTPS(Layer 7)流量
Network Load Balancer: 處理TCP(Layer 4)流量
Classic Load Balancer: 可同時處理Layer 4/Layer 7流量, 主要處理跨多個EC2之間的負載平衡

ELB可以處理大量流量(無論是一般或惡意)

但是並不會加快速度

可以想像成買保險

讓系統能承受的瞬間流量能增加

買多買少則是要看需求

Google也有出Cloud Load Balancing

Cloud Watch

300

前面講的到ELB或Auto Scaling到底要加到多少程度

或是EC2等級要開多大都只是預測

遇到問題不一定把機器等級調高或是增加機器數量就能解決效能問題

但是有數據的時候就能更精準的抓到問題的癥結點

主要功能

監測資源並且蒐集log整理成可讀、有用的指標(metrics)
將指標轉換為統計數據(Turn Metrics Into Statistics)
在自訂指標達到某些條件時, 發出警報觸發Auto Scaling

自訂監測的警報(Alarm)範例

303

EC2: CPU使用率大於60%且超過5分鐘
RDS: 同時連線數量超過10個且超過1分鐘
ELB: 健康的機器小於5台且超過10分鐘

發生警報(Alarm)能做什麼事情?

304

Stop, terminate, reboot, recover EC2
觸發Auto Scaling
使用SNS發簡訊或Email通知管機器的人

Auto Scaling

309

https://aws.amazon.com/tw/autoscaling/

依照自訂的條件、排程調整機器

讓系統更有彈性

而且是透過ELB自動開關機器(Automatically registers new instances with load balancers when specified)

為什麼需要Auto Scaling?

每種行業類別的Web都會有淡旺季(節慶)

或是有活動時流量會爆增

假設有活動時我們需要5台機器

但是如果平常開5台機器運作又很貴

How it works?

314

What: 用AMI(映像檔)建立啟動設定, 設定下面的一些東西, 基本上跟開一台EC2差不多
- 名稱
- 映像檔
- Instance Type
- User data(第一次建好主機要執行的command)
- Security Group
- IAM Role
Where: 設定Auto Scaling Group
- 名稱
- 選擇Launch Configuration Name(上一個步驟的啟動設定)
- 設定AZ/Subnet(最好能跨AZ避免天災)
- Max/Min(最多/最少的機器數量)
- 選擇Load Balancer
- Desired Capacity(一開始的機器數量)
When: 觸發Auto Scaling的方式
- 排程: 例如預先知道有活動, 可以排程在活動前一小時開多一點機器備載
- 指標達到條件: 例如CPU超過60%而且維持5分鐘以上

調整的類型

增減機器效能N%
增減機器數量

Warmup Period

322

EC2都會有一個開機等待時間叫Warmup Period

所以做Auto Scaling都需要注意這個時間

其他心得

這部份的Lab練習就是直接讓我們開ELB+Auto Scaling

設定完之後開起來

然後手動關掉其中一台機器

過一陣子之後就會看到自動長出一台新的EC2

Cloud Formation

364

可將系統架構做成設定檔樣版化

甚至也能直接用拉的話出架構

AWS Training的Lab就是用Cloud Formation做出來的

要刪掉系統環境也很簡單

進入Cloud Formation就能一鍵刪乾淨

當然Google也有出類似的Deploy工具

Google Deployment Manager

SNS

428

Simple Notification Service

可通知的方式

HTTP/HTTPS請求
Email(純文字/JSON)
簡訊
手機推播
AWS SQS
AWS Lambda

Google也出一個Cloud Pub/Sub

Lambda

456

AWS無伺服器運算服務

可直接貼一段Code上去(有Python、Node.js就是沒有PHP)

Google也有出一個差不多的功能叫Google Cloud Function

主要特色

Listening/Polling
Auto scaling
Queue
Processing Load Balancing

因為擁有以上特色

所以處理瞬間大量的功能

而寫code就不須管他是一個處理程序或是多個

直接把它當一個處理程序來寫就可以了

另外Lambda支援以下三種方式來上code

從無到有自己寫
用AWS提供的樣板
使用Git Repository

其他心得

我覺得Lambda要看使用情境來用

太複雜的Code丟到Lambda上會不好管理

不過如果是簡單的code丟到Lambda上是真的滿方便的

可以直接忽略主機、Highly Available、Scalable等問題

AWS vs Google

Google有提供類似於AWS主要的服務

IAM	IAM
EC2	Compute Engine
RDS	Cloud SQL
S3	Cloud Storage
Lambda	Cloud Function
SNS	Cloud Pub/Sub
Cloud Formation	Deployment Manager

心得

Architecting on AWS算是AWS中階的訓練課程

在參加之前

我本來對於雲端的系統架構大概就是基本的EC2做Web Server、RDS開DB、S3放圖片檔案

其他的服務也只是聽過

但是不太知道要怎麼設計架構

不過聽完之後發現有滿多架構不錯可以拿來參考

至少之後對於雲端架構的概念不會再只有EC2、RDS、S3這樣而已

像是我個人最喜歡的部份就是Load Balancer + Auto Scaling + Cloud Watch那段

那段算是我覺得以現階段最有可能會用到而且能解決問題的

算是非常有收穫的三天

Architecting on AWS筆記