Azure 儲存解決方案

本篇我們將會介紹關於Azure的儲存服務，從Azure SQL DB Managed Instance, Azure VM中的 SQL Server， Azure table storage 與 Cosmos DB等。同時我們也會學習到如何設計Azure Storage solution是具資料加密的功能。

本篇將讓我們在Azure Cloud具有下列能力:

• Azure SQL Database的設計
• Azure SQL Managed Instance的設計
• Azure VM中的 SQL Server的設計
• Database Scalability的建議方案
• Database Availability的建議方案
• 針對在 data at rest/ data in transmission/data in use進行資料加密
• Azure SQL Edge的設計
• Azure tables的設計
• Azure Cosmos DB的設計

Azure SQL DB的設計

關聯式資料是具有共用結構描述的結構化資料類型。 資料會儲存在具有資料列、資料行和索引鍵的資料庫資料表中，用於電子商務網站之類的應用程式儲存體。下圖為在Azure Cloud中可供我們選擇的部署模式，分別是IaaS (SQL Virtual Machine), PaaS(Managed instances, Databases)。

Azure SQL Database

這是Azure的PaaS部署模式。 它是一種高度可擴展的RDBMS服務，具有高可用性的 SLA。

SQL DB也是唯一支援以下的部署選項：

• 非常大的DB(目前可支援到100TB)
• 可建立一個 SQL Database elastic database pool，Pool中的所有DB會共用同一組運算和儲存體資源。 每個DB都可以視目前的負載，在設定的限制內，使用需要的資源。
• SQL Database 有兩個主要定價選項：DTU 和vCore。 serverless選項也適用於單一資料庫，可針對非預期的workloads進行AutoScaling

Azure SQL DB還可以Azure其他的服務整合，如 Azure Data Factory 與機器學習。詳細的功能如下圖所示

SQL elastic pools

當我們要使用Azure SQL DB時，我們可以建立 SQL elastic pool。這個部署方式讓我們有"一組運算與儲存的資源"可以share我們所有在這個pool裡的Database。每一個DB可以使用這一個pool中它們所需的資源(在我們的限制之下)，根據現有的負載。詳情可以參閱Azure 文件。

Azure Database的選購模型

Azure SQL DB有三種定價方式分別是：

1. DTU(Database Transaction Unit)，是運算、儲存體與 I/O 資源的結合量值。 DTU 選項是預先設定好的簡易購買選項。
2. vCore: 選擇vCore數目，更充分地掌控運算成本。 此選項支援適用於 SQL Server 的 Azure Hybrid Benefit 和reserved capacity (這需要預先付款)。
3. Serverless: 適用於 SQL Database 中單一資料庫的compute tier。 serverless model可根據工作負載需求自動調整運算資源，並以使用的運算量來計費。

DTU就是將DB會用到的所有資源(包含 compute/storage/IO)結合起來．DTU模式是一個簡單且"預先配置(先圈資源，不管你有沒有用到)"的購買選項．但這個無法用在 SQL managed instance．而vCore的概念就回到我們在VM架設SQL Server，每個SQL instance有著獨立的 compute/ storage/ IO resource，是不能被共用的．

Serverless 模式是 Azure SQL DB中單一個DB的compute tier。 它會根據工作負載需求進行autoscaling compute，並僅按使用的計算量計費。 下圖為一個範例示意圖。

如果我們的DB是用在Production，哪就會推薦使用基於 vCore 的模型，因為它允許我們獨立選擇compute和storage resource。這種方式不會讓共用的resource影響到Production．而 DTU 的模式，其資源是分享的所以適合用在開發 /測試的環境中，因為使用效率可以最大化就算使用量到頂了影響層面也不會太大。

vCore 模型還允許我們使用適用於 SQL Server 的 Azure Hybrid benefit and(or) 預留容量（預付費用）來節省費用。 但這些option在 DTU model中是不能使用的。

Azure Database service tiers

根據效能、可用性和存儲需求，Azure 在下表討論的 vCore model中提供了三個DB service tier。

Azure SQL DB和 Azure SQL managed instance確保 99.99% 的可用性，即使在基礎設施掛掉的情況下也是如此。

Azure SQL DB和 SQL managed instance可以使用的service tier是 — General purpose和business Critical。 Azure SQL DB還多一個Hyperscale service tier。

對於General Purpose service tier， primary replica 使用locally attached的 SSD 作為 tempdb。 data和log file存儲在 Azure Premium storage中。 然後將backup file存儲在 Azure standard storage中。 發生fail over時，Azure service fabric將尋找具有備用容量的節點並啟動新的 SQL Server instance。 然後將DB file attach，進行recovery，並update gateway以將Application指向新節點。(如下圖)

Business critical架構適用於需要"低延遲和最短停機時間"的重要系統。 Business critical就像在背景部署 Always On availability group(AG)的功能，data和log file的存儲方式與General purpose不同，因為它們存儲在direct attached的 SSD 上。

在Business critical場景中，data和log file都在直接掛載的 SSD 上運行，這降低了網路延遲。 在此架構中，有三個secondary replicas。 如果發生任何類型的故障，fail over到secondary replica會很快，因為資料已經存在並且SSD已經被attach了。

Azure SQL DB Hyperscale是一項全託管服務，可通過將存儲快速擴展到 100 TB 來適應不斷變化的需求。 靈活的雲原生架構允許存儲是根據需求增長的，並使我們能夠幾乎即時備份資料並在幾分鐘內恢復我們的DB— — 無論data operation的大小如何。

Hypersacle 提供快速DB restore、快速scale out和scale up。 Hypersacle DB會根據需求增長 — 我們只需為使用的容量付費。

下圖說明了Hypersacle架構中不同類型的節點。計算節點是relational engine所在的地方，也是SQL語言、query和transaction processing運作的地方。運算節點具有基於 SSD 的cache（標記為 RBPEX — Resilient Buffer Pool Extension）。有一個或多個secondary compute nodes充當hot standby node來進行fail over，以及充當read-only compute nodes。Page server是代表scaled-out storage engine的系統。Pager server的工作是按需求將DB page提供給compute node。Page Server還維護涵蓋基於 SSD 的cache以提高效能。Log service接受來自primary compute replica的日誌記錄，將它們保存在durable cache中，並將日誌記錄轉發到其餘compute replicas（以便它們可以update cache）以及相關的Page server，因此Data可以在那裡被update。這樣，來自primary compute replica的所有資料更改都會通過日誌服務傳送到所有的secondary compute replicas 與page servers。

Azure SQL Managed Instance

Azure SQL managed instance是 Azure SQL 的 PaaS 部署選項。 它提供了一個 SQL Server insatce，但消除了不需要管理VM的工作。 SQL Server 中大多數功能在 SQL managed instance都是可以使用的。

SQL managed instance適合希望使用instance scope的功能並希望在不重構Application的情況下搬到 Azure。SQL Managed Instance使用vCore模式。 我們可以定義配置給Managed Instance的 CPU 核心數和儲存體上限。 Managed Instance內的所有DB會共用配置給Instance的資源。

SQL managed instance scope的功能包括：

• SQL Server Agent
• Service Broker
• CLR(Common language runtime)
• Database Mail
• Linked servers
• Distributed transactions
• Machine Learning Services

假設我們有多個用於不同類型資料的mainframe applications。我們希望整合這些Application可以看到overall view。 另外，我們 想要一種減少overhead的方法。由於我們使用 很多SQL Server 功能，我們(IT 部門)選擇遷移到 Azure SQL managed instance。 我們能夠順利移動很大的資料並獲得以下效益：

• Automatic patching and version updates
• Automated backups
• High availability
• Reduced management overhead

Azure SQL Managed Instance 的擴展(Scalability)

SQL managed instance使用 vCores model，我們能夠定義分配的instance的最大 CPU core和最大存儲空間。關於SQL DB與SQL managed instance的功能比較可以參考Azure的文件．

在VM上的SQL Server 設計

將SQL Server運行在我們需要自行管理的ＶＭ上意味著:

• 我們需要SQL Server的專家，來管理SQL Server
• 我們要自行負責OS與SQL Server的patch工作

我們使用一個醫療業的案例(如下圖)。 為了頻繁轉換其Application並安全可靠地託管它們，我們希望快速遷移到 Azure。這個案例中我們可以使用 Azure Site Recovery 將在大約 1,000 個 VM 上運行的數十個Application遷移到 Azure。

PS. 如果我們在地端機房已經有採購Windows Server與SQL Server 的license，我們可以使用Azure Hybrid Benefit.

到此我們可以來比較上述所提的三種SQL Server的部署模式有何不同(如下表)

Azure SQL Database的動態擴展性(Scalability)

如果我們希望將SQL server遷移到雲端，必須選擇一種低延遲和高可用性的DB解決方案來存儲關聯式資料。 我們可能決定實施 Azure SQL DB，這是一項完全託管的服務，在Availability Zones的Business critical service tier中具有 99.995% 的可用性 SLA。

我們的下一個決定是如何處理可擴展性。 就是relational DB的可擴展性。 我們必須設計一個可動態擴展的解決方案，以處理工作負載。 我們的解決方案應該能夠隨著時間的推移處理越來越多的request，而不會對可用性或效能產生負面影響。 在這種情況下，我們要怎麼做呢？

Azure SQL DB讓我們能夠以最短的停機時間更改分配給我們的DB的資源，包括：

• CPU power
• Memory
• IO throughput
• Storage

Azure SQL DB的動態擴展讓我們能夠：

• 使用 DTU 或 vCore model來定義將分配給每個DB的最大資源量．
• 使用Elastic pools並為pool中的DB設置最小和最大資源限制。

Azure SQL DB的擴展型態

• Vertical — 在單一個instance上不斷加資源上去．也稱為scaling up
• Horizontal — Horizontal scaling是指添加或刪除DB以調整capacity或整體效能，也稱為“scale out”。 使用Elastic Database client library管理scale out

下圖說明的scale up and scale out的模式

Vertical Scaling(Scaling up)解決方案設計

假設我們的公司在全球的業務經歷快速增長，需要為每個國家/地區維護和擴展單獨的 Azure SQL DB。 但是，增長速度和DB負載差異很大，因此資源需求無法預測的。 我們該如何管理擴展(scaling)以滿足組織的業務需求呢？

在這種情況下，最好選擇 SQL Elastic pools來擴展、管理效能和管理一組 Azure SQL DB的成本(如下圖)。

上圖顯示了 SQL Elastic pools和不同service tier的scaling capability。 pool中的DB共享分配的資源。 在平均使用率較低但很少出現高使用率峰值的情況下，我們可以在pool中分配足夠的capacity來管理group的高峰。 要正確配置 SQL Elastic pools以降低成本，必須選擇正確的購買模型和service tier （基於 DTU model 的basic/standard/permium或基於 vCore model 的general purpose or business critical）。更多的 SQL elastic pools可參考此篇文件。

Horizontal Scaling解決方案設計

這裡有兩種水平擴展:

• Read Scale-out
• Sharding

假設我們 我們有一個Application要存取 OLTP來更改裡面的資料，以及使用 Analytics application access read-only workload來呈現資料可視化。 我們可以做些什麼來分擔一些運算能力，從而不影響Application的效能？

一個簡單的方法是為某些service tier使用pre-provisioned的read scale-out功能。 read scale-out功能允許我們使用其中一個read-only replica的運算能力來分擔real-only的作業，而不是在read-write replicas上運行它們。 這樣，一些real-only workload可以與read-write workloads 分離，並且不會影響它們的效能。

下表呈現了 Azure SQL DB 和 Azure SQL managed instance的Read Scale-out provisioning：

而下圖則呈現了business critical service tire的read scale-out的架構:

在下圖Business Critical場景中，data和log files都在直接掛載上的 SSD 上運作，這降低了網路延遲。在此架構中，有三個secondary replica。如果發生任何類型的故障，fail over到secondary replica會很快，因為該replica已經存在並且資料已經直接掛載上的 SSD的。

在上面顯示的 Azure SQL DB 或 Azure managed instance 的 premium/business critical tier的高可用性架構中，我們可以看到它被配置為一個 Always On Availability Group，用於DR和Application的高可用性。有一個主要的read-write replica和幾個secondary read-only replicas。secondary replicas與primary replicas具有相同的compute size。我們設置connection string option來決定connection是路由到write replica還是read-only replica。

我們可以使用以下方法disable和re-enable Premium or Business Critical service tiers中的單一個DB和elastic pool DB的read scale-out：

• Azure portal
• Azure PowerShell
• REST API

PS:
在primary replica上所做的資料異動同步傳送到read-only replicas。 在連接到read-only replicas的session中，read始終是transactionally consistent。 但是，由於資料傳送延遲是變動的，因此不同的replica可以在相對於primary replica和彼此略有不同的時間點return data。

Sharding

假設我們有一個Application，這個Application的transaction throughput超出了我們給予對應DB的capacity。 我們如何配置DB以提高效能和可用性呢？

上述情況的一個可能解決方案是用sharding來進行 Horizontal Scaling 或horizontal partitioning。 這是一種將大量相同結構的資料分佈在多個獨立DB中。

Sharding的原因包括：

• 如果資料總量大到單一個DB無法處理，也就是超過了單一DB可以處理的量
• 如果整體工作負載的transaction throughput超過單個DB的capacity
• 當不同客戶或租戶的資料需要物理隔離時
• 在組織內部，出於合規性原因，資料存在地理性隔離

上圖呈現使用shard map manager在 Azure SQL DB上scaling out DB。 shard map manager是一個特殊的DB，它維護著一個shard set中所有shard（也就是DB）的global mapping information。 Metadata允許Application根據sharding key的值連接到正確的DB。 此外，shard set中的每個shard都包含track the local shard data（稱為 shardlet）的maps。

Azure SQL 提供 Azure Elastic Database tools。 這提供了許多工具來幫助我們從Application logic在 Azure 中建立、維護和查詢sharded SQL DB。

我們在設計上要把scale-in考量進去。 重要的是，我們的Application可以在負載下降時處理scal-in。

採用適合的DB擴展策略

下表列出了在選擇Vertical/Horizontal scaling之前要記住的重點。

Database的高可用度方案

若要了解 Azure SQL 中的可用性選項和功能，我們就需要了解service tier。 我們選擇的service tier將決定我們部署的DB或managed instance的底層架構。

有兩種模式：DTU 和 vCore。 這裡將重點介紹 vCore service tier及其高可用性架構。 我們可以將 DTU 模型的basic和standard tier等同於general purpose，將其Premium tier等同於Business Critical。

General Purpose

General Purpose service tier的DB和managed instance具有相同的可用性架構。下圖為一個guideline，首先考慮application和control ring。Application連接到server name，然後連接到gateway (GW)，gateway將Application指向要連接的server，在 VM 上運行。對於General Purpose，primary replica將locally attached SSD 用於 tempdb。data和log file存儲在 Azure Premium Storage中，這是 locally redundant storage（一個region中的多個副本）。然後將backup file存儲在 Azure Standard Storage中，預設下為 RA-GRS。換句話說，它是globally redundant storage（在多個region有副本）。

所有 Azure SQL 都構建在 Azure Service Fabric 之上，它充當 Azure backbone。如果 Azure Service Fabric 確定需要進行failover，則failover將類似於failover cluster instance (FCI)。service fabric將尋找具有備用容量的節點並啟動新的 SQL Server instance。然後將 DB file attach上去，恢復運作，並更新gateway以將Application指向新節點。不需要virtual network or listener or updates。這個功能是內建的。

Business Critical

Business critical通常可以實現所有 Azure SQL service tiers (General Purpose, Hyperscale, Business Critical)的最高效能和可用性。 Business critical用於需要低延遲和最短停機時間的mission-critical applications。

使用Business Critical就像在背景部署 Always On availability group(AG)。與eneral Purpose tier不同，在Business Critical中，data 和log file都在direct-attached SSD 上運作，這降低了network latency。 （General Purpose使用 remote storage。）在這個 AG 中，有三個secondary replicas。其中一個可用作read-only endpoint（無需額外收費）。當至少有一個secondary replicas強化了其transaction log的異動時，transaction 可以完成commit。

使用其中一個secondary replicas進行Read scale-out支援session-level consistency。因此，如果read-only session在replica無法使用導致連接錯誤後重新連接，它可能會被重導向到與 read-write replica不是 100% 最新的replica。同樣，如果Application使用read-write session寫入資料並立即使用read-only session讀取資料，則最新資料可能不會立即在replica上讀得到。資料延遲是因為非同步transaction log redo operation。

如果發生任何類型的故障並且service fabric確定需要failover，則failover到secondary replica會很快，因為這個secondary replica已經存在並且附加了資料。在failover中，我們不需要listener。即使在failover之後，gateway也會將我們的connection重定向到主節點。這個切換發生得很快，然後service fabric負責啟動另一個secondary replica。

Hyperscale

Hyperscale service tier只有可以在 Azure SQL DB使用。 這個service tier具有獨特的架構，因為它使用分層式快取和頁面伺服器，以擴充快速存取資料庫頁面的能力，而不需要直接存取資料庫檔案。

由於此架構使用成對的page servers，因此我們可以水平擴展以將所有資料放在caching layers中。這種新架構還支援高達 100 TB 的DB。因為它使用快照，所以無論大小如何，都可以進行幾乎即時的DB備份。DB restores需要幾分鐘而不是幾小時或幾天。我們還可以在一定時間內scale up or down 以乘載我們的工作負載。

log service用於提供replica和page server。當log service強化landing zone時，Transactions可以commit。因此，commit不需要secondary compute replica的consumption change。與其他service tier不同，我們可以確定是否需要secondary replicas。我們可以配置零到四個secondary replicas，它們都可以用於read-scale。

與其他service tier一樣，如果service fabric確定需要，則會發生automatic failover。但回復時間將取決於secondary replicas的存在。例如，如果我們沒有replica並且發生failover，則場景將類似於General Purpose service tier：service fabric首先需要找到備用容量。如果我們有一個或多個replica，則回復速度更快，並且更接近於Business Critical service tier的回復。

Business Critical 為具有需要低延遲的small log writes的工作負載保持最高效能和可用性。但是Hyperscale service tier允許我們有更高的log throughput（以 MB/second計），提供最大的DB大小，並提供多達四個secondary replicas以實現更高level的read scale。因此，當我們在兩者之間進行選擇時，我們要考量的是我們workload。

Geo-replication 與 auto-failover groups

選擇service tier（並在適用時考慮Availability zone）後，我們可以考慮一些其他options來取得read-scale或failover到另一個region的能力：geo-replication 與auto-failover groups。 在on-premises SQL Server 中，設定這些configuration中的任何一個都需要大量的計劃、協調和時間。

對於Geo-replication 與auto-failover groups，只需在 Azure portal中點幾下或在 PowerShell/Azure CLI 中執行一些命令即可進行配置。

Data at rest / in transit / in use的資料安全設計

如果我們是DBA，幫助確保 Azure SQL DB的環境安全。 假設我們是一家電商，將電話號碼、地址和信用卡等客戶資料存儲在託管的 Azure SQL DB中。 我們可以實施什麼解決方案來防止未經授權的人來存取資料呢？

按資料敏感性和業務影響對存儲的資料進行分類有助於組織確定與資料相關的風險。 在這裡，我們將詳細了解不同的資料狀態和加密模式。

良好資料保護的三個基本原則是：

• Data discovery
• Classification
• Protection

大型組織、政府和軍事單位一直在使用資料分類來管理資料的完整性。 資料分類的結果是metadata，使我們能夠將資料標記為：

• Public
• Confidential
• Restricted

資料分類後，可以對分成較高等類資料實施資料保護措施。 在這裡中，我們將探討結構化資料的資料加密。

資料存在於三種基本狀態之一 ：data-at-rest, data-in-motion, data-in-process。
在下表中，我們可以看到資料的狀態和可以實現的加密方法。

PS:
縱深防禦是一種採用分層方法來減緩主要在獲取未經授權的資訊存取攻擊策略。

Data-at-rest的保護

Data-at-rest加密是實現資料隱私、合規性和資料主權的必要步驟。 加密有助於降低與未經授權的資料訪問相關的風險。 需要保護Data-at-rest免受未經授權或off-line access原始文件或對不安全server的備份或將所有DB和transaction log files複製到另一台不安全server。就資安層面來看，Data-as-rest的加密指實現了資安C.I.A(confidentiality, integrity and availability)中的confidentiality與integrity．

Transparent data encryption

TDE 通過加密Data-at-rest來保護 Azure SQL DB、Azure SQL managed instance和 Azure Synapse Analytics 免受惡意離線活動的威脅。 它對DB及備份檔和transaction log files at rest執行即時的加解密，而無需更改Application。 預設情況下，對所有新部署的 Azure SQL DB啟用 TDE。 使用 Azure SQL managed instance，2019 年 2 月之後建立的 DB都會有 TDE。

• TDE 在page level執行資料的加解密。
• 當資料被寫入Disk上的data page時，資料被加密，當data page被讀入memory時，資料被解密。
• 最終結果是Disk上的所有data page都被加密。
• DB backup也將被加密，因為backup operation只是將data page從DB file複製到backup device。 在backup operation期間不進行解密。
• TDE 使用稱為Database Encryption Key (DEK) 的對稱密鑰對整個DB的storage進行加密。
• Service-managed TDE — DEK 受內建server certificate保護。
• Customer-managed TDE — 加密 DEK 的 TDE protector由客戶提供並存儲在客戶擁有和管理的KMS(key management system)

PS:
要將 TDE 與 Always On Availability Group中的DB一起使用，必須將用於加密DB的憑證備份並還原到Availability Group中將託管DB副本的其他server。

TDE的Azure Key Vault service

Azure Key Vault 是一種用於存儲和access 密碼、certificastes或keys等敏感資料的工具。 它是Application secrets的集中存儲解決方案，還有助於監控keys/certificates的access方式和時間。 Azure Key Vault 可與其他 Azure 服務整合。 Key Vault data有自己的 RBAC 策略，獨立於 Azure subscription，因此user需要獲得明確的訪問權限。

在我們之前的假設狀況中，我們正在實施一種解決方案，以保護data-at- rest免受未經授權的人access資料。 Customer-managed TDE — Bring Your Own Key TDE 實現是上述場景的一個解決方案。 Database Encryption Key(DEK) 的 TDE 保護器是我們管理的非對稱密鑰，存儲在我們擁有和管理的 Azure Key Vault（Azure 基於Azure Cloud的外部KMS）中，並且永遠不會離開key vault。更多的Azure SQL TDE with cuntomer-managed key資訊請參閱此篇文件。

Data-in-transit的保護

SQL DB、SQL managed instance和 Azure Synapse Analytics 始終對所有connection強制實施加密（SSL/TLS ）。 這確保所有資料在client和server之間的“傳輸中”都被加密。 Microsoft 提供或支援的所有驅動程序都使用TLS 連接到 Azure SQL DB或 Azure SQL managed instance中的DB。 在某些情況下，我們可能希望使用 VPN 隔離on-premises和cloud infra之間的整個communication channel。

下表中，我們可以看到甚麼狀況使用 VPN gateway、TLS 和 HTTPS

Data-in-use的保護

如果我們讓公司的業務人員access包含客戶電話號碼和電子郵件地址的。 我們希望他們能夠查驗客戶的通聯記錄，但我們只開放業務人員只能看到客戶電話的最後三碼(如下圖)。 我們將如何針對這種情況實施解決方案？

動態資料遮罩

動態資料遮罩是一種基於policy-based security feature，它在指定DB fields的查詢結果中隱藏敏感資料，而DB中的資料不會更改。 它通過使我們能夠指定要顯示多少敏感資料而對Application layer的影響最小，從而有助於防止對敏感資料未經授權的訪問。

• 動態資料遮罩自動發現 Azure SQL DB和 SQL managed instance中的潛在敏感資料，並提供可操作的建議來蓋掉這些fields。
• 它通過混淆查詢結果中的敏感資料來作業
• 只能在 Azure portal中為 Azure SQL DB 設定資料遮罩政策
• 可以使用 PowerShell cmdlet 和 REST API 設置動態資料遮罩

資料遮罩規則包括要要遮罩的column以及應如何遮罩資料。 使用標準遮罩或指定我們的自定義遮罩邏輯。下表為需要遮罩的column和邏輯：

PS: 動態資料遮罩是一個 presentation layer feature並且Admin看到的資料永遠都沒有遮罩。

想像一個由所有授權等級的使用者查詢和 存取 DB的狀況。 沒有admin權限的user查詢包含一些敏感客戶資料（例如電話號碼、電子郵件等）以及購買和產品資訊。我們將如何實施一種解決方案，在允許user查看其查詢的剩餘field的同時蓋掉敏感資訊？

Data-in-use的動態資料遮罩 — 我們可以使用電子郵件、信用卡等的預設遮罩邏輯設定動態數據遮罩policy，或為相關field指定自定義文本或隨機數。 非admin人員將看到被遮罩的value。 我們可以通過將其他user添加到 SQL user（從遮罩清單中排除）來允許其他user查看沒有被遮罩的資料。

Data-at-rest 與Data-in-transitr的Always Encrypted功能

Always Encrypted 是一個主要在保護存儲在特定DB 中的敏感資料不被存取（例如，信用卡號、身份證號等）的功能。 這包括DBA或其他有權 存取DB以執行管理任務的特權用戶。 資料始終是加密的，這意味著加密的資料只能被有權拿到 加密密鑰的client application 來解密。 這個key可以存儲在 Windows Certificate Store 或 Azure Key Vault。

以下是Always Encrypted的作業流程

• Always Encrypted 使用兩種類型的key：column encryption keys and column master keys。
• column encryption key用於加密encrypted column中的資料。column master key再對所有的column encryption key再一次加密。
• DB engine只存儲column encryption keys的encrypted values和有關column master keys位置的資訊，這些資訊存儲在外部受信任的密鑰存儲中，例如 Azure Key Vault、Windows Certificate Store
• 要以明文形式存取存儲在encrypted column中的資料，Application必須使用已經enable Always Encrypted 的client driver。通過client driver進行加密和解密。
• Driver 會通透與DB engine協作，以獲取column的column encryption key的encrypted value以及相對應的column master key的位置。
• Driver 連結包含列column master key的key store，以解密encrypted column encryption key value，然後使用plaintext column encryption key加密parameter。
• Driver將針對encrypted columns的參數的plaintext values替換為其encrypted values，並將查詢發送到server進行處理。
• Server計算結果，對於結果中包含的任何encrypted columns，Driver附加該column的encryption metadata，然後Driver解密結果並將plaintext values返回給Application。

關於 Always Encrypted best practices可以參考此文件。另外一個重要的是Always Encrypted 不適用於動態資料遮罩。 "意思是無法同時加密和遮罩同一個column"。 我們需要優先保護正在使用的資料，而不是通過 動態資料為我們的app user 遮罩資料。

假設 我們在業務區域有一個地端的client application。 作為其DB雲端遷移的一部分，我們正在評估 Azure SQL DB。 計劃將DB維護外包給第三方。 我們需要第三方供應商或雲端管理員不可以存取敏感資料。 我們該怎麼做？

Always Encrypted 用於data-at-rest and data-in-transit — Always Encrypted 確保DBA和Application admin之間的權責分離。 通過將 Always Encrypted keys存儲在地端機房或第三方託管的受信任密鑰存儲中，他們可以確保 Azure 雲端管理員無法存取敏感資料。 Always Encrypted 使我們能夠有信心的存儲不受其直接控制的敏感資料。

Azure SQL Edge的設計

Azure SQL Edge 是一個優化的relational database engine，適用於 IoT 和 IoT Edge 部署。 Azure SQL Edge 建構在與 SQL Server 和 Azure SQL 相同的engine上。 這意味著具有 SQL server技能的開發人員可以reuse他們的code在 Azure SQL Edge 上構建edge-specific solutions。 Azure SQL Edge 提供tream, process, and analyze relational 和non-relational （例如 JSON、graph和time-series data）的功能。

Azure SQL Edge 有兩個不同的版本，如下所示。 這些版本具有相同的功能集，僅在使用權限以及它們可以在host system上access的memory和cpu core數量方面有所不同。

• Azure SQL Edge Developer — 開發環境使用．每個Azure SQL Edge Developer最多包含 4 cores cpu 與32G memory
• Azure SQL Edge: 正式環境使用．每個Azure SQL Edge最多可以有 8 core cpu and 64GB memory.

Azure SQL Edge的部署模式

這裡有兩種部署模式：

• Connected deployment through Azure IoT Edge :
  Azure SQL Edge在Marketplace是available的並且能夠被部署為 Azure IoT Edge的module．
• Disconnected deployment:
  通過 Azure SQL Edge container image進行斷Disconnected deployment，可以從 docker hub pull並部署為獨立的 docker container或 Kubernetes cluster。

Azure SQL Edge的作業流程

Azure SQL Edge是一個容器化的Linux Application．start-mempry佔用小於 500 MB。 這允許我們設計和構建在許多IoT設備上運行的Application。 SQL Edge 可以：

• Capture continuous data streams in real time
• Integrate the data in a comprehensive organizational data solution

下圖顯示了SQL edge擷取與儲存 streaming data的能力

對於IoT資料，重要的是不僅要擷取一直長大在資料量的持續real-time streams，而且還要從中獲得有價值的洞察。 Azure SQL Edge有內建的streaming engine來幫助滿足這些需求。 它具有以下特點

• Streaming engine允許對傳incoming data streams進行transformation, Windowed aggregation, Simple anomaly detection and classification
• 允許存time-indexed data的time-series storage engine。 這可以匯總並存儲在cloud中之後來分析

下圖顯示 Azure SQL Edge 與network edge的組件交互，包括edge gateway、IoT device和邊edge servers。

將 IoT apps部署到edge時，安全性是一個主要問題。由於 Azure SQL Edge 基於 SQL Server 技術，因此它具有與 SQL Server Enterprise 相同的安全功能。同樣的安全策略和實踐也從cloud擴展到edge。

保護 Azure SQL Edge 部署如下描述的步驟：

1. Platform and system security。這包括physical docker host、主機上的OS以及將物理設備連接到Application和client的網路系統。
2. Authentication and authorization。 SQL authentication是指使用username和password連接到 Azure SQL Edge 時對user的身份驗證。authorization是指在 Azure SQL Edge 的DB中分配給user的權限
3. Database object security。 “Securables”是DB包含的Server、DB和objects。加密增強了安全性。使用TDE的資料保護能夠遵守許多安全法規。 Always Encrypted 將擁有資料的users和管理資料的user分開
4. Application security。 Azure SQL Edge 安全最佳做法包括編寫安全的client application。

安全性

將 IoT 應用程式部署到edge時，安全性是主要的考量。 由於 Azure SQL Edge 是以 SQL Server 技術為基礎，而且具有與 SQL Server Enterprise 相同的安全功能。 相同的安全性原則和做法會從雲端延伸至邊緣。

確保Azure SQL Edge 部署的安全性包含四個步驟：

1. 平臺和系統安全性。 此安全性步驟包括實體 Docker 主機、主機上的作業系統，以及將實體裝置連線到應用程式和用戶端的網路系統。
2. 驗證和授權。 SQL 驗證是指使用使用者名稱和密碼連線至 Azure SQL Edge 時的使用者驗證。 授權是指Azure SQL Edge 中資料庫內指派給使用者的權限。
3. 資料庫物件安全性。 資料庫物件或 安全性實體 是資料庫中的伺服器、資料庫和其他物件。 加密可增強安全性。 使用TDE)的資料保護可協助符合許多安全性規範。 「Always Encrypted」提供Data Owner與DBA之間的權責分離。
4. 應用程式安全性。 Azure SQL Edge 安全性最佳作法包括寫入安全性用戶端應用程式。

何時使用Azure SQL Edge

Azure SQL Edge適合以下需求

Azure Cosmos DB 與tables的設計

Azure Cosmos DB 是一種用於現代應用開發的完全託管的 NoSQL DB服務。 它具有個幾毫秒的response times，並保證任何scale的速度。

作為一項全託管的服務，Azure Cosmos DB 通過自動管理、更新和修補來免除一些ＤＢＡ管理作業。 它還通過具有成本效益的serveless和auto scaling options來處理容量管理，這些選項可以回應Application的需求，使容量與需求相匹配。

Azure Cosmos DB 的一些功能包括：

• Automatic and instant scalability.
• Enterprise-grade security.
• Business continuity is assured with 99.999% SLA-backed availability.
• Turnkey multiple region data distribution anywhere in the world.
• Open-source APIs and SDKs for most popular languages.
• Takes care of database administration with automatic management, updates, and patching.
• Build fast with no-ETL analytics over operational data.

Azure tables storage與 Azure Cosmos DB tables的不同處

Azure table storage是一種在cloud中存儲non-relational structured data（稱為structured NoSQL data）的服務(示意圖如下)，提供具有schemaless design的key/attribute。 因為Table storage是schemaless的，所以隨著Application求的發展，很容易調整資料。

Table storage的常見用途包括：

• 存儲 TB 的結構化資料，能夠為 Web scale application提供服務。例如，我們可以在一個table中存儲任意數量的entities，並且一個storage account可以包含任意數量的table，直至storage account的容量限制。
• 存儲不需要復雜的join、foreign keys, 或stored procedures。
• 使用clustered index快速查詢資料。對於許多類型的Application來說，Access table storage既快速又經濟。對於類似的資料量，table storage的成本通常低於傳統 SQL。

Azure Cosmos DB 為 Azure table storage編寫並需要high availability, scalability, and dedicated throughput等premium capabilities的應用程序提供table API。

如果我們正在考慮搬遷到Azure， Azure table storage和 Azure Cosmos DB table之間的行為存在一些差異。例如：

• Azure Cosmos DB table的容量在建立後就立刻會被收錢，即使沒用到滿還是要收。這種收費結構是因為 Azure Cosmos DB 使用預留容量模型來確保client可以在 “10 ms”內讀取資料。在 Azure table storage中，是用多少算多少，但只能保證在 “10 秒”內進行read access。
• Azure Cosmos DB 中的查詢結果未按partition key 與 row key的順序排序，因為它們來自storage table。
• Azure Cosmos DB 中的row keys限制為 255 個bytes。
• Batch operation限制為 2 MB。
• Azure Cosmos DB 支援Cross-Origin Resource Sharing (CORS)。
• Azure Cosmos DB 中的table name區分大小寫。它們在Storage table中不區分大小寫。

雖然這些差異很小，但我們應該仔細檢查我們的Application，以確保搬遷不會導致意外問題。

其他的Cosmos DB

針對為Azure table storage而編寫的Application只需少量code change即可搬遷到 Cosmos DB table API。 Azure Cosmos DB table API 和 Azure table storage 共享相同的table data model，並通過其 SDK 來expose 相同的 create, delete, update, and query operations。

如果我們當前使用 Azure table storage，則通過搬遷到 Azure Cosmos DB table API 可以有以下效益：

Cosmos DB 提供哪些Database API？

Azure Cosmos DB 提供多個DB API，為一系列 NoSQL DB提供native interface。 通過使用這些 API，Azure Cosmos DB 可幫助我們使用已有的生態系統、工具和技能來進行資料建模和查詢。

在這裡，我們將學會一些適用於 Core (SQL) API、API for MongoDB、Cassandra API 和 Gremlin API 的現實場景。 下圖總結了選擇合適的data storage solution的工作流程。

何時使用 Core(SQL) API

假設我們為一家銷售汽車零部件的電商工作。公司將大量產品目錄存儲為 JSON file。對於semi-structured data storage，我們決定搬到 Azure Cosmos DB。我們需要為 Cosmos DB 選擇一個 API，它將：

• 為新產品啟用fast scaling。
• 支援當前使用 SQL 查詢 JSON data的方法。

我們的要求是：

• 使用團隊現有的SQL 語法技能來做JSON object 的查詢。
• 具有保證throughput的Globally accessible data。
• 支援快速添加新的產品類別。

根據上述要求，我們決定使用 Core (SQL) API 來存儲面向客戶的電商網站的目錄。此 API 以document format存儲資料。為什麼選擇 Core (SQL) API？

• 讀取和寫入只有幾毫秒延遲。
• 具有auto failover功能的Globally distributed DB。
• 具有 99.999% 的 SLA 的Read and write availability。
• 利用預置的provisioned throughput 或 auto scale。
• 推薦用於存儲cache data, session management repository, user & profile management, and product recommendation等use case。

何時使用MongoDB API

假設我們 使用 Mongo DB 來存儲不同產品的採購訂單。產品不限於任何結構，可以具有許多屬性(attributes)。我們希望遷移到 Azure Cosmos DB。我們需要幫助DBA選擇正確的 API。

我們的需求是：

• 現有DB使用 MongoDB 來處理採購訂單。
• 運營團隊希望最少的減少code change和盡可能少的停機時間進行搬遷。
• 開發團隊花費了大量精力來建構自己做的SDK。
• 訂單量正在增加，因此需要考慮可擴展性。
• 需要針對BI的real-time data進行分析。

此處的一個有效選擇是為 MongoDB API for Azure Cosmos DB。適用於 MongoDB 的 Azure Cosmos DB API 實現了 MongoDB 的wire protocol。我們可以利用我們的 MongoDB 經驗並繼續使用我們最喜歡的 MongoDB drivers、SDK 和tools，方法是將我們的Application指向 API for MongoDB account的connection string。

下圖顯示了 Azure Cosmos DB 的不同programming languages對標準 MongoDB protocol的使用。

以下是MongoDB 的優勢

何時使用Cassandra API

假設我們正在為涉及存儲health tracker data的用例建模解決方案。 這還涉及telemetry 與sensor data。 目前這是在 Apache Cassandra 中完成的。 我們需要幫助他們選擇正確的 API 來擴展他們的DB需求。

我們的要求是：

• 開發人員目前正在使用 Cassandra Query Language (CQL)、基於 Cassandra 的工具（如 cqlsh）和 Cassandra client drivers
• 該解決方案應支援horizontal scaling。
• 需要Online load balancing和cluster growth。
• 應該有一個靈活的schema。

這裡的一個有效選擇是為 Cassandra API for Azure Cosmos DB.。 Cassandra API 是與 Apache Cassandra 相容的wire protocol。 此 API 將資料存儲在column-oriented schema中。 Cassandra API 目前僅支援 OLTP 。 API 支持 CQL 版本 3.x。

以下是Cassandra API的優勢

何時使用Gremlin API？

假設我們需要在 Azure 生態系統中為我們 分析和provision一個新的non-relational database application。我們正在尋找存儲social media entity relationships並能夠在DB中快速瀏覽它們。

我們的要求是：

• 使用Data Explorer 來Store, retrieve, and manipulate圖形資料並將其可視化。
• 在不影響效能的情況下處理大量transactions。
• 克服傳統graph database 靈活性和relational方法的限制。
• User應具備使用 Graph query language來ingest和query 資料的能力。

這裡一個有效的選擇是選擇基於 Apache TinkerPop 的 Azure Cosmos DB 的 Gremlin API。 Apache TinkerPop 是一個使用 Gremlin 查詢語言的圖形計算框架。graph是由vertices和edges組成的結構。Vertices呈現objects，edge呈現vertices之間的關係。

此類DB的use case是存儲organizational hierarchies, online fraud detection systems, social media graphs, and IoT。 Gremlin API 目前僅支援OLTP場景。

下圖顯示了 Cosmos DB context中的 Gremlin API。

Gremlin API的優勢是什麼？

• Gremlin API 具有與開源 Gremlin 的wire protocol支援，因此我們可以使用開源 Gremlin SDK 來建構我們的Application。
• 我們可以存儲具有數十億個vertices and edges的massive graphs。 資料將使用graph partitioning自動分佈，允許彈性擴展throughput and storage。
• 我們可以有毫秒等級的millisecond latency 圖形並輕鬆地演化graph structure。
• Gremlin API 還與 Apache Spark 和 GraphFrames 一起用於複雜的graph scenarios場景。
• Multi-region replication提供regional failover機制，以確保我們的Application 的連續性。