多租用戶 SaaS 資料庫租用模式

適用於:Azure SQL Database

本文描述多租用戶 SaaS 應用程式可使用的各種租用模型。

在設計多租用戶 SaaS 應用程式時,您必須小心選擇最適合您的應用程式需求的租用模型。 租用模型可決定每個租用戶的資料如何對應至儲存體。 您所選的租用模型會影響應用程式的設計和管理。 稍後切換到不同的模型有時所費不貲。

A. SaaS 概念與術語

在軟體即服務 (SaaS) 模型中,公司將不會出售軟體的「授權」。 而是讓每位客戶向公司支付租金,使每位客戶成為公司的「租用戶」

每個租用戶支付租金後,便可以存取 SaaS 應用程式元件,並將資料儲存於 SaaS 系統中。

「租用戶模型」一詞是指組織租用戶儲存資料的方式:

  • 單一租用戶:每個資料庫只會儲存來自一個租用戶的資料。
  • 多租用戶:每個資料庫都會儲存來自多個不同租用戶的資料 (搭配保護資料隱私權的機制)。
  • 另外還提供混合式租用戶模型。

B. 如何選擇適當的租用模型

一般情況下,租用模型不會影響應用程式的功能,但可能會影響整體解決方案的其他層面。 下列準則可用來評估每個模型:

  • 延展性:

    • 租用戶的數目。
    • 每一租用戶的儲存體。
    • 彙總儲存體。
    • 工作負載。
  • 租用戶隔離:資料隔離和效能 (某個租用戶的工作負載是否會影響其他人)。

  • 每一租用戶的成本:資料庫成本。

  • 部署複雜度:

    • 結構描述的變更。
    • 查詢的變更 (模式所要求)。
  • 操作複雜度:

    • 監視和管理效能。
    • 結構描述管理。
    • 還原租用戶。
    • 災害復原。
  • 自訂能力:輕鬆支援租用戶專屬或租用戶類別專屬的結構描述自訂。

租用討論著重於「資料」圖。 但請考慮一下「應用程式」層。 應用程式層會被視為龐大的實體。 如果您將應用程式分割成許多小元件,您所選的租用模型可能會改變。 就使用的租用和儲存體技術或平台而論,您可以將某些元件視為與其他元件不同。

C. 具有單一租用戶資料庫的獨立單一租用戶應用程式

應用程式層級隔離

在此模型中,整個應用程式會重複安裝 (針對每個租用戶安裝一次)。 應用程式的每個執行個體都是獨立的執行個體,因此它決不會與任何其他獨立執行個體互動。 應用程式的每個執行個體只有一個租用戶,因此只需要一個資料庫。 租用戶本身全然擁有此資料庫。

Design of standalone app with exactly one single-tenant database.

每個應用程式執行個體會安裝在不同的 Azure 資源群組中。 資源群組可屬於軟體廠商或租用戶所擁有的訂用帳戶。 在任一情況下,廠商可以為租用戶管理軟體。 每個應用程式執行個體都會設定為連線至其對應的資料庫。

每個租用戶資料庫都會部署為單一資料庫。 此模型提供最強大的資料庫隔離。 但是隔離要求將足夠的資源配置給每個資料庫,以處理其尖峰負載。 此處的重點是,彈性集區無法使用於部署在不同資源群組或不同訂用帳戶中的資料庫。 從整體資料庫成本的觀點來看,此限制讓此獨立單一租用戶的應用程式模型成為最昂貴的解決方案。

廠商管理

即使應用程式執行個體是安裝於不同的租用戶訂用帳戶中,廠商仍可存取所有獨立應用程式執行個體中的所有資料庫。 透過 SQL 連線即可進行存取。 此種跨執行個體的存取可以讓廠商集中進行結構描述管理和跨資料庫查詢,以便進行報告或分析。 如果想要使用這種集中式管理,則必須部署可將租用戶識別碼對應到資料庫 URI 的目錄。 Azure SQL Database 提供分區程式庫,可搭配使用以提供目錄。 分區化程式庫已正式命名為彈性資料庫用戶端程式庫

D. 每一租用戶一個資料庫的多租用戶應用程式

下一個模式會使用具有許多資料庫的多租用戶應用程式,所有都是單一租用戶資料庫。 為每個新租用戶佈建一個新資料庫。 為每個節點新增更多資源,以垂直方式相應「增加」應用程式層。 或者,藉由新增更多節點,以水平方式相應「放大」應用程式。 縮放是以工作負載為基礎,並且與個別資料庫的數目或規模無關。

Design of multi-tenant app with database-per-tenant.

針對租用戶自訂

如同獨立應用程式模式,使用單一租用戶資料庫可提供強大的租用戶隔離。 在模型只會指定單一租用戶資料庫的任何應用程式中,可以針對其租用戶自訂和最佳化任何一個指定資料庫的結構描述。 此自訂作業不會影響應用程式中的其他租用戶。 或許一個租用戶所需的資料可能超過所有租用戶所需的基本資料欄位。 此外,額外的資料欄位可能需要索引。

如果每一租用戶一個資料庫,很容易就能達成一或多個個別租用戶的結構描述自訂。 應用程式廠商必須設計一些程序來小心管理大規模的結構描述自訂。

彈性集區

當資料庫部署於相同的資源群組時,可以將它們分組為彈性集區。 集區會提供符合成本效益的方式來共用橫跨多個資料庫的資源。 相較於要求每個資料庫大到足以容納它所遭遇的使用量尖峰,此集區選項的成本比較低。 即使集區資料庫會共用資源的存取權,它們仍可達到較高程度的效能隔離。

Design of multi-tenant app with database-per-tenant, using elastic pool.

Azure SQL Database 會提供設定、監視和管理共用所需的工具。 集區層級和資料庫層級兩者的效能計量可在 Azure 入口網站或透過 Azure 監視器記錄取得。 計量可供深入了解彙總與租用戶特有的效能。 個別的資料庫可以在集區之間移動,以將保留的資源提供給特定租用戶。 這些工具可讓您以符合成本效益的方式確保良好效能。

每一租用戶一個資料庫的作業規模

Azure SQL Database 有許多專用於大規模管理大量資料庫 (例如超過 100,000 個資料庫) 的管理功能。 這些功能可讓每一租用戶一個資料庫的模式看似合理。

例如,假設系統以包含 1000 個租用戶的資料庫作為其唯一的一個資料庫。 此資料庫可能有 20 個索引。 如果系統轉變成擁有包含 1000 個單一租用戶的資料庫,則索引的數量會提升至 20,000 個。 在 Azure SQL Database 的自動微調中,依預設會啟用自動編製索引功能。 自動編製索引功能可為您管理 20,000 個索引與其進行中的 create 和 drop 最佳化。 這些自動化動作會發生於個別資料庫中,而且不受其他資料庫中的類似動作所調配或限制。 在忙碌的資料庫與較不忙碌的資料庫中,自動化索引編製功能會以不同的方式處理索引。 如果必須以手動方式完成此大量管理工作,則在每一租用戶一個資料庫的規模中,這種索引管理自訂作業可能不切實際。

可縮放自如的其他管理功能包括:

  • 內建備份。
  • 高可用性。
  • 在磁碟上加密。
  • 效能遙測。

自動化

可以將管理作業編寫為指令碼,並透過 devops 模型提供。 這些作業甚至可以在應用程式中自動執行並且公開。

例如,您可以將單一租用戶自動復原到較早的時間點。 復原只需要還原儲存租用戶的一個單一租用戶資料庫。 此還原並不會影響其他租用戶,這就確認管理作業屬於每個個別租用戶的精細層級。

E. 具有多租用戶資料庫的多租用戶應用程式

另一個可用模式是在多租用戶資料庫中儲存許多租用戶。 應用程式執行個體可以有任意多個多租用戶資料庫。 多租用戶資料庫的結構描述必須有一或多個租用戶識別碼資料行,如此才能選擇性地擷取任何指定租用戶中的資料。 此外,結構描述可能需要只由部份租用戶使用的一些資料表或資料行。 不過,靜態程式碼與參考資料只會儲存一次,並由所有租用戶共用。

犧牲租用戶隔離

資料:多租用戶資料庫必定會犧牲租用戶隔離。 多個租用戶的資料會一起儲存在一個資料庫中。 在開發期間,確保查詢決不會公開來自多個租用戶的資料。 SQL Database 支援資料列層級的安全性,其可強制查詢所傳回的資料範圍限於單一租用戶。

處理:多租用戶資料庫會讓其所有租用戶共用計算和儲存體資源。 此種資料庫可以整體進行監視,確保其效能可以接受。 不過,Azure 系統沒有內建方法可監視或管理個別租用戶對於這些資源的使用。 因此,多租用戶資料庫會提高遇到吵雜芳鄰的風險,以致其中一個過度活躍租用戶的工作負載影響到同一個資料庫中其他租用戶的效能體驗。 其他應用程式層級的監視功能可以監視租用戶層級的效能。

成本較低

一般而言,多租用戶資料庫的每一租用戶成本最低。 單一資料庫的資源成本會低於同樣大小的彈性集區。 此外,在租用戶只需要有限儲存體的情況下,單一資料庫中可能會儲存數百萬個租用戶。 沒有任何彈性集區可以包含數百萬個資料庫。 不過,包含 1000 個集區且每個集區有 1000 個資料庫的方案可以到達數以百萬計的規模,但是有變得難以管理的風險。

接著會討論多租用戶資料庫模型的兩種變形,其中的分區化多租用戶模型最具彈性且最能擴充。

F. 具有單一多租用戶資料庫的多租用戶應用程式

這個最簡單的多租用戶資料庫模式會使用單一資料庫來裝載所有租用戶的資料。 隨著更多租用戶的新增,資料庫會相應增加更多儲存體和計算資源。 雖然一定有終極規模限制,但是此相應增加是有必要的。 不過,在達到該限制之前,資料庫早已變得難以管理。

相較於在多租用戶資料庫中實作管理,著重於個別租用戶的管理作業更為複雜。 而且這些作業的速度可能會變得非常慢。 例如,僅僅一個租用戶的資料時間點還原作業。

G. 具有分區化多租用戶資料庫的多租用戶應用程式

大部分 SaaS 應用程式一次只會存取一個租用戶的資料。 這種存取模式可讓租用戶資料分散於多個資料庫或分區,而任何一個租用戶的所有資料會容納在一個分區中。 與多租用戶資料庫模式結合的分區化模型,幾乎沒有規模限制。

Design of multi-tenant app with sharded multi-tenant databases.

管理分區

分區化會增加設計和操作管理的複雜度。 需要有目錄,才能維護租用戶與資料庫之間的對應。 此外,需要有管理程序才能管理分區和租用戶填入。 例如,必須設計一些程序來新增和移除分區,以及在分區之間移動租用戶資料。 其中一種調整方式是新增分區,並在其中填入新的租用戶。 其他時候,您可能會將密集填入的分區分割成兩個比較不密集填入的分區。 移動或中斷數個租用戶之後,您可能會將稀疏填入的分區合併在一起。 合併會導致更加符合成本效益的資源使用率。 租用戶也可能會在分區之間移動,以平衡工作負載。

SQL Database 提供可搭配分區化程式庫和目錄資料庫運作的分割/合併工具。 所提供的應用程式可以分割及合併分區,而且可以在分區之間移動租用戶資料。 此應用程式也可在這些作業期間維護目錄,並將受影響的租用戶標示為離線,再移動它們。 移動之後,應用程式會以新的對應再次更新目錄,並將租用戶標示回線上。

較小的資料庫比較容易管理

藉由將租用戶分散到多個資料庫,分區化多租用戶方案便可產生比較容易管理的較小資料庫。 例如,將特定租用戶還原至先前的時間點,現在牽涉到從備份 (而非包含所有租用戶的較大資料庫) 還原單一較小資料庫。 您可以選擇資料庫大小和每個資料庫的租用戶數目,來平衡工作負載與管理投入量。

結構描述中的租用戶識別碼

視使用的分區化方法而定,可能為對資料庫結構描述強加其他條件約束。 SQL Database 分割/合併應用程式要求結構描述包含分區化索引鍵,這通常是租用戶識別碼。 租用戶識別碼是所有分區化資料表的主索引鍵中的前置元素。 租用戶識別碼可讓分割/合併應用程式快速找出並移動與特定租用戶相關聯的資料。

分區的彈性集區

分區化多租用戶資料庫可以置於彈性集區中。 一般而言,一個集區中具有許多單一租用戶資料庫,與一些多租用戶資料庫中具有許多租用戶的成本效益相同。 如果有大量相當不活躍的租用戶,多租用戶資料庫比較有優勢。

H. 混合式分區化多租用戶資料庫模型

在混合式模型中,所有資料庫都有其結構描述中的租用戶識別碼。 這類資料庫能夠儲存多個租用戶,而且可以進行分區。 所以就結構描述而言,這些全都是多租用戶的資料庫。 而實際上,其中有些資料庫只包含一個租用戶。 不論如何,儲存在指定資料庫中的租用戶數量不會影響資料庫結構描述。

四處移動租用戶

您可以隨時將特定租用戶移到它自己的多租戶資料庫。 您也可以隨時改變心意,將租用戶移回包含多個租用戶的資料庫。 當您佈建新的資料庫時,您也可以將租用戶指派給新的單一租用戶資料庫。

可辨識之租用戶群組的資源需求之間有很大差異時,混合式模型就會脫穎而出。 例如,假設不保證參與免費試用的租用戶能擁有與訂閱租用戶一樣高的效能等級。 此原則可能適用於免費試用階段的租用戶,而且這些租用戶即將儲存在所有免費試用租用戶共用的多租用戶資料庫中。 當免費試用租用戶訂閱基本服務層級時,可以將租用戶移到另一個可能有較少租用戶的多租用戶資料庫。 支付進階服務層級費用的訂閱者可以移到其擁有的全新單一租用戶資料庫。

集區

在此混合式模型中,可以將訂閱者租用戶的單一租用戶資料庫放在資源集區中,以降低每個租用戶的資料庫成本。 這也可以在每一租用戶一個資料庫的模型中達成。

I. 比較租用模型

下表摘要說明主要租用模型之間的差異。

測量 獨立應用程式 每一租用戶一個資料庫 分區化多租用戶
調整
1-100
非常高
1-100,000
無限
1-1,000,000
租用戶隔離 非常高 低;任何單一租用戶除外 (亦即單獨在 MT DB 中)。
每一租用戶的資料庫成本 高;針對尖峰調整大小。 低;使用集區。 最低;適用於 MT DB 的小型租用戶。
監視和管理效能 僅限每一租用戶 彙總 + 每一租用戶 彙總;雖然是適用於單一物件的僅限每一租用戶。
部署複雜度 低度 低度 中;由於分區化。
操作複雜度 低-高。 個別時簡單,大規模時複雜。 低-中。 模式可處理大規模時的複雜度。 低-高。 個別租用戶管理很複雜。

下一步