Kinesis是由AWS提供的一項流數據管理服務，可輕松收集、處理和分析實時流數據。本文詳細介紹了迪士尼API服務團隊如何實現Kinesis數據流的自動縮放功能，保證流量高峰時的數據傳輸效率，并有效降低成本。本文來自迪士尼技術博客。

文 / Nick Burkard

譯 / 咪寶

原文

https://medium.com/disney-streaming/delivering-data-in-real-time-via-auto-scaling-kinesis-streams-72a0236b2cd9

摘要

Kinesis是Amazon Web Services（AWS）提供的一項托管式流數據服務，在迪士尼流媒體服務中被廣泛應用于實時和批量分析，并支持個性化視圖、流并發和應用程序域事件分析等功能。在本篇文章中，將詳細介紹迪士尼流媒體服務的API服務團隊是如何實現Kinesis數據流的自動縮放功能的，這項功能使我們能夠在流量高峰時段穩定地傳輸數據，同時保持成本效益。

問題

團隊的工作

在迪士尼流媒體服務中，我們的API服務團隊（包括我自己）負責那些向客戶端公開公共API的應用程序，這意味著我們將大量參與客戶端通信協議、支持流量需求的擴展、通過回退和降級提供可靠性以及安全性。

與大多數使用AWS部署的應用程序一樣，我們的應用程序將事件記錄到CloudWatch日志中。由于CloudWatch也是AWS提供的一項管理服務，因此我們可以很容易地集成它來存儲和查詢應用程序事件。我們還將應用程序事件發布到一個更大的數據湖平臺中，這個平臺支持對應用程序事件進行更豐富的分析和可視化，這也就是Kinesis 數據流的來源。

動機

選擇Kinesis流作為我們的數據湖平臺的入口點，需要確保數據不會丟失或長時間落后于實時交付。

一個簡單的解決方案是過度供應流。然而，這并不劃算，因為它相當于一天的大部分時間里都在浪費錢。

我們還研究了AWS Labs提供的一個應用程序Kinesis Scaling Utility，它可以通過CloudWatch來監控指標，并根據配置擴展Kinesis流。但是，它不是滿足我們需求的最佳解決方案：

原因如下：

擴大規模的速度不夠快。

應用程序需要不斷運行，這會產生額外的成本。

上述兩點是應用程序監控指標方法的結果，每隔設定的時間間隔來查詢CloudWatch。我的團隊需要盡快進行擴展并且節約成本，因此我們開始創建自己的解決方案。

有關Kinesis的基礎知識

為了更好地理解為我們的解決方案做出的選擇，我將介紹Kinesis流如何工作的一些基礎知識。有關進一步介紹的文檔，請參閱AWS提供的關鍵概念頁面。（https://docs.aws.amazon.com/zh_cn/streams/latest/dev/key-concepts.html#terminology）

分片

Kinesis流在創建時分配了一定數量的分片。流中的每個分片都有一個散列鍵范圍，它是一系列有效的整數值。在創建時，這些分片被認為是開放的，這意味著它們可以接收數據并產生成本。

對于添加到流中的每條記錄，必須定義分區鍵。流散列此分區鍵，結果為整數。流確定生成的整數落入哪個散列鍵范圍，并將記錄發送到正確的已打開分片。

在向流中添加記錄時，可以選擇定義顯式哈希鍵，這將強制將記錄發送到特定的開放分片。

縮放

縮放Kinesis流的過程稱為重新分片，它可以通過調用UpdateShardCount來異步啟動，必須提供目標分片用以計數（要縮放的分片數）。

向下縮放流合并成對的分片以實現所需的總數。向上縮放流將多個分片分成兩半以獲得所需的總分。

這意味著可以將最小的流縮小到其當前打開的分片計數的一半。相反，這也意味著可以將最高的流擴展為其當前打開的碎片計數的兩倍。

例如，Kinesis流有12個開放分片。在此流上調用UpdateShardCount時，目標分片計數必須在[6,24]的范圍內，超出此范圍的值將導致錯誤。

數據的可用性

Kinesis流具有設定的數據保留期，默認為24小時。

重新進行分片后，分片將被關閉，這意味著它們無法再接收數據。它們不會產生成本并將保留到數據保留期后。

要求

為了實現將CloudWatch日志數據提供給自動擴展Kinesis流的目標，需要創建幾個不同的組件。我們將這些組件組織成兩個單獨的堆棧，以確保將來可重用。

自動縮放堆棧

在大量使用期間縮放Kinesis流及其相關資源，在非高峰時段縮小。

Kinesis流

已處理數據的主要目標。此數據可以驅動實時處理或存儲以進行批量分析。

此流可以與其關聯的擴展組件同時創建，也可以在AWS環境中存在。

擴展

Lambda可以擴展Kinesis流，根據Kinesis指標和可選的外部Lambda的計算吞吐量觸發它的警報。處理觸發擴展Lambda的警報跟蹤Kinesis流報告的度量。

擴展架構

為了跟蹤何時進行擴展，Lambda將在成功調用時向CloudWatch報告兩個自定義指標（OpenShards和ConcurrencyLimit）。這些自定義指標將允許我們監控擴展行為。

縮小

Lambda可以縮小Kinesis流、縮放警報以及可選的外部Lambda到原始設置。

在非高峰時段（處理失敗的日志之后）每天一次，CloudWatch規則將以10分鐘的間隔觸發Scale Down Lambda。這樣做的目的是為了抵消Kinesis縮小的限制（最低有效目標分片計數是當前打開分片計數的一半）。

如果當前正在大量使用流，如果當前正在按比例縮小或者已經縮小到默認的分片數量，則此Lambda將跳過縮小過程。

縮小架構

與擴展Lambda一樣，只要成功調用，Lambda也會向CloudWatch報告兩個自定義指標（OpenShards和ConcurrencyLimit）。

日志處理堆棧

從CloudWatch 日志處理事件，將結果發送到Kinesis流。

記錄處理器

Lambda將處理來自所選日志組的事件，將結果發送到Kinesis流。

如果批處理中的任何日志事件未能發送到Kinesis流（帶有錯誤代碼返回），則日志處理器Lambda將使用指數退避和抖動算法來嘗試將失敗的日志事件重新發送到Kinesis流。這使并發日志處理器能夠在不同時間重新發送日志事件。

其保留的并發執行（一次可以運行多少并發Lambdas）將等于分配給Kinesis流的分片數。這樣可以避免向Kinesis流寫入比它可以處理的數據更多的數據，還能讓我們直接控制數據流入Kinesis流的速度，這意味著數據將落后于實時交付，而不是完全丟失。

失敗的日志處理器

為了解釋上述日志處理器的潛在故障，任何失敗的日志事件批次（已重試兩次但仍然失敗）將被保存到死信隊列中（DLQ）。

在非高峰時段每天一次，CloudWatch規則將觸發失敗的日志處理器。這個單獨的Lambda將向DLQ詢問任何失敗的日志事件，并通過日志處理器重新處理它們。

為了避免超時和長時間的運行，失敗的日志處理器將能夠異步地重新調用自身以繼續重新處理失敗的日志事件，假設有更多失敗的日志事件可用。

架構解決方案概述

根據我們的體系結構組件的計劃，我們可以轉向如何利用它們來處理日志事件并自動擴展Kinesis流。

關鍵指標

如前所述，擴展Lambda將使用警報來監控Kinesis指標，以查看它是否超過計算的閾值。

建議的方法是在5分鐘內從關聯的Kinesis流中測量IncomingRecords或IncomingBytes的總和。這可以讓我們直接了解流入流中的數據量并做出有關擴展的明智決策。

門限計算

選擇上述推薦指標之一后，我們可以繼續計算我們想要監控的閾值。

對于具有n個分片的Kinesis流，Lambda將擴展到最多n個調用（由其保留的并發執行控制）。

每個Lambda每秒向Kinesis流發送平均m條記錄。警報監視度量總和的時間是s秒。

因此，監視的閾值是n * m * s。

為確保在數據落后之前進行擴展，我們可以監控計算閾值的百分比。由于AWS的80％被認為是最佳實踐，我們將繼續監控該值。

架構

由于兩個堆棧都是獨立且通用的，因此它們可以單獨部署或串聯部署。當兩者都部署為針對相同的Kinesis流時，結果是我們開始的問題的解決方案。

架構拓撲

驗證結果

當為我們的某個應用程序部署架構時，我們需要驗證我們的數據是否實時可用，并且在需要時進行擴展。

首先，我們可以比較轉發到日志處理器Lambda的日志事件數量與使用CloudWatch寫入Kinesis流的記錄數量，以確保數據不會落后。

轉發日志與已處理日志

轉發到日志處理器的日志事件總和等于每個數據點發送給Kinesis的記錄總和。這意味著處理后的數據可以實時獲得！

最后，我們可以使用Grafana將我們報告的自定義指標與并發日志處理器Lambda的平均數量進行可視化。

自定義指標與平均并發

一旦超過設定的閾值就會發生放大，而在非高峰時段的設定時間開始按比例縮小并持續到結束。并發日志處理器Lambdas的平均數量也從未超過并發限制。這證實了我們正在自動擴展Kinesis流！

結論

我們已經成功開發了一個解決方案架構，其中包含兩個可重復使用的CloudFormation模板，可以單獨部署或者聯合部署。

日志處理模板使我們能夠以最小的努力一般地轉換數據。圍繞CloudWatch日志和Kinesis的所有樣板代碼都在后臺處理。這使團隊可以專注于如何轉換數據。

自動縮放模板使我們能夠定義Kinesis流安全放大和縮小的時間和方式。Kinesis流不再需要過度配置，以避免突然出現尖峰。這最大限度地減少了人工干預并降低了總體成本。

當這兩個模板一起部署時，我們還可以控制將日志事件流轉換為Kinesis流的速度。如果突然出現峰值，數據將暫時落后于實時交付，直到擴大規模完成為止。這比稍后重試失敗的日志事件批要好得多，因為它將日志事件完全刪除或多次處理的概率降到最低。

總的來說，構建這個解決方案架構非常有趣！雖然它最初是為API服務的用例開發的，但我很高興我們將架構概括為兩個獨立的堆棧。這將使迪士尼流媒體服務的其他團隊能夠利用這兩個模板并為體系架構做出改進。

LiveVideoStack? 招募

LiveVideoStack正在招募編輯/記者/運營，與全球頂尖多媒及技術專家和LiveVideoStack年輕的伙伴一起，推動多媒體技術生態發展。了解崗位信息請在BOSS直聘上搜索“LiveVideoStack”，或通過微信“Tony_Bao_”與主編包研交流。

點擊【閱讀原文】或掃描圖中二維碼，了解更多大會講師及分享內容信息！

總結

以上是生活随笔為你收集整理的通过自动缩放Kinesis流实时传输数据的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。