AWS 架構最佳實踐概述(十一)

AWS 架構最佳實踐

AWS合理架構的框架支柱

  • 安全性 - 保護並監控系統
    • 能夠保護信息、系統和資產
    • 通過風險評估和緩解策略
  • 可靠性 - 從故障中恢復並減少中斷
    • 從基礎設施或服務故障中恢復
    • 動態獲取計算資源以滿足需求
    • 減少配置錯誤和暫時性網絡問題來減少中斷
  • 績效 - 謹慎使用資源
    • 高效的使用計算資源以滿足系統需求
    • 在需求改變和技術發展時依舊保持效率
  • 成本優化 - 消除不必要的費用
    • 減少不必要的成本和次優資源
  • 卓越操作

合理架構設計原則

  • 停止猜想容量需求 - 傳統環境存在浪費
  • 在生產層面測試系統 - 傳統環境下因爲高昂的測試成本,所以通常都無法真實模擬生產環境進行測試
  • 降低架構改變風險 - 傳統環境中需要排隊等待的測試序列化,在測試過程中的各種改變,可能影響後續測試。
  • 通過自動化讓部署更簡單 - 低成本通過腳本創建並複製系統,追蹤變更和恢復
  • 支持架構的不斷髮展 - 傳統環境受產品生命週期限制,前期決策也可能成爲阻礙,無法響應不斷變化的業務需求
  • 數據驅動型架構 - 在雲環境中,可以通過CloudWatch收集相關數據,來了解架構負載情況。雲基礎架構以代碼的形式存在,因此可以利用這些數據來改善架構。
  • 通過模擬大型流量實現改進 - 通過模擬大型流量,來改進架構中的不足之處,並且積累應對的經驗和方案。

高可用和冗餘

  • 發現當前架構中的單點故障,引入冗餘來消除
  • 選擇最適合的備份和恢復方案最高效的冗餘
  • 使用不同的可用區實現地域高可用
  • 利用Route53和ELB主動切換來實現主動的冗餘機制減少中斷時間

彈性設計

  • 彈性系統是隨時間推移或響應業務需求突然變化以應對增長的負載,隨用戶、流量、數據大小的增長而不會影響性能
  • 資源增長應該引入規模經濟效益,成本應遵循童謠你給的維度從而使該系統創造商業價值
    • 垂直縮放
      • 通過停止實例調整更多的CPU、RAM、IO、網絡等功能實現
      • 垂直縮放有其上限、且不容易實現
    • 水平縮放
    • 無狀態應用程序
    • 所有操作不需要知道過去的上下文,會話也不會被存儲
    • 可以進行任意的水平擴展且可隨意的安全終止,因爲系統資源間不會共享會話數據
    • 所有節點不需要意識到其他節點的存在,只需要處理分配給他的工作量即可
  • Autoscaling是最佳實踐
    • 無狀態組件
      • 大多數應用程序都需要維護某些狀態信息,如登錄信息等。
      • 方案一:
        • 應用程序可以通過用戶會話標識存儲在客戶端本地(如HTTP Cookie)實現一定程度的無狀態, 但是會存在兩個問題:
        • 放在客戶端本地Cookie的信息容易被篡改,每次都需要傳送用戶會話狀態佔用資源增加延遲
      • 方案二:
        • 用戶會話信息存儲在服務器關聯的數據庫中, 如DynamoDB,從而實現服務器組件的無狀態化
    • 有狀態組件
      • 很多應用程序和體系結構都無法轉變成無狀態的
      • 許多遺留系統設置被設計成必須依靠本地單獨計算資源運行的

自動化部署

  • 公有云最大的好處就是能夠利用API來自動化部署過程,建議從一開始就進行自動化部署
  • 自動化和可重複部署將有效的減少錯誤並促使高效的可擴展更新過程
  • Bootstrap 實例
    • 利用自動化動作Bootstrap實例
      • 在初始化過程中用於只是簡單的指定如名稱、角色信息,其他都有腳本自動完成,對不同的選項提供所有必要的自動化啓動資源,包括code、script和configuration等。
    • 重複創建相同環境
    • 對雲基礎架構保持抽象
    • 減少人工部署錯誤機會
    • 創建一個自我發現和自我修復的環境

選擇合適的存儲

  • S3
    • Web需要大規模存儲容量和性能
    • 高耐久性數據,以及支持災難恢復的備份
  • Glacier
    • 數據歸檔和長期備份
  • Cloudfront
    • 利用內容交付網絡在全球邊緣位置部署靜態、動態、流媒體和交互式內容
  • DynamoDB
    • 快速且靈活的NoSQL數據庫,靈活的數據模型和可靠的性能
    • 可以用來解耦有狀態應用,將用戶狀態存儲在DynamoDB中使應用程序可以實現無狀態組件
  • EBS
    • 可靠地塊存儲運行關鍵程序,如Oracle,SAP,Exchange等
  • RDS
    • 高可用的SQL數據庫
  • Redshift
    • PB級數據倉庫,支持業務分析
  • ElasticCache
    • Redis集羣內存緩存
  • EFS (彈性文件系統)
    • 多個EC2實例之間共享應用程序的通用文件系統

AWS 架構最佳實踐概述(十一)

在每一層建立安全

  • 傳統的安全審計是定期和審計的,但是在雲端可以提供持續監控和治理,同事利用代碼將安全策略嵌入基礎設施設計
  • 最佳實踐
    • 對數據進行清點和優先級排序,在傳輸和存儲時應用適當的加密級別
    • AWS功能實現多級防禦
      • 網絡層面: VPC 、 子網、安全組、路由控制
      • 主機層面: WAF、 IAM
    • 將安全交給AWS
      • 使用AWS 託管服務,由AWS進行補丁和安全管理
      • 減少特權訪問
      • 應用程序使用臨時安全令牌在EC2上運行
    • 使用IAM進行賬戶和權限管理
      • 使用臨時令牌提供聯合訪問
      • 對憑據進行自動分發和輪換
      • 授予最小權限的標準安全慣例
    • 利用代碼實現安全
      • 利用CloudFormation腳本進行可靠地安全部署 稱爲"Golden Environment"
      • 最佳安全實踐將會被很容易的在不同環境中重用並且集成到CICD pipeline中
      • 可以利用安全測試自動發現與安全策略基線的偏差
      • CloudFormation 可以作爲產品導入AWS Service Catalog 中進行一致性治理
    • 實時審計
      • AWS實現持續監控和控制自動化,最大限度降低安全風險
      • 藉助Config Rules 可以知道某個組件是否在短時間內不合規
      • CloudWatch提供廣泛的日誌記錄、
      • CloudTrail 實現實際的API調用
      • 所有日誌可以備Lambda、EMR等自動處理

並行化處理思維

  • 雲中可以輕鬆實現並行處理
  • 如檢索和存儲數據時,雲被設計成處理大規模並行操作,所以爲了提高性能和吞吐率,應該儘可能使用並行請求設計
  • Web應用程序,應該設計成支持ELB負載均衡的傳入請求分佈的並行處理
  • 批處理場景下更多的使用擁有多從屬節點的hadoop架構

鬆耦合設計

  • 將系統設計成多個獨立組建的系統體系,組件越鬆散,相互依賴性越低,系統規模就能更大
  • Amazon API Gateway提供了公開定義接口的方法,是完全託管的服務
  • 支持開發人員創建、發佈、維護和監控以及保護各種規模API
  • 可以處理所涉及的數十萬併發的API調用,包括流量管理、授權和訪問控制
  • 異步集成是鬆耦合的常用模式,利用SQS或者Kinesis進行鬆耦合集成
  • 利用異步集成耦合可以引入額外的彈性,可以對處理失敗的消息進行再次處理

AWS最佳實踐

  • 實現擴展架構 - 以應對需求變化
  • 自動部署環境 - 消除手工操作提高系統的穩定性和一致性,並提高組織效率
  • 使用一次性資源 - 將服務器和其他組件視爲臨時資源
  • 鬆耦合組件 - 降低相互依賴,當一個組件變化或出故障時,其他組件不受影響,ELB和SQS是主要解耦解決方案
  • 設計服務而不是設計服務器 - 託管方案和無服務架構讓環境實現更高的可靠性和環境 ,如Lambda, SQS,SNS,DynamoDB
  • 更合適的數據庫解決方案 - 技術與工作負載相匹配,選擇關係型數據庫,NoSQL數據庫,數據倉庫以及針對搜索優化過的數據存儲
  • 避免單點故障 - 實施冗餘以避免單點故障破壞整個系統,可以選擇停機啓動的自動化解決方案或者託管服務在故障時自動對底層進行替換
  • 優化成本 - 確保資源規模適當、可以根據需求進行自動縮減和擴展,充分利用不同的定價方案. 將資本性支出轉變爲可變支出。
  • 使用緩存 - 儘可能減少冗餘數據檢索操作
  • 在各個位置保護基礎設施安全 - 可以在外圍和資源內部或資源之間實現安全性

事件驅動架構

概述

  • 雲計算的優勢就是快速對資源需求方面的變化作出響應,以應對變化。
  • 傳統模式下,即便是在雲計算平臺中,當服務器滿負荷也會導致無法響應訪問,雖然手工擴展只需要幾分鐘時間,但是也是不能接受的

基於事件驅動的架構

  • 監控解決方案CloudWatch
    • 利用CloudWatch監控服務器隊列,通過設置多樣的閾值來觸發擴展,閾值規則設置可以設定到特定的應用程序自定義指標。
  • AutoScaling
    • 通過收到CloudWatch的告警進行實例擴展,在應用服務達到全容量前就準備就緒來提供無縫體驗
    • 垂直擴展
      • 對實例規格進行變化,如CPU、內存等
      • 垂直擴展始終有其天花板,而且可能會存在更多的性能問題, 如Java堆棧過大造成的回收時長,而且可能需要重啓服務器
    • 水平擴展
      • 對實例數量進行變化,添加和刪除實例
      • 幾乎沒有任何能力限制,只是應用程序設計的過程中需要考慮對水平擴展的支持

AWS 架構最佳實踐概述(十一)

  • EC2 Auto Recovery
    • 當EC2出現問題時,對受損的實例自動恢復功能或自動替換
    • 通過CloudWatch 檢測可能因爲網絡連接丟失、系統電源損耗、主機軟硬件問題導致的EC2受損
    • 替換實例是可以保持相同的實例ID,元數據、IP地址,但是內存數據將會丟失
    • 在中國區尚不支持
    • 不能使用實例存儲必須是EBS支持的存儲

Web應用設計

Web應用的業務價值

AWS 架構最佳實踐概述(十一)

基於雲架構的Web託管架構實踐

AWS 架構最佳實踐概述(十一)

  • Route53 提供DNS服務
  • Cloudfront 爲高容量內容提供邊緣緩存
  • 前端ELB將流量分不到Web服務器的AutoScaling組
  • Web服務器安全組 實現外部防火牆的安全策略
  • 後端服務器安全組實現後端防火牆的安全策略
  • 後端ELB將流量分佈到後端應用程序集羣中
  • ElastiCache 爲應用程序提供緩存服務,從而減少數據庫層的負載
  • 通過S3存儲和提供靜態資產
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章