Office許可服務(wù)和Azure Cosmos DB第1部分：遷移生產(chǎn)工作負載

挑戰(zhàn)：有限的吞吐量

在Microsoft，Office許可服務(wù)（OLS）支持在全球數(shù)百萬個設(shè)備（包括Windows，Mac，平板電腦和移動設(shè)備）上激活Microsoft Office客戶端。它存儲諸如機器ID，產(chǎn)品ID，激活計數(shù)，到期日期等信息。Office客戶端每天被全球用戶訪問OLS的次數(shù)超過2.4億次，其中第一個呼叫是在激活許可證后從客戶端發(fā)出的，然后每2-3天從客戶端進行一次檢查，以確保客戶端檢查許可證仍然有效。

直到最近，OLS的后端數(shù)據(jù)存儲都依賴于Azure Table存儲，該存儲包含分布在18個表中的約5 TB數(shù)據(jù)，其中單獨的表用于不同的許可證類別，例如消費者，企業(yè)和OEM預(yù)安裝。

在經(jīng)歷了數(shù)年持續(xù)的工作負載增長之后，2018年初，OLS服務(wù)開始接近需要比表存儲所提供的吞吐量更多的點。如果不解決該問題，表存儲的固有吞吐量限制將開始威脅到整體服務(wù)質(zhì)量，從而損害全球數(shù)百萬用戶。

Microsoft的軟件工程師Danny Cheng領(lǐng)導OLS開發(fā)團隊，他解釋說：

“每個表存儲帳戶都具有固定的最大吞吐量，并且不會超出該范圍。到2018年，OLS的可用存儲吞吐量已不足，并且由于我們已經(jīng)將每個表維護在其自己的表存儲帳戶中，因此我們無法獲得更多的吞吐量來滿足客戶的更多請求。OLS服務(wù)在高峰使用時間受到限制，因此我們必須盡快找到更具擴展性的存儲后端。

在尋找長期的存儲解決方案時，OLS團隊不僅需要額外的吞吐量。我們希望能夠在全球不同地區(qū)部署OLS，以通過將服務(wù)副本更靠近用戶所在的位置來最大程度地減少延遲。但是使用表存儲時，地理復(fù)制功能相當有限?！?/span>

OLS團隊還希望更好的災(zāi)難恢復(fù)。使用表存儲，他們將所有數(shù)據(jù)存儲在美國的多個區(qū)域中。所有讀取和寫入都到達主區(qū)域，并且沒有用于復(fù)制到兩個備份區(qū)域的SLA，這可能需要60分鐘。如果主要區(qū)域不可用，則需要人工干預(yù)，并且很可能會丟失數(shù)據(jù)。

“如果一個地區(qū)要宕機，那將是一個真正的恐慌情況，將有30到60分鐘的停機時間以及類似的數(shù)據(jù)丟失窗口，”Cheng說。

解決方案：遷移到Azure Cosmos DB

OLS團隊選擇遷移到Azure Cosmos DB，后者提供了從表存儲的一舉一遷移的遷移路徑，從而可以輕松交換具有交鑰匙式全局分發(fā)，低延遲，幾乎無限的可伸縮性，保證高價的高級后端服務(wù)?？捎眯缘鹊取?/span>

“最初，當我們意識到我們需要一個新的存儲后端時，這令人感到恐懼，因為我們不知道需要多少新代碼?！盋heng說?！拔覀冊贏zure上研究了幾種存儲選項，Azure Cosmos DB是滿足我們所有需求的唯一存儲選項。借助其Table API，我們甚至不需要編寫很多新代碼。從許多方面來說，這都是理想的升降選擇，只需很少的工作即可提供我們所需的可伸縮性和許多其他好處。”

設(shè)計決策

在準備部署Azure Cosmos DB時，OLS團隊必須做出一些基本的設(shè)計決策：

一致性級別，為團隊提供了解決讀取一致性與延遲，可用性和吞吐量之間的基本權(quán)衡的選項。

“我們之所以選擇強一致性，是因為我們的某些業(yè)務(wù)邏輯需要在寫入存儲后立即從存儲中讀取信息，”Cheng解釋說。

分區(qū)鍵，它指示Azure Cosmos DB容器中的項目如何劃分為邏輯分區(qū)-并確定數(shù)據(jù)存儲的最終可伸縮性。

“使用Azure Cosmos DB Table API，分區(qū)鍵自然可以映射到我們在Table存儲中的映射，因此我們能夠重用相同的分區(qū)鍵，”Cheng說。

遷移過程

盡管Azure Cosmos DB提供了數(shù)據(jù)遷移工具，但那時使用它會導致OLS服務(wù)停機，這不是一個選擇。（注意：今天，您可以在不停機的情況下進行實時遷移。）為了解決這個問題，OLS團隊構(gòu)建了一個數(shù)據(jù)遷移解決方案，該解決方案包含三個組件：

將當前數(shù)據(jù)從表存儲移動到Azure Cosmos DB的數(shù)據(jù)遷移器。

一個Dual Writer，它將新的數(shù)據(jù)庫更改寫入表存儲和Azure Cosmos DB。

一致性檢查器，用于捕獲表存儲和Azure Cosmos DB之間的任何不匹配情況。

數(shù)據(jù)遷移器組件基于Azure Cosmos DB團隊提供給Microsoft客戶的組件。

“為了解決停機問題，我們添加了Dual Writer和Consistency Checker組件，它們與OLS服務(wù)本身在同一臺生產(chǎn)服務(wù)器上運行，”Cheng解釋說。

OLS團隊于2019年末完成了遷移過程。如今，Azure Cosmos DB已部署到與表存儲相同的三個區(qū)域，該團隊在遷移過程中盡可能地模仿了表存儲拓撲。同樣，美國中北部是主要（讀/寫）區(qū)域，而其他兩個區(qū)域當前是只讀的。Azure Cosmos DB環(huán)境具有18個表，這些表包含5 TB數(shù)據(jù)，每秒消耗約100萬個請求單位（RU/s），這是用于在Azure Cosmos DB中保留保證的數(shù)據(jù)庫吞吐量的單位。

既然遷移已經(jīng)完成，該團隊計劃啟用多主機功能，該功能將對所有區(qū)域（而不是主要區(qū)域）進行寫操作。為此，該團隊還計劃通過將其后端存儲復(fù)制到全球其他區(qū)域來進行全球擴展，以此作為從Office客戶端角度通過將OLS數(shù)據(jù)副本更靠近其用戶所在位置來改善延遲的一種方法。