一個高流量網站運行在 EC2 上，並使用 Kinesis Data Streams 收集網站日誌。Kinesis 消費者應用程式（也在 EC2 上）在資料量激增時會跟不上，導致記錄被丟棄。哪種解決方案能以最少的操作負擔來改善串流處理？

當 Kinesis 消費者應用程式跟不上資料量時，最直接的解決方案是水平擴展消費者。監控 GetRecords.IteratorAgeMilliseconds 指標可以有效判斷消費者是否落後，因為它表示消費者處理最新記錄的延遲時間。增加 EC2 實例數量可以讓更多消費者同時處理資料，從而提高處理能力。同時，增加 Kinesis 串流的保留期限可以防止在消費者處理速度較慢時資料被丟棄，為消費者提供更多時間來追趕。 其他選項的缺點： 將日誌持久儲存在 S3 並使用 EMR 處理會增加額外的複雜性和延遲，不適合即時處理需求。 將消費者遷移到 Lambda 雖然減少了操作負擔，但 Lambda 的併發限制可能在極高流量下仍會遇到瓶頸，且可能需要重新設計應用程式邏輯。 為 Kinesis Data Stream 增加更多分片會提高串流的吞吐量上限，但如果消費者應用程式本身處理能力不足，增加分片並不能解決消費者跟不上的問題，反而可能導致資料在分片中堆積更快。