re:Invent 2020: Werner Vogels Keynote
前言
隨著科技的發展,工廠設備需要一直更新才能追上產能需求。如今,科技的趨勢也從以往的中央運算(Central computing)方式,發展成邊緣運算(Edge computing),因此 AWS Snowcone 就是一個很好用的邊緣運算設備。
主要的特色有:
- 小型、輕量:Snowcone 大約長 9 英寸、寬 6 英寸、高 3 英寸,重量為 4.5 磅。具備 2 個 CPU,4GB 內存,8TB 可用容量以及支援 Wi-Fi 或有線網絡。
- 堅固:可承受高溫、低溫的環境,甚至受到撞擊仍可以正常使用,即使碰到水,也不會故障。
- 安全:支援多層次加密,可確保資料在傳輸及儲存上的安全性
- 支援 IoT Greengrass 及部分 EC2 Instance Type:使用者在搬遷資料的過程中,即使使用者所在位置的網路訊號不佳,還可以持續做資料處理的工作。
CloudShell
由於今年疫情關係,迫使許多企業必須做數位轉型,我們必須做出改變才能適應新的環境,像是開發工作不再限制於辦公室內,或其他特定地點。
因此像是 Cloud9 等 Web IDE 服務在今年變得非常熱門。像是哈佛都使用 Cloud 9 來上程式設計相關的課程。
既然 Web IDE 好評如潮,有著不需要安裝開發環境的良好特性,廣受開發者喜愛,AWS 現在推出 AWS CloudShell。讓大家更方便的使用 AWS 提供的 CLI 工具,且不需要收費。
現在開始,大家可以從 AWS Console 上方導覽格看到開啟 CloudShell 的 icon:
按下按鈕等待幾秒鐘時間,即可下達指令操作,它的環境是以 Amazon Linux 2 所建置,你可以在這個環境中儲存 1GB 的資料,要注意的是,僅有在 $HOME
路徑底下的資料會永久儲存,其他位置則是當 Session 關閉後,資料就不會存在。且內建 Python、Node Runtime、Bash、PowerShell、jq、git、ECS CLI、SAM CLI、npm 以及 pip 等工具,使用者還可以在裡面安裝 CDK 或是其他工具,在使用上更加方便哦!
注意:使用這項服務的話,必須要擁有 AWSCloudShellFullAccess 這項權限,倘若超過 20 分鐘以上閒置狀態時,必須要重新整理頁面。
Infrastructure 的重要性
企業在使用雲端時,主要的考量之一是雲端的高可用性,而雲端之所以有高可用性主要要歸功於他的 Infrastructure ,跟這座百年工廠一樣,從電源方面的考量開始。
為了保證服務底下的機器維持在可用的狀況,就要去思考當災難來臨時,如何設計應對災難的適宜方案,從 Infrastructure 基礎建設最底層的電源系統開始,AWS 供電的方式如下:從電力公司取得電能後,經由 UPS 再傳輸到設備。當電力公司發生問題時,AWS 會短暫的利用 UPS 供電,並透過 Switch Gear 將電源切向發電機,達到電源供應的的高可用性。
隨著時代的演進,工廠的設備會慢慢更新,往效能更好、更省錢的方向前進,因此 AWS 也鼓勵使用者慢慢將 CPU 往 ARM-based 的 Graviton2 轉換,因為 Graviton2 對於 Nodejs、Python 及 .net 都做了優化,連 ECS、EKS、CodeBuild 都可以用。
VPC Reachability Analyzer
使用 AWS 服務時,通常最複雜的事就是管理網路,在過去要追蹤測試 VPC 裡面的流量是一件費時又費工的事,需要經過慢慢的除錯才能定義出問題在哪裡,透過 VPC Reachability Analyzer 使用者可以不用發出任何流量,就可以有一個網路服務的流程圖做驗證,是個很好的 troubleshooting 工具。
假設現在要看 VPC Peering 是否互通,選擇在這兩個不同 VPC 內的 Instance 測試,除此之外也可以測試:
- Transit Gateways
- VPN Gateways
- Elastic Network Interfaces (ENIs)
- Internet Gateways
- VPC Endpoint
- VPC Peering Connections
創建完成後,使用者可從顯示在 Console 的分析圖,知道連線是否互通的狀態,而且也能清楚了解到在這中間經過了哪裡流程,大大幫助網路除錯的問題。
Fault Injection Simulator
在以往,要對整個系統進行故障測試時,通常需要耗費很大的成本,也很難驗證結果的正確性,使用 AWS Fault Injection Simulator(即將在 2021 年推出)可以輕鬆進行 Chaos Engineering,透過這項服務,發現系統整體的安全性問題,觀察系統的響應方式並優化、改善整個系統,避免造成嚴重後果。
Netflix 的分享介紹了混亂的工程(Chaos Engineering)技術。這是一個簡單的概念:強迫錯誤發生,所以你可以;
- 防止未來再次發生
- 了解如果發生故障該如何應對
通過這個服務使用者可以更輕鬆的實踐系統的高可用性,不用像以往等到錯誤發生、系統崩潰時才知道哪裡有問題,以利企業打造出更優良的 Application。
Amazon Prometheus & Grafana
Prometheus 是一個能夠幫助使用者輕鬆的監測大量容器化應用程式的開源專案。AWS 推出 Prometheus 的託管服務後,使用者可以不用管理太多的底層架構、調整設定,直接使用 Prometheus 查詢語言(PromQL),來管理 Amazon EKS 和 Amazon ECS 中的容器喔!
Grafana 則是一個著名的開源視覺化工具,可以按照不同需求新增各種套件,收集來自四面八方的資料(例如:來自 Google、Microsoft 雲端的運行指標),在 AWS 推出了 Grafana 託管服務(AMG)後,使用者無需管理 Grafana 的配置、版本升級、安全修補等等跟 workload 無關的瑣事,AMG 還內建了各式各樣的圖表,讓使用者輕鬆的使用 Grafana。
總結
這次 Keynote 的真正意義在於「搞清楚應用程式的趨勢」。
儘管那些新的服務多好玩、多好用,但 Keynote 還是不斷地圍繞在 高可用性 這個議題。Werner 引入並闡述了「可靠性」的概念,以及 builder 關注可靠性的重要性。真正重要的是要 building well。
Keynote 深度探討了很多維運上的細節,但整體而言是 builder 需要考慮實際情況的。
- 預見的(Foreseen)
- 可預見的(Foreseeable)
- 不可預見的(Unforeseeable)
這意味著團隊需要為將要發生的事情、可能發生的事情做好計劃,並準備好在一些不可預知的事情發生時做出反應。
所以在這次 Keynote 中 Werner Vogels 主要點出 4 個達到 building well 關鍵:
Everything fails, all the time
是 Werner Vogels 在過去一直強調的重要概念,無論我們努力地增強 IT 系統及基礎架構,失敗從來都不是「如果」的問題,而是「何時」的問題。有很多企業都認為在基礎設施投入大量成本,讓架構夠穩固,那麼就能一勞永逸,但誰能保證發生故障機率為零呢?
基本上,非常難達到 100% 的可靠度,因為就算在硬體上投資了鉅額的成本,但誰能保證設備永遠不斷電?即使硬體、團隊、流程處理能力再好,偶爾還是會發生錯誤的。我們並不是要傾力去預防故障發生,需要將邏輯顛倒過來!擁抱失敗,而且以「最快恢復」為目標,去處理一切。
Encrypt everything
現今有許多企業開始注重 Defence-in-Depth 概念,去保護自家系統不受任何異常影響,而最好辦法就是 — Encrypt everything,讓其他人無法輕易的擷取你的數據,AWS 幾乎所有服務都內建加密的功能,確保大家能夠對所有內容進行加密。
Operations are forever
在專案一開始選擇開發工具或平台時,要考慮的因素很多,像是要使用哪種語言?每一種語言的特性可能在開發過程中可以減少很多不必要的問題,但最需要在意的地方應該是 可靠度。因為應用程式在運行的時間一定大於開發時間,而且需要長時間維護。所以使用者在挑選解決方案時要加入 Operations are forever 的思維才行。
Monitoring ≠ Observability
當整個系統被拆成許多不同的小服務的時候,以往地端使用 DBG 的偵錯模式,就會有很好的改變。在以前開發者可以透過 DBG 去逐步調試它,並監視程式執行中變數的變化情形,但拆成很多小服務就沒辦法這樣做了。
目前大部分的團隊都著重在監視(Monitoring),但要非常了解整個系統才能達到有效的監控,因為必須知道整個系統的所有運作細節,才能在最關鍵的流程或執行狀態中收集到最有用的資料,而 Observability 是希望整個系統能夠有一些衡量指標來觀測系統整體穩定性。
坐而言,不如起而行!
Now! Go! Build!!!
Keep invent and reInvent. – Andy Jassy