Jordan Sitkin 和 Luke Demi 討論了 Coinbase 應(yīng)對 2017 年加密貨幣的激增的方式,以及工程師們是如何利用從這些經(jīng)歷中獲得的經(jīng)驗教訓(xùn)來創(chuàng)建用
Jordan Sitkin 和 Luke Demi 討論了 Coinbase 應(yīng)對 2017 年加密貨幣的激增的方式,以及工程師們是如何利用從這些經(jīng)歷中獲得的經(jīng)驗教訓(xùn)來創(chuàng)建用于容量規(guī)劃的新工具和技術(shù)、為加密貨幣熱潮的未來浪潮做準(zhǔn)備的。Luke Demi 是 Coinbase 可靠性團(tuán)隊(Reliability Team)的軟件工程師。Jordan Sitkin 是 Coinbase 的軟件工程師。本文整理自他們在 QCon 的演講《Capacity Planning for Crypto Mania》。
正文
Demi:我就開門見山地說了。如果我們試圖在 2017 年 5 月訪問 Coinbase,那么,可能看到這么一個頁面。我們也許在嘗試檢查自己的余額、或在購買新的加密貨幣,或者是想從 Coinbase 的網(wǎng)站提取資金,但是我們卻發(fā)現(xiàn)加密貨幣的價格在飛漲。人們突然對購買加密貨幣真正感興趣了,所以加密貨幣的交易系統(tǒng)崩潰了。有點(diǎn)像 QCon 的網(wǎng)站,對吧?只是開個玩笑,不過我們迫不及待地想從負(fù)責(zé)此事的人那里看到關(guān)于這一“貨幣戰(zhàn)爭”的故事。
但不管怎么說,冷靜。沒錯,這個現(xiàn)象很糟糕,原因有很多。但主要是因為,如果當(dāng)時你是 Coinbase 的客戶,那么你一定會產(chǎn)生擔(dān)心的情緒——你會擔(dān)心自己的錢不見了。Coinbase 剛剛被黑了,發(fā)生了什么事?我們開始看到一些可怕的說法,比如這種:“Coinbase 隨著比特幣和以太網(wǎng)而沒落了。”
好吧,這么說很對。但是,很傷人。這些年我們一直低調(diào)行事,嘗試建立這個生態(tài)系統(tǒng),并試圖領(lǐng)導(dǎo)這場變革。這些 Reddit 上的評論,有點(diǎn)幽默,但抓住了那天的情緒。我再讀一條評論:“有趣的是,Coinbase 應(yīng)該使用了 AWS,因此容量不該是個問題。除非他們不使用自動擴(kuò)展或者太便宜而無法購買更多的 AWS 資源,或者只是懶。”
這是某天我們在一個房間里的寫照。那天非常有趣,因為我們一整天都在發(fā)愁。大概有 8 小時,我們在一個有沙發(fā)的房間里就這么坐著,想找出方法來讓網(wǎng)站回復(fù)原狀。那天的《紐約時報》刊登了一篇文章,稱 Coinbase 宕機(jī)了,無法處理網(wǎng)絡(luò)負(fù)載。對我們公司來說,這是一個重要的轉(zhuǎn)折點(diǎn)。我們意識到,如果我們不能團(tuán)結(jié)一致,那么,Coinbase 就無法生存。
Siktin:我們把這個訪談叫做加密狂熱的容量規(guī)劃。該訪談的內(nèi)容是我們?nèi)绾握一刈罴褷顟B(tài)。也就是說,我們?nèi)绾螐?Luke 剛介紹的、去年那個黑暗的日子開始把這個故事反轉(zhuǎn)。我們準(zhǔn)備介紹我們在那段時間學(xué)到的東西。在那段短短幾個月的時間里,Coinbase 的流量增加了 20 倍。
我們犯了一些錯,得到了一些教訓(xùn),而且我們有幸在工作的同時進(jìn)行了一些有趣的挑戰(zhàn)。當(dāng)然,在此期間,我們的工具和系統(tǒng)不得不快速成熟。我們將介紹 Coinbase 從那天開始的故事,并會隨時提出一些見解和經(jīng)驗。然后,我們計劃講講我們現(xiàn)在在做的事,為未來做更好的準(zhǔn)備。
先簡單做個介紹。我是 Jordan,這位是 Luke。我們是 Coinbase 可靠性團(tuán)隊成員。需要說明的是,在去年那場瘋狂的熱潮中,我們只是涉及其中的兩位。我們也是現(xiàn)在和未來負(fù)責(zé)維護(hù)系統(tǒng)可靠性的人。
買賣數(shù)字貨幣
正如你們中的很多人所指出的,大家已經(jīng)很熟悉 Coinbase 了。對于 Coinbase,大多數(shù)人都知道是個應(yīng)用程序。我們希望它成為最簡單、最值得信任的數(shù)字貨幣交易及管理場所。但是現(xiàn)在,Coinbase 實際上遠(yuǎn)不止是個應(yīng)用程序。我們是圍繞著 Coinbase 這一名稱的一個其他品牌和服務(wù)的小集合。為了更全面地概述我們的技術(shù)棧,今天我們在這里主要討論的是一個獨(dú)立 Rails 應(yīng)用程序。它由 MongoDB 數(shù)據(jù)庫支持,其基礎(chǔ)設(shè)施在 AWS 上部署和管理。
在今天的演講中,我們希望告訴大家兩件重要的事情。首先,今天演講的題目是跟容量規(guī)劃有關(guān)的,但是,我們實際上會用大多數(shù)時間來談負(fù)載測試。原因是,我們覺得負(fù)載測試(或者叫容量測試、壓力測試、批量測試)是我們在容量規(guī)劃工作中最重要的工具。我的意思是,通過容量測試(或同樣術(shù)語的不同其他叫法),實際上能夠模擬和研究生產(chǎn)中可能發(fā)生的真實故障。這樣說應(yīng)該比較容易理解吧。
其次,我們希望告訴大家,在負(fù)載測試環(huán)境中,與生產(chǎn)完全對等不是從負(fù)載測試系統(tǒng)中獲得良好結(jié)果的必須要求。我們準(zhǔn)備解決它的方法之一是,引入我們稱之為容量周期的概念。這將是我們在整個演講中都要回歸的主題,因此,我希望現(xiàn)在就把它介紹給大家。我們準(zhǔn)備詳細(xì)介紹它的含義,但我們也打算通過這種方式分享我們的一些經(jīng)驗。
后端 RPM
Demi:好,我們稍微回頭看看,再講一點(diǎn)關(guān)于這個故事的背景。其實只是展示一下我們的流量模式在事情變糟前的樣子。我要說的是,它們很隨意。這是我們到 Rails 服務(wù)的后端流量。我們可以看到,流量一會兒增加一會兒下降,但其波動處于一個相當(dāng)狹窄的范圍內(nèi)。這里畫了一條紅線,沒其他特別的原因,只是表示上面的情況很糟糕,但我們離那里還很遠(yuǎn)。
在這個時間點(diǎn),紅線就意味著人們真正開始對加密貨幣、盈利能力這類東西感興趣了,它們不是我們擔(dān)心的事情類型。我們不認(rèn)為我們會碰到這條紅線。然而,這條紅線最終成為一場災(zāi)難。這是我們的流量圖。稍微提一下,該圖截止到 2017 年 7 月前后。這張圖展示了我們的流量變化,以及我們穿過這條紅線的方式。很顯然,這背后是以太坊和比特幣的熱潮。
我們在這條紅線上方待了幾天。有幾天我們從太平洋時間凌晨 3 點(diǎn)開始一直到半夜,每分鐘都有 10 萬多個請求,因為人們只是不斷嘗試登錄以購買產(chǎn)品。我們的系統(tǒng)崩了,但是沒關(guān)系,人們只是想繼續(xù)回來。對這一現(xiàn)象最恰當(dāng)?shù)拿枋鼍褪?ldquo;爆炸“,人們到處飛。這里再展示一下《紐約時報》的那篇文章。大家可以看出那段時間事情進(jìn)展得有多不順利。
網(wǎng)絡(luò)服務(wù)時間崩潰
事情進(jìn)展不順利的原因是,雖然事情進(jìn)展的方式正常,但進(jìn)展速度太快了。這是 New Relic,非常簡單,它顯示了我們的的 Ruby 時間和 MongoDB 時間。我們可以看到,Ruby 時間顯然占了我們應(yīng)用程序內(nèi)部所做的一大塊,MongoDB 時間只有一點(diǎn)點(diǎn)。
這是我們訪問網(wǎng)站時,通??吹降臉幼印?0% 的時間是 Ruby 的,一點(diǎn)點(diǎn)是 MongoDB 的,還有其他一些服務(wù)我們沒有算在這里。但是,當(dāng)我們經(jīng)歷這些問題時,也就是當(dāng)網(wǎng)站宕機(jī)時,它看起來是這樣的。出于一大堆不同的原因,這讓人感到困惑。
首先,Ruby 和 MongoDB 緊密相連。我們可以看到,由于某些原因,它們是同步的。很顯然,它們上升了很多。我的意思是,大家看一下左側(cè)的圖表,這是 4 秒的響應(yīng)時間,只是為了獲取 Ruby 和 Monogo。我們可以想像在那個時間點(diǎn),沒人能通過。
這是個讓人非常困惑的圖表。但是,更讓人困惑的是,在那個時間點(diǎn),這是我們擁有的唯一圖表。我們當(dāng)時盯著這圖表看,坐在那里討論說:“好吧,顯然 Mongo 很慢,但是 Ruby 也很慢。”“還會有其他情況嗎?”“伙計,圖表就是這樣顯示的”。我們沒有使用工具深入研究正在發(fā)生的事情。
實際上,這張圖表是錯誤的。但是,它讓我們在這段時間陷入了很難搞的事情。我們花了好多天做荒謬的事。我們當(dāng)時最靠譜的做法應(yīng)該是:“如果我們調(diào)整內(nèi)核參數(shù)會怎樣?”那在當(dāng)時是有道理的。是的,也許內(nèi)核就是問題所在。難搞的事情有一大堆。
驚醒夢中人
為了解釋 Jordan 提出的周期,我來描述一下當(dāng)時發(fā)生的事情。我們會在每天早上,或用一整天的時間,進(jìn)行一次細(xì)致的一致負(fù)載測試。當(dāng)我們進(jìn)而分析它時,我們完全搞錯了方向。對于工具和周期的改進(jìn)部分,我們應(yīng)該做的是添加工具以幫助我們理解在負(fù)載測試過程中發(fā)生的事。在那個時間點(diǎn),我們沒有那么做。我們只是再次盯著同樣的工具,并思考古怪的想法。
為了解決這一問題及其中一些擴(kuò)展問題,我們做了每個人都最愛做的事——把責(zé)任推到數(shù)據(jù)庫和升級版本上。我們升級了 MongoDB 的每一個版本,以讓自己保持最新的版本。如果你熟悉 MongoDB 就會知道,我們一開始使用的版本非常糟糕,因此升級版本會有一些相當(dāng)大的改進(jìn)。我們還做了另外一些事,比如把我們的集群分開。
舉個例子說,我們有一個用戶集和一個事務(wù)集被托管在同一個主機(jī)上,我們就把它們分開。這樣它們各自就會有更多的增長空間,這讓我們擺脫了當(dāng)時的困境。然而,我們意識到,如果我們希望能夠承受更多的負(fù)載,還需要更好的方法。因為在這個時間點(diǎn)上,我還是感覺流量一直在增加,也就是事情仍然在變壞。情況確實如此。
然而,我們在這里得到了一個重大的教訓(xùn)。這比較明顯,但是把它說清楚真的非常重要。好的工具會讓問題顯現(xiàn)出來。但是,糟糕的工具會讓問題變得模糊,讓人感到困惑,總有一天會讓我們看上去像個白癡。
Sitkin:回到我們的時間線,假設(shè)我們現(xiàn)在處于 2017 年中期?;氐竭@張我們一直在看的流量圖表。我們可以看到,在這次突破之后,我們被迫經(jīng)歷了一些慌亂、快速改進(jìn)了系統(tǒng),存活下來了。流量增加而又相對穩(wěn)定了。我們的流量到達(dá)了新基線水平。我們基本上在這個時間點(diǎn)處理這個問題。我們可以看到,雖然有些波動,但我們基本上處于一種新的流量平衡中。
此時,那些來自用戶的負(fù)載測試再也沒有使我們的站點(diǎn)以相同的方式宕機(jī)了。我們沒有跳進(jìn)這個周期,這個周期是我們后來才明白的。結(jié)果,我們對我們的工具做了很大變換,優(yōu)化了我們已有的工具。但是,我們沒有足夠的創(chuàng)造力來強(qiáng)迫我們的系統(tǒng)創(chuàng)建下一個故障模式。因此,我們?nèi)杂悬c(diǎn)不安,擔(dān)心未來。為了從周期的角度來說明這一點(diǎn),最終我們將其親切地稱為 YOLO 負(fù)載測試階段,可以在這里看到我們的負(fù)載測試步驟的一周版本。
我們意識到,我們需要人為地返回這個負(fù)載測試,以便回到快速改進(jìn)周期。于是,我們只做了我們可以想到的最簡單的事。我們基本上只是采用了一些現(xiàn)成的工具,運(yùn)行了一些合成負(fù)載測試。我們再次根據(jù)開發(fā)環(huán)境進(jìn)行了測試。我們不是很確定從哪里開始最好,于是,我們就這么開始工作了。
實際負(fù)載測試的支柱
在繼續(xù)詳細(xì)介紹我們所做的工作之前,現(xiàn)在是介紹我們稱之為實際負(fù)載測試支柱概念的好時機(jī)。這是一種在三個類別中分解負(fù)載測試策略的方法,是評估實際可行性的一種更好的方法。其中一個重點(diǎn)是,這三個類別中的每一個都可以單獨(dú)解決,同時提高了我們負(fù)載測試的真實性。我們不一定需要把它們一起提高,或者它們彼此之間甚至不必同樣重要。
第一個我們稱為數(shù)據(jù);現(xiàn)在展示的是我們數(shù)據(jù)庫中數(shù)據(jù)的形狀。類似于:在我們的測試環(huán)境中,每種類型有幾行?跟在生產(chǎn)中所有的相比,這些記錄之間的關(guān)系是否真實?接下來的是流量。這是從負(fù)載測試系統(tǒng)中出來的流量形狀。
我們可以問問自己,出現(xiàn)了多少請求?速率是多少?這些請求到達(dá)哪些端點(diǎn)?這些請求的分布是否匹配我們在生產(chǎn)環(huán)境中實際看到的流量類型?第三類是三者中最簡單的,那就是構(gòu)成我們負(fù)載測試環(huán)境的物理系統(tǒng)是否匹配我們在生產(chǎn)中實際運(yùn)行的東西?我們在負(fù)載測試環(huán)境中運(yùn)行的這類服務(wù)器有多少?它們之間是如何關(guān)聯(lián)的?網(wǎng)絡(luò)層看起來都一樣嗎?
在這種情況下,回到我們在這個時間點(diǎn)真正在做的。我們從一個名為 Locust 的現(xiàn)成開源工具開始。我們覺得,對我們來說,這是開始實施分布式負(fù)載測試最容易的方法。我們知道,我們可以從中得到相當(dāng)大的吞吐量。大家如果不熟悉 Locust,我就簡單介紹一下。
這是一個工具,允許我們用 Python 編寫模擬的用戶流,然后在多個節(jié)點(diǎn)上回放它們,以實施分布式負(fù)載測試。這其中,我們擁有的一個主控件是調(diào)試我們的模擬用戶池中的用戶數(shù)量,然后添加到這個池中的速度快慢。
再多講一些細(xì)節(jié)。這是 Locust 的基本架構(gòu)圖。我們有一個主節(jié)點(diǎn),我們與它交互來控制測試,然后,它控制一群從屬節(jié)點(diǎn)。這些從屬節(jié)點(diǎn)中的每一個負(fù)責(zé)維護(hù)一個小用戶池,這些用戶正運(yùn)行在我們用 Python 編寫的模擬用戶流中。
在這個時間點(diǎn)上,這是我們的第一次嘗試。最終,這個測試對我們來說就是個玩具。它沒有真正提供我們所需的結(jié)果類型。但是,我們沒有真正理解它沒有提供的原因,也沒有真正相信它提供給我們的結(jié)果。但是,盡管存在這些問題,它確實有助于我們更好地理解一個良好的負(fù)載測試系統(tǒng)應(yīng)有的樣子。
從我們剛剛介紹的這些支柱的角度來看,我們知道,數(shù)據(jù)和系統(tǒng)與生產(chǎn)不匹配。這是一種設(shè)計。我們知道,我們剛剛的測試只是用一種幼稚的先通過方式來實驗。但真正的問題是,我們不了解系統(tǒng)輸出流量的方式在哪些方面是不現(xiàn)實的。我們還沒有建立一個提高現(xiàn)實性的流程,甚至沒有創(chuàng)建這個初始用戶流。我們并沒有根據(jù)基本原理來做這件事。因此,該系統(tǒng)永遠(yuǎn)不會成為我們工具箱中的重要工具,因為我們不信任它。巧合的是,這也很快變得無關(guān)緊要。
圣杯(the holy grail)
Demi:因為在 2017 年稍晚的時候,也就是 2017 年 10 月,加密貨幣真正成為主流?,F(xiàn)在,我們把我們工作的公司稱為“媽媽都知道“的公司了。我們的應(yīng)用程序在應(yīng)用程序商店下載排行榜上排名第一,新聞報道開始的風(fēng)格變成這樣了:“比特幣狂熱”,“加密貨幣狂熱”,“我們應(yīng)該買點(diǎn)加密貨幣嗎?”,“我們是否應(yīng)該把錢都投資到加密貨幣上?”
我們的流量現(xiàn)在呈現(xiàn)這種趨勢。這條紅線是我為了擴(kuò)展而隨意畫的。并且對更大規(guī)模,流量會有更大的躍升,這也就是我們之前宕機(jī)的原因。而在這段時間里,情況沒有那么糟糕。我們肯定會在某些地方出故障,這取決于我們跟得有多近,信不信由你們。但是,我們能夠生存下來的原因是,我們這里有個東西,我們把它稱為“容量周期的圣杯“。
為了解決這個問題,也就是我們認(rèn)識到的基本問題,我們進(jìn)入了這個周期的節(jié)奏。比如,我們會在凌晨 4:30 醒來,這時候東海岸的人們會在想:“我應(yīng)該買比特幣嗎?”他們就開始對我們的網(wǎng)站進(jìn)行狂轟濫炸。我們花了一個早上只是為了保持網(wǎng)站在線。午餐時,我們會分析結(jié)果:今天宕機(jī)的原因是什么?明天我們又會因為什么宕機(jī)?
例如,假設(shè)我們在 Mongo 上的用戶集合現(xiàn)在已經(jīng)被分解成一個新的集群,我們沒有更多空間進(jìn)行垂直擴(kuò)展。那么我們能做些什么?于是,我們花上一個晚上試圖改進(jìn)。我們添加檢測以增加清晰度,也就是可以通過添加新功能來改進(jìn)。然后,第 2 天,我們再次測試負(fù)載。這個周期會繼續(xù)下去。每天我們醒來,喝杯咖啡,“好,現(xiàn)在來個負(fù)載測試,”然后,下午來分析發(fā)生的事,并改進(jìn)工具。
這是在這段時間,我們?yōu)樵撚脩艏核龅钠渲幸恍┲匾虑?。在一個周末,我們利用了我們稱之為 Memcached 的標(biāo)識緩存添加了一個完整的緩存層。這使用戶集群的負(fù)載下降了 90%。這給我們帶來了足夠的余量,至少夠用幾周。
它允許我們堅持到第二天并解決下一個問題。這個流程讓我們解決了問題。它也告訴了我們一個重要的道理:當(dāng)我們在解決問題時,反饋越快,進(jìn)展也越快。每次我們經(jīng)歷這個周期,就是一個改進(jìn)的機(jī)會。我們經(jīng)歷的次數(shù)越多,能夠做出的改進(jìn)次數(shù)也越多。
Sitkin:讓我們回到我們的時間線?,F(xiàn)在是 2018 年,我們剛剛經(jīng)歷過這個讓人痛苦、非常累人的周期。在這個周期中,我們得到了快速反饋周期和快速改進(jìn),并我們的系統(tǒng)上取得很多進(jìn)展。我們進(jìn)入了一個平穩(wěn)期,不是每天都能創(chuàng)下歷史新高。我們開始不那么頻繁地創(chuàng)歷史新高了。你可能會認(rèn)為,我們會因為體驗到這一點(diǎn)而感到寬慰。是的,相信我,在這幾天能多睡點(diǎn)真是太好了。
但是,每天早上我們都會有一種潛在的焦慮感,因為我們不再進(jìn)行這個奇妙的負(fù)載測試了。在增加我們的容量方面,我們沒有這種真正的催化想法,即我們要做的最重要的事情是什么。就周期而言,基本上,這是當(dāng)我們的負(fù)載測試逐步脫離我們控制的時候。有一點(diǎn)點(diǎn)害怕,因為我們知道仍然存在一些揮之不去的性能問題。很顯然,仍然要添加新功能,因為新情況還在繼續(xù)出現(xiàn)。
事實上,現(xiàn)在我們非常關(guān)注推出新貨幣。每次我們進(jìn)行這項工作時,都可以看到略微不同的有趣的流量峰值,我們希望為這些情況做好準(zhǔn)備的不同流量模式。因此,我們在這個時間點(diǎn)覺得有必要回到現(xiàn)實,恢復(fù)這個負(fù)載測試步驟。我們需要能夠在測試環(huán)境中看到實際負(fù)載。
生產(chǎn)流量的捕獲及回放
基于我們在 YOLO 合成負(fù)載測試方法上的經(jīng)驗,我們對來自合成系統(tǒng)的流量并不十分自信。在我們處理這個問題的過程中,這個揮之不去的問題出現(xiàn)了好幾次,那就是,我們?yōu)槭裁床荒茉谪?fù)載測試中使用實際的生產(chǎn)數(shù)據(jù)。這看起來是個很自然的問題,非常有趣。這樣,在我們的負(fù)載測試中創(chuàng)建宕機(jī)的方式就會自然地與我們在生產(chǎn)中看到的宕機(jī)類型相匹配。其原因就是,我們實際上在利用實際的用戶行為。
此外,我們非常確定 MongoDB 是目前堆棧中最敏感的部分。它是共享最多的資源,這也就是之前我們宕機(jī)的原因。但是,一般來說,單獨(dú)測試某些東西不是好主意,我希望在這里使用另一個概念,以證明我們?yōu)槭裁从X得在像數(shù)據(jù)庫之類的東西中進(jìn)行單獨(dú)測試是有用的。
Neil Gunther 有一個通用可擴(kuò)展性定律(Universal Scalability Law)的概念。這是眾多描述系統(tǒng)拓?fù)鋽U(kuò)展的不同方法的其中之一。在這里的這張簡單圖表上,我們已經(jīng)有了兩條線;虛線代表沒有共享資源的系統(tǒng)可以如何擴(kuò)展。隨著吞吐量的增長,負(fù)載和它有完美的線性關(guān)系,因此它可以進(jìn)行完美的線性擴(kuò)展。這兩者之間的關(guān)系沒有理由隨著負(fù)載的增加而變化,在該系統(tǒng)中沒有共享資源。
但是,與此相反,我們有這條紅線,它代表有共享資源的系統(tǒng)可以如何擴(kuò)展,因為要爭奪共享資源(如數(shù)據(jù)庫)。隨著負(fù)載的增加,吞吐量根據(jù)圍繞著共享資源的爭奪情況會下降。這個曲線的形狀會根據(jù)系統(tǒng)的實際設(shè)計變化。但是,這里的關(guān)鍵是,隨著系統(tǒng)的增長,我們在這些資源上的收益遞減。
然后,隨著負(fù)載更多的增長,我們甚至開始后退了一點(diǎn)點(diǎn)。這是一種說法,在數(shù)據(jù)庫上的負(fù)載幾乎總是讓我們失敗。正是這個原因,它才是共享資源。大多數(shù)時候,我們對像應(yīng)用程序節(jié)點(diǎn)的東西有個相當(dāng)清晰的擴(kuò)展描述。這些節(jié)點(diǎn)是無狀態(tài)的,本身并不是共享資源,但它們通常會加載到有問題的數(shù)據(jù)庫上。
mongoreplay 加農(nóng)炮(mongoreplay cannon)
因此,我們設(shè)計了圍繞負(fù)載測試數(shù)據(jù)庫的捕獲回放。最終,我們構(gòu)建了被稱為 Mongoreplay 加農(nóng)炮(Mongoreplay cannon)的東西。它由兩個主要部分組成;我們已經(jīng)有了 Mongoreplay 捕獲流程,和我們的應(yīng)用程序節(jié)點(diǎn)及后端工作人員有機(jī)地結(jié)合在一起。
它在數(shù)據(jù)庫驅(qū)動上創(chuàng)建了一個額外的套接字,用于監(jiān)聽 Mongo 的有線流量并存儲它。然后,我們有另一個流程:稍后當(dāng)我們準(zhǔn)備實施負(fù)載測試時,能夠交互并處理這些捕獲文件,把它們合成一個文件,然后以實際卷的倍數(shù)回放到測試環(huán)境。這些文件通常是我們生產(chǎn)數(shù)據(jù)庫的克隆。
這是一個巨大的勝利。當(dāng)我們在討論單獨(dú)測試數(shù)據(jù)庫時,這對我們來說非常好。我們使用它可以很好地完成一些事情,如充滿信心地正確調(diào)整我們的集群規(guī)模。因為我們知道我們可以根據(jù)數(shù)據(jù)庫的更改參數(shù)調(diào)整不同的可調(diào)參數(shù),并確切知道它在現(xiàn)實世界中的響應(yīng)方式。
又因為,我們在應(yīng)用程序?qū)嶋H生成的數(shù)據(jù)庫上回放相同的負(fù)載。我們能夠在我們的測試環(huán)境中創(chuàng)建這些非?,F(xiàn)實的故障。當(dāng)然,接下來我們要考慮的是,如果這招真的好用,那么我們可以單獨(dú)測試數(shù)據(jù)庫。但是,用同樣的策略測試我們系統(tǒng)的其余部分會怎樣呢?
Demi:正如我們能看到的,很顯然,我們能夠單獨(dú)測試 MongoDB。因此,從字面上看,我們能夠在 Rails 和 Mongo 之間捕獲流量并回放之。這是我們能夠獲得的最接近的結(jié)果。然而,我們意識到,在我們的系統(tǒng)中有很多邊界,我們不得不想出一種方法來測試,該方法能夠與我們的 Mongoreplay 故事的成功相匹配。
這一切努力是為了確保我們不會在適當(dāng)?shù)臅r機(jī)宕機(jī)。如果我們不測試負(fù)載測試中的關(guān)系和邊界,那么,它可以告訴我們很多關(guān)于單獨(dú)系統(tǒng)的事情。但是,如果在我們的環(huán)境中稍微不那么突出的系統(tǒng)或其他共享資源之間發(fā)生新的回歸,那怎么辦?因此,我們知道我們需要嘗試找到不同的方法。
流量、數(shù)據(jù)及系統(tǒng)
讓我們從流量開始,回顧現(xiàn)實主義的三層或三個支柱。這些是我們以有效性為標(biāo)準(zhǔn)對它們進(jìn)行的排序。例如,最底層的、最不切實際或基本的測試方法是使用這種簡單的單用戶流。因此,這意味著只測試當(dāng)用戶點(diǎn)擊三或四個頁面時所發(fā)生的事,就像我們在運(yùn)行 A/B 測試或類似的東西一樣。
第二種,也許是更現(xiàn)實的方法,可以根據(jù)真實的用戶流做些像合成流量生成這類的事情。比如,我們可能會有個工具可以綜合地生成流量,但卻需要查看我們的日志數(shù)據(jù),以找出如何在新環(huán)境中進(jìn)行回放。最后,Holy Grail 是這種捕獲回放的想法。我們用的是完全真實的生產(chǎn)流量,我們只是把它指向其他內(nèi)容,并看看它的響應(yīng)情況。
順便提一下,捕獲回放聽起來不錯。我們碰到的主要問題是,特別對流量來說,記錄 post body 是極其困難的。我們在 post body 中存儲了很多敏感信息,針對非生產(chǎn)環(huán)境或者在生產(chǎn)環(huán)境中重放這些信息時,會存在很多問題。此外,很多用于后續(xù)請求的 ID 并沒有被確定地生成。因此,當(dāng)我們嘗試重放流量時,很難匹配那些請求。結(jié)果,我們需要做的是以某種方式重寫它們,使其工作,這有損于現(xiàn)實性。
然后,回過來談?wù)剶?shù)據(jù)。最簡單的方法就是,用 siege 測試開發(fā)環(huán)境的方法來測試數(shù)據(jù)庫,以便創(chuàng)建它們。只需要創(chuàng)建一些基本用戶,把它們插入負(fù)載測試框架中就可以了。下一個最佳選擇是,綜合生成數(shù)據(jù),但用更實際的方法來實現(xiàn)。實際查看用戶的布局、擁有很多賬號的用戶是否有很多以及這些用戶之間的關(guān)系,然后在我們的環(huán)境中綜合地創(chuàng)建這些東西。
最后,這里有排在前兩位的清除數(shù)據(jù)的方法。因此,我們可以使用生產(chǎn)數(shù)據(jù)庫,把它放到較少的生產(chǎn)環(huán)境中或另一個生產(chǎn)環(huán)境中。但是,重要的是,要明確地刪除那些我們要保護(hù)的重要客戶信息。很顯然,獲取一個真實負(fù)載測試的最佳可能方法是在生產(chǎn)環(huán)境中對數(shù)據(jù)進(jìn)行實際的測試。
最后,來講講系統(tǒng),這是有道理的。但是,如果我們在一個簡單的開發(fā)環(huán)境中進(jìn)行測試,那得不到實際的結(jié)果。如果我們的集群大小有問題,那么就不會產(chǎn)生實際的結(jié)果。然后,是創(chuàng)建生產(chǎn)平價環(huán)境。也許我們想做一個編譯框架,該框架可以創(chuàng)建我們的所有生產(chǎn)資源,只要把它指向另一個 AWS 賬號并運(yùn)行就可以。這很現(xiàn)實。但是,很顯然,在生產(chǎn)中測試是最終的策略。我們得到了確切的生產(chǎn)環(huán)境,它具有所有的問題和節(jié)點(diǎn)等等東西。
然而,我們開始思考這個問題時,意識到捕獲回放方法很難,合成方法也很難。但是,我們是區(qū)塊鏈公司。我們?yōu)槭裁床荒苡脜^(qū)塊鏈解決方案來解決這個問題?于是,我們決定采用大膽的新方法。因此,今天,我們很高興地宣布,在 Coinbase 發(fā)布 Load Testing Coin。
Load Testing Coin 是兼容 ERC20 的 coin,允許你告訴你的用戶來加載測試你的負(fù)載。我在開玩笑。我們不希望把大家搞得太興奮。我們不得不這樣做,沒有隨便搞個 Load Testing Coin,那是假的。但是,事實上,那會很酷,對嗎?如果你只需要告訴用戶來,… ,不是 coin,這個 coin 是愚蠢的。說真的,你會買它嗎?
Sitkin:是的,我也許會考慮買。
Demi:我們會加油的。抱歉,這個講話是要轉(zhuǎn)錄的,對嗎?可以掐掉這段嗎?所以這里的關(guān)鍵在于,理想的解決方案是告訴實際用戶到網(wǎng)站來做真實的事情。就像發(fā)生在我們身上的一樣,我們希望根據(jù)需要創(chuàng)建密碼狂熱,但是,如果我們能激勵人們加入,那就好了。
不幸的是,這個想法被否決了。但是,事實是,我們決定要做的是,回到我們跟 Locust 的最初策略上。我們決定看看,根據(jù)這些層,我們可以對這個策略做多少改進(jìn)?我們?nèi)绾窝刂@些層往上走,并把這個策略改進(jìn)為我們?nèi)粘9ぷ髦锌梢杂玫膶嶋H東西?
實踐中的容量周期
Sitkin:因此,正如 Luke 所說的,我們回到我們之前被稱為 YOLO 的測試策略。但是,我們從這個新起點(diǎn)開始,更好地了解我們需要負(fù)載測試系統(tǒng)做什么。因此,在這一節(jié)里,我將逐步介紹在我們的實際日常工作中應(yīng)用這個容量周期可能的感覺。就采取負(fù)載系統(tǒng)而言,負(fù)載系統(tǒng)處于一個非?;镜臓顟B(tài),然后,使用我們的周期來增加其真實性。最終,找到我們系統(tǒng)的一些有趣的擴(kuò)展問題。
這個示例的設(shè)置在這里,我們打算盡快開始。我們將其范圍縮小到剛夠用規(guī)范工廠創(chuàng)建種子數(shù)據(jù)。我們可以通過數(shù)據(jù)獲得現(xiàn)實基線水平。然后,對于流量,我們剛打算重新創(chuàng)建腳本,只是一個單用戶流的單個簡化版本,只是那些最基本的可能工作。然后,系統(tǒng)變成基于我們已經(jīng)在運(yùn)行的開發(fā)環(huán)境,即位于負(fù)載平衡器背后的少數(shù)節(jié)點(diǎn),沒有后臺工作人員。然后,我們的三個主要后臺數(shù)據(jù)庫每個只有一個實例。因此很直接,很簡單,很精簡。
我們開始吧。我們進(jìn)行第一個負(fù)載測試,每秒最多 400 個請求。首先,Redis 上的 CPU 得到了充分利用。我們到達(dá)了上限。因此,很自然地,我們會深入查看系統(tǒng)是如何布局的。很明顯,這里的問題是,我們通過運(yùn)行幾個不同的 Redis 集群來隔離生產(chǎn)中的工作負(fù)載,然后在我們的測試環(huán)境中,我們只運(yùn)行這個服務(wù)一切的集群。
因此,這是一個快速的循環(huán)周期。很明顯,我們在這里能做的最簡單的事情是,讓我們的系統(tǒng)更加真實。于是,我們打算通過打破 Redis 集群和測試環(huán)境來改進(jìn)層,以匹配我們在生產(chǎn)環(huán)境中所運(yùn)行的東西。
好了,那么,讓我們再次經(jīng)歷這個周期。結(jié)果,這一次,我們在同一個時間點(diǎn)宕機(jī)了??纯次覀?Redis 集群 CPU 的統(tǒng)計數(shù)據(jù),我們又一次看到其中之一滿負(fù)荷運(yùn)作。事實證明,我們實際上只是忘了禁用一個跟蹤工具,該工具消耗了大量計算資源,而在生產(chǎn)中我們不使用它。因此,我們又有了一個好機(jī)會來提高我們的負(fù)載測試環(huán)境中的系統(tǒng)類別的真實性,即只需要禁用該工具。因此,這是又一個快速反饋周期。
好,我們再來測試一下。這次,我們走得更遠(yuǎn)一些,每秒有 850 個請求。再我們的系統(tǒng)中查看這些指標(biāo),這次發(fā)生了不同的事情。我們查看 Redis 狀態(tài),看上去都沒問題。我們查看 Mongo 統(tǒng)計數(shù)據(jù),看上去也沒問題。所以我們縮小了查看范圍,我們只查看了在這個端點(diǎn)上我們實際看到的生產(chǎn)中的請求,還有我們在負(fù)載測試系統(tǒng)中看到的請求的端到端跟蹤,并且所有內(nèi)容看起來幾乎相同。 但顯然,出現(xiàn)問題比我們預(yù)期的時間要早。 但事實證明,我們注意到我們的應(yīng)用程序節(jié)點(diǎn)上的 CPU 滿負(fù)荷了。 基本上,Ruby 時間是問題的根源。
我們在這里有另一個機(jī)會來提高系統(tǒng)中的真實性,可以通過匹配應(yīng)用程序節(jié)點(diǎn)和我們在生產(chǎn)中實際運(yùn)行的支持服務(wù)之間的比例來實現(xiàn)。最簡單的方法是增加在測試環(huán)境中運(yùn)行的應(yīng)用程序節(jié)點(diǎn)數(shù)量,因為這讓我們與生產(chǎn)系統(tǒng)更為接近。因此,我們可以很快地做出改變,并再次完成該周期。
第四次的時候,我們走得更遠(yuǎn),每秒有 1500 個請求。這一次,出現(xiàn)的第一件事是,我們 MongoDB 集群上的 CPU 負(fù)載太高了。如果你們經(jīng)常使用 MongoDB,應(yīng)該知道 mloginfo 這個出色的工具。我們使用了這個工具。這確實是個非常好的工具,可以用于解析 MongoDB 服務(wù)日志,并提供特定排序細(xì)分,特別是那些查詢形狀在系統(tǒng)中是又昂貴又慢的。
并且,它給我們指出,有一個單獨(dú)的、從未出現(xiàn)過的昂貴的查詢在這里排名很高。這種情況向我們指出一個事實,即在負(fù)載測試系統(tǒng)和生產(chǎn)中的數(shù)據(jù)形狀之間可能有重大的差異。因此,這里我們意識到,在每次負(fù)載測試運(yùn)行之間,我們沒有正確地重置我們的數(shù)據(jù)庫狀態(tài)。這給我們指出了一個事實,我們需要增加數(shù)據(jù)類別的真實性,例如修復(fù)此重置腳本。
現(xiàn)在,我們使用改進(jìn)的負(fù)載測試環(huán)境進(jìn)行另一次測試運(yùn)行。我們在每秒 1400 次請求時出錯,非常類似的范圍。但是這一次,在 MongoDB 上的 CPU 統(tǒng)計數(shù)據(jù)又一次沒問題。但是,通過查看跟蹤,我們看到,事實上來自 Memcached 的響應(yīng)很慢。那絕對是我們不習(xí)慣看到的。因此,我們對這個問題進(jìn)行了一點(diǎn)研究,查看硬件級的統(tǒng)計數(shù)據(jù)。第一件事情是,我們嘗試針對單個 T2 micro 運(yùn)行生產(chǎn)級的負(fù)載。T2 micro 是一個運(yùn)行 Memcached 的很小實例。因此,很顯然,很快就崩潰了。
同樣,這里有個簡單的增加現(xiàn)實性的方法,就是提高 MongoDB 節(jié)點(diǎn)上實例的大小。這給我們另一個機(jī)會來完成一個周期。這一次,我們事實上做得相當(dāng)好;在這個用戶流上每秒有 1700 個請求。從資源的角度看,這實際上是特別昂貴的流。通常,我們在生產(chǎn)中不經(jīng)常碰到這種負(fù)載。在測試環(huán)境中達(dá)到每秒 1750 個請求是非常令人鼓舞的;這是個好結(jié)果。
Mongo 上的 CPU 統(tǒng)計數(shù)據(jù)看起來相當(dāng)不錯,就像我們的跨堆棧硬件統(tǒng)計數(shù)據(jù)一樣,看起來相當(dāng)健康。這讓我們稍作停頓,因為,假如我們這里的用戶流事實上以非常逼真的方法來運(yùn)行的話,那么,我們自然不會期望能夠提供這類負(fù)載。
因此,這讓我們意識到,我們在生產(chǎn)環(huán)境中所看到的和我們在負(fù)載測試環(huán)境中所看到的之間,可能在流量類別上有差異。再深入一點(diǎn),我們注意到,這絕對是事實。為了在我們的應(yīng)用程序中重現(xiàn)這個用戶行為,我們只是運(yùn)行了一小部分真正需要點(diǎn)擊的端點(diǎn)。通過更好地調(diào)查和編寫更好的腳本,以更好地重建用戶在實際執(zhí)行該流程時在日志中所看到的內(nèi)容,那么,我們能夠提高流量類別的真實性。
最后一次運(yùn)行這個周期,這次,我們每秒最多得到 700 個請求。根據(jù)我們可能期望看到的情況,這可能更為現(xiàn)實。分析表明,我們大部分堆棧的硬件統(tǒng)計數(shù)據(jù),特別是 Mongo 沒有問題。我們習(xí)慣于看到 Mongo 中的故障,因此,這常常是我們在數(shù)據(jù)庫層首先查看硬件統(tǒng)計數(shù)據(jù)的地方。
然而,我們 web 節(jié)點(diǎn)上的 CPU 也滿負(fù)荷。上次我們遇到這個問題時,我們覺得測試環(huán)境中的應(yīng)用程序節(jié)點(diǎn)增加了一倍,因為,這讓我們到了更接近生產(chǎn)環(huán)境的地方。但是,這次我們不打算這么做,因為在負(fù)載測試中運(yùn)行的節(jié)點(diǎn)數(shù)量與在生產(chǎn)環(huán)境中的節(jié)點(diǎn)數(shù)量的比例是準(zhǔn)確的。因此,這么做就不對,會因為添加更多節(jié)點(diǎn)而破壞我們的真實性。
但是,當(dāng)我們真正挖掘一些分析以查看我們的應(yīng)用程序在 CPU 方面做了什么事、實際上占用了什么的時候,我們發(fā)現(xiàn)了一些有趣的事情。這是一個我們已經(jīng)意識到的問題。但是,我們注意到,這個特定的性能問題是造成我們這次測試失敗的瓶頸。我們有一些事件跟蹤的處理十分低效。
因此,這里,這是我們希望得到的結(jié)果。我們實際上發(fā)現(xiàn)了一個令人信服的現(xiàn)實瓶頸。當(dāng)我們達(dá)到這個負(fù)載水平時,這可能會讓我們在生產(chǎn)中宕機(jī)。實際上,這里要做的正確的事情是應(yīng)用修復(fù)。因此,我們改進(jìn)了系統(tǒng)。現(xiàn)在我們可以跳回到循環(huán)周期中,并獲得更多的見解。
我把這個例子留在這里。但是,我希望,通過講解這個真實世界的例子,我已經(jīng)讓你知道,這個快速反饋周期有多么的強(qiáng)大。它可以在測試下改進(jìn)系統(tǒng),也可以改進(jìn)測試系統(tǒng)本身。循環(huán)周期的每次迭代都是一個改進(jìn)這些東西其中之一的機(jī)會。不久之后你就會發(fā)現(xiàn),事實上最重要的問題在哪里。
關(guān)于這些問題,還要注意一件重要的事情,即我們也許意識到我們的系統(tǒng)有很多潛在的性能問題。但是,真正的價值在于,它迫使這些問題中的其中一個變?yōu)樽钔怀龅?、最可能讓我們失敗的問題。于是,這讓我們的工作計劃變得非常容易。這是最重要的事,它實際會把能力提升到一個新的水平。
現(xiàn)在,我們在這里,對未來有一些更大的計劃。但是,我希望在本節(jié)留下一個經(jīng)驗,即我們都在負(fù)載測試環(huán)境中追求真實性。但是,關(guān)鍵在于,隨著我們每一步都在增加真實性,這個過程就和最終目標(biāo)一樣重要,因為我們一路上要學(xué)很多東西。
未來
Demi:我們今天就是為此事而來的。我們現(xiàn)在在用的這個負(fù)載是為新貨幣的發(fā)行做準(zhǔn)備的。現(xiàn)在,這更像是 Luke 和 Jordan 的工具。我們能夠用它來找出和確認(rèn)每次我們發(fā)行新貨幣時會引發(fā)流量激增的任何事情。我們可以測試那些已知的在這些過程中將會變得突出的流,并確保沒有在它們發(fā)生前就存在,而我們卻還沒有發(fā)現(xiàn)的瓶頸。
我們目前正在增加這些測試的真實性。構(gòu)建自動化方法來了解最新的流量模式,并把它們應(yīng)用到我們實際在運(yùn)行的測試方法中,這是我們目前的首要任務(wù)。同時,我們要繼續(xù)改進(jìn)我們使用數(shù)據(jù)的方法。我們希望很快得到的結(jié)論是,我們的流量基于完全真實的流量,并且,我們的數(shù)據(jù)基于真實的清洗用戶數(shù)據(jù)。理想情況下,我們的系統(tǒng)也是一樣的。
這個周期將繼續(xù)指導(dǎo)我們。我們對這個容量周期感到非常興奮。我們在內(nèi)部對每個人宣傳此周期的有效性;有些人相信也有些人不信。但是,我們內(nèi)部真正要做的就是堅持這個想法。我們不希望這只是個 Luke 和 Jordan 的工具。因為 Luke 和 Jordan 的工具無法長久存活。當(dāng)我們在做其他事情時分心了,怎么辦?如果這個工具開始分離崩析,怎么辦?它會變得毫無用途。
我們正在嘗試做的是,創(chuàng)建一個可重復(fù)的持續(xù)元素以實現(xiàn)把我們的代碼交付到生產(chǎn)中。我們希望為大家創(chuàng)建這個本質(zhì)上是快速反饋的循環(huán)周期。因此,當(dāng)有人推動新的生產(chǎn)變革時,他們應(yīng)該知道它會不會影響生產(chǎn)工作中的績效。因此,我們處理這個問題的一些方法可能成為壓縮測試環(huán)境中構(gòu)建過程的一部分,比如一個非常一致的環(huán)境。我們能夠處理多少請求來掌控最重要的流?這些是我們現(xiàn)在要關(guān)注的事情。
教訓(xùn)
但是,在我們離開之前,我想再快速回顧一下我們的教訓(xùn)。首先,良好的工具會讓問題浮現(xiàn)出來,而糟糕的工具會使問題變得模糊不清,讓我們感到困惑。我認(rèn)為,這適用于幾乎任何事情,特別是,如果我們是那些經(jīng)常在生產(chǎn)中挖掘問題的人。如果我們沒有合適的工具,那么就添加合適的工具。如果我們不了解我們的工具,那么要保持好奇,去研究它。不要以為我們看到的就是實際存在的。
更快的反饋意味著更快的進(jìn)展。這適用于一切,但是,特別適用于我們的生存能力,以及在這些瘋狂流量增長時期有所發(fā)展。這只是因為,我們能夠使用這個快速反饋來指導(dǎo)我們采取的行動。最終,我們使用簡化的負(fù)載測試環(huán)境獲得出色的負(fù)載測試結(jié)果,并增加了真實性。
因此,當(dāng)我們進(jìn)行負(fù)載測試時,過程和目標(biāo)一樣有價值。不要害怕深入,立即開始以取得成果。我們過去曾經(jīng)遇到問題,我們已經(jīng)經(jīng)歷了無數(shù)次宕機(jī)。我們一開始就想到真實性,并試圖讓一切都和生產(chǎn)環(huán)境中的一樣,但是,在這個過程中,我們失去了一路上所學(xué)到的東西。
演講到此結(jié)束。最終,我們學(xué)到了關(guān)于容量規(guī)劃的很多真正有價值的經(jīng)驗教訓(xùn)。我們當(dāng)然希望這個演講能幫助你避免犯我們已經(jīng)犯過的錯。這是我們的推特號。但是,我們真的很想知道你們是如何在現(xiàn)場進(jìn)行負(fù)載測試的。希望這能激發(fā)一些有趣的對話。當(dāng)然,也可以在會議的其他時間通過推特聯(lián)系我們。
問與答
參與者 1:謝謝你們的演講。很有見解,真實地反映了我們團(tuán)隊現(xiàn)在正在進(jìn)行的一些活動。我很想從你們的經(jīng)驗中學(xué)到東西,并把它應(yīng)用到我的團(tuán)隊中。我的一個問題是,你們是從哪里觸發(fā)這些任務(wù)的?如果負(fù)載測試從生產(chǎn)負(fù)載中減去 5 倍、10 倍、50 倍,那么,你們會延伸到什么程度?你們是否會滿足于“好吧,目前的設(shè)計就這樣了,它能夠支持什么”?
Sitkin:Locust 提供了一個 web UI,讓我們真正開始測試。因此,這是使用這個開源工具的好處之一。為了回答你關(guān)于我們?nèi)绾螞Q定將測試提升到什么程度的問題,到目前為止,我們基本上把它設(shè)置在一個荒謬的程度上,我們在尋找性能開始下降、服務(wù)崩潰的時間點(diǎn)。
因此,在這個時間點(diǎn)上,我們真正在做壓力測試。我們在尋找系統(tǒng)停止工作的時間,然后只是測量這個程度是什么,不斷地將它增加。我們對想要達(dá)到的目標(biāo)有個粗略的想法,這是上次在解決中讓我們宕機(jī)原因的一個粗略倍數(shù)。但是,其中很大一部分只是意識到特定用戶流從哪里開始消失。
參與者 1:還有一個問題。由于依賴服務(wù)不受你們控制,你們是如何使用依賴服務(wù)的?如果這些是瓶頸,你們有什么建議來解決它們,甚至和這些團(tuán)隊合作來解決問題?
Sitkin:是的,這就是我說的負(fù)載測試中有點(diǎn)藝術(shù)性的一部分。我們在開始時非常簡單的一個好處是,如果很難開始,那么就放一邊。然后,當(dāng)你對一小部分流的真實性有信心時,就可以開始逐個把這些依賴項添加進(jìn)去。它們中的每一個都會有自己的特性,關(guān)于刪除或模擬的最好方法。
例如,作為加密貨幣公司,我們最終觸及的很多事情都是區(qū)塊鏈。當(dāng)然,我們必須創(chuàng)造性地剔除這些東西。我們用這樣的東西只能實現(xiàn)一定程度的真實性。因此,我發(fā)現(xiàn)很難對這類問題給出一個普遍的答案。但是,我認(rèn)為,回到流程,一切都是關(guān)于逐一解決它們的問題。獲得快速反饋周期,并一次只添加一個。不是一下子就追求完全的真實性。因為通過添加一個更改獲得的觀察結(jié)果可能非常有用。
參與者 2:謝謝你的精彩演講。我的問題是,作為一家快速發(fā)展的公司,當(dāng)你們飛快地發(fā)布新產(chǎn)品和新功能時,你們是否在生產(chǎn)中看到,數(shù)據(jù)的形狀和請求的模式經(jīng)常變化?如果是這樣,你們?nèi)绾巫屇銈兊呢?fù)載測試環(huán)境跟得上這些改變?
Demi:是的,特別是在流量方面,這是使用捕獲回放的主要好處之一。你可以保證捕獲并再次運(yùn)行,你可以保證流量是最新的。但是。我們現(xiàn)在的處理方法是。通過一個腳本運(yùn)行于數(shù)據(jù)的各個部分,然后我們提取其中存在的流。因此,存在一定的有狀態(tài)流。因此,你不能只是按順序回放請求,需要把它們拉出來。
我們能夠做的是,生成數(shù)據(jù)形狀,然后把它們應(yīng)用到 Locust 上。這個部分事實上更容易。數(shù)據(jù)的形狀實際上極其困難。這是我們完全沒解決的問題。我們知道數(shù)據(jù)的形狀是什么樣的,我們實際上能夠使用我們數(shù)據(jù)團(tuán)隊在用的分析工具。
它們能夠在我們擁有的最大用戶上指導(dǎo)我們,比方說,10000 個不同的交易,對嗎?因此,我們可以在那里構(gòu)建一個分布,但是要保持它是最新的,我們根本沒解決這個問題。這很難。但是,理想情況下,我們可以做的是,與這些工具進(jìn)行交互,并在我們清除和更新測試時進(jìn)行調(diào)整。
參與者 3:很棒的演講。我想知道,因為生成負(fù)載測試是相當(dāng)昂貴的,基本上像攻擊,因為我們試圖讓網(wǎng)站宕機(jī)。我想知道,你是否找到一個方法可以計算實際情況下的理論極限值?是否可以根據(jù)一些例子,據(jù)此推斷并找到下一個瓶頸在哪里?
Sitkin:我接觸過一點(diǎn)通用擴(kuò)展理論的概念。當(dāng)我們實施這個有點(diǎn)巧妙的方法進(jìn)行負(fù)載測試時,這些是我們要注意的事情。這也有助于我們形成關(guān)于什么可能出錯的假設(shè)。但是,我認(rèn)為,我們發(fā)現(xiàn)進(jìn)入循環(huán)周期的好事是,我們很快就能測試這些假設(shè)。這也有點(diǎn)讓我們的性能理論方法變得更好,看到這些東西與現(xiàn)實世界的真實關(guān)系。但是,為了更直接地回答你的問題,我們還沒有做類似學(xué)術(shù)研究的方法。我們一直在實踐中關(guān)注那些我們系統(tǒng)中產(chǎn)生的啟發(fā)。你有什么不同意見嗎?
Demi:代價不菲?,F(xiàn)在我們要做的是,構(gòu)建一些真正復(fù)雜的技術(shù),以讓我們不因為財務(wù)問題而失敗。這就涉及到如何進(jìn)行擴(kuò)展。幸運(yùn)的是,AWS 使這個變得非常簡單。數(shù)據(jù)庫擴(kuò)展的方式,應(yīng)用程序服務(wù)擴(kuò)展的方式,我們有一個腳本來啟動和關(guān)閉。這是有幫助的。
但是,我們喜歡做的是,當(dāng)我們接受這種擠壓測試的想法時,每一個進(jìn)入我們主要項目的拉取請求或提交,這就是我們打算做的事。我認(rèn)為,我們還沒有真正討論作為一個開始,我們可以做什么,但是,使用我們在擠壓測試環(huán)境中目前所有的相同數(shù)據(jù),并在完整的生產(chǎn)環(huán)境中也這么做,來看看它們能處理多少。然后,我們可以進(jìn)行推斷,那將是個相當(dāng)不錯的處理方法。你對這個想法有什么看法?
Sitkin:好主意。Luke。
Demi:一起做個演講不容易。我們必須對每個想法進(jìn)行交流。我很高興你喜歡這樣。