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)粘９ぷ髦锌梢杂玫膶嶋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)行交流。我很高興你喜歡這樣。
