AWS的雲端架構框架-效能篇

這一篇我們概述AWS提倡的雲端架構框架的第四個面向 — 系統的效能．所謂良好的效能是指“有效率的使用電腦的運算資源來達到我們系所需，並且能跟依據業務量能的需求變化與技術進化而演變”．

在系統效能的部分， AWS給了我們設計原則的概觀，最佳實踐以及在這個過程中我們需要回答的問題．

五個設計原則

AWS在雲端的系統效能層面上提出了五個設計原則，它們分別是：

• 庶民用的先進技術：AWS讓我們很簡單的使用先進的技術，這意味著操作它的人可能不需要是很厲害的工程師，這一類簡易的先進技術的實作讓我們可以進行複雜的作業．與其花各項的資源(時間/金錢/人力)從底層(基礎建設)自建所有的東西，不如像用水電般(也是基礎設施)的使用這些先進技術．
• 瞬間達到我們的系統能服務全世界：將我們的系統服務部署在多個AWS regions，讓我們的客戶感受到系統的順暢無阻的流程．
• 使用無伺服器(Serverless)架構：這種架構能夠讓我們從傳統地端機房的所有相關基礎設施建置/維護作業中解放出來．這大大減少了組織需要對這些基礎設施所需的維運人力與相關成本．
• 能有更多的實際運作實驗：使用雲端的虛擬化與自動化，我們能很快的製造一個一模一樣的生產環境或是不一樣的環境參數(如設定組態/機器規格大小/空間大小等等)來進行不一樣的實驗以求達成效能與成本的最佳化．
• 使用正確的技術：我們需要理解在雲端技術上的各項服務或工具是如何能夠最符合我們的系統服務的運作目標．例如歸檔資料應該就放在S3上而不是EFS．

四個最佳實踐

• 選擇
• 檢視
• 監控
• 權衡

生活上有需多事都需要我們進行“權衡”．在雲端的設計上當然也不例外，有一好沒有兩好，像是資料在運作中是要進行壓縮比較好還是有快取．但我們需要依據事實(也就是data-driven的方式)來建立一格高效能的系統架構．我們要從系統架構的所有層面，從high-level design到我們的資源型態是被正確“選擇”與設定．

我們需要定期與不定期根據AWS所提供的最新技術來“檢視”我們之前的設計還是不是符合我們的效能需求甚至可以有所優化．而“監控”則可以為我們提供我們預期的系統效能是否有所偏差．

選擇

我們優化整體的系統服務不會只有一種方法或單一功能，而是多個方法與功能組合起來達成一個之於我們系統服務的最佳解．就像要用樂高積木要組合一個房子，每個人用的方式或功能都會不盡相同．

而 AWS則提供了多種的方法與功能(就是不同的積木)，這樣的方式可以讓我們很容易的拼出最接近我們理想中的系統服務所需．而這些方法與功能(就是不同的積木)在我們傳統的地端機房環境中幾乎是看不到的．

以下問題是我們在考量系統效能面時需要回答一些問題：

Q1:我們如何選擇最佳的效能架構？
這通常需要多種方法與功能來實現整體系統服務的最佳效能。 架構良好的系統使用多種解決方案和功能來提高效能。

最佳實踐的方式有：

• 認知到有哪些的雲端運算中可用的服務與資源
• 對於架構選擇有一套處理流程
• 將成本要素納入我們的決策
• 有政策性或參考性的架構
• 從AWS或合作商得到良好的指引
• 對現有系統服務進行基準測試
• 對現有系統服務進行壓力測試

上面我們提到使用 data-driven的方式選擇我們的架構模式與實作來達成具成本效益的方案．AWS提供基於各產業知識來協助我們帶的達成此一目的，但是我們還是需要用一些基準測試或實驗來取得我們可以應用的資料，最終達成價購的優化．

而針對我們的系統服務，我們也會組合好幾種架構方法(例如event-driven, ETL, pipeline)．我們的架構的施作將使用專門用於優化我們的架構效能的 AWS 服務。 在以下部分中，我們將討論要考慮的四種主要資源類型（運算、存儲、資料庫和網路）。

運算(Compute)

這裡的重點在於如何選擇運算資源是恰如其份是我們的系統所需要的，這其中包含了成本效益問題，因為運算資源的選用越是恰如其份我們就有更多的資源做其他事，而不會造成資源浪費．但有時“效能跟成本”是一體兩面的事，我們有時需要在這兩者之間做出權衡．

在AWS中，運算單元分為instance, containers跟functions:

• Instance: 這通常是VM．在 AWS中，VM的大小可以根據我們的業務需求進行即時的變更．而在AWS中的 VM選擇會比我們在地端機房更多，諸如VM裡要不要有GPU．
• Containers: 這通常運行在VM中，也可以看做是Application的虛擬化，意味著每個Container的資源都是獨立分隔的．AWS Fargate是一個serverless服務，讓我們可以不用管控(installation/configuration/management)container or EC2，而只需要注意運作在上面的Application．AWS的container orchestration還有ECS與EKS.
• Functions: 這直接將我們的程式代碼放到AWS的Lamda中運作，其他的底層基礎設施則通通可以不用管．

Q2: 我們如何選擇我們所需要的運算單元？
系統服務的最佳運算方案因應用程式設計、使用模式和配置設置而異。 架構可以為各種組件使用不同的運算方案，並啟用不同的功能來提高效能。 錯誤的運算架構方案可能會導致效能的效率低下。

最佳實踐的方式有：

• 評估可用的運算單元選項
• 了解可用的運算單元的組態選項
• 收集相關的運算指標
• 確認系統所需的配置
• 使用可用的彈性資源
• 根據指標重新評估所需的運算資源

在架構運算單元的使用時，我們應該利用可用的彈性機制來確保我們有足夠的容量來隨著前端業務需求的變化來維持在一定的效能基準上。

儲存(Storage)

雲端存儲是雲端計算的重要組成部分，保存我們系統服務要使用的資訊。 雲端存儲通常比地端機房的存儲系統更可靠、可多擴展性和安全。 我們需要對我們要存儲的資料/資訊選擇如object、block和file 的這些種類的存儲服務。

在 AWS中，AWS提供了 Object, block與file這三類的儲存服務

• Object storage: 提供了一個可擴展(scalable)、耐久(durable)的平台，可以讓資料從Internet被取用，不管什麼樣的資料類型我們通通可以塞進去。 AWS S3 是一種object存儲服務，提供可擴展性、資料可用性、安全性和效能。 AWS S3 可以實現 99.999999999%（11 個 9）的持久性，意味著每一百萬年才會遺失一個檔案。
• Block Storage: 為每個VM提供高可用性、一致、低延遲的block storage，這類似於DAS(direct-attached storage)或SAN(Storage Area Storage)。 AWS EBS 是提供 EC2 的持久存儲而設計。
• File storage: 這是提供託管式的NFS storage服務．AWS EFS提供的就是這一類的Managed NFS service．而AWS FSx則提供比EFS更高的效能與跟多的功能選項，甚至可以整合第三方的服務．

Q3: 我們如何選擇我們所需要的儲存方案？
系統的最佳存儲方案因存取方法（block、file或object）的種類、存取模式（random或sequential）、所需要的throughput、存取頻率（online、off line、archival）、資料更新頻率而異 （WORM — Write Once Read many，dynamic）以及可用性和持久性等等因素的限制。 良好的系統架構使用多種存儲方案並啟用不同的功能來提高笑能且有效地使用資源。

最佳實踐的方式有：

• 了解各種儲存選項的特徵與需求
• 評估可用的設定組態
• 根據存取模式與指標做出決策

當我們選擇儲存方案時，我們要非常了解這一類的資料它的“存取模式”是什麼．這樣才可以針對存取模式選擇到最佳效能的存取方案．

資料庫(Database)

AWS提供了專門打造的資料庫服務，可以解決我們的系統服務帶來的不同問題。 我們可以從許多專門打造的資料庫引擎中選擇我們需要的資料庫類型，包括relational、key-value、document、in-memory、graph、time series和ledger等類型的資料庫。 選擇最適資料庫來解決特定問題，我們可以擺脫尤其限制性的一套資料庫用到底的問題，專注於構建應用程式以滿足我們的業務的效能需求。

AWS 提供了上述的資料庫類型。 使用 AWS 資料庫，我們不需要進行數據庫底層的管理工作，例如安裝伺服器、補丁、設定、配置、backup/restore。 AWS 會持續監控我們的DB cluster，以通過自我修復存儲和自動擴展保持我們的系統服務是正常運作的。

Q4: 我們如何選擇我們所需要的資料庫方案？
系統的最佳資料庫解決方案根據availability、consistency、partition tolerance、latency、durability、scalability和query capability的要求而有所不同。 一個很大的系統服務其底下的各種子系統一定會使用不同的資料庫方案，並啟用不同的功能來提高效能。 選錯了資料庫方案可能會導致效能效率降低。

最佳實踐的方式有：

• 理解我們的資料特徵
• 評估可用的選項
• 收集並記錄資料庫的效能指標
• 根據存取模式決定哪一種資料儲存服務
• 根據存取模式與效能指標優化資料儲存服務

我們系統服務的資料庫種類對效能效率有重大影響。 它通常是根據組織預先設定而不是通過data-driven的方法來抉擇範圍。 重要的是還要考量系統服務的“存取模式”，另外也需考量其他非關聯式資料庫方案是否可以更有效地解決問題（例如使用graph、time series或in-memory）。

網路(Network)

由於網路位於所有系統服務的各組件之間，因此它會對系統服務效能和行為產生巨大的正面和負面影響。 還有一些系統服務是高度依賴網絡效能，例如HPC(High Performance Computing)。 我們還必須確定我們的系統服務所需要的bandwidth、latency、jitter和throughput。

在 AWS 中，網路是虛擬化的，並且有多種不同的類型和配置可供使用。 這樣是因為我們可以根據我們需要的網路行為來選擇不同的網路服務。 AWS 提供產品功能（例如，Enhanced Networking、EBS-optimized、S3 transfer acceleration和dynamic CloudFront）來優化網路流量。 AWS 還提供一些其他的網路功能（例如，Route 53 latency routing、VPC endpoints、AWS Direct Connect 和 AWS Global Accelerator）以減少network distance或jitter。

Q5: 我們如何配置我們的網路？
系統服務的最佳網路方案會因latency、throughput requirement、jitter和bandwidth而異。 物理性限制（例如使用者或地端機房）決定了整個系統服務的點位。 這些限制可以通過edge location或resource placement來抵消。

最佳實踐的方式有：

• 理解網路如何影響我們的系統效能
• 評估可用的網路功能
• 選擇合適大小的網路連結方式(如果是混合雲就可能要用VPN或專線)
• 使用ELB且加密端終止在ELB上
• 選擇網路協定來強化網路效能
• 根據網路需求將我們的系統服務與組件放在適切的位置( Region/AZ/place groups/ edge location等等)
• 根據指標優化網路組態設定

部署網路時必須考量到點位。 我們可以選擇將資源放置在靠近終端使用者或其他系統服務的地方。 隨著系統服務的演變，使用網路監控指標變動網路配置。 通過使用Regions、placement groups和edge service，我們可以顯著提高效能。 基於雲端的網路可以快速重建或修改，因此有必要隨著時間的推移不斷進化我們的網路架構來保持網路效能。

效能需要回顧

雲端技術是會迅速演變的，我們必須確保系統服務的各項組件使用最新的技術和方法來不斷提高效能。 我們必須不斷評估對系統服務組件的變動會滿足我們需要的效能和成本目標。 機器學習和人工智慧 (AI) 等新技術也許可以讓我們重新構想客戶體驗並在所有業務系統中進行創新。

Q6: 我們如何改強化每次更版的系統服務？
在建置系統服務時，我們的選項可能是有限的。 但是，隨著時間的推移，我們可以使用提高系統服務效能的新技術和新方法。

最佳實踐的方式有：

• 持續使用最新的資源與服務
• 定義可以強化系統效能的處理流程
• 隨著時間的推移進化系統效能

效能不佳的架構通常不是沒有不然就是有問題的效能回顧流程的結果。 如果我們的架構表現不好，實施效能回顧流程將允許我們應用品質管理大師戴明的PDCA 循環來推動迭代改良。

監控

當我們將系統服務部署到雲端中時，跟地端環境一樣我們需要進行監控，才能在有大問題發生之前進行修復，以免衝擊到組織的業務．監控機制需要能夠在達到特定的閥值時通知我們進行處理，有些閥值可以人為設定也可以是統計出來不斷變動的．

Amazon CloudWatch 是一項監控和具觀測性的服務，為我們提供監控資料和對雲端資源操作的見解(insight)，CloudWatch監控我們的系統服務、回應系統範圍的效能變化、優化資源使用率並能看到維運狀況的一個單一面板資訊。 CloudWatch 用logs、metrics和events的資料型態從 AWS 和地端機房伺服器上運作的系統來收集監控和系統操作資料。 AWS X-Ray 幫助開發人員分析和debug 生產環境、分佈式應用程式。 借由 AWS X-Ray，我們可以深入了解應用程式的執行情況，發現根本原因並確定效能瓶頸。 我們可以利用這些總結資料快速做出回應並保持系統服務是平穩運作的。

Q7: 我們如何監控我們的資源以確保它如我們希望的效能在運作？
系統性能會隨著時間的推移而降低。 監控系統效能以識別效能不足並調整內部或外部因素，例如OS或應用程式的負載。

最佳實踐的方式有：

• 紀錄與效能相關的指標
• 當事件或事故發生時能對指標進行分析
• 訂出量測系統效能的KPI(如API回應的延遲)
• 監控系統能發出告警
• 定期的檢視各種指標
• 主動性的監控與告警

確保我們沒有收到假警報是有效的監控方案關鍵。 自動觸發器可避免人為錯誤，並可減少解決問題所需的修復時間。 我們需要計畫有一個跟生產環境一模一樣環境的問題與災難演練日，來測試我們的告警方案有作用並確保它能正確識別問題。

權衡

當我們要建立解決方案時，需要在各項因素之間取得權衡以確保我們的方法是最適法。 根據我們的現行狀況，我們可能需要在系統的consistency、durability和space換取時間或latency，以提供更高的效能。

用 AWS，我們的系統可以在幾分鐘內部署到全球，並在全球多個位置部署資源，以便更接近我們的客戶。

Q8: 我們如何在各項因素間取得權衡來增進效能？
答案就如上述所示．

最佳實踐的方式有：

• 了解在整個系統服務中哪一部分的效能是最重要的
• 學習設計模式與服務
• 辨識權衡的結果如何影響我們的客戶與系統效能
• 量測效能強化後的成果
• 使用多個與效能相關的策略(如使用cache 或 read-replica來強化資料讀取)

當我們對系統服務進行變更時，我們需要收集和評估指標以確定這些變更的影響。 量測對系統和最終使用者的影響，以理解我們的權衡結果如何影響我們的系統。 使用系統性方式（例如負載測試）來探索權衡的決定是否能提高效能。