INFOCOM'22：面向最大邊緣吞吐量的層感知協作微服務部署 - 網安

如今，輕量級的基于容器的微服務被廣泛提出，以提升邊緣云的彈性。而容器所固有的分層結構提供了一種引人注目的方法來解決邊緣服務器的資源稀缺問題，即通過層共享來應對，這可以顯著提高存儲利用率并提高邊緣吞吐量。最近的研究表明，不僅可以在同一臺服務器內可以實現層的共享，而且可以在服務器之間進行。因此，在微服務部署時可以充分利用這一點。在本文中，我們研究了如何通過結合服務器內和服務器間兩種層共享模式來協同部署微服務，以最大化邊緣吞吐量的問題。我們將這個問題表述為整數線性規劃形式，并將其證明為 NP難問題。我們提出了一種基于隨機舍入的啟發式算法，并對其具有合理的近似比進行形式化分析。通過大量的實驗，我們驗證了我們提出的算法的效率，結果表明，和當前最先進的兩種策略相比，它可以分別多部署6倍和12倍微服務實例，并且邊緣吞吐量分別提高了27.74%和38.46%。

該結果“Layer-aware Collaborative Microservice Deployment toward Maximal Edge Throughput”發表在IEEE Infocom 2022，是實驗室分布式系統組在微服務部署領域的研究成果。

背景與動機

通過在網絡邊緣提供計算資源，邊緣云已成為一個與云系統互補的有前途的平臺。由于具有終端用戶距離近的優勢，邊緣云非常適合許多對延遲敏感的應用，例如自動駕駛、醫療保健、增強現實、智能制造等。但是，與大型數據中心賦能的中心云相比，邊緣云資源比較稀缺。因此，如何最有效地利用邊緣資源便成為近來的主要研究熱點之一。另一方面，基于容器的微服務被提倡作為一種邊緣服務提供范式，這要歸功于它的輕量級優勢，與傳統的虛擬機 (VM) 相比具有更好的靈活性和彈性。

雖然容器相對較輕量級，但它們所占的空間仍遠不能忽略不計。例如，Docker Hub中下載次數最多的134個鏡像的大小從109MB到2045MB不等。這給存儲帶來了沉重的負擔，嚴重限制了邊緣服務器的服務能力。同時也會導致圖片下載流量大，微服務啟動慢。最近的一項研究表明，在100Mbps網絡上，單個微服務的平均啟動時間高達20.7秒，其中72.4%的啟動時間用于鏡像下載。為了克服這個問題，現有研究已經嘗試縮小容器鏡像大小，啟用部分鏡像下載，預導入所需庫或重新設計容器鏡像等方法。

通過仔細檢查容器架構，可以觀察到像Docker的容器鏡像具有內在的分層結構。可以適當地利用這樣的特征來減少鏡像存儲需求、下載流量以及微服務啟動時間，而無需重構容器鏡像。基于容器的微服務將其容器鏡像中所需的所有內容打包并存儲在多個層中，包括運行時工具、系統工具和系統依賴項。因此，在服務器上部署微服務本質上相當于將所有需要的層加載到服務器中。幸運的是，已經指出一些公共層（尤其是那些只讀層）可以在同一服務器上的不同微服務之間共享（即服務器內共享）或通過分布式文件系統跨不同服務器共享（即服務器間共享）。最近的一項研究表明，57個具有代表性的微服務鏡像具有19個公共基礎層。以Cassandra、JAVA、Python和gcc的微服務為例，它們的鏡像都需要一個非最新的Debian Linux分布層。通過共享公共層，可以顯著降低微服務的存儲需求。這不僅減少了鏡像下載流量和啟動時間，而且潛在地擴展了資源受限的邊緣服務器的服務容量。

在邊緣云系統中，考慮到邊緣服務器的資源稀缺性，在微服務部署過程中自然會考慮層共享。現有研究在很大程度上將容器視為輕量級VM。最近有學者提出一種層共享微服務部署解決方案來提高邊緣吞吐量（定義為邊緣云滿足的請求數）。但是，本研究僅關注服務器內層共享。在考慮跨服務器層共享的情況下，只要啟動時間可以接受，本地沒有存儲的層可以從另一臺服務器加載。這實質上擴大了層共享范圍并提高了資源利用率以實現更高的邊緣吞吐量。到目前為止，還沒有系統的研究可以定量地描述吞吐量的提高，而這項工作試圖填補這一空白。

值得注意的是，通過啟用服務器間層共享，微服務部署和層存儲不再緊密耦合，因為微服務所需的層可以獨立于微服務之外存儲。因此，微服務部署不可避免地變得更加復雜，因為邊緣服務器現在可以相互協作以平衡存儲和計算資源的使用，以便處理邊緣云上的更多請求。這項工作側重于以最大化邊緣吞吐量為目標的分層感知協作微服務部署，這被證明是NP難的。為解決計算復雜度問題，本文提出了一種基于隨機舍入的啟發式算法。

設計與實現

層共享有利于提高資源有限邊緣服務器的吞吐量。我們以三個常用的微服務MySQL、Nginx和Cassandra為例，他們的最新版本分別為 443MB、109MB 和 323MB，且都基于CentOS的同一個大小為55MB的非最新Linux分布層。將這三個微服務的鏡像放置在同一個邊緣服務器之上時，這個基于CentOS的Linux基礎層可以被所有鏡像使用，因此在保證計算資源、通信資源充足時，考慮層共享結構，一方面可以避免重復多次下載，有效降低微服務放置的下載流量，另一方面可以減少重復放置基礎層帶來的存儲容量開銷。一旦微服務放置成功，它們就會投入運行以處理用戶請求。無法在本地處理的請求會被卸載到另一個放置有該微服務的邊緣服務器或云端進行處理，最終達到最高的吞吐量。由于減少了從倉庫下載到帶寬有限的服務器的鏡像總大小，層共享在一定程度上可以加速微服務啟動。以上優勢都是不考慮MySQL、Nginx和Cassandra的層共享性質，將他們的鏡像分別視為一個整體所不能實現的。上面的例子告訴我們層共享確實有利于降低微服務放置的下載流量和存儲開銷。同時，請求調度應與層感知微服務放置一起考慮，以提高資源受限邊緣服務器的服務提供能力。服務器間層共享解耦了微服務部署和層存儲，并使服務器協作能夠平衡它們的存儲和計算資源使用。這就提出了一個新問題，即如何制定微服務部署和分層存儲決策，以更好地利用邊緣資源實現最大邊緣吞吐量。

在本文中，我們考慮以最大化邊緣吞吐量為目標的協作層感知微服務部署和層存儲問題（JMDLS）。通過利用服務器內和服務器間的層共享，我們共同平衡存儲和計算資源的使用，以最大限度地提高邊緣云的服務能力。我們將問題表述為 ILP 形式，并通過將其簡化為聯合背包問題來證明它是NP難的。

我們提出了一種基于隨機舍入的啟發式算法，且該算法具有合理的近似比。為了解決計算復雜性，我們結合了JMDLS公式并提出了一種基于隨機舍入 (RR) 的算法來尋找解決方案。該算法通過將二進制變量放寬為 [0,1]，整數線性規劃形式的原始JMDLS公式首先被松弛為可以在多項式時間內求解的線性規劃問題。通過求解松弛JMDLS得到的實數解可以被認為是做出決策的概率。因此，部署和存儲決策分別按照概率進行對應設置。由于松弛和隨機舍入的解決方案可能違反資源容量限制，因此，我們檢查是否違反了任何存儲資源、計算資源或通信資源的容量限制，如果是則對放置決策進行合理地修正。

為了驗證算法的有效性，我們分別在小規模的模擬場景和大規模的實際場景中評估我們提出的基于隨機舍入的啟發式算法的性能。小規模的模擬場景中，我們利用Gurobi計算最佳放置策略，將其與我們的算法進行比較，驗證相比于其他放置策略，我們的算法與最佳放置策略足夠接近，有著良好的性能。在大規模的實際場景中，我們設計由14個分布式邊緣服務器組成的邊緣云，其存儲容量、計算能力、上行鏈路容量、下行鏈路容量和數據訪問速率范圍為分別為109~1045MB、8~12GHz、320~2400Mbps、1280~1920Mbps和100~400Mbps。考慮了來自Docker Hub的80個微服務。每個微服務的層數在6~13之間，鏡像大小在109~2045MB 之間，計算資源需求在1~5MHz之間。在具體實驗時，我們在不同的請求分布情況下，在保持其他條件不變的前提下，分別增加存儲資源、計算資源和帶寬資源，統計所有邊緣服務器上的吞吐量，與當前最先進的兩種策略LA-MPRS和JSPRR進行對比，從而等到最終實驗結果。我們提出的算法的效率通過大量實驗得到驗證，實驗結果（圖1和2）表明和當前最先進的兩種策略相比，它可以分別多部署6倍和12倍微服務實例，并且邊緣吞吐量分別提高了27.74%和38.46%。