AWS各項服務的優化與節費

運用"雲端服務"加速企業的數位轉型願景

9 min readMar 8, 2024

本文中我們將討論當我們的環境已經在AWS中運作，並且開始大都是Cloud-native服務時。對於這些使用中的服務，我們有哪些優化其使用的效率進而導致成本節費呢。以下是即將討論的重點:

使用AWS Auto Scaling來效率極大化
分析(Analytics)優化
機器學習的優化

使用AWS Auto Scaling來效率極大化

這應該是學習或使用過AWS的人一開始認識的概念。因為這種機制是效率優化的體現 — 只在需要時開啟需要的資源，用完後就關閉。本文中還是需要再次定義甚麼是Auto scaling，之後介紹幾種auto scaling的使用策略與政策。

什麼是Auto Scaling?

從企業的角度來看，準確的預測未來業務量是極其困難的任務。所以預估出來的數字通常是一種樂況的數字。而作為IT單位就會用這種樂觀數字來預估所需要的IT資源，有時可以還要保護自己不會因為未來三到五年不會因為IT資源不夠用被罵就再加碼一些。

不幸的是這樣的與預估通常都錯得離譜，因為沒有人可以預見未來到底是甚麼樣態。而這樣的確認偏誤就造成企業的資源浪費，也是一種機會成本的浪費。

因應這種狀況，我們應該當只有需要IT資源時才使用它。AWS Auto Scaling是一種當我們的系統需要其底層資源(CPU/Memory/Storage)時才會提供。有這一類功能的AWS服務如，EC2 instance/spot fleets，ECS，DynamoDB，Aurora。

AWS Auto Scaling VS. EC2 Auto Scaling

這兩個不同之處在於，前者控制多個服務的Auto Scaling，後者只專注於EC2。EC2的Auto Scaling提供比AWS Auto Scaling更多的控制細項。

EC2提供以下三種的Scaling:

手動的

自動的
排程式 (scheduled)— 例如知道在未來某個時間會需要資源的

自動的
動態式(Dynamic): 這細分為以下兩種

Simple scaling
使用CloudWatch中的CPU指標來決定scale out/in，例如CPU平均只要超過80%就加Instance，低於70%就減instance。但這只考慮一個指標來決定，但我們知道影響系統效能的因素其實很多。
Step scaling
這個方式可以給我們更多的控制細項。這是以條件式的方式來決定要不要scale out/in。例如CPU使用率介於60–70%，就加10%的運算力，如果高於70%就加40%的運算力這兩種條件。

以上都是使用CloudWatch的指標來決定Scale in/out。但還有另一種宣告式，AWS稱為target tracking的方式來決定scale in/out。例如我們希望整個EC2 fleet總體平均的target tracking維持在60%。哪Auto Scaling就會幫我們維持在這一個數字。當然，我們可以不只使用CPU作為唯一指標。Memory、Storage、Network latency等都可以作為Auto Scaling的指標。

AWS Auto Scaling

AWS在許多託管服務中提供了Auto Scaling的功能(如上述的AWS服務)。AWS Auto Scaling就是把這一些服務的Auto Scaling機制的聚合起來，在同一個介面上設定這些資源的Auto Scaling。

目前該服務只支援target-tracking scaling policies。此種方式較適合KPI式的資源管理方法(維持在一個工作目標水準)，也很直覺。

而該服務也是AIop(懶人管理法)的一種，因為它利用了機器學習的方式來預測之後的資源需求大概需要增減多少。這至少需要14天的歷史資料，ML模型才可以開始運作(預估未來兩天的需求)。

分析(Analytics)優化

在資訊爆炸的時代，資料分析需要大量的IT基礎設施資源。所以如何在這一議題上進行成本優化呢?資料分析有幾個以下步驟，我們需要針對以下步驟個別進行優化:

Data Ingestion
Data Exploration
Model Training
Model Deployment

針對資料的使用模式(Hot/Warm/Cold)，我們需要知道資料該儲存在S3或其他SQL or NoSQL的儲存點。並且根據AWS提供的服務進行聯合式查詢分析。另外如果儲存大量的歸檔或歷史資料，我們可以對其資料進行壓縮與選用正確的檔案格式，這樣可以加速分析與節省儲存費用。像是用Parquet這一類的columar format，而不是用CSV這一類的檔案格式。

如果是單次性且不是常態的資料分析，哪麼我們可以用S3 + Athena。如果是經常性且穩定的分析需求，哪麼我們可以使用Redshift(加RI)。對Redhsift有爆發性的臨時分析需求，哪我們也可以使用Redshift的 concurrency scaling功能(一種Auto Scaling)，例如月報的產出。如果我們啟用此功能，Redshift會加上額外cluster來增加read query的能力。由於是把分析作業在不同的Redshift進行分流，這時需要開啟WLM(Workload Manage)的Queue中。

機器學習的優化

一個ML的workflow通常會需要進行資料探索(data exploration)與特徵工程(Feature engineering)。在這一節，我們將討論AWS SageMaker(End-to-End ML Workflos)的成本優化，特是在model training 與model deployment。

所謂的model training是指演算法需要尋找資料的模式(patterns)與學習如何歸納(generalize)其資料模式。隨後可以對未來的新資料進行預測(Prediction)。

優化model training與tuning

我們一開始當然可以使用較小的insatnce來進行ML的作業。但是，較小的instance可能會讓我們遇到一些錯誤，例如OOM(Out-of-memory)之類的問題。所以選擇大一點的instance進行分析通常會比較好，因為SageMaker會幫我們依據需求動態的增加或減少Instance數量。然而就算選擇大一點的Instance有時training job還是會一直在跑，這時我們就需要SageMaker Debugger來協除我們看作業卡在哪裡，以免機器一直開著浪費錢。

例如，在神經網路 (NN) 上訓練深度學習 (DL) 模型通常涉及調整每次訓練運行（epoch）的權重並觀察生成的模型指標。神經網路會調整權重以查看這些變化是否對模型產生正面影響。然而，可能會出現調整權重並不能產生更好結果的情況。如果不斷執行模型調整作業，但每次迭代都沒有優化模型，那麼執行這些資源就是浪費。最好儘早停止工作以減少不必要的迭代。提前停止有助於減少 SageMaker 訓練時間，這與減少浪費有關。

又或者我們可以用spot instance來訓練模型，如以下範例的代碼

use_spot_instance=True.
Model = sagemaker.estimator.Estimator(
container,
role,
train_instance_count=1,
train_instance_type='ml.m4.8xlarge,
use_spot_instance=True,
max_wait = 180,
sagemaker_session=sess)

由於Spot insatnce可能會在訓練作業完成之前被終止，因此使用 max_wait 參數將指示 SageMaker 等待一定秒數（在本例中為 180秒），以便新的spot instance取代已終止的。一旦超過 max_wait 時間，作業就會完成。如果使用checkpoint，訓練作業將從spot instance終止時的最新檢查點開始。

另外一種費用節費的方式就是在訓練作業進行時如何將資料載入SageMaker。一種是File mode(完全載入)，另一種是Pipe mode(串流的方式)。File mode適合大檔案(大於10GB)，Pipe mode是將資料從S3中平行串流到SageMaker之中，但這需要High I/O。streaming的方式讓我們不用等待資料的完全載入，及早進行訓練作業。

優化model deployment

一旦我們搞定了模型，接下還來就是佈署了。在SageMaker中就是將模型佈署成SageMaker endpoints(HTTPS)。這種付費是基於Instance type與使用小時數，也就是用量維度加上時間維度的計費方式。

ML模型其實跟代碼開發一樣也是會有分環境的，我們應該在不需要時關閉非Production環境的所有SageMaker endpoints。而這一點Cloud Watch可以協助我們，CloudWatch可以告知我們在Endpoints沒有收到任何流量時發出通知。例如使用"Invocation"這一個指標，進行一段時間的加總為零(Sum)後通發相關通知。

有時我們在訓練大量的資料集會需要借助GPU來協助，但是我們一開始無法預估到底要用多大的GPU資源才能進行相關作業。太小可能於事無補，太大可以有資源浪費。所以我們可以在Instance上掛載EIA(Elastic Inference Accelerator)，這可以將GPU資源動態的掛載與卸除。例如以下範例

predictor = model.deploy(
initial_instance_count=3,
instance_type='ml.m4.2xlarge',
accelerator_type='ml.eia2.medium')

另外SageMaker也有跟EC2一樣的Savings Plans方案。