層感知的邊緣微服務部署與請求調度策略
在基于容器的微服務被廣泛應用于邊緣計算的前提下，運行過程中以容器鏡像的形式封裝的微服務需要頻繁地被從遠程倉庫下載到本地邊緣服務器，這會產生大量下載流量和本地存儲方面的開銷。鑒于邊緣服務器資源有限，最大限度地減少以上開銷以增強微服務性能至關重要。其中，基于容器的微服務所具有的分層結構性質尚未得到有效利用，即不同微服務在同一邊緣服務器中放置的基礎層可以被共享。本文提出了層感知的邊緣微服務放置和請求調度問題，即如何通過合理利用同一服務器的鏡像之間的層共享特性，有效地增加微服務的放置數量和服務吞吐量。我們將該問題抽象化為具有近似子模性的優化問題，并證明該問題具有NP難的性質，并進一步設計了具有合理近似比的迭代貪心算法。大量實驗驗證了該算法的有效性，與當前最先進的微服務放置策略相比，迭代貪心算法放置的微服務數量可以增加27.61%，微服務吞吐量可以提高73.13%。
該結果“Layer Aware Microservice Placement and Request Scheduling at the Edge”發表在IEEE Infocom 2021，是實驗室分布式系統組在微服務部署領域的研究成果。
- 論文原文：
- https://ieeexplore.ieee.org/document/9488779
背景與動機
通過在用戶附近提供服務，邊緣計算可以快速并按需應對飛速增長的服務和用戶的需求。而針對資源受限的邊緣設備，提供輕量級和易于部署的服務是一個必然的趨勢。因此，基于容器的微服務被認為是一種解決問題的有效方式。與虛擬機（VM）不同，容器與底層主機共享操作系統內核，從而以更低的開銷實現更快的服務啟動。正因如此，微服務自然更適合邊緣計算中的服務開發和運營，因此受到了學術界和工業界的廣泛關注。微服務放置是微服務編排中的主要任務之一。當前，人們已經針對與其相關的不同目標進行了廣泛的研究，例如，更好的資源效用、更低的服務成本或更快的微服務啟動，提出了許多不同的近似算法，例如貪心策略、啟發式算法和機器學習等。然而，現有的微服務放置工作本質上將容器視為具有較小資源需求的輕量級虛擬機。實際上，基于容器的微服務有兩個根本上不同于虛擬機放置的特性。
第一個特性是，一旦將虛擬機放置在邊緣服務器上，傳統的基于虛擬機的服務就會在數小時、數天甚至數月的時間內持續提供某些功能。因此，現有的放置研究通常側重于提高資源效用或最小化資源消耗。但是，事實上，微服務通常是短暫的，需要根據實時服務需求動態激活和停用。例如，谷歌每秒啟動7000多個微服務，其中27%的生命周期短于5分鐘，11%甚至短于1分鐘。因此，基于容器的微服務放置需要經常性地被重新做出決策。此外，必須首先及時從遠程倉庫下載相應的容器鏡像到本地磁盤以進行微服務放置。當微服務鏡像較大時，頻繁的下載會導致大量的流量開銷，導致下載時延較長。這嚴重阻礙了微服務的啟動速度，成為微服務編排的主要瓶頸。
另一個特性是基于容器的微服務與虛擬機具有完全不同的結構。容器鏡像采用分層結構，將運行時工具、系統工具、libs、系統依賴等所需項目打包在不同的獨立層中。因此，可以按層下載和存儲微服務鏡像。不同的鏡像可能共享幾個共同的基礎層。最近在其他論文中的一項調查更是表明，57個代表性鏡像可以共享19個基礎層，Docker等主流容器產品支持放置在同一服務器上的鏡像之間的層共享。通過這個性質，多個不同的微服務只需要從倉庫下載一份共享層，這點特別有利于資源有限的邊緣服務器。
因為更加靠近用戶，在邊緣啟用微服務可以實現低延遲和快速響應。因此，在邊緣滿足用戶請求自然比在云中更有利，用戶能夠獲得更好的體驗質量。鑒于上述基于容器的微服務特性，在邊緣放置微服務主要存在兩個困難：（1）如何在下載流量和存儲方面最大限度地減少與放置相關的開銷；(2)如何將分層結構恰當地應用到放置中。在本文中，我們首次研究了層感知的微服務放置與請求調度 (LA-MPRS) 問題，其目標是最大化邊緣吞吐量，即邊緣服務器所滿足的請求數量。這被證明是一個具有挑戰性的問題，因為微服務放置和請求調度問題通常被表述為整數線性規劃 (ILP) 問題。由于與放置決策高度相關分層結構的存在，這個問題被進一步復雜化。之后我們進一步設計了關于LA-MPRS問題的迭代貪心算法，在微服務放置與請求調度方面解決了以上困難。
設計與實現
層共享有利于提高資源有限邊緣服務器的吞吐量。我們以四個常用的微服務Cassandra、JAVA、Python和gcc為例，他們都基于 Debian 的同一個非最新Linux分布層。將這四個微服務的鏡像放置在同一個邊緣服務器之上時，這個基于Debian的Linux基礎層可以被所有鏡像使用，因此在保證計算資源、通信資源充足時，考慮層共享結構，一方面可以避免重復多次下載，有效降低微服務放置的下載流量，另一方面可以減少重復放置基礎層帶來的存儲容量開銷。一旦微服務放置成功，它們就會投入運行以處理用戶請求。無法在本地處理的請求會被卸載到另一個放置有該微服務的邊緣服務器或云端進行處理，最終達到最高的吞吐量。由于減少了從倉庫下載到帶寬有限的服務器的鏡像總大小，層共享在一定程度上可以加速微服務啟動。以上優勢都是不考慮Cassandra、JAVA、Python和gcc的層共享性質，將他們的鏡像分別視為一個整體所不能實現的。上面的例子告訴我們層共享確實有利于降低微服務放置的下載流量和存儲開銷。同時，請求調度應與層感知微服務放置一起考慮，以提高資源受限邊緣服務器的服務提供能力。
圖1 （a）存儲資源容量（b）啟動時間閾值 （c）計算資源容量（d）通信資源容量對邊緣吞吐量和服務實例數量的影響
考慮到層共享，我們研究了層感知的邊緣微服務放置與請求調度（LA-MPRS）問題，以在資源受限的邊緣實現最大吞吐量，首先將LA-MPRS問題表述為 ILP 形式，并證明了該問題的NP難和近似子模性。為了解決計算復雜的問題，我們進一步設計了一種具有合理近似比的迭代貪婪算法，本著逐個迭代添加微服務實例的原則，在不違反容量約束的情況下貪心地最大化吞吐量。這樣的設計基于這樣一個事實：對于給定的放置決策，我們總是可以通過遍歷有限多種可能性來找到添加微服務實例的最佳放置決策。近似比的結果證明也表示了放置決策的合理性。為了驗證算法的有效性，我們考慮使用從Docker Hub中頻繁下載的100種容器來提供不同類型的微服務，鏡像大小范圍為109~1045MB，層數范圍為6~13。一些基礎層可以在微服務之間共享，平均占到整個鏡像為12%~51%范圍內。微服務請求根據來自IBM Docker Registry Trace Player的邊緣服務器真實數據，范圍為7~135RPS。每個微服務所需的計算資源和請求大小根據微服務類型分別設置在0.002~0.05GHz和863~3561KB范圍內。實驗結果（圖1）表明，基于層共享的迭代貪心算法與現有解決方案相比，可增加27.61%的微服務數量，提高73.13%的邊緣吞吐量。
