Amazon DOP-C02: 事件驅動架構與自動化 — 學習指南

By Laurynas Brazys · 4 August 2026 · #amazon #dop-c02 #certification #exam-prep #study-guide

屬於 AWS DevOps Engineer Professional DOP-C02 — 學習指南. 使用經過驗證的解答練習： Amazon 考試中心, 或參加限時模擬考試： ExamRoll.io.

總覽

事件驅動架構將生產者與消費者解耦，強調非同步通訊，並使系統對流量高峰和故障具有彈性。其核心原則是透過事件/訊息實現鬆散耦合、由消費者驅動的擴展、冪等處理器，以及明確的故障處理和可觀測性。AWS 提供了用於持久性佇列、發布/訂閱 (pub/sub)、事件匯流排、串流處理、協同運作和維運自動化的建構模塊。精通 Amazon SQS、Amazon SNS、Amazon EventBridge、AWS Step Functions、Lambda 事件來源映射、AWS Systems Manager Automation 和 OpsCenter，以及 Kinesis Data Streams 和 Firehose 之間的交互作用，能讓您建構出可擴展、容錯且可稽核的自動化和資料管道。

訊息傳遞與擷取：SQS、SNS、Kinesis 和 Firehose

Amazon SQS 提供持久且可擴展的佇列以實現解耦。標準佇列提供至少一次交付和盡力排序，並具有幾乎無限的吞吐量；它們適用於那些能透過冪等性金鑰和條件式寫入來容忍重複和亂序訊息的平行工作者。FIFO 佇列則強制執行每個訊息群組的有序交付和僅一次處理語意，並具備重複資料刪除功能 (在五分鐘的視窗期內)。它們保證順序和單一處理，但犧牲了絕對吞吐量：可在 FIFO 內使用多個訊息群組來平行化，或啟用高吞吐量 FIFO 以達到每秒數千則訊息。設定每個佇列或每則訊息的可見性逾時，使其超過最大處理時間；對於 Lambda 消費者，將可見性逾時設定為您函數逾時的至少六倍，以允許在訊息重新出現前進行重試。使用長輪詢來減少空接收。當訊息超過 maxReceiveCount 時，無法處理信件佇列 (DLQ) 會捕獲有問題的訊息 (poison messages)；之後可將訊息從 DLQ 重新驅動回來源佇列，以便在修正後重新處理。監控 ApproximateAgeOfOldestMessage 來偵測積壓情況，並驅動並行/自動擴展的變更。

Amazon SNS 提供受管、高吞吐量的發布/訂閱 (pub/sub) 服務。發布者只需向一個主題推送一次；SNS 就會將訊息分發 (fan-out) 到多個訂閱 (SQS、Lambda、HTTP/S、電子郵件、行動裝置)。訂閱篩選政策使用訊息屬性，僅將相關的通知路由給每個訂閱者，從而減少下游的成本和負載；可表達如精確匹配、前綴、數值範圍、非…即是 (anything-but) 和存在 (exists) 等述詞。使用 SNS 進行分發 (fan-out)、解耦的通知和行動推播。啟用重試機制，並考慮為無法交付的訊息設定每個訂閱的 DLQ。對於需要有序分發的需求，SNS FIFO 主題搭配 FIFO SQS 訂閱可強制執行排序和重複資料刪除。

Kinesis Data Streams 提供有序、低延遲的串流，具備分片層級的平行處理能力，適用於即時分析和事件處理。生產者使用分割區索引鍵將記錄寫入分片；消費者 (Lambda、KCL、Enhanced Fan-Out 消費者、Kinesis Data Analytics) 則透過檢查點機制，按分片順序讀取記錄。對於不可預測的負載，可使用隨選容量；對於可預測的吞吐量，則使用帶有重新分片功能的預置分片。調整分割區索引鍵以平衡熱分片，並監控 IteratorAge 來追蹤消費者延遲。Enhanced Fan-Out 提供每個消費者串流專屬的 2 MB/s 吞吐量，並透過 HTTP/2 進行低延遲推送。

Kinesis Data Firehose 是一項全受管的交付服務，用於將資料近乎即時地擷取到 S3、Amazon OpenSearch Service、Splunk 或 HTTP 端點，並提供可選的 Lambda 轉換、緩衝 (依大小/時間)、壓縮和加密功能。其資料來源可為直接的 PutRecord/PutRecordBatch 呼叫、Kinesis Data Streams 或 CloudWatch Logs/Events 訂閱。當您需要具有轉換和批次處理功能的受管交付，且不想自行建構和操作消費者程式碼時，請使用 Firehose。動態分割功能讓您能根據索引鍵將記錄路由到不同的 S3 前綴，以實現高效率的下游處理。

路由、協調與排程：EventBridge 與 Step Functions

Amazon EventBridge 是用於路由、治理及跨帳戶/事件網域整合的中央事件匯流排。使用預設匯流排處理 AWS 服務事件，使用自訂匯流排來區隔網域並應用權限，並使用合作夥伴匯流排進行 SaaS 整合。規則透過基於內容的模式來匹配事件，並可將事件傳送至 200 多種 AWS 服務作為目標。使用輸入轉換器來塑造酬載 (payload)，並利用封存/重播功能在復原或新消費者上線時重新處理歷史事件。資源政策允許跨帳戶的事件路由，以便將治理合併到一個平台帳戶中。EventBridge Pipes 提供點對點、可設定的流程，從事件來源 (SQS、Kinesis、DynamoDB Streams、在 Amazon MSK 上自行管理的 Apache Kafka 等) 到目標，並內建篩選、批次處理、轉換，以及透過 Lambda 或 Step Functions 進行擴充的功能——當您不想管理一個完整的消費者應用程式，但需要輕量級的中介處理時，這是理想的選擇。EventBridge Scheduler 提供一次性與 cron 排程，以執行角色來叫用目標，並支援時區及可選的彈性時間視窗，以減少「驚群效應」(thundering herds)。

AWS Step Functions 使用 Amazon States Language 定義的分散式工作流程進行協調，其狀態包括 Task、Choice、Parallel、Map (包含 distributed Map)、Wait、Pass、Succeed/Fail，以及強大的 Retry/Catch 模式。深度的服務整合消除了呼叫 AWS API 所需的膠水程式碼 (glue code)，包括同步 (.sync) 和帶有任務權杖 (task token) 的回呼 (callback) 模式。選擇標準工作流程 (Standard Workflows) 來處理長時間執行、需要大量稽核的協調，它提供僅有一次的狀態推進、長達一年的執行時間，並按狀態轉換計價；執行歷史會被保留，具有高可視性及內建的 X-Ray 追蹤。選擇高速工作流程 (Express Workflows) 來處理高吞吐量、短生命週期的協調 (秒級到分鐘級)，您可以透過按請求+執行時間計價和至少執行一次的語意來換取大規模擴展；適用於串流擷取擴充、事件路由器，以及您可以讓任務具備冪等性 (idempotent) 的微協調。應用如帶有補償任務的 saga 模式和集中式錯誤處理等設計模式；將重試/逾時外部化到狀態機中，以簡化任務程式碼。

運算觸發與背壓：Lambda 事件來源映射

Lambda 事件來源映射 (Event Source Mappings, ESMs) 將輪詢式來源連接到 Lambda，並控制並行、批次處理與錯誤處理。

SQS：Lambda 透過輪詢佇列來水平擴展，並以批次方式 (最多 10 則訊息；最大批次處理視窗可達 300 秒) 叫用您的函式。對於標準佇列，擴展會隨著佇列深度和訊息吞吐量而變得非常積極；對於 FIFO 佇列，Lambda 會維持每個訊息群組的順序，並一次處理一個群組的一批次。在 ESM 上設定最大並行數，以限制 worker 的擴展規模並保護下游系統；結合預留/預置並行來保證容量。使用部分批次回應功能，只確認成功的紀錄並將失敗的紀錄重新排入佇列，以避免重播整個批次。將佇列的可見性逾時設定為超過最壞情況下的總重試時間。DLQ (無效信件佇列) 和重送政策可用於隔離有問題的訊息 (poison messages)。
Kinesis Data Streams：預設每個分區 (shard) 一個並行的 Lambda 叫用，以確保每個分區內的順序。當跨子序列的順序可以不一致時，可將 ParallelizationFactor 增加至 10，以便在每個分區內並行處理多個批次。批次大小最多 10,000 筆紀錄 (6 MB)，最大批次處理視窗可達 5 分鐘，讓您能攤提成本並增加吞吐量。在函式錯誤時使用二分搜尋 (bisect on function error) 來找出批次中的錯誤紀錄，並使用失敗時的目的地或最大重試次數/紀錄存留時間來丟棄或路由無法處理的紀錄。監控 IteratorAge 來偵測消費者延遲，並相應地重新分區或增加並行化。
DynamoDB Streams：在語意上與 Kinesis 相似；批次大小最多 1,000 筆紀錄 (6 MB)，並採用每個分割區索引鍵一個分區的模型。消費者會收到有序的項目層級變動 (INSERT, MODIFY, REMOVE)。應用相同的失敗處理方式 (錯誤時二分搜尋、最大重試次數、紀錄存留時間) 和篩選。使用包含您消費者所需屬性的串流檢視類型 (NewImage, OldImage, NewAndOldImages, 或 KeysOnly) 來優化酬載大小。

ESM 中的事件篩選功能會在輪詢器層級丟棄不相關的事件，以減少叫用次數。在串流上使用輪轉視窗彙總 (tumbling window aggregation) 搭配 Lambda，可隨時間彙總紀錄，以實現小批次處理模式。

操作自動化與修復：Systems Manager Automation 與 OpsCenter

AWS Systems Manager Automation 提供以 JSON/YAML 編寫的 runbook (類型為 Automation 的文件)，其中包含諸如 aws:runCommand、aws:executeScript、aws:invokeLambda、aws:approve、aws:createStack 和 aws:executeAutomation 等步驟。Automation 可接受參數、發出輸出、透過變更歷史記錄進行版本控制，並使用專用的 AutomationAssumeRole 執行，以實現最低權限和跨帳戶/區域的操作。可控制整個機群的並行性和錯誤閾值、要求核准和 Change Calendar 時間窗，並透過 SNS 與通知整合。您可以按排程、從 EventBridge 規則 (用於對 AWS Health、CloudWatch 或 API 事件進行近乎即時的修復)、從 AWS Config 修復動作以強制執行政策 (例如，將預設標籤套用到 EBS 磁碟區或將預設執行個體描述檔附加到 EC2 執行個體)，以及從 OpsCenter 叫用 automation。

OpsCenter 將來自 CloudWatch 警示、AWS Config、Health 事件或自訂來源的操作問題彙總為 OpsItems。每個 OpsItem 都會追蹤狀態、優先順序、重複資料刪除、相關資源和 runbook 連結。您可以關聯一鍵式 runbook 以進行標準修復，並透過串接 EventBridge 或 Config 規則來啟用自動修復，以便在 OpsItem 建立或更新為符合條件 (例如，安全群組在 SSH 上允許 0.0.0.0/0、修補程式合規性偏離或備份失敗) 時啟動特定的 Automation。使用 Systems Manager Explorer 可將跨帳戶和區域的機群運作狀態和未解決的 OpsItems 視覺化。這種組合——將 OpsItems 作為持久性記錄，加上將 Automation runbook 作為程式碼化的修復方案——能夠實現可稽核、一致的大規模操作。

← 高可用性、韌性與災難復原 · 所有領域 · 儲存、資料庫與資料管理 →

練習這些題目 → · 在 ExamRoll.io 上限時練習 →