隨著資料驅動應用日益普及，有效管理資料生命週期對於無伺服器應用程式的可持續性至關重要。許多團隊因快速交付功能而忽略閒置資源的清理，導致資源浪費和環境負擔。本文將深入探討如何最佳化資料生命週期，包含刪除未使用的資源、在低能耗時段執行批次工作、選擇合適的資料儲存方式、以及制定資料保留策略。此外，我們也將探討如何透過資料分類別、標記和定期清理來提升資料管理效率，並針對 DynamoDB 和 S3 等服務提供具體的實務建議，最終目標是降低營運成本並提升整體效能。
刪除未使用的服務和資源
未使用的資源被忽略的原因有兩個。首先，許多受管理的服務是按使用付費的，當閒置時不會產生任何成本，因此您不會看到它們對您的每月雲端帳單產生影響。第二個原因是高效能團隊的速度。隨著團隊不斷交付新功能，他們沒有時間審核他們的無伺服器堆積疊和雲端資源，並清除不再需要的資源。
您可能在非生產環境中有更多被遺棄的資源。假設您為一個概念驗證建立了一個DynamoDB表格。由於表格中沒有資料且未使用，因此不會產生任何成本。然而，DynamoDB服務仍然維護著表格的詳細資訊和磁碟空間。將這種情況乘以數量，您就可以衡量其規模和可持續性影響。
在低能耗期間執行批次工作
夜間批次工作通常執行資料整合、工程分析、商業分析、付款結算等任務。在與AWS合作時，請識別雲端區域中的較安靜時段，並在那段時間內安排批次工作。批次工作通常具有可預測的負載，是組態資源的理想選擇。
資料和儲存
資料在現代數字世界中驅動著我們的生活。資料驅動已經成為董事會中的常見術語——資料驅動決策、資料驅動行銷、資料驅動設計、資料驅動文化、資料驅動思維、資料驅動心態等。每當您分享資料時，您都會啟動無數資料操作，透過您所持有的數字裝置。捕捉、儲存和處理資料需要雲端計算、儲存和網路能力，這些資源會消耗能量。由於資料在雲端中傳輸，因此會在環境中留下碳足跡。因此，對於可持續的無伺服器應用程式，思考和關心您的資料至關重要。
在許多組織和團隊中，資料一旦發揮了作用，就常常被忽略和遺忘。除非儲存服務的成本足以對您的每月雲端帳單產生影響，否則工程師對資料會很隨意。
如果您消耗的資料不具有價值或您不需要某些資料，那麼就不要儲存它。
傳播資料保留請求
當您使用分散式事件驅動微服務架構時，資料所有權被隔離到個別微服務中，在應用程式中對齊資料生命週期可能具有挑戰性。如果您比必要時間更長地保留資料，就會違反可持續性原則。如果您刪除它太早，當服務協調執行分散式任務時，失敗很可能會發生。口頭協定、電子郵件、聊天訊息和設計檔案是團隊採用的常見方法，用於傳播資料保留依賴關係。在事件驅動架構中，您可以使用事件傳遞此類別資訊。
圖表翻譯：
graph LR
A[資料產生] --> B[資料儲存]
B --> C[資料處理]
C --> D[資料分析]
D --> E[資料視覺化]
E --> F[資料決策]
圖表展示了資料從產生到決策的整個過程，強調了每個階段對於最終決策的重要性。
資料生命週期
現代數字世界中我們所產生和消耗的資料量遠遠超出了我們的想象。只需想象一下著名的航班追蹤服務Flightradar24，它映射了全球所有正在執行的航班，並在特定時間間隔內顯示每個航班的運動情況。為了提供如此獨特的體驗，它從多個衛星、雷達、航空公司、機場等收集和處理資料。
內容解密：
import pandas as pd
# 載入資料
data = pd.read_csv('data.csv')
# 處理資料
processed_data = data.drop_duplicates()
# 分析資料
analysis = processed_data.groupby('category').sum()
# 視覺化資料
import matplotlib.pyplot as plt
plt.plot(analysis)
plt.show()
程式碼展示瞭如何使用Python對資料進行處理、分析和視覺化，強調了每個階段對於最終決策的重要性。
伺服器無法持續運作的可持續性模式
在資料生命週期中，從建立到銷毀，我們可以在每個階段應用模式和實踐以支援雲端的可持續性。以下幾節提供了一些提示。
選擇合適的資料儲存
選擇適合您資料和存取模式的資料儲存。如第1章所述，有許多型別的資料函式庫可供使用（物件儲存、鍵值、關係、檔案、圖形等）。每種型別都有其目的，根據其適合度選擇正確的資料函式庫是關鍵。透過選擇合適的資料儲存，您可以避免將「方形 peg」放入「圓形孔」的情況。
Amazon S3是一個高效能的物件儲存。它不適合處理結構化資料和執行關係資料函式庫中正常的資料操作。
資料分類別和標記
在設計伺服器無法持續運作的應用程式時，識別資料分類別並指派適當的標記是一種良好的實踐。您可以根據上下文（敏感性、分享性、機密性、耐久性等）以多種方式對企業中的資料進行分類別。如果您根據耐久性對資料進行分類別，例如，您可以為每個類別指派特定的保留期，而不是將所有資料保留相同的時間。可能的分類別包括：
- 暫時快取資料：暫時資料可能包括與Lambda函式相關的短暫資料、API快取、資料函式庫前面的快取、ElastiCache等。
- 短期操作資料：您可能將在處理API請求或對域事件做出反應時儲存的資料分類別為短期資料。這些資料不需要保留超過一定期間，通常是在請求處理完成後。
- 長期和活躍業務資料：這是業務操作的一部分且具有重要價值的資料。這種資料的丟失可能會產生嚴重的後果，例如客戶不滿意、法律問題、監管違規等。
- 可檔案化資料：如其名稱所示，可檔案化資料不需要立即存取，但它具有業務和法律重要性，並且需要長期保留。
刪除不需要的資料
刪除不需要的資料是支援雲端可持續性的基本活動。以下是刪除伺服器無法持續運作應用程式中不需要的資料的一些常見方法：
- 簡單TTL：您可以啟用DynamoDB表格上的TTL功能並為每個專案新增過期時間值。
- TTL與資料轉換：當一個專案被頻繁存取時，它被視為“溫度”高的專案。隨著存取頻率的降低，它變得“涼爽”。最後，它變成可檔案化的資料，可以轉換為低成本的儲存。
- 定期資料清理：您可以組態CloudWatch日誌群組的保留期或設定API Gateway的快取過期時間。
內容解密：
以上內容強調了在伺服器無法持續運作應用程式中實作可持續性的重要性。透過選擇合適的資料儲存、分類別和標記資料、刪除不需要的資料，可以減少雲端營運的環境影響，同時也能夠節省成本和提高效率。
graph LR
A[選擇合適的資料儲存] -->|選擇正確的資料函式庫|> B[分類別和標記資料]
B -->|根據上下文分類別|> C[刪除不需要的資料]
C -->|啟用TTL功能|> D[定期資料清理]
圖表翻譯：
此圖表展示了在伺服器無法持續運作應用程式中實作可持續性的步驟。首先，選擇合適的資料儲存以確保正確的資料函式庫被使用。接下來，分類別和標記資料以根據上下文進行分類別。最後，刪除不需要的資料透過啟用TTL功能和定期資料清理。
資料儲存與清除的可持續性策略
當資料儲存系統無法提供自動資料清除功能，或者由於某些原因無法使用時，定期的資料清理活動就變得非常重要。您可以使用 EventBridge Scheduler 來組態一次性或定期的資料清除任務，分別對應單次或一系列的清理動作。
資料過渡政策和儲存選擇
正如前一節所述（在「TTL 與資料過渡」中），將冷資料轉移到存取次數較少、成本較低的儲存型別對於可持續性和成本控制至關重要。例如，一個電子商務應用可能會在某個時間後將已退役的產品資料轉移到冷儲存中。之前提到的資料分類別為大多數資料過渡動作提供了基礎。
S3 儲存生命週期政策
S3 儲存生命週期政策易於組態且運作高效。減少大量資料移動是另一項重要的可持續性措施。資料傳輸在不同應用、服務、業務領域或區域之間或跨越其他邊界時會不斷發生，但有方法可以限制昂貴的資料移動以支援雲端可持續性。例如：
- 您可能不需要將 DynamoDB 表中的資料複製到其他 AWS 區域作為全域政策。識別哪些表可以從全域啟用中受益，並僅對這些表啟用此選項。
- 檢查是否已啟用複製（全域表選項）的 DynamoDB 表是更新密集型表。如果是，請始終使用正確的資料模式來限制對大型資料集的更新。
- 定期審查您的資料複製政策並審核您的資料儲存（S3、DynamoDB 等）。
從系統資源利用效率和成本效益角度來看，有效管理閒置資源和資料生命週期對於無伺服器應用程式的可持續性至關重要。本文深入探討了從資料儲存策略到批次工作排程等多個層面的最佳實務，並特別強調了資料分類別、標記和過渡策略的重要性。分析顯示，僅僅依賴按使用付費的服務模式並不足以確保最佳資源利用，主動的資源清理和資料生命週期管理才是降低環境影響和成本的關鍵。技術團隊應著重於建立自動化的資源管理機制，例如利用 EventBridge Scheduler 定期清理資料，並結合 S3 儲存生命週期策略等工具，才能最大程度地提升無伺服器應用程式的可持續性。未來，預計更多精細化的資料生命週期管理工具和服務將會出現，進一步簡化開發者的工作流程，並推動更廣泛的可持續性實踐。玄貓認為，將可持續性融入無伺服器應用程式的設計和維運，不僅是降低成本的有效途徑，更是企業履行社會責任的重要體現。
