丨性能及穩(wěn)定性上如何優(yōu)化擴展etcd

希望通過這兩節(jié)課的學習，能讓你在使用etcd的時候，設計出良好的業(yè)務結(jié)構(gòu)，遵循etcdetcd性能 甚至更換技術方案去etcd化。我們說讀性能差，其實本質(zhì)是讀請求鏈路中某些環(huán)節(jié)出現(xiàn)了瓶頸。所以，接下來我將通過一張讀性能分析鏈路圖，為你從上至下分析影響ecd性能、穩(wěn)定性的若干因素，并給出相應的壓測數(shù)據(jù)，最終為你總結(jié)出一系列的etcd性能優(yōu)化和擴展方法。在下圖中，我為你總結(jié)了一個開啟鑒權(quán)場景的讀性能瓶頸分析鏈路圖，并在每個步驟數(shù)字旁邊，標出了影響性能的關鍵因素。我之所以選用鑒權(quán)的讀請求為案例，是因為它使用較廣泛并且請求鏈路覆蓋最全，同時它也是最容易遇到性能瓶頸的場景。起看看影響它性能表現(xiàn)的因素以及最佳優(yōu)化實踐。首先是流程一負載均衡。在02節(jié)時我和你提到過，在etcd3.4以前，為了節(jié)省與server節(jié)點的連接數(shù)，v3負載均衡器最終只會選擇一個sever節(jié)點IP，與其建立但是這可能會導致對應的server節(jié)點過載（如單節(jié)點流量過大，出現(xiàn)丟包），其他節(jié)點卻是低負載，最終導致業(yè)務無法獲得集群的最佳性能。在etcd3.4后，引入了Round-robin負載均衡算法，它通過輪詢的方式依次從endpoint列表中選擇一個endpoint(長連接)，使server節(jié)點負載盡量均衡。所以，如果你使用的是etcd低版本，那么我建議你通過LoadBalancer后端etcd集群。因為一方面LoadBalancer一般支持配置各種負載均衡算法，如連接數(shù)、Round-robin等，可以使你的集群負載更加均衡，規(guī)避etcd 通過負載均衡算法為請求選擇好etcdserver節(jié)點后， 就可調(diào)用server的RangeRPC方法，把請求發(fā)送給etcdserver。在此過程中，如果server啟用了鑒權(quán)，那 如果server使用的是鑒權(quán)，你在創(chuàng) 是如何向sever請求校驗用戶名、正確性的呢是通過向server發(fā)送AuthenticateRPC鑒權(quán)請求實現(xiàn)認證的，也就是圖中的根據(jù)我們05介紹的認證原理，server節(jié)點收到鑒權(quán)請求后，它會從bob獲取此用戶對應的算法版本、salt、cost值，并基于用戶的請求明文計算出一個hash在得到hash值后，就可以對比db里保存的hash是否與其一致了。如果一致，就會返回一個token給。這個token是 server節(jié)點的通行證，后續(xù)server只需要校驗“通行證”是否有效即可，無需每次發(fā)起昂貴的AuthenticateRPC請求。講到這里，不知道你有沒有，若你的業(yè)務在etcd過程中未復用token，每次訪問etcd都發(fā)起一次Authenticate調(diào)用，這將是一個非常大的性能瓶頸和隱患。因為正如我們05所介紹的，為了保證的安全性，認證（Authenticate）的開銷非常昂貴，涉及到大量CPU那這個Authenticate為了得到Authenticate壓測集群etcd節(jié)點配置是16核32G；壓測方式是我們通過修改etcd v3庫、ben ark工具，使ben ark工具支持Authenticate接口壓測； 和connection參數(shù)，運行多次，觀察結(jié)果是否穩(wěn)定，獲取測試最終的非常驚人。etcdv3.4.9之前的版本，Authenticate接口性能不到16 和connection增多，該性能會繼續(xù)。 和connection的數(shù)量達到200個的時候，性能會下降到8QPS，P99延時18對此，我和小伙伴王超凡通過一 減少鎖的范圍PR（該PR已經(jīng)cherry-pick到了3.4.9版本），200QPS，并且P99延時在1由于導致Authenticate接口性能差的瓶頸，是在于鑒權(quán)使用了bcrpt計算最令人頭疼的是，Auenticate的調(diào)用由v3庫默默發(fā)起的，etcd中也沒有任何日志記錄其耗時等。當大家開啟鑒權(quán)后，遇到讀寫接口超時的時候，未詳細了解etcd的同我收到小伙伴的求助，協(xié)助他們排查etcd異常超時問題。通過metrics定位，我發(fā)現(xiàn)這些問題大都是由比較頻繁的Authenticate調(diào)用導致，只要臨時關閉鑒權(quán)或升級到etcdv3.4.9版本就可以恢復。為了幫助大家快速發(fā)現(xiàn)Authenticate等特殊類型的expensiverequest，我在etcd3.5版本中提交了一個PR，通過gRPC器的機制，當一個請求超過300ms時，就會打印第一，如果你的生產(chǎn)環(huán)境需要開啟鑒權(quán)，并且讀寫QPS較大，那我建議你不要圖省事使用鑒權(quán)。最好使用鑒權(quán)，這樣能完美避坑認證性能差、toen過期等問題，性能幾乎無損失。第三，如果你使用鑒權(quán)時遇到性能瓶頸問題，可將etcd升級到3.4.9及以上版本，能通過在這個步驟中，讀模式對性能有著至關重要的影響。我們前面講過etcd提供了串行讀和線性讀兩種讀模式。前者因為不經(jīng)過ReaIndex模塊，具有低延時、高吞吐量的特點；而后者在犧牲一點延時和吞吐量的基礎上，實現(xiàn)了數(shù)據(jù)的強一致性讀。這兩種讀模式分別為不同場景的讀提供了解決方案。 16核32G，三個server節(jié)點8核16G、SSD盤， 與server節(jié)RTT0.1ms0.2msetcdv3.4.91000 112 ark--endpoints=addr--conns=100-s=1000o--consistency=s--得到串行讀壓測結(jié)果如下，32QPS，2.5ms。12 ark--endpoints=addr--conns=100-s=1000o--consistency=l--得到線性讀壓測結(jié)果如下，19萬QPS，平均延時4.9ms10011萬需要注意的是，以上讀性能數(shù)據(jù)是在1個ky、沒有任何寫請求、同可用區(qū)的場景下壓測出來的，實際的讀性能會隨著你的寫請求增多而出現(xiàn)顯著下降，這也是實際業(yè)務場景性能與社區(qū)壓測結(jié)果存在非常大差距的原因之一。所以，我建議你使用ecdenark在你的ecd集群環(huán)境中自測一下，你也可以參考下面的etcd社區(qū)壓測結(jié)果。如果你的業(yè)務場景讀QPS較大，但是你又不想通過ecd 等機制來擴展性能，那可以進一步評估業(yè)務場景對數(shù)據(jù)一致性的要求高不高。如果你可以短暫的不一致，那你可以通過串行讀來提升etcd的讀性能，也可以部署Learer節(jié)點給可能會產(chǎn)生exeiereadreest的業(yè)務使用，實現(xiàn)cheapexeiereadreest。了解完讀模式對性能的影響后，我們繼續(xù)往下分析。在我們這個鑒權(quán)讀請求的性能分析案例中，讀請求使用的是etcd默認線性讀模式。線性讀對應圖中的流程四、流程五，其中流程四對應的是ReadIdex，流程五對應的是等待本節(jié)點數(shù)據(jù)追上Leaer的進度在早期的etcd3.0版本中，etcd線性讀是基于Raftlogread實現(xiàn)的。每次讀請求要像寫請求一樣，生成一個Raft日志條目，然后提交給Raft一致性模塊處理，基于Raft日志執(zhí)行的有序性來實現(xiàn)線性讀。因為該過程需要經(jīng)過磁盤I/O，所以性能較差。為了解決Raftlogread的線性讀性能瓶頸，etcd3.1中引入了ReadIndex。ReadIndex僅涉及到各個節(jié)點之間網(wǎng)絡通信，因此節(jié)點之間的RTT延時對其性能有較大影響。雖然同跨可用區(qū)部署時，各個可用區(qū)之間延時一般在2毫秒內(nèi)。如果跨城部署，服務性能就會下降較大。所以一般場景下我不建議你跨城部署，你可以通過Learner節(jié)點實現(xiàn)異地容災。如果異地的服務對數(shù)據(jù)一致性要求不高，那么你甚至可以通過串行讀Learner節(jié)點，各個節(jié)點之間的RTT延時，是決定流程四ReadIndex性能的因一磁盤IO到了流程五，影響性能的因素就是磁盤IO延時和寫QPS如下面代碼所示，流程五是指節(jié)點從Leader獲取到已提交的日志條目索引(rs.Index)后，它需要等待本節(jié)點當前已應用的Raft日志索引，大于等于Leader的已提交索引，確123456789ifai:=s.getAppliedIndex();ai<rs.Index{select{case<-case<-s.stop}:}//unblockalll-readsrequestedatindicesbefore而應用已提交日志條目到狀態(tài)機的過程中又涉及到隨機寫磁盤，詳情可參考我們03中介紹過etcd的寫請求原理。因此我們可以知道，etcd是一個對磁盤IO性能非常敏感的系統(tǒng)，磁盤IO性能不僅會影響Leader穩(wěn)定性、寫性能表現(xiàn)，還會影響讀性能。線性讀性能會隨著寫性能的增加而快速下降。如果業(yè)務對性能、穩(wěn)定性有較大要求，我建議你盡量使用SSD盤。下表我給出了一個8核16G的三節(jié)點集群，在總key數(shù)只有一個的情況下，隨著寫請求增大，線性讀性能下降的趨勢總結(jié)（基于benark工具壓測結(jié)果），你可以直觀感受當本節(jié)點已應用日志條目索引大于等于Leader已提交的日志條目索引后，讀請求就會接到通知，就可通過MVCC模塊獲取數(shù)據(jù)。RBAC規(guī)則數(shù)、Auth讀請求到了MVCC模塊后，首先要通過鑒權(quán)模塊判斷此用戶是否有權(quán)限請求的數(shù)據(jù)路徑，也就是流程六。影響流程六的性能因素是你的RBAC規(guī)則數(shù)和鎖。RBACkeyetcd內(nèi)，時間復雜度僅需要O(logN另外一個因素則是AuthStore的鎖。在etcd3.4.9之前的，校驗接口可能會占用較長時間的鎖，導致接口阻塞。etcd3.4.9之后合入了縮小鎖范圍的PR，可一定程度降低expensiverequest、treeIndex通過流程六的后，則進入流程七，從treeIndex中獲取整個查詢涉及的key列表版本號信息。在這個流程中，影響其性能的關鍵因素是treeIndex的總key數(shù)、查詢的key數(shù)、獲取treeIndex鎖的耗時。首先，treeIndex中總key其次，若要reeInex須獲取到鎖，但是可能其他請求如compact操作也會獲取鎖。早期的時候，它需要遍歷所有索引，然后進行數(shù)據(jù)壓縮工作。這就會導致其他請求阻塞，進而增大延時。compacttreeIndex接下來我重點給你介紹下查詢key數(shù)較多等expensivereadrequest假設我們鏈路分析圖中的請求是查詢一個Kubernetes集群所有Pod，當你Pod數(shù)一百以內(nèi)的時候可能對etcd影響不大，但是當你Pod數(shù)千甚至上萬的時候，流程七、八就會遍歷大量的key，導致請求耗時突增、內(nèi)存上漲、性能急劇下降。你可結(jié)合 13db大小、14延時、15內(nèi)存三節(jié)一起看看，這里我就不再重復描述。expensivereadrequestexpensivereadrequestList全量數(shù)據(jù)，然后通過etcdWatch機制去獲取增量變更數(shù)據(jù)。比如Kubernetes的Informer機制，就是典型的優(yōu)化實踐。其次，在設計上評估是否能進行一些數(shù)據(jù)分片、拆分等，不同場景使用不同的etcdrefix前綴。比如在Kuerees中，Pod全部都部署在efalt命名空間下，盡量根據(jù)業(yè)務場景按命名空間拆分部署。即便每個場景全量拉取，也只需要遍歷自己命名空間下的資源，數(shù)據(jù)量上將下降一個數(shù)量級。再次，如果你覺得Watch改造大、數(shù)據(jù)也無法分片，開發(fā)麻煩，你可以通過分頁機制按批最后，如果以上方式都不起作用的話，你還可以通過引入cache實現(xiàn)緩存expensivereadrequest的結(jié)果，不過應用需緩存數(shù)據(jù)與etcd的一致性。大key-value、bob從流程七獲取到key列表及版本號信息后，我們就可以bo b模塊，獲取key-value信息了。在這個流程中，影響其性能表現(xiàn)的，除了我們上面介紹的expensivereadrequest，還有大key-value和鎖。首先是大key-value。我們知道etcd設計上定位是個小型的元數(shù)據(jù)，它沒有數(shù)據(jù)分片機制，默認dbquota只有2G，實踐中往往不會超過8G，并且針對每個key-value大小，它也進行了大小限制，默認是1.5MB。大key-valueetcdOOM、serveretcd1MBkey-value17我們可以執(zhí)行如下benark12ark--endpoints=addr--conns=100-s=1000rangekey--consistency=l--得到其結(jié)果如下，從下圖你可以看到，一個1MB的key-value，線性讀性能QPS下降到1163，平均延時上升到818ms，可見大key-value對性能的巨大影響。其次是鎖，etcd為了提升bo b讀的性能，從etcd3.1到etcd3.4版本，分別進行過優(yōu)化讀性能的思路是首先我們可通過etcd v3自帶的Round-robin負載均衡算法或者LoadBalancer，盡量確保整個集群負載均衡。30倍。線性讀性能受節(jié)點之間RTT延時、磁盤IO