雲端資源用量最佳化策略與實踐

– 14 分鐘閱讀

雲端資源的浪費是常見現象，並非總是源於惡意或疏忽。技術團隊常面臨多重任務的壓力，而管理階層不一定會優先投資資源浪費檢測工具。要找出資源浪費，可以關注成本穩定且使用過時資源的區域。長時間未使用的資源很可能可以最佳化。移除或移動閒置資源可以直接降低成本，例如刪除未使用的儲存卷或將資料轉移到低價的冷儲存。調整資源大小需要考量 CPU 使用率、記憶體用量等指標，並在成本文省和服務效能之間取得平衡。設定最小節省金額門檻，可以避免在低價值的調整上浪費時間。

雲端資源使用最佳化：減少浪費與成本最佳化

研究顯示，雲端團隊通常分為兩類別：一類別是真的忘記某些資源的存在，另一類別則是聲稱自己忘記了這些資源。換句話說，資源被遺忘並留在雲端帳戶中是非常常見的現象。當你在公司內部發現類別似情況時，不應直接歸咎於惡意或粗心大意。工程團隊的工作往往面臨多重優先事項的競爭，而長官層並不總是優先考慮用於檢測資源浪費的自動化工具。換言之，這種情況可能發生在任何人身上。

要找出資源浪費，可以關注那些成本非常穩定且使用過時資源的區域。「舊且不變」並不是雲端運算應有的運作方式。如果某個資源長時間未被使用，很可能可以對其進行最佳化。

移除或移動資源以減少使用量

單純告訴團隊不要忘記資源並不能徹底解決問題。有些資源可能是由自動化工具建立的，但當指令刪除資源時，這些工具並未被組態為一併移除相關資源。或者，團隊可能故意將某些資源保留到未來的某個時間點，但隨著優先事項的轉移，這些資源最終被遺忘。此外，有些資源可以在其父資源被刪除後繼續存在，例如掛載到伺服器的磁碟區。當刪除某些資源時，雲端服務提供商可能會自動建立資料快照，這些快照即使在不需要時仍會保留。

對於被遺忘或丟失的資源，團隊可以輕鬆處理。減少使用量的最簡單方法是直接刪除這些資源，從而節省100%的相關成本。

另一個常見的話題是關於保留儲存在某個資源中的資料。通常，團隊根據合規性原因需要長期保留這些資料。即使你需要保留未使用的磁碟區，也可以透過多種方式降低成本。例如，雲端服務提供商提供多種儲存層級，將資料儲存在高價儲存方案中毫無意義，可以將其轉移到低價的「冷儲存」資源，如Azure Archive或AWS Glacier儲存。

程式碼範例：刪除未使用的雲端資源

import boto3

# 初始化 AWS 客戶端
ec2 = boto3.client('ec2')

# 定義刪除未使用的EBS磁碟區的函式
def delete_unused_volumes():
    # 取得所有未使用的EBS磁碟區
    response = ec2.describe_volumes(
        Filters=[
            {'Name': 'status', 'Values': ['available']}
        ]
    )
    
    # 刪除未使用的EBS磁碟區
    for volume in response['Volumes']:
        volume_id = volume['VolumeId']
        ec2.delete_volume(VolumeId=volume_id)
        print(f"Deleted unused EBS volume: {volume_id}")

# 呼叫函式刪除未使用的EBS磁碟區
delete_unused_volumes()

內容解密：

  1. 初始化 AWS 客戶端：使用 boto3 函式庫初始化 AWS 的 EC2 客戶端，以便與 AWS 服務進行互動。
  2. 定義刪除未使用的EBS磁碟區的函式：delete_unused_volumes 函式負責取得並刪除所有未使用的 EBS 磁碟區。
  3. 取得所有未使用的EBS磁碟區：透過 describe_volumes 方法並使用篩選條件 status=available 取得所有未使用的 EBS 磁碟區。
  4. 刪除未使用的EBS磁碟區：遍歷所有未使用的 EBS 磁碟區，並透過 delete_volume 方法刪除它們。
  5. 輸出已刪除的磁碟區ID：在刪除每個 EBS 磁碟區後，輸出其 ID 以便記錄。

調整資源大小以減少使用量（正確調整大小）

要調整資源大小，需要對資源的使用情況有清晰的瞭解，包括CPU使用率、記憶體使用量、網路吞吐量和磁碟利用率。

在進行正確調整大小時，不僅要考慮成本文省，還要確保不會對團隊正在執行的服務產生影響。團隊管理服務的主要目標是確保服務本身不會耗盡所需的運作能力。因此，他們通常會抵制調整資源大小的想法，尤其是對於支援生產應用程式的資源。

如果團隊需要停止手頭的工作來調查調整資源大小的問題，勢必會對交付時間表產生影響。在決定團隊是否應該專注於調整資源大小以降低成本時，應考慮這些影響。通常，只有少數高成本資源能夠帶來顯著的節省，而大量的小型資源所能節省的成本微乎其微。我們建議設定一個截止點（最小節省金額），低於該門檻的正確調整大小建議可以被忽略。這個門檻應該經常檢視，以確保它仍然合理。目標是確保花在正確調整大小上的時間能夠為企業帶來實質性的節省。

圖表示例：資源利用率與調整大小

@startuml
skinparam backgroundColor #FEFEFE
skinparam componentStyle rectangle

title 雲端資源用量最佳化策略與實踐

package "網路架構" {
    package "應用層" {
        component [HTTP/HTTPS] as http
        component [WebSocket] as ws
        component [gRPC] as grpc
    }

    package "傳輸層" {
        component [TCP] as tcp
        component [UDP] as udp
        component [TLS/SSL] as tls
    }

    package "網路層" {
        component [IP] as ip
        component [ICMP] as icmp
        component [路由協議] as routing
    }

    package "鏈路層" {
        component [Ethernet] as eth
        component [WiFi] as wifi
        component [ARP] as arp
    }
}

http --> tcp
ws --> tcp
grpc --> tcp
tcp --> tls : 加密
tls --> ip
udp --> ip
ip --> routing
routing --> eth
routing --> wifi
eth --> arp

@enduml

圖表翻譯： 此圖示展示瞭如何透過監控資源利用率來決定是否需要調整資源大小。如果監控發現資源利用率較低，則會提出調整大小的建議，並實施調整，最後驗證效能與成本是否符合預期。

正確調整雲端資源大小：避免常見錯誤與最佳實踐

在雲端運算的世界中，正確調整資源大小（Rightsizing）是最佳化成本的關鍵步驟。然而，這個過程並不像看起來那麼簡單。許多企業在進行雲端遷移時，常常會犯下一些常見的錯誤，導致無法充分發揮雲端的成本效益。

為什麼正確調整資源大小很重要？

AWS 的產品經理 Rick Ochs 指出，高品質的資源大小調整建議至關重要，可以幫助工程團隊避免花費數小時驗證工作來發現潛在風險，例如帳戶配額、附件限制或 CPU 速度差異。如果提供的建議過於簡單或不準確，可能會導致工程團隊花費更多時間拒絕這些建議，而不是從調整資源大小中獲益。

Benjamin Coles，一位資深軟體開發工程師，分享了他在遷移專案中的經驗。他指出，「提升-轉移」（Lift-and-Shift）模式是一種快速但不完美的方法，可以在不考慮需求的情況下將盡可能多的資源遷移到雲端。這種方法本質上是延遲的技術債務，需要在未來進行調整。

如何正確調整資源大小？

要正確調整資源大小，需要考慮多個因素，而不僅僅是 CPU 平均使用率。Benjamin Coles 建議，在遷移過程中，應盡可能根據應用程式的實際效能需求建立 EC2 例項，而不是簡單地匹配原有的例項規格。這樣可以避免將本地資料中心的過度組態直接帶入雲端。

例如，如果有 100 台系統使用 16 核 x 128 GB RAM 的例項，相當於 c6g.4xlarge，每小時成本為 $0.544，年成本約為 $476K。將例項大小減少一半，使用 c6g.2xlarge，每小時成本為 $0.272，年成本約為 $238K。這樣不僅可以降低營運成本，還可以獲得財務團隊的青睞。

常見的錯誤與解決方案

  1. 僅依賴平均值或峰值：在評估現有工作負載時，不能僅僅依靠平均值或峰值。這可能會導致誤導性的結果。

    • 解決方案：使用更全面的指標，包括 I/O、吞吐量、記憶體使用率等，而不僅僅是 CPU 平均使用率。

  2. 過度組態：在本地資料中心，硬體通常會被過度組態，以避免在應用程式增長時需要重新購買硬體。

    • 解決方案：在雲端遷移時，應根據實際需求組態資源，而不是簡單地複製本地資料中心的組態。

最佳實踐

  • 監控和調整：開啟監控以瞭解應用程式的實際資源使用情況，並根據需要調整例項大小。
  • 逐步最佳化：如果無法立即檢視利用率，可以預設使用較小的例項，並在出現效能問題時再進行調整。
  • 持續審查和最佳化：持續審查和最佳化資源組態，以確保成本效益的最大化。

透過遵循這些最佳實踐和避免常見錯誤，企業可以在雲端運算中實作更有效的成本最佳化，從而提高整體的營運效率和財務效益。

正確調整雲端資源規模的挑戰與對策

在雲端運算的世界中，正確調整資源規模（Rightsizing）是一項重要的任務，但同時也伴隨著許多挑戰。許多企業在進行資源調整時，會遇到一些常見的錯誤，從而導致成本增加或效能下降。以下將探討這些常見錯誤以及對策。

平均使用率的陷阱

僅憑平均使用率來評估資源需求可能會導致錯誤的決策。圖 15-1 展示了兩種不同的 CPU 工作負載：一種在短時間內達到 90% 以上的峰值，然後在剩餘時間內保持在 10% 以下；另一種則持續保持在 20%。如果只看平均值，可能會忽略峰值對資源的影響。

內容解密：

  • 平均使用率不能完全反映實際資源需求。
  • 峰值使用率可能對資源組態產生重大影響。

調整資源規模的誤區

將所有工作負載調整到最大或峰值同樣是一個錯誤。在企業虛擬機器（VM）的典型使用月中，各種活動（如修補程式安裝、維護、佈署和備份）可能會導致 CPU 使用率激增。然而，這並不意味著應該立即升級資源。

內容解密：

  • 峰值使用率不應成為調整資源規模的唯一依據。
  • 應使用百分位數計算等方法來制定合理的調整建議。

超越運算資源的調整

除了運算資源外，其他服務如資料函式庫伺服器和儲存裝置也需要進行調整。忽略這些非運算服務可能會導致潛在的成本文省被忽略。

內容解密：

  • 資料函式庫伺服器（如 RDS、Cloud SQL）和儲存裝置（如 EBS、Persistent Disk）需要被納入調整範圍。
  • 調整這些服務可以帶來顯著的成本文省。

資源形狀的選擇

選擇正確的運算家族和資源形狀對於成本最佳化至關重要。不同的雲端供應商提供不同的運算家族和資源組態，應根據工作負載的需求進行選擇。

內容解密：

  • 不同運算家族具有不同的 CPU、記憶體和其他功能。
  • 選擇合適的資源形狀可以降低成本並提高效能。

效能模擬的重要性

在進行資源調整之前，模擬不同組態對效能的影響是非常重要的。這可以幫助團隊做出更好的決策，避免效能下降或中斷。

圖表翻譯：

圖 15-2 展示了根據平均值進行調整可能導致的效能問題（Clipping）。

處理預留例項的不確定性

過去，團隊可能會擔心調整資源規模會影響預留例項（Reserved Instance）的覆寫範圍和浪費。然而，目前三大雲端供應商都提供了更靈活的選項，可以放心地進行調整。

內容解密：

  • 現有的預留例項選項提供了更大的靈活性。
  • 可以根據使用量的變化調整預留例項。

管理雲端成本：最佳化儲存與網路資源

在雲端運算的世界中，成本管理是一項持續的挑戰。隨著資料量的增長和應用程式的日益複雜，儲存和網路資源的管理變得越來越重要。本文將探討如何透過最佳化儲存和網路資源來降低雲端成本。

移除未使用的區塊儲存卷

區塊儲存的一個主要特點是其資料在計算例項停止後仍然保留。這對於資料保留來說是好的，但如果你為不再需要的儲存空間付費，那就不好了。未使用的卷被稱為未附加或孤立卷，它們的狀態通常被標記為「可用」。這些卷如果沒有附加的計算例項，就無法使用，因此基本上是無用的。刪除這些卷是節省成本的第一步。

刪除未附加捲的步驟

  1. 確認資料是否不再需要：在刪除卷之前，應該檢查該卷最後一次被附加的時間。如果是很久以前，就有很大的可能是不再需要該捲了。
  2. 考慮建立快照：在刪除卷之前，先建立該卷的快照。快照通常比原始卷便宜，因為它們會丟棄空白空間、壓縮資料並儲存在更便宜的儲存層中，如AWS的S3或Google Cloud的Cloud Storage。

最佳化已使用的區塊儲存卷

一旦刪除了未附加的卷，下一步就是檢查已附加但未被使用的卷。這些卷通常出現在相關例項已被關閉但卷未被刪除的情況下。要發現這些卷，可以檢視卷的網路吞吐量和IOPS（每秒輸入/輸出操作次數）。如果在過去10天內沒有任何吞吐量或磁碟操作，很可能該卷未被使用。

重點關注零吞吐量或零IOPS的卷

  • 檢查卷的歷史使用情況，找出未充分利用的磁碟。
  • 將高IOPS保證的卷（如AWS的預組態IOPS卷或Azure的高階磁碟）調整為更低的IOPS，以降低成本。

利用彈性卷

AWS EBS等服務允許在使用的同時增加捲的大小、調整效能或更改卷型別，無需維護視窗或停機。這樣可以避免過度組態儲存，從而節省成本。

物件儲存的最佳實踐

物件儲存服務（如AWS S3、Google Cloud的Cloud Storage和Azure的Blob Storage）通常是存放大多數資料的地方。實施資料保留政策、選擇合適的儲存層/類別對於降低物件儲存成本至關重要。

實施資料保留政策

  • 對資料進行分類別，並根據資料型別選擇合適的儲存類別。
  • 利用雲端服務提供商提供的自動分類別和資料類別選擇功能，如AWS的Intelligent-Tiering。

網路成本最佳化

網路流量不是像雲端計算例項或物件儲存桶那樣的命名資源，因此網路成本容易被忽略。最佳化網路成本需要與管理網路的團隊密切合作。

清理未使用的IP地址

  • 刪除未與執行中的計算例項相關聯的固定IP地址，以減少網路支出。

最佳化網路路由

  • 使用雲端服務提供商提供的網路結構（如AWS VPC端點），以減少應用程式與雲端服務之間的資料傳輸成本。

透過重新設計減少使用量

最複雜的使用量減少方法是重新設計服務本身。透過改變軟體的佈署方式、重寫應用程式或更換軟體，可以利用雲原生服務。

動態擴充套件

  • 根據業務需求動態擴充套件服務，在繁忙時段增加資源，在非繁忙時段減少資源。
  • 需要應用程式本身支援動態擴充套件，這可能需要重新設計應用程式碼。

最佳化雲端使用：用量最佳化的策略與實踐

在現代化的軟體開發中，建構根據服務、鬆耦合、模組化且無狀態的應用程式架構正逐漸取代傳統的單體式應用程式。這種趨勢主要歸因於雲端和容器環境的支援，使得應用程式能夠更有效地擴充套件。未來，將會有越來越多的應用程式具備可擴充套件性。

排程運作與資源管理

許多開發團隊在非工作時間仍保持開發和測試環境的運作。考慮到一個地理位置集中的開發團隊，他們每週僅使用資源40至50小時，而在其餘118小時以上完全閒置。如果能夠在約70%的時間內關閉開發資源，將為組織帶來巨大的成本文約。對於分散式團隊來說，總會有一些時間是大家的週末。

鼓勵工程團隊在非工作時間關閉資源的一種方法是允許他們將節省下來的成本用於新的專案或工程工作，這有助於推動雲端支出管理的文化責任感。

提供自動化的方式來關閉不需要的資源，是確保資源在非工作時間停止的最佳方法。我們將在後續的FinOps生命週期運作階段的討論中進一步探討自動化。

對預留例項的影響

人們常常問：「我們已經購買的預留例項（Reserved Instances, RIs）該怎麼辦？」如果存在承諾性的預留方案，如節省計劃（Savings Plans, SPs）、承諾使用折扣（Committed Use Discounts, CUDs）或預留例項（Reserved Instances, RIs），人們總是擔心使用量的變化會導致預留資源利用不足。通常，人們會先進行使用量最佳化，然後再承諾進行費率最佳化，如RIs或CUDs。

實施使用量減少通常需要比預期更長的時間。幾乎每天我們都會聽到有人說：「我會在清理基礎設施後再進行承諾。」我們的經驗是，10次中有9次，清理工作比預期的要長——通常需要數月——在這段時間內，他們最終還是要為過大的資源支付更高的隨需費率。

程式碼範例：評估預留例項的使用狀況

def analyze_reserved_instances_usage(ri_usage_data):
    """
    分析預留例項的使用狀況，並計算未充分利用的比例。
    
    :param ri_usage_data: 包含預留例項使用資料的字典
    :return: 未充分利用的預留例項比例
    """
    total_reserved = sum(ri_usage_data.values())
    used_reserved = sum(value for value in ri_usage_data.values() if value > 0)
    underutilized_ratio = (total_reserved - used_reserved) / total_reserved
    return underutilized_ratio

# 假設的預留例項使用資料
ri_usage_example = {
    'instance_type_1': 100,
    'instance_type_2': 50,
    'instance_type_3': 0  # 未使用的預留例項
}

underutilized_ratio = analyze_reserved_instances_usage(ri_usage_example)
print(f"未充分利用的預留例項比例：{underutilized_ratio:.2%}")

內容解密：

此程式碼範例展示瞭如何分析預留例項的使用狀況，並計算未充分利用的比例。首先，我們定義了一個函式analyze_reserved_instances_usage，它接收一個包含預留例項使用資料的字典ri_usage_data。然後，我們計算了總預留例項數量和已使用的預留例項數量，並據此計算出未充分利用的比例。最後，我們使用一個假設的預留例項使用資料字典ri_usage_example來演示如何使用這個函式。

使用量最佳化的優先順序

在考慮使用量減少的建議時，必須將可能的節省與工程工作量和對生產服務的風險進行權衡。如果調查和實施變更所需的時間超過節省的金額，那麼可能最好忽略這些建議。理想情況下，您應該過濾掉低價值和/或高風險的建議。

FinOps Foundation的一位成員讓他的團隊以工程小時來評估雲端支出。他們考慮到預期的節省金額相當於多少工程小時。如果他們能夠透過僅使用3個工程小時來捕捉到相當於1000個工程小時的節省，他們就會進行這項工作。如果只能節省5個工程小時，那麼就不太值得做了。

將節省視為工程小時，有助於團隊將所產生的節省視為團隊中新增的一名工程師。節省的工程小時越多，就越有可能獲得額外的員額批准。

我們不建議在未調查變更影響的情況下進行變更。有時團隊會進行變更——或者更糟糕的是，設定自動化以強制調整資源大小——而沒有了解其影響。這可能會導致服務的生產問題。

玄貓 BlackCat

玄貓 BlackCat

技術愛好者，專注於分享程式開發、雲端技術與 AI 應用的心得體會。