我們如何將 Intune 打造 (重新打造!) 為領先全球的擴充雲端服務

我們通常在 Microsoft 並不會這麼做,但今天我想要分享一篇僅針對內部用途所撰寫的部落格文章 (列出如下)。

首先,您可能會這麼問:「那您為何發佈此資訊?」

簡單來說,當我與客戶開會並引導他們邁向各自專屬的數位轉型之路時,我往往會聽到 IT 小組 (和其領導者) 關於如何擴充其基礎結構或 App 的掙扎點,不是只有雲端本身,還有在此過程中雲端對他們訴諸的要求。

深切了解這種感受,我也曾經經歷這一切。

我的目標是要透過下列資訊,分享我們如何打造自己的全球雲端服務,希望其中的一些資訊能在您投入心力時做為藍圖,協助您打造出自己的成果。

我們是透過雲端並且針對雲端設計了 Intune,最終打造出領先全球的行動服務,並且是唯一具備真正雲端規模的服務。

此架構是能讓客戶達成其目標、保護其資料及保護其智慧財產權的最佳方法,完全不需要侷限於生產力或規模的任何限制。

從頭開始努力進行某件事是很罕見的體驗 (簡直就是:像 [檔案] > [新增] 一樣),然後開始操作並將建立的內容最佳化到大規模雲端服務,每天為數十億個交易提供服務。

在 Intune 投入的努力,就是這些罕見但值回票價的商機之一。

對我來說,這篇部落格文章最突出的地方在於完成此成果的工程師才華。我只能這麼說,  當您環顧現今巨大 (且不斷成長) 的行動管理市場時,Intune 是獨一無二真正的雲端服務。其他解決方案宣稱有雲端模型,但深入探究其核心,就會發現它們並非做為雲端服務打造。

Intune 工程小組現在已成為外界定期邀請進行分享的 Microsoft 小組之一,發表邁向大規模雲端服務之路的做法。我們一開始進行 Intune 時,在一些難以置信的工程師眼裡,Azure 只是一道微光,正因如此,其初始架構並不是在 Azure 上打造。在 2015 年,我們發現 Intune 的使用量真正開始增加,因而了解我們必須重新設計 Intune,使它成為基於雲端式微服務架構所打造的現代化 Azure 服務

這最終變成一項至關重要的決策。

回顧之下,這項決策如此重要的原因相當顯而易見:  隨著服務擴充到數千萬、然後擴充到數億、甚至擴充到數十億的裝置和 App,雲端式架構是唯一的解決之道,可提供您期待的可靠性、擴充性和品質。此外,如果沒有雲端式架構,我們的工程小組也無法以足以滿足客戶需求的敏捷速度進行回應。

做出這項變更以來,有數之不盡的客戶針對他們發現的可靠性和效能變化發表評論,我們提供新創新技術的速度也獲得了廣大的回響。

這一切都是因為架構而得以實現。 架構確實至關重要。

針對此架構的透徹觀點是花費幾百個小時調查其他解決方案後而得,之後,我們才決定重建 Intune。開始 Intune 的這項工作之前,我們密集分析並評估了許多互相競爭的解決方案,確認是否應該改為購買其中一個解決方案。我們考慮的這些解決方案沒有一個是雲端服務,完全沒有。每一個都是傳統內部部署主從式產品,皆為託管於資料中心,被稱為雲端服務的產品。

這並不是邁向超大型規模之路。

若要辨別產品是否為主從式架構或雲端服務,有個簡單的方法就是版本號碼。如果您看到類似「產品 X v8.3」的內容,您會立即知道這不是雲端服務。  當一天更新多次服務時,雲端服務中不會有像版本號碼這樣的項目。

我很期待 Intune 的未來,因為有一些是唯有雲端服務能夠執行的案例,也就是說,Intune 工程小組已經針對我們的競爭對手尚未發現的問題提供解決方案,換言之,此小組的專業知識只會繼續增長,為符合客戶需求做好萬全準備。

身為工程小組領導者,思考這對於我們為客戶打造的服務和工具有何意義是令人萬分期待的事情,以及當客戶帶著新專案和新挑戰來到我們面前時,我們將能如何回應。

如果您尚未切換到 Intune,請花幾分鐘閱讀這篇文章,之後請再與我們連絡。

 


 

Intune 邁向具有高度擴充性的全球分散式雲端服務的旅程

 

大約從 2015 年的下半年開始,屬於 Enterprise Mobility + Security (EMS) 一部分的 Intune 已展開其旅程,成為 Microsoft 史上成長最快速的業務。我們開始發現,此快速業務成長的徵兆使得後端作業對應地大規模急速增加。同時,我們也在 Intune、Azure 和其他相關領域中的各個服務層面進行了創新。我們在 Intune 中所面對的挑戰非常有趣但也十分艱難,就是要在短時間內在創新與急速成長之間取得平衡。我們準備了一些風險降低措施,但我們想要在擴充性和效能方面保持領先並掌握局勢,而這波成長的步伐有如當頭棒喝,加快我們邁向成為更成熟且可擴充的全球分散式雲端服務的旅程。在接下來的幾個月,我們開始踏上這段旅程,並且在設計、操作和執行服務這些方面做出大幅變更。

此部落格是由 4 個單元組成的系列,將說明 Intune 如何邁向雲端服務旅程,成為在 Azure 上執行的其中一個最成熟且可擴充的雲端服務。現在,我們是以大規模執行的最成熟服務之一,同時持續改善可用性、可靠性、效能、擴充、安全性和靈活度這 6 大支柱。

架構和背景以及迅速反應行動提升了客戶滿意度,並且對業務成長帶來了正面影響。

  1. 我們採取主動的措施和行動,為立即的未來成長做好準備。
  2. 採取讓服務更加成熟的行動,提供高可用性和擴充性,媲美其他大規模世界級服務。
  3. 邁向先驅服務之路,為分散式系統中的各種大規模作業樹立典範。

除了簡單扼要地詳細說明主題,這些部落格也會逐一摘錄學習重點。由 4 個單元組成的系列,其第一單元如下所述。在接下來幾個月,我們將在未來的部落格中介紹其餘 3 個主題。

背景和架構

在 2015 年,Intune 的組合是結合在託管於私人資料中心的實體機器上執行的一組服務,以及在 Azure 上執行的一組分散式服務。到了 2018 年,所有 Intune 服務皆已移轉到 Azure 上執行。這篇和未來幾篇部落格僅著重於在 Azure 上執行的分散式服務。將在實體機器上執行的服務移轉到 Azure 是另一個不同的旅程,我們也許會在日後某個時刻發表相關的部落格。本節的其餘內容專注於自 2015 年起的背景和架構。

全球架構檢視

Intune 的雲端服務是建置在 Azure Service Fabric (ASF) 上。所有服務都會部署到包含一組前端 (FE) 和中介層 (MT) 節點的 ASF 叢集。FE 節點託管於 A4 SKU (14 GB,8 核心) 上。MT 節點託管於 A7 SKU (56 GB,8 核心) 上。一個叢集與其他叢集完全不相關且不受其支配,這些叢集無法以任何方式或形式彼此存取,因為它們託管於完全不同的訂閱或資料中心。全世界共有 18 個這類的 ASF 叢集,分散於 3 個地區:北美 (NA)、歐洲 (EU) 和亞太 (AP)。每個 ASF 叢集都部署了一組相同的服務,並且執行相同的功能。這些服務包含無狀態和具狀態分割服務。圖 1 顯示全球架構檢視。

圖 1:Intune 的全球叢集 (也稱為 Azure 縮放單位,簡稱 ASU):架構檢視 (2015 年) SKU (14 GB,8 核心)。MT 節點託管於 A7 SKU (56 GB,8 核心) 上。

叢集架構向下鑽研

在每個叢集之中,我們有 5000 項以上的服務,透過一組約 80 種唯一類型的無狀態微服務和約 40 種唯一類型的具狀態微服務執行。無狀態服務會在由 Azure Load Balancer 路由傳送的所有 FE 節點上,執行多個執行個體。具狀態服務和一些高價值無狀態服務會在 MT 節點上執行。具狀態服務是在記憶體內部架構上建置,我們當時在內部將該架構打造為無 SQL 資料庫 (請回想一下,我們這裡談的是 2015 年)。

我們實作的具狀態記憶體內部存放區是 AVL 樹狀結構和雜湊集的組合,可進行極快速的寫入、取得、資料表掃描,以及次要索引搜尋。這些具狀態服務已針對擴充進行分割。每個分割都有 5 個用來處理可用性的複本。這 5 個的其中之一會做為用來處理所有要求的主要複本。其餘 4 個則是從主要複本複寫的次要複本。我們的某些服務需要針對其資料作業保持強大的一致性,也就是說,我們需要複本的仲裁,以滿足寫入的需求。在這些案例中,在 CAP 定理中,相較於 AP,我們更偏好使用 CP,也就是說,在沒有可用複本仲裁的情況下,我們無法寫入,因此會失去可用性。我們的某些案例有良好的最終一致性,而相較於 CP,我們更受益於 AP,但為了簡單起見,我們的初始架構支援所有服務間的強大一致性。因此,我們目前偏好 CP。

ASF 在許多方面都有卓越的表現,其中一項是在叢集上的密集封裝服務。我們一般在每個 MT 節點上執行的程序數目介於 30 到 50 之間,託管多個具狀態複本。它也非常適合處理所有複雜情況,包括管理和協調複本容錯移轉和移動、執行為我們的所有服務部署推出升級,以及叢集上的負載平衡。如果主要複本故障,ASF 會自動將次要複本提升為主要複本,並且建立新的次要複本,以滿足 5 個複本的要求。新的次要複本會啟動並完成完整的記憶體到記憶體資料移轉 (從主要複本移轉到次要複本)。我們也會透過 10 分鐘的 RPO,在外部保存的 Azure 資料表/Blob 儲存體中定期備份資料,萬一遇到災害或分割遺失而導致所有複本遺失的狀況,就能進行復原。圖 2 顯示叢集檢視。圖 2 顯示叢集檢視。

擴充圖 2:Intune 的 Azure 縮放單位 (也稱為叢集或 ASU) 架構 (2015 年) RPO,在遇到災害或分割遺失而導致所有複本遺失的狀況時進行復原。圖 2 顯示叢集檢視。圖 2 顯示叢集檢視。

問題

如先前所述,隨著使用量急速成長 (大約從 30 億個交易成長到 70 億個交易/每天),在 2015 年底和 2016 年初時,我們的後端服務開始出現了巨大的對應流量增長。因此,我們開始設法設計講求策略的解決方案來提供立即的緩解之道,以處理因這些成長難題而導致的任何問題。

問題 #1:

我們領悟的第一件事就是,我們需要適當的遙測和警示功能。我們需要遙測功能的規模也經歷了從當時的基礎 Azure 基礎結構進行許多急速的創新,而且由於 GA 時機等因素而無法立即運用。因此,從講求策略的觀點來說,我們必須非常快速地投資一些檢測/診斷解決方案,這樣才能取得足夠的資料來開始進行移轉。在備妥正確的遙測功能後,我們開始針對應處理的最重大問題進行資料收集,藉此實現最大的緩解。

我們在遙測的快速投資獲得了相當大的回報,讓我們能夠調查和判斷策略解決方案,以及快速地反覆執行。全都是因為這個短期但具強烈影響力的遙測投資的推波助瀾,我們有機會思考其餘的問題。

問題 #2:

遙測讓我們意識到,某些分割正在處理龐大的資料量。有時候,單一分割會儲存數百萬個物件,而叢集間的交易率可達到每天最高 60 億的數目。資料增加就表示,當次要複本必須建立,以及任何現有主要/次要複本故障或必須進行負載平衡時,資料傳輸量也會增加。資料愈多,就需要花費愈多的時間,以及相關的記憶體和 CPU 費用來建立次要複本。

此時間大多是因為在重建期間,於複本之間移轉時所需的資料序列化/還原序列化。我們使用資料合約序列化程式,而在針對許多序列化程式進行各種效能調查後,我們決定改為使用 Avro。Avro 提升了 50% 的輸送量和 CPU,並且大幅縮短重建所需花費的時間。例如,針對 4 GB 資料傳輸,我們原本最多需要花費 35 分鐘的重建作業,可在 20 分鐘或 20 分鐘以內完成。這並不是最佳的成效,但我們需要的是立即的緩解,而這個解決方案協助我們達成了這一項目標。我會在下一篇部落格中分享我們如何縮短此時間,從 20 分鐘縮短為在幾秒內完成。

問題 #3:

使用量成長也帶來了新的流量,以及針對我們未完全最佳化為提高處理效率 (CPU/具記憶體智慧功能) 的演算法帶來了新的搜尋模式。我們使用 AVL 樹狀結構設計了高效率次要索引搜尋,不過,針對特定搜尋模式,我們還能更進一步地最佳化。我們假設次要索引樹狀結構大小通常會比執行完整資料表掃描的主要樹狀結構大小更小,而且應該會符合我們所有的需求。不過,在我們審視某些高 CPU 使用量問題時,我們發現了偶爾限制 CPU 進行某些次要索引搜尋的流量模式。根據進一步的分析顯示,在次要索引中搜尋數百萬個物件的分頁和排序可能會導致極高 CPU 使用量,並影響在該節點上執行的所有服務。

這是絕佳的深入解析,讓我們能夠立即採取回應行動並設計替代的演算法。針對搜尋產生的分頁和排序,我們設計並實作了一項最大的堆積方法,來取代 AVL 樹狀結構。插入和搜尋的時間複雜性較適合最大堆積量為依據的排序。插入 1 百萬個物件將時間從 5 秒縮短為 250 毫秒,而我們發現針對 1 百萬個物件的排序依據 (基本排序) 從 5 秒改善為 1.5 秒。從執行這些作業類型的搜尋查詢數量來看,這項改善是透過針對叢集中的記憶體和 CPU 使用量,大幅節省 cluster.saving 中的記憶體和 CPU 使用量所達成的。

問題 #4:

當我們執行部署/升級時,我們發現了絕大部分的成長影響。當 Azure 依據其 OS 修補排程而將 FE 和 MT 節點重新開機時,這些問題會變得更加嚴重。這些節點是由 UD 以序列方式重新開機的升級網域 (UD),具有 20 分鐘的硬性限制,每個 UD 必須能完全運作,才能移動到下一個 UD 升級。

隨著升級,浮現了 2 個問題類別:

  • 具狀態服務的複本計數等於 UD 數量 (兩者皆為 5)。因此,當一個 UD 升級時,ASF 必須將所有複本從該 UD 移動到其他 4 個的其中之一,同時維持各種限制,例如適當分配複本以維持故障網域置換、主要/次要複本不在相同的節點上,以及各種其他限制。因此,在升級期間,需要一定程度的複本移動和密度。從上述的問題 #2,我們了解有些重建最多可能需要花費 20 分鐘,這表示次要複本無法在下次 UD 升級前完全備妥。此問題的整體影響在於,我們因為未啟用充足的複本數量來滿足升級期間的寫入而失去了仲裁。圖 3 顯示升級期間複本密度變更的影響。舉例來說,我們的其中一個服務所發生的重建量,是從約 350 個複本急遽增加到約 1000 個複本。我們立即採取的回應是針對要獲得一些緩解的節點增加 SKU,但基礎平台並不支援就地升級 SKU。  因此,我們必須容錯移轉到新的叢集,也就是說,我們必須執行資料移轉。這會是非常複雜的程序,因此我們捨棄了這項構想。在後續的其中一篇部落格文章中,將會說明我們如何克服這項限制。
  • Intune 和 ASF 小組針對此問題執行了深入分析,而在 ASF 小組的協助下,我們最終決定最佳設定是使用 4 個複本搭配 5 個 UD,這樣一個 UD 便隨時可供使用,以接受額外的複本並避免過度移動複本。這大幅提升了我們的叢集穩定性,而升級期間的 3 倍差異複本密度下降了 50 到 75%。

 

圖 3:升級期間的複本計數和密度影響

 

最後,我們也發現我們的叢集能夠在複本計數和記憶體使用量方面取得更好的平衡。有些節點的使用量很高,有些節點幾乎是處於閒置狀態。顯然,這會在流量高峰或升級期間對承受大量負載的節點造成過度的壓力。我們的解決方案是在叢集中實作負載平衡計量、報表和設定。此影響在圖 4 和 5 中呈現得最清楚,藍色線條表示改善之後的平衡。X 軸是我們使用的節點名稱。

 

圖 4:改善負載平衡前後的每個節點複本計數。

 

圖 5:改善負載平衡前後的每個節點記憶體使用量。

 

學習重點

  • 此經驗教會我們 4 個首要學習重點,我相信這些可適用於任何大規模的雲端服務:
  • 將遙測和警示功能列為您的設計中最關鍵的環節之一。監控遙測和警示、反覆執行,然後在進入生產階段環境前進行精簡,然後再於生產階段將功能公開提供給客戶。
  • 了解您的相依性。如果您的擴充解決方案不符合您的相依平台,局勢將會充滿不確定性。例如,如果您的擴充解決方案是從 10 個節點擴充到 500 個節點,請確認相依平台 (Azure 或 AWS 等等) 可支援增加的量,以及這麼做所需花費的時間。例如,如果有增加的限制 (例如一次只能新增幾個節點),您將需調整回應機制 (警示等功能) 以說明此延遲。同樣地,還有一個範例是相應增加。如果您的相應增加解決方案是執行 SKU 升級,請確保您的相依平台可支援以就地升級的方式將低效能 SKU 升級為高效能 SKU。
  • 持續驗證您的假設。許多雲端服務和平台仍在不斷進化,您幾個月前所做的假設在很多方面可能已不再有效,包括相依平台的設計/架構、替代可用較佳/最佳化解決方案,已被取代的功能等。您可以採取的一部分做法是監控核心原始碼路徑的流量模式變化,並確保您導入的該設計/演算法/實作在其使用情形中仍然有效。雲端服務流量使用模式可能會改變,幾個月前有效的解決方案可能已不再是最佳解決方案,而需重新訪查/更換為更有效率的解決方案。
  • 請將容量規劃列為優先考量的項目。判斷如何執行預測容量分析,並確保能以定期的頻率檢查。這會突顯出對於影響客戶的擴充問題,提供回應支援和主動支援的差別。

結論

實作和推出上述所有解決方案直到進入生產階段花費了 3 到 4 個月的時間。直到 2016 年 4 月,我們獲得振奮人心的成果。我們的叢集穩定性、可用性和可靠性有了大幅的改善。而我們的客戶也感受到這一點,對於我們在可靠性和穩定性所做的改善項目,給予非常正面的評價和回應。這是非常鼓舞人心的一步,但我們仍虛心吸取上述學到的寶貴經驗,藉此繼續帶領我們往前邁進,取得更多改善項目。我們已展開邁向成熟且可擴充的分散式雲端服務旅程。

請注意,這些部落格文章內容所描述的特色和功能可能會因市場而異。如需有關您所在市場的特定產品方案完整詳細資料,請瀏覽 Microsoft 365Office 365Windows 10Enterprise Mobility + Security
這些文章所連結的內容可能未提供您當地的語言版本。