安全遷移每秒服務(wù)數(shù)百萬個請求的數(shù)據(jù)庫

這篇具有很好參考價值的文章主要介紹了安全遷移每秒服務(wù)數(shù)百萬個請求的數(shù)據(jù)庫。希望對大家有所幫助。如果存在錯誤或未考慮完全的地方，請大家不吝賜教，您也可以點(diǎn)擊"舉報違法"按鈕提交疑問。

關(guān)鍵字: [Amazon Web Services re:Invent 2023, Cassandra, Database Migration, Shadow Traffic, Performance Evaluation, Correctness Verification, Automated Migration]

本文字?jǐn)?shù): 1800, 閱讀完需: 9 分鐘

視頻

如視頻不能正常播放，請前往bilibili觀看本視頻。>> https://www.bilibili.com/video/BV1Rj41157AM

導(dǎo)讀

Netflix 的數(shù)據(jù)平臺每秒以毫秒級的延遲從其托管在亞馬遜云科技上的在線數(shù)據(jù)存儲（如 Apache Cassandra 和 EVCache（基于 Memcached））提供數(shù)千萬次請求。在本論壇中，您將了解如何利用云的影子流量和獨(dú)特功能安全地遷移 PB 級數(shù)據(jù)和每秒數(shù)以百萬計的請求，而不會有任何數(shù)據(jù)丟失或用戶可見的性能下降風(fēng)險。通過確保所有操作都是等效的、使用云來啟動影子硬件以及在處理等效回填時復(fù)制流量，企業(yè)可以幫助確保安全升級。

演講精華

以下是小編為您整理的本次演講的精華，共1500字，閱讀時間大約是8分鐘。如果您想進(jìn)一步了解演講內(nèi)容或者觀看演講全文，請觀看演講完整視頻或者下面的演講原文。

Joey和Ayushi在臺上討論了如何在Netflix安全遷移大量請求的數(shù)據(jù)庫技術(shù)。他們解釋道，Netflix擁有全球最大的數(shù)據(jù)庫，分布于4個亞馬遜地區(qū)（每個地區(qū)有3個可用區(qū)）的全球基礎(chǔ)設(shè)施中。他們的系統(tǒng)能高效處理海量的流量和數(shù)據(jù)，例如，單位數(shù)毫秒延遲通常小于10ms。因此，在進(jìn)行數(shù)據(jù)庫遷移時必須確保安全措施，防止數(shù)據(jù)丟失或損壞。

在Netflix，盡管數(shù)據(jù)庫遷移有時是由于需求變化、數(shù)據(jù)存儲新功能或成本優(yōu)化等原因而不可避免，但應(yīng)盡量推遲。例如，對于常規(guī)軟件或內(nèi)核升級，遷移通常是多余的。然而，當(dāng)他們需要遷移數(shù)據(jù)庫時，必須自動化這個過程并采取安全措施，以防止數(shù)據(jù)丟失或損壞。在Netflix，他們可以遵循由數(shù)據(jù)平臺團(tuán)隊制定的標(biāo)準(zhǔn)化程序，在基礎(chǔ)設(shè)施上并行執(zhí)行遷移。

為了實現(xiàn)這一目標(biāo)，Netflix首先抽象了底層存儲API，使應(yīng)用程序與特定數(shù)據(jù)存儲解耦。他們利用一個名為“數(shù)據(jù)網(wǎng)關(guān)”的服務(wù)來定義通用CRUD API用于數(shù)據(jù)訪問。這個網(wǎng)關(guān)負(fù)責(zé)將操作轉(zhuǎn)換為當(dāng)前正在使用的數(shù)據(jù)庫的本地API。通過插入這個中間抽象層，Netflix可以在不換出數(shù)據(jù)存儲的情況下切換數(shù)據(jù)存儲。例如，網(wǎng)關(guān)可以無縫地將應(yīng)用程序發(fā)出的放/取操作轉(zhuǎn)換成適用于后端Cassandra或DynamoDB的正確API調(diào)用。

此外，網(wǎng)關(guān)API還包括寫操作的項目有效性令牌，使得可以安全地重放重復(fù)請求。這些令牌允許Netflix在避免潛在沖突（如Cassandra中的最后寫入獲勝）的情況下重放寫入。對于讀取API，Netflix設(shè)計它們支持可恢復(fù)的分頁，通過返回固定大小的2兆字節(jié)結(jié)果頁面和令牌，而不是無界的結(jié)果集。這種方法在遷移過程中在陰影流量期間便于比較舊和新數(shù)據(jù)存儲。

在接下來的遷移過程中，舊數(shù)據(jù)存儲仍然作為主用系統(tǒng)處理所有請求，同時新的數(shù)據(jù)存儲接受流量的影子復(fù)制。網(wǎng)關(guān)將傳入的請求復(fù)制并并行分派給新舊數(shù)據(jù)存儲的實施，但只使用來自舊系統(tǒng)的響應(yīng)。這種流量影子復(fù)制方式可以在將生產(chǎn)負(fù)載切換到新系統(tǒng)之前發(fā)現(xiàn)新系統(tǒng)的任何潛在性能或正確性問題。

當(dāng)流量完成影子復(fù)制后，Netflix啟動一個回填操作，從舊存儲向新存儲復(fù)制數(shù)據(jù)，同時使用項效力令牌合并正在進(jìn)行的寫入。這個回填過程利用跨區(qū)域復(fù)制的Amazon S3快照來提高彈性。數(shù)據(jù)平臺團(tuán)隊使用部署在Amazon EMR集群上的Apache Spark作業(yè)高效地并行復(fù)制數(shù)TB的數(shù)據(jù)來恢復(fù)這些備份。EMR作業(yè)比較新舊系統(tǒng)之間的數(shù)據(jù)以識別任何差異，然后在切換之前進(jìn)行切掉。

在整個過程中，Netflix會進(jìn)行全面監(jiān)控和驗證，以確保將讀取和寫入切換到新數(shù)據(jù)存儲之前的影子流量的準(zhǔn)確性和性能與主要流量相匹配。Netflix自動驗證性能指標(biāo)并在檢測到降級時進(jìn)行故障切換。舊系統(tǒng)作為快速回滾選項保持可用，以防在切換后出現(xiàn)任何問題。只有在充分驗證了正確行為之后，Netflix才會廢棄舊數(shù)據(jù)存儲。

對于大規(guī)模遷移活動，Netflix通常會“鋪路”，建立應(yīng)用程序團(tuán)隊可以采用的努力最小的標(biāo)準(zhǔn)基于網(wǎng)關(guān)的遷移流程。但是，由于不支持通用網(wǎng)關(guān)的獨(dú)特接口或訪問模式，一些系統(tǒng)需要更自定義的基于庫的遷移。雖然可行，但基于庫的方法缺乏內(nèi)置儀器和故障隔離。因此，引入的任何錯誤都有直接影響生產(chǎn)流量的風(fēng)險。由于這個風(fēng)險，Netflix在可能的情況下強(qiáng)烈更喜歡網(wǎng)關(guān)方法。

Joey最近分享了一個關(guān)于Netflix的例子。他們把Netflix的Cassandra基礎(chǔ)設(shè)施從版本3成功遷移到了4.1。由于Cassandra 3將停止支持，而新的4.1版本提供了許多改進(jìn)，如更好地滿足Netflix高吞吐量使用案例的擴(kuò)展需求，因此這次升級是必要的。然而，在開始模擬流量時，團(tuán)隊發(fā)現(xiàn)Cassandra 4.1的寫入延遲比版本3高出兩倍，讀取延遲也高出兩倍多，這導(dǎo)致canary分析測試失敗。經(jīng)過深入調(diào)試，發(fā)現(xiàn)Cassandra 4.1節(jié)點(diǎn)配置錯誤，例如使用了CMS垃圾回收器而非低延遲的G1收集器。切換到Amazon Corretto JDK也提高了性能。在糾正這些配置問題后，4.1版本的性能達(dá)到了與3版本相當(dāng)?shù)乃?，使得新版本得以順利推廣。

另一個主要遷移項目是將從Thrift協(xié)議升級到更新的CQL協(xié)議。Thrift在2016年被標(biāo)記為過時，所以現(xiàn)在是時候進(jìn)行升級了。過去的嘗試揭示了在從Cassandra 2遷移到3的過程中可能會出現(xiàn)數(shù)據(jù)損壞問題，這將增加項目風(fēng)險并延誤其進(jìn)度。最終在2023年，他們決定處理這個涉及超過200個數(shù)據(jù)庫的大規(guī)模遷移。

團(tuán)隊定義了門戶和庫遷移路徑，以提供靈活性。通過門戶路線，應(yīng)用程序團(tuán)隊可以在數(shù)據(jù)遷移完成之前獨(dú)立快速完成API遷移，避免停機(jī)時間。一旦API切換完畢，數(shù)據(jù)平臺工程團(tuán)隊就可以按照自己的速度遷移底層數(shù)據(jù)。由于獨(dú)特的接口或訪問模式不受通用門戶支持，需要自定義庫支持。

在遷移過程中模擬所有流量，Netflix發(fā)現(xiàn)了幾個可能導(dǎo)致問題的原因。例如，與CQL提供的并行讀取相比，Thrift的多鍵讀取性能慢了8倍。另一個發(fā)現(xiàn)是效率低下的分頁邏輯，它會完整地檢索大型100兆字節(jié)的行，而不是以2兆字節(jié)的小塊進(jìn)行檢索。

由于抽象網(wǎng)關(guān)層的存在，數(shù)據(jù)平臺團(tuán)隊能夠在不改變Cassandra本身的情況下解決這些性能問題。此外，由于數(shù)據(jù)存儲的不一致排序問題，掃描也帶來了挑戰(zhàn)。解決方案包括一致性規(guī)范令牌，并在切換期間強(qiáng)制網(wǎng)關(guān)固定掃描到一個實現(xiàn)或另一個實現(xiàn)。

總的來說，Netflix成功地將支持300多個內(nèi)部應(yīng)用程序和數(shù)千TB數(shù)據(jù)的250多個關(guān)鍵數(shù)據(jù)庫進(jìn)行了遷移。這僅僅是通過嚴(yán)格遵循數(shù)據(jù)平臺團(tuán)隊創(chuàng)立的標(biāo)準(zhǔn)化遷移流程實現(xiàn)的。

Ayushi分享了一些例子，如將DynamoDB升級到具有較低延遲的Cassandra緩存層，以及用Netflix構(gòu)建的新鍵值服務(wù)替換Dynamite Redis實現(xiàn)。從DynamoDB到Cassandra的遷移展示了需求如何隨時間而變化。應(yīng)用程序開始時需要一個最適合其需求的鍵值存儲。然而，隨著使用量的增長和訪問模式的改變，Cassandra成為了最佳選擇。

通過這些大規(guī)模遷移過程中的仔細(xì)陰影化、金絲雀測試和性能評估，避免了任何重大問題或故障。即使有數(shù)千TB的數(shù)據(jù)和數(shù)百個集群，Netflix在這方面的專業(yè)知識使他們能夠在會員提供不間斷的優(yōu)秀流媒體體驗的同時，創(chuàng)新并優(yōu)化其基礎(chǔ)設(shè)施。

最后，Joey和Ayushi分享了Netflix從廣泛遷移經(jīng)驗中吸取的關(guān)鍵教訓(xùn)：

自動化簡化了最復(fù)雜的遷移過程
新系統(tǒng)的正確性和性能退化需要進(jìn)行嚴(yán)格的測試
盡可能將API遷移與數(shù)據(jù)遷移解耦
優(yōu)先進(jìn)行同質(zhì)遷移，以便更容易地進(jìn)行數(shù)據(jù)映射
使用網(wǎng)關(guān)抽象存儲，以便更輕松地切換實現(xiàn)
通過陰影流量揭示問題，而不影響客戶
使用物品有效性令牌確保新系統(tǒng)上的安全寫重播
使用分頁API允許在數(shù)據(jù)存儲之間進(jìn)行可讀比較
在網(wǎng)關(guān)中解決數(shù)據(jù)存儲問題，而不是在存儲本身進(jìn)行更改
標(biāo)準(zhǔn)化遷移路徑，同時仍支持自定義一次性的需求

總的來說，通過對細(xì)節(jié)進(jìn)行精心提煉、追蹤和核實，即使面對的是每秒需要處理數(shù)百萬請求的關(guān)鍵任務(wù)型數(shù)據(jù)庫，也能夠?qū)崿F(xiàn)安全、穩(wěn)定且高效的遷移過程。在這方面，Netflix憑借其專業(yè)知識在優(yōu)化基礎(chǔ)設(shè)施的同時，為全球各地的客戶提供了持續(xù)不斷的優(yōu)質(zhì)流媒體服務(wù)。

下面是一些演講現(xiàn)場的精彩瞬間：

Joey和Ayushi展示了一種在高流量場景下安全遷移數(shù)據(jù)庫的方法。