【每周快報】0409-0415 AWS 服務更新
前言
AWS 在三月初推出了針對製造工業進行瑕疵檢測的 Amazon Lookout for Vision,在上周又另外新增了預測性維護服務 – Amazon Lookout for Equipment,透過機器學習讓使用者可以針對振動頻率、聲音、溫度等資訊進行預測。機器學習領域外,AWS 也對大數據服務做了改動,像是 Amazon Redshift 新增支援當 producer clusters 暫停時,資料能夠繼續被使用的功能,而 Amazon Athena 則推出 Query execution plans 功能幫助使用者改善查詢效能。
本篇文章也將分享 AWS Step Functions、eksctl、Amazon EC2 Auto Scaling…等各項服務的新功能與支援。
焦點新聞
Amazon Lookout for Equipment 正式推出,協助企業進行預測性維護
製造業為了提高生產效率,降低機台故障而導致的意外停機風險,大多數企業會選擇儲存 Sensor 所收集到的資料,並建立 Dashboard,監視其設備狀況並獲得即時警報。
以傳統的統計方法來預測硬體設備是否該維修已無法滿足企業對於準確度的需求,所以 AWS 針對製造業新增了預測性維護服務,以機器學習為基礎,使用者可以針對振動頻率、聲音、溫度等資訊進行預測。
倘若使用者有使用過 Amazon Personalize 或者 Amazon Forecast 的話,進入主控台後會發現非常眼熟,主要有四個步驟:
- 創建資料集:使用者得在此步驟中 設定好資料集的格式(Schema) 以利 Lookout for Equipment 擷取。
- 擷取資料集:設定好資料集來源位置(S3 bucket),並給予 Lookout for Equipment 擷取此 S3 bucket 的權限(IAM Role)。
使用者得確定存放於 S3 中的資料集格式與第一步驟中所設定的格式相同,否則會有錯誤發生。
- 訓練瑕疵檢測模型:當擷取完成後,便可開始訓練模型,Lookout for Equipment 會先提供使用者它所擷取出來的資料欄位,使用者也可選擇哪些欄位要作為訓練資料進入後續訓練動作。
不選擇的話 Lookout for Equipment 會自動針對這資料進行選擇與訓練。
- 當使用者按下訓練模型後,訓練時間會持續大概一個小時,具體時間會取決於資料集的大小。訓練完成後,使用者可以使用評估期數據來評估模型。
- 訓練完成後,接下來當然就是要進行推論囉!選擇輸入資料的位置(可以透過 API 或 Console 操作),並決定好推論結果的存放位置就可以囉~
參考來源至:Detect abnormal equipment behavior with Amazon Lookout for Equipment — now generally available
其他服務更新
AWS Step Functions 新增 Data Flow Simulator
隨著使用者的微服務架構日漸複雜,Lambda 的使用場景也越來越多,像有些使用者會想將多個 lambda 有順序的串連在一起,或者 Lambda 發生錯誤時能自動 Retry 等,這些情況下,原生的 lambda 很難達成。
因此 AWS Step Functions 變成為了上述問題的最佳解決方案,使用者可以透過 JSON-based 的語言(Amazon State Lamguage)來定義 State Machine,讓多個 Lambda 之間的互動更為協調。
為了因應流程的複雜性,Step Functions 有提供許多語法來讓使用者擷取、合併與輸出每個 State 所傳入、傳出的值(例如:InputPath
、ResultPath
、ResultSelector
等語法),這些語法雖好用,但實際上在測試時卻很難驗證,需要實際跑過 Step Functions 然後檢查每個 State 的 Input/Output 才有辦法確定語法是否正確。
此次更新後,Step Functions 推出了 Data Flow Simulator,這個工具大幅改善了整個 Step Functions 在輸入輸出值測試的流程。
使用者可以完整的從 State Input
經過 InputPath
一直到 State Output
去設定整個值的傳遞。
如上圖中,最原始的State Input
為左方的 JSON(可以看到裡面有 version
、library
、metadata
等參數),當使用者只想在下一個 State 傳入 library
中的 movies
參數的話,他可以在這邊先檢查 $.libary.movies(圖中最上方)
作為 Inputpath
所傳入的結果(右方 JSON)。
透過這個方式,使用者可以很清楚的測試整個資料在傳遞過程中的刪減與設定,省去了許多測試上的麻煩。
參考來源至:AWS Step Functions adds new data flow simulator for modelling input and output processing
eksctl 新增支援透過資源量來創建 nodegroup
eksctl
是 Amazon EKS 原生的 CLI 工具,以往 eksctl
就有語法能夠指定 Managed Nodegroup 和 Self-managed Nodegroup 的 Instance Type,但目前有超過 270 種 EC2 Instance Type 可供使用者選擇,這導致使用者必須花時間確定哪種 Instance 比較適合作為使用者工作負載的 nodegroup,尤其是在取用 Spot Instance 的時候(因為還需要選擇一組與Cluster Autoscaler 配合使用的 Instance)。
此次更新後,eksctl
與 EC2 Instance selector 整合,讓使用者可以直接透過 eksctl
給予欲取用的 vCPU、memory 量來得到相對應的 Instance Type 推薦。
EC2 Instance Selector 是一組 CLI 和 Go library,讓使用者可以透過 vCPU、memory 來獲得 Instance Type 推薦並創建 nodegroup。
參考來源至:eksctl now supports creating node groups using resource specifications and dry run mode
Amazon EC2 Auto Scaling 新增加速擴展的功能
當使用 EC2 Auto Scaling 長機器時,假設 Instance 需要大量寫入資料到 EBS volume ,此時初始化就會花比較多的時間,可能沒有辦法即時處理突如其來的流量,而產生延遲的狀況。在這次的更新,EC2 Auto Scaling 新增了 Warm Pool 的功能,藉由它就可以解決初始化機器延遲的問題喔!
其實就是事先做暖機的動作!現在你可以從 EC2 Auto Scaling 的控制台上,選取你想設定的 Auto Scaling,在 Instance Management 選項下,找到 Warm Pool 的功能。
使用者可以選擇創建 Stopped 或 Running 狀態的 Instance,設定在 Warm Pool 下的 Instance 最小數量及最大數量。
可以根據業務所需,彈性調整 Warm Pool 設定,如果選擇創建 Stopped 狀態的 Instance 還可以減少花費!
參考來源至:Amazon EC2 Auto Scaling introduces Warm Pools to accelerate scale out while saving money
Amazon Athena 推出 Query execution plans 功能
當透過 Athena 查詢資料時,對於較龐大、複雜資料集,常常可能會耗費大量的時間及效能在查詢資料,要如何去改善這件事呢?此次更新後,Amazon Athena 提供 EXPLAIN 語法可用在分析 JOIN 順序及類型、驗證 Partition Pruning⋯等用途,幫助使用者改善查詢效能。
現在開始,當使用者在執行 Query 時可以加上 EXPLAIN 語法,例如以下查詢。
EXPLAIN
SELECT
request_timestamp,
elb_name,
request_ip
FROM sampledb.elb_logs;
在預設狀況下,結果會以 Text 的方式輸出。
- Output[request_timestamp, elb_name, request_ip] => [[request_timestamp, elb_name, request_ip]]
- RemoteExchange[GATHER] => [[request_timestamp, elb_name, request_ip]]
- TableScan[awsdatacatalog:HiveTableHandle{schemaName=sampledb, tableName=elb_logs,
analyzePartitionValues=Optional.empty}] => [[request_timestamp, elb_name, request_ip]]
LAYOUT: sampledb.elb_logs
request_ip := request_ip:string:2:REGULAR
request_timestamp := request_timestamp:string:0:REGULAR
elb_name := elb_name:string:1:REGULAR
使用者可以選擇 GRAPHVIZ
或是 JSON
的方式輸出,只要在 EXPLAIN 語法中指定格式即可。
參考來源至:Amazon Athena now presents query execution plans to aid tuning 參考來源至:Using the EXPLAIN Statement in Athena
Amazon CloudWatch Lambda Insights 新增支援 AWS Lambda Container Images
以往使用者可透過 CloudWatch 監控 Lambda function 運作的狀態,包括 function 執行期間 CPU 及 memory 使用狀況,或是連線上的問題,可幫助使用者偵錯。
此次更新後,CloudWatch Lambda Insights 新增支援 Lambda Container Images。開始使用之前,使用者需要將以下的指令,加入 Dockerfile,讓打包出來的 container image 包含 Lambda Insights agent,才能夠在 container image 運行成 Lambda function 時,可以與 CloudWatch 溝通。
RUN curl -O https://lambda-insights-extension.s3-ap-northeast-1.amazonaws.com/amazon_linux/lambda-insights-extension.rpm && \
rpm -U lambda-insights-extension.rpm && \
rm -f lambda-insights-extension.rpm
當運行成 Lambda function 後,還需要給
CloudWatchLambdaInsightsExecutionRolePolicy
的權限。參考來源至:Amazon CloudWatch Lambda Insights Now Supports AWS Lambda Container Images (General Availability)
AWS Backup 現在支援跨帳戶、跨 Region 備份 Amazon FSx 共享檔案系統裡的資料
AWS Backup 是一項可幫助使用者集中管理各項 AWS 服務備份機制的服務。此次更新後,使用者可透過 AWS Backup 建立跨 Region 的 Amazon FSx 備份計畫,以保護應用程式在不同 Region 的資料一致性;或者跨帳戶複製資料,以滿足合規性需求。
在啟用此功能之前,來源端與目標端的 FSx 檔案系統,需要先以 VPC Peering 或是 Transit Gateway 建立其 VPC 之間的連線。如附圖:
圖片來源至:Cross-region and cross-account backups for Amazon FSx using AWS Backup
Amazon Redshift 支援當 producer clusters 暫停時資料能夠繼續被使用
Amazon Redshift Sharing 功能最少會有 2 個腳色 producer cluster 跟 consumer cluster,當使用者將資料 ingest 進入 producer 時,會自動將那些資料同步到一個或多個 consumer,使用者就可以從 consumer 撈取資料,減少 producer 的工作負載。
這次改版後,使用者可以視情況要求,在沒有需要 producer 時關掉或暫停 producer 以節省開支,並在 producer 關閉期間也可利用 consumer 來撈取資料。就是 Amazon Redshift 的 read replica 拉。
參考來源至:Amazon Redshift now supports data sharing when producer clusters are paused