共用方式為

Azure 上 SaaS 工作負載的數據

  • 發行項

將數據視為解決方案最有價值的資產。 身為獨立軟體廠商 （ISV），您必須負責管理客戶的數據。 您的數據設計策略和數據存放區選擇可能會大幅影響您的客戶。

本文提供如何確保客戶數據完整性和機密性，同時符合商務效能需求的指引。 它強調重要考慮，以協助您有效地達成這些目標。

選取資料儲存體

軟體即服務 （SaaS） 解決方案中的數據存放區會影響其架構、效能、可靠性和交易複雜度。 比較 Azure 受控服務的功能與類似的非Microsoft供應專案。 在某些情況下，您也可以考慮在虛擬機上執行開放原始碼產品。

設計考量

  • 區分您的交易式和分析作業。 事務數據存放區的設計目的是要支援您的應用程式，而分析數據存放區則用於報告和機器學習等工作。 這些存放區是使用特製化產品所建置，而且對於效能、存取模式、架構和使用案例有獨特的需求。

    本指南著重於事務數據存放區。

  • 瞭解您的數據需求。 預估磁碟區、其可變更的頻率，以及您需要儲存的數據類型。

    預期數據會隨著時間大幅成長。 針對 SaaS 解決方案，成長會在多個維度中發生。 隨著客戶數目的增長，預期數據量和類型會增加。 請確定您計劃進行這種成長，並投資可支援它的技術。

    根據數據的性質，決定關係型或非關係型數據平臺。 對於許多交易式工作負載，關係資料庫是將應用程式實體模型化為離散數據表的絕佳選項。 此方法可讓查詢跨關係型數據模型運作。 或者，如果您的數據自然適合檔模型或遵循圖表結構，則非關係方法可能更適合。

    如需詳細資訊，請參閱 SQL 與 NoSQL 數據平臺。

  • 將數據存放區的類型降到最低。 將不同類型的數據儲存在多個不同的數據存放區，對於具有各種數據平臺專業知識的成熟組織而言，可能會很有説明。 不過，這種方法通常會為初創公司和較小的組織帶來不必要的複雜性。 將焦點放在一或少數數據存放區會更有效率。

    如果您沒有使用多個資料存放區的商務理由，請將您的精力集中在一或少數數據存放區上。

  • 使用您知道的內容，並投資它。 如果您的小組已經具備特定數據存放區的專業知識，最好使用該數據存放區，而不是投資學習新的技能。 數據存放區和平臺很複雜，設計決策可能難以反轉。

    然而，請記住潛在的增長。 如果您目前的數據存放區不再符合您的需求，請選擇可增強解決方案效能、復原能力、安全性和營運效率的數據存放區。 它也應該協助小組加深其專業知識。

設計建議

建議 優點
將日常作業的事務數據存放區與分析和報告數據存放區分開。 混合數據存放區的意圖可能會導致不必要的複雜度。 數據分割可提升作業效率，並最大化每個數據存放區的使用率。
根據您的需求，選擇關係型或非關係型數據結構。 從一或少數數據存放區開始。

排定受控數據存放區的優先順序。 常見的選擇包括 Azure Cosmos DB、Azure SQL、MySQL、MongoDB 和 PostgreSQL。		 這種方法有助於將複雜性降至最低，並確保您使用正確的產品將效率最大化。 受控數據存放區可讓您彈性地管理資源和成本，並根據您的需求進行調整。 使用受控數據存放區比在自己的基礎結構上部署自己的數據存放區，會產生較少的管理負擔。
投資學習您選擇的技術。 讓您的小組能夠管理高調整需求和其他 SaaS 解決方案的複雜性。 瞭解您使用的工具及其更廣泛的生態系統，讓您可以在調整規模時有效地使用您的數據平臺。
在數據設計中採用彈性。 隨著您的 SaaS 解決方案成長或需求變更，您可以藉由新增或變更資料存放區來調整。 這種彈性可讓您從一個數據存放區開始，並隨著時間而演進，以符合您的需求。

租用模型和資料庫策略

數據設計的主要層面是決定代表您的客戶裝載資源，或在其環境中裝載資源。 大部分的 SaaS 提供者都會為所有客戶裝載資源，以提供資料庫管理的靈活性。 如果您在客戶的環境中裝載資源，請考慮如何存取和管理這些資源。

設計考量

  • 規劃資料庫分割。 在企業對企業 （B2B） SaaS 解決方案中，建議您為每個客戶建立專用資料庫。 這種方法可藉由維護客戶之間的嚴格隔離來增強數據安全性，進而降低混合數據的風險，並支持客戶管理的加密密鑰。 它也可協助您符合某些客戶的法規合規性需求。

    將客戶數據分成個別資料庫可以藉由將嘈雜的鄰近問題降到最低，以改善效能。 某些受控數據存放區包含資源配置控件，以減輕這些問題、提供成本效益，以及納入大規模管理多個資料庫的工具。

    在某些情況下，適合將多個客戶的數據儲存在單一數據存放區中。 例如，在企業對取用者 （B2C） 解決方案中，您可以根據客戶標識元，將數據儲存在具有邏輯分割的單一存放區中。 在共用元件的 B2B 解決方案中，您可以針對特定部分使用單一資料存放區，例如事件存放區，同時確保您在每個事件中包含客戶識別碼。

  • 與應用程式元件共置資料存放區。 如果您代表客戶裝載資源，請部署在相同的 Azure 區域中，以避免輸出頻寬費用和延遲。 當您將應用程式和資料存放區裝載於客戶的環境中時，請將它們一起部署在相同的環境中，以避免跨環境的複雜性。

  • 盡可能實際地標準化數據存放區管理。 統一性是跨客戶管理數據的關鍵。 隨著您的業務成長，客戶之間的差異會增加風險和複雜性。 這些差異也可以讓生產中斷的可能性更高，而且疑難解答更困難。

    請避免管理中的一次性變更，以支援個別客戶。 例如，若要支持客戶管理的元數據，請避免架構變更，例如將額外的數據行新增至資料庫。 相反地，為客戶建置功能以新增自己的元數據。 同樣地，如果您需要為不同的客戶提供不同層級的資料庫效能，請建立單一程式，讓您可用來將不同的組態套用至不同層級的客戶。

如需租使用者模型如何影響數據策略的詳細資訊，請參閱。

設計建議

建議 優點
評估是否要在多個客戶之間共享資料庫，或提供共用數據平臺。

視需要為每個客戶的數據部署單一資料庫。 如果不需要嚴格隔離，請放寬此策略，例如 B2C 解決方案。		 這種方法可將吵雜的鄰近問題降到最低，並可支援某些客戶的合規性需求。
在相同的區域中部署應用程式和其資料庫。 此方法可優化跨區域數據庫存取所產生的頻寬成本和延遲。
設計用來儲存客戶定義數據或元數據的標準化方法。 請避免變更個別客戶的架構，或造成客戶環境不同。 這種方法可協助您避免管理每個客戶資料庫之間的不一致作業負擔。
規劃客戶部署環境中的例行維護作業。

規劃如何存取資料庫以進行更新、架構變更、維護和其他作業。		 此主動式方法可將缺少維護的問題降到最低，並降低停機時間和效能問題的風險。

規劃容量

容量規劃是指資源使用率的管理，著重於 CPU、記憶體、記憶體和磁碟作業，例如每秒輸入和輸出作業（IOPS）。 某些數據存放區會將這些資源合併為簡單的綜合資源耗用量計量，例如 Azure SQL 中的資料庫輸送量單位 （DTU）或 Azure Cosmos DB 中的要求單位 （RU）。 受控數據存放區在資源管理方面提供彈性，這可讓您隨著時間變更。 建立初始計劃並隨著需求發展而反覆運算非常重要。

設計考量

  • 瞭解您的資源配置需求。 SaaS 解決方案中的不同客戶可能會有不同的資源需求。 較小的客戶可能需要最少的資源，而較大的客戶可能需要更多資源。 較大的客戶通常會支付更多費用，這可讓資源配置更高。 您可以針對每個客戶使用不同的資料庫，根據其大小和需求調整資源配置。

  • 了解數據平臺提供的不同容量模型。 雲端式數據平臺通常會提供多個資源模型。 例如，某些 Azure 服務，例如 Azure Cosmos DB 提供布建、輸送量型模型和無伺服器模型。 Azure SQL 資料庫 也提供彈性集區。

    布建的輸送量需要預先決定的資源配置，無論是從單一資料庫還是資料庫群組。 彈性集區 允許在多個資料庫之間共享資源。 彈性集區通常用於 SaaS 解決方案。

    雖然布建的輸送量需要您事先配置資源，但 Azure Cosmos DB 等服務仍會提供 自動調整輸送量。 您可以根據指定的觸發程式，設定動態新增或移除資源的規則。

    無伺服器資源模型會根據需求自動調整。 如果您無法事先預測容量需求，這項功能會讓他們成為良好的起點。 不過，它們可能會支援較少的功能，並在您成長時變得成本效率低下。 無伺服器模型可在 Azure SQL 資料庫 和 Azure Cosmos DB 中使用。

設計建議

建議 優點
為每個客戶建立資料庫需求的模型。 判斷您是否應該有許多小型資料庫、較少的大型資料庫，或兩者的混合。

使用 T 恤大小調整練習，將客戶分類為小型、中型和大型貯體。		 此方法提供每位客戶所需的資源粗略估計，並協助您將客戶對應至計費模型。
根據使用資源集區的客戶資料庫大小來分割資源集區。

使用布建的容量來達到您的優勢。 例如，您可以為較小的客戶建立共用 SQL 彈性集區、中型客戶的個別集區，以及大型客戶的專用資源。		 您可以根據客戶的資料庫大小來分割資源集區，以優化資源配置和成本效益。
利用受控服務所提供的內建調整功能。 您可以將調整責任卸除至平臺。 彈性集區和自動調整等功能可協助優化資源使用。
定期檢閱無伺服器數據存放區，以確保它們能夠繼續符合您的需求。 您可以確定資料存放區會隨著您不斷演進的需求保持有效。 隨著需求變更，將效能和成本效益優化。

高可用性和災害復原

SaaS 解決方案的客戶通常對高可用性（HA）和災害復原（DR）寄予厚望。 如果您的客戶在受管制的產業中運作，或依賴您的解決方案進行日常作業，則其需求可能更嚴格。

HA 和DR不是一次性的解決方案，而且取決於各種因素。 清楚瞭解適用於您和客戶需求的可用選項，以做出有關減輕不同風險的明智決策。

取捨：可靠性、成本和效能：數據服務的復原通常需要將復本或複本分散到更廣泛的地理區域，以降低風險。 然而，有取捨。 數據必須移動的距離越長，您就越能防範本地化失敗。 但是，跨較長距離複製數據會增加延遲，而且通常會花費更多成本。 許多受控數據存放區都提供自動化的數據復寫，但它們可能會對您可以跨不同距離執行的復寫類型施加限制，以維持效能。

設計考量

  • 量化復原能力。 使用服務等級目標（SLO）測量復原需求，其中包括運行時間、復原時間和恢復點等計量。 這些計量是由您的商務需求和客戶所驅動，這些客戶可能有不同的需求。 如果您代表客戶儲存大量數據，您的 HA 和 DR 解決方案可能需要更複雜，才能符合嚴格的需求。

    如需復原計量的詳細資訊，請參閱 RE：04 定義可靠性目標的建議。

  • 使用平臺功能。 Azure 透過使用可用性區域，以及使用多個區域跨更廣泛的地理區域，在資料中心內、區域內提供復原功能。 結合可用性區域、跨區域備份和多區域部署等策略，以達到解決方案的正確復原層級。 針對高復原需求，請考慮區域之間具有異步數據複寫的多區域主動-被動架構。 這種方法可能會導致在重大中斷期間遺失某些數據。

    取捨：具有複寫的多區域、主動-主動設計是最有彈性的，但建置和測試很複雜。 針對大部分主動-主動解決方案，您需要設計衝突解決方法，以考慮數據同步處理延遲。 大部分的解決方案都不需要這種復原能力。

    請參閱使用可用性區域和區域的 RE：05 建議。

  • 使用部署戳記來隔離元件的爆破半徑。 部署戳記模式在 SaaS 解決方案中廣泛使用，因為它提供部署、管理、效能和復原的優點。 例如，在 美國 中部署一個戳記，而歐洲的另一個戳記可確保某個區域中的客戶與另一個區域中的中斷隔離，而且可以獨立運作。

設計建議

建議 優點
當您考慮您和客戶的整體數據需求時，請專注於復原需求。 藉由將設計決策放在這些需求中，您可以確定您做出適當的取捨，並避免針對您的需求進行不足或過度工程。
反映計費模型中不同層級的復原能力。

與客戶設定期望。 重大中斷期間零數據遺失，或 100% 運行時間可能不切實際。		 計費模型可協助您的客戶了解他們註冊的保證復原能力。 例如，在較低層級的情況下，客戶獲得最少的保證。 在較高層級中，客戶會收到更多復原能力，因為您可以負擔在多個區域復寫其資源。
針對生產解決方案使用 Azure 可用性區域。 可能的話，請使用區域備援數據存放區。 可用性區域可針對數據中心中斷提供復原能力，而不會大幅增加解決方案的成本、延遲或複雜度。
使用可用的跨區域複寫，以全域備援格式保留數據存放區的備份。 跨區域數據備份會增加額外的復原層級。
使用部署戳記，在地理位置分散的位置建立解決方案的個別實例。 藉由使用部署戳記在地理位置分散的位置建立解決方案的個別實例，您可以增加復原能力並提供更多優點，例如更容易的作業管理。
評估您是否需要多區域部署，以及是否需要主動-主動設計以符合需求。

請考慮所涉及的取捨。 無狀態元件比數據存放區等具狀態元件更容易複寫。		 跨區域分散您的解決方案或戳記，藉由在區域之間複寫數據來提供較高層級的復原能力。

安全性與合規性

您必須負責確保客戶數據的機密性和完整性。 當您建置安全性基準時，請考慮您的安全性需求和承諾。 規劃以符合客戶的合規性需求，包括數據保留。

設計考量

  • 網路功能： 考慮誰將存取您的數據存放區。 一般而言，只有您的應用程式需要直接通訊，因此請將其設定為專用網路。

  • 身分識別： 請考慮如何存取您的數據存放區。 許多 SaaS 解決方案會針對所有資料存放區使用單一應用程式身分識別，應用層會強制執行隔離和授權。 針對數據列層級安全性或資料庫層級授權，您可能需要將使用者的身分識別傳播至多租用戶環境中複雜的數據存放區。

  • 數據保留： 事先規劃您的數據保留原則。 維護更多數據會增加記憶體成本和管理複雜性。 例如，事務資料庫中的大量數據可能會使查詢和截斷進程複雜化。

    對於長期數據保留，例如合規性或未來分析，請考慮將數據重新放置到適合長期保留的存放區。

設計建議

建議 優點
將您的數據存放區設定為使用私人端點，並停用公用端點。 這種方法藉由限制對內部網路的存取，來增強安全性。 藉由限制存取，您可以降低未經授權存取和潛在數據外泄的風險。
使用受控識別和Microsoft Entra ID 進行驗證。 避免使用資料庫金鑰或認證。 受控識別不需要資料庫金鑰或認證，進而降低認證竊取的風險，並簡化存取管理。
當您使用共用數據存放區時，請確定應用程式會藉由在 子句中包含 WHERE 租使用者識別碼，將所有要求範圍限定為單一租使用者。 此程式可協助降低跨租用戶數據外泄或仿真的風險。
根據合規性和商務需求規劃您的數據保留策略。 避免保留不必要的歷程記錄數據。 針對長期保留，將數據從主要存放區移至封存記憶體。 藉由避免不必要的保留，您可以維護較小的介面區。
使用數據存放區功能來支援您的數據生命週期需求。

在 Azure Cosmos DB 中，設定 檔存留 時間。 在 Azure SQL 中，使用 資料表分割 來實作滑動視窗策略，以將封存程式對資料庫的影響降到最低。		 這些方法可確保有效率的數據生命週期管理、藉由封存或刪除過時的數據來優化記憶體，並盡可能減少手動介入。

Operations

SaaS 解決方案通常包含大量的資料庫或其他存放區。 請務必規劃車隊的例行維護，並探索自動化選項，以有效率地管理這些工作。

設計考量

  • 瞭解小組的功能。 如果您沒有大型資料庫管理員小組，他們可以對個別客戶的資料庫執行詳細分析，請規劃大規模執行作業，並盡可能使用平臺工具。

  • 規劃您的定期維護程式。 列出所需的定期維護作業及其頻率。 特定作業會根據您使用的數據存放區類型而有所不同。 例如：

    • 監視位於特定實體的數據和數據總量，例如重要數據表。
    • 重建索引。
    • 根據變更查詢模式建立或移除索引。
    • 重新平衡數據分割。

    探索可協助您定期維護的平臺功能，並主動尋找新問題。 例如，Azure 中的 SQL 資料庫 Advisor SQL 資料庫 監視問題。

  • 自動化的設計。 自動化作業對於 SaaS 解決方案而言至關重要，可有效地調整規模。 識別一般和偶爾的工作，併為其建立劇本或自動化腳本。 對於無法立即自動化的工作，請徹底記錄程式，以確保一致性和清晰性。

設計建議

建議 優點
盡可能爭取客戶數據存放區之間的一致性。

如果客戶需要特殊住宿，請將它們整合到整體程式中，而不是自定義該客戶的設定。 例如，針對每個資料庫使用相同的架構，並使用相同的程式來部署和管理您的資源。		 一致性可讓您更輕鬆地大規模進行變更，並將部署或維護程式期間意外問題的風險降到最低。
仔細部署有限的資源，並尋求簡化作業的機會。 您可以避免效率小，並提升資源使用率和整體效能。
針對重複的工作建置自動化。 選擇購買自動化工具，而不是建置自定義解決方案。

探索平臺和非Microsoft廠商所提供的選項。		 藉由投資品質自動化，您可以重複使用這些資產，並減少經常容易發生錯誤的手動工作。 如果您不是所使用之數據存放區的專家，或不確定必要的維護工作，自動化工具是有價值的。
仔細部署小組的資料庫管理容量。 為最具影響力的活動保留人力資源資料庫管理員，例如處理大型客戶或建置可跨許多客戶調整的自動化。 藉由將有價值的函式排定優先順序，您可以將效率最大化。

客戶存取數據

某些客戶可能會要求直接存取其數據以進行自定義報告或分析。 請仔細考慮客戶如何存取解決方案中的數據，以及是否要授與這些要求，或提供符合其需求的替代方法。

設計考量

  • 為直接存取的理由辯護。 透過取得其商務問題的相關信息，瞭解客戶為何需要存取原始數據。 共同作業以尋找符合其需求的解決方案，而不會對您的平臺造成風險。

    尋找符合需求的替代方式，而不是提供直接存取權。 如果報告用途需要存取權，最好使用應用層方法。 例如，您可以使用 power BI Microsoft來建置報表，或者您可以將數據的子集導出至提供給它們的檔案。 您也可以建立 API，讓他們可用來存取您的數據。

  • 評估安全性和隔離影響。 提供數據存放區的直接存取會造成重大的安全性風險。 避免向外部合作對象公開內部資源，包括客戶。 在有許多客戶共享解決方案的 SaaS 環境中，風險甚至更高，因為環境可能會遭到惡意探索以存取其他客戶的數據。

    請考慮以不影響生產系統的安全、隔離的方式為客戶提供其數據的存取權，並可讓您進行內部資料庫設計變更，而不會中斷客戶的查詢。

  • 請考慮對效能的影響。 允許直接存取您的事務數據存放區可能會導致主要應用程式的效能問題。 例如，客戶可能會執行資源密集型查詢，以中斷應用程式的功能。

設計建議

建議 優點
避免直接存取您的數據存放區。

如果您必須提供直接存取權，請在數據平台支援時，提供只讀複本的存取權。		 應用層方法可讓您控制客戶如何使用您的數據。 如果無法建立應用層建構，透過只讀複本的存取可減少客戶對作業的查詢壓力。
避免公開內部實作詳細數據。 藉由控制對數據結構的存取，您可以防止客戶對資料庫架構的功能進行假設。 這種彈性可讓您隨著時間發展及優化資料庫結構，而不需要客戶建置工具的限制或不正確的假設。

其他資源

多租用戶是設計 SaaS 工作負載的核心商務方法。 這些文章提供有關數據設計考慮的詳細資訊：

後續步驟

瞭解 SaaS 工作負載的 DevOps 考慮，包括有效率的客戶生命週期管理和安全部署做法。

設計區域：Azure 上 SaaS 工作負載的 DevOps 做法