Azure 運算單元設計

運用"雲端服務"加速企業的數位轉型願景

28 min readFeb 7, 2022

不同類別的應用程式有不同的運算需求，為每種類別選擇正確的運算技術非常重要。理想情況下，我們希望建立運算資源、配置資源到pay-as-you-go的理想狀況。所以在本文中我們會根據組織的業務運算需求學習到如下的目標:

選擇運算服務
Azure VM的方案設計
Azure Batch的方案設計
Azure App service的方案設計
Azure Container instances的方案設計
Azure Kubernetes Service的方案設計
Azure Function 的方案設計
Azure Logic App的方案設計

擇運算服務

運算是指運行應用程式的運算資源。 Azure 提供了多種運算服務，我們將在這節中介紹這些服務。

Virtual Machine(IaaS)。在 Azure 虛擬網路中部署和管理 VM。
Azure Batch (PaaS)。用於運行大規模並行和高效能計算 (HPC) 應用程式的託管服務。
Azure Function(FaaS)。直接在雲端中跑code的託管服務，無需管理基礎架構。
Azure Logic Apps(PaaS)。用於建立和運作自動化工作流程的平台。
Container Instances(PaaS)。在 Azure 中運行容器的快速簡單的方法。不需要管理與配置任何底層的VM，也不需要更高等級的服務。
Azure App Service(PaaS)。用於託管 Web 應用程式、行動應用程式後端、RESTful API 或自動化業務流程的託管服務。
Azure Kubernetes Service(PaaS)。Azure的K8S託管服務。

以下是一個high-level的指引流程圖。幫助我們根據一些情況來判斷應該使用何種Azure 運算服務。

上圖中，Cloud Optimized是一種遷移到雲端的策略。

Cloud Optimized重構(refactor)應用程式以利用雲原生特性和功能。
Lift and shift 策略無需重新設計應用程式或改code即可遷移工作負載。 Lift and shift讓組織能夠以最小的變動與中斷繼續運行應用程式。
Containerize: 通常很舊的應用程式容器化的代價太大，新開發的應用程式通常較能容器化。

檢視運算選項

運算解決方案具有三個託管選項：

Infrastructure as a Service(IaaS)
Platform as a Service(PaaS)
Function as a Service(FaaS)？

還有不是運算解決方案的Software-as-a-Service(SaaS)。託管選項決定了開發人員和雲端提供商(以下簡稱CSP)的責任，我們稱之為Shared responsibility。這個託管決定將影響我們的設計。

IaaS允許我們建立單一的VM以及相關的網路和存儲組件。然後，我們將所需的任何軟體和應用程式部署到這些VM上。除了由 Microsoft 管理基礎結構外，此模型最接近傳統的地端機房環境。我們仍然管理各個VM。
PaaS提供了一個託管環境，我們可以在其中部署您的應用程式，而無需管理VM或網路資源。 Azure App Service是一項 PaaS 服務。
FaaS更進一步消除了對託管環境的管理工作。在 FaaS 模型中，我們部署代碼，服務會自動運作它。 Azure Functions 是一項 FaaS 服務。

Azure VM的方案設計

無論我們是建立新的還是使用lift and shift模式進行遷移，Azure VM都可能是我們的選擇。 Azure VM 是 Azure IaaS模型的基礎。 Azure VM 可用於在雲端中開發、測試、部署應用程式或擴展我們地端的資料中心。 Azure VM 提供了一種快速、可擴展、靈活的方式來為企業增加更多的運算能力。

決定使用虛擬機有兩種主要場景

建立新VM ，因為對應用程式的需求可能會有波動。在 Azure 中的 VM 上運行它具有經濟效益(視狀況決定經濟效益)。
Lift and shift (rehosting)遷移策略，涉及將資料和應用程式從地端機房移動到Azure 的VM。

讓我們看一下在為 Azure VM 設計時要考慮的檢查清單。

Start with the network
Name the VM
Decide the location for the VM
Determine the size of the VM
Review the pricing model
Review the storage options
Select an operating system

網路

首先要考慮的根本不是VM — — 而是網路。因此，請花一些時間考慮我們的網路配置。設置好Network addresses 與subnets後，更改它們並非易事。如果我們有地端網路加入，則需要在建立任何VM之前仔細考慮網路拓撲。

VM命名

我們通常沒有過多考慮的一件事是VM名稱。此名稱定義了一個可管理的 Azure resource，並且也不容易更改。選擇有意義且一致的名稱，以便我們可以容易識別 VM 的功能。例如，PrdUsc-web01 可能代表託管在美國中南部位置的第一個正式環境的Web server。

VM該放在哪裡

Azure 在世界各地都有資料中心，裡面裝滿了servers 與disks。這些資料中心被分組到地理區域（“美國西部”、“北歐”、“東南亞”……）以提供redundancy 與 availability。

每個VM都位於我們希望分配資源（CPU、Storage……）的Region中。 Region位置可讓我們將VM放置在盡可能靠近我們客戶的位置。此位置可以提高效能並確保我們滿足任何當地法律、合規或稅務要求。

考慮位置選擇的另外兩件事。

位置可能會限制可用選項。每個region都有不同的可用硬體，並且某些配置並非在所有地區都可用。
不同region之間存在價格差異。要找到最具成本效益的選擇，我們需要檢查在不同region的所需配置。

VM的大小

設置名稱和位置後，我們需要確定 VM 的大小。 Azure 為不同的 VM 大小提供不同的memory和storage選項。

確定適當 VM 大小的最佳方法是考慮 VM 需要運行的工作負載類型。根據工作負載，我們可以從可用 VM 大小的subset中進行選擇。 Azure VM 工作負載分類如下。

若以上的資訊還不確定我們需要何種Azure的 VM instance type，我們可以使用Azure提供的VM選擇器工具。

定價模式

每個 VM 將分別收取兩種訂閱費用：compute和stroage。通過分離這些費用，我們可以獨立擴展它們並且只為需要的部分付費。

Compute costs — 運算費用每小時結帳一次，但按分鐘計價。例如，如果 VM 部署 52 分鐘，我們只需支付 52分鐘的使用費。如果我們停止並刪除該 VM，則無需為計算容量付費。每小時價格因選擇的 VM 大小和OS而異。
Storage costs— 需要為 VM 使用的存儲單獨付費。容量劃多大就要為這個容量付錢，無論我們有沒有用滿它。

用哪種硬碟

Managed disks在背景處理 Azure storage account的建立和管理。我們指定disk大小和效能層（Standard或Premium），Azure 建立和管理disk。當我們添加disk或scale up和scale down VM 時，我們無須擔心正在使用的storage。

作業系統

Azure 提供了可以安裝到 VM 中的各種OS images，包括多個版本的 Windows 和各種版本的 Linux。 Azure 將OS licens的錢捆綁到費用中。

如果我們要尋找的不僅僅是base OS image，我們可以使用 Azure marketplace。有各種images，不僅包括OS，還包括軟體工具。例如，有一個 WordPress 的images。Image stack由 Linux server、Apache Web server、MySQL DB和 PHP 組成。因此，我們無需設定和配置每個組件，而是安裝一個 Marketplace image並一次獲取整個stack。

最後，如果我們找不到合適的OS image，我們可以建立自己的disk image然後可以將disk image上傳到 Azure storage並用於建立 Azure VM。(PS:Azure 僅支持 64 位OS)

小提示：我們在規劃VM時需要考慮很多事情。花幾分鐘時間思考一下我們需要VM嗎？如果是這樣，我們將在規模、定價和OS方面做出哪些決定？

Azure Batch的方案設計

Azure Batch 在雲端中進行大規模的應用程式。我們可以進行需要大量運算的作業並動態調整資源，而無需管理基礎架構。 Azure Batch 可以建立和管理compute nodes pool（VM）。 Azure Batch 還可以安裝要運行的應用程式，並安排作業在運算節點上運行．

何時使用Azure Batch

Azure Batch 適用於獨立運作的應用程式（parallel workload）。
Azure Batch 對於需要相互通訊的應用程式（tightly coupled workloads）也很適用。例如，我們可以使用 Batch 構建為金融業運行蒙地卡羅模擬的服務或處理圖片的服務。
Azure Batch 支援大規模平行和高效能計算 (HPC) 批次處理作業，能夠擴展到數十、數百或數千個 VM。當準備好運行作業時，Batch 會執行以下操作。
— 啟動compute VM pool
— 安裝應用程式和暫存資料
— 運作我們所需的運算工作的數量
— 識別失敗、重新排入佇列工作，並在工作完成時縮小集區。

Azure Batch 作業方式

如下圖所示，Azure Batch 的典型實際場景需要資料和應用程式的檔案。 Batch workflow首先將資料和應用程式檔案上傳到 Azure storage account。根據需求，我們可以建立一個包含所需數量的 Windows 或 Linux virtual compute nodes的 Batch pool。如果需求增加，compute node可以自動擴展。

上圖可以分為兩部分：

使用 Azure 作為平台的服務。該平台用於完成大量運算的工作，然後取回結果。我們還可以監控作業和任務進度。
批次處理作為我們的服務背後的運算平台。 Batch 使用 Azure storage來獲取完成作業所需的應用程式或資料。 Azure Batch 將輸出寫入 Azure storage。在背景，有VM的collection（pools）。 Pools是jobs和tasks在上面執行的資源。

Azure Batch的最佳實踐

Azure Batch 的最佳實踐分為pools、nodes和jobs。

Pools。如果我們的Jobs包含短期作業(tasks)，不要為每個Job創建一個 new Pool。建立new pool的overhead將減少job的運作時間。此外，最好讓我們的jobs動態使用pools。如果我們的jobs對所有內容都使用相同的pools，那麼如果pool出現問題，jobs就有可能無法運行。

Nodes。不能保證單個nodes不會掛。如果我們的 Batch 工作負載需要確定性、有保證的進度，我們應該配置具有多個nodes的pools。考慮對具有合規性或法規要求的工作負載使用分離的 VM 大小。

Jobs。使用具有唯一名稱的方式，以便我們可以準確地監控和記錄活動。考慮將我們的tasks分組到有效大小的jobs中。例如，使用包含 1000 個tasks的單個job比建立每個包含 10 個tasks的 100 個jobs更有效。

更多的Azure Batch最佳實踐請參閱此文件．

Azure App service的方案設計

Azure App service是一種基於 HTTP 的服務，可讓我們建立和託管 Web apps、background jobs, mobile backends, 與RESTful APIs。 App Service允許我們使用我們慣用的開發語言。 Azure App service提供自動縮放和高可用性。 App Services支援從 GitHub、Azure DevOps 或任何 Git repo進行自動化部署。

App Service的類型

借助 Azure App service，我們的所有apps都享有共同的效益，包括：

聚焦於網站開發和 API 邏輯。 Azure 會處理基礎結構，以執行及調整 Web 應用程式
以多種開發語言和框架進行開發。
使用安全endpoints進行整合部署和管理。
具有高可用性的全球規模。
內建Load Balancing和traffic management。

使用App service deployment slots進行CD(continuous deployment)

Azure DevOps 為提供開發團隊來規劃工作、協作開發代碼以及建立和部署應用程式。 在持續部署時，盡可能使用deployment slots進行新的Production build。

使用Standard App Service Plan tier或更高等級時，我們可以將apps部署到staging environment、驗證變更並進行smoke tests。準備就緒後，我們可以swap staging 與production slots。 swap operation warms up必要的worker instance以匹配生產規模，從而消除停機時間。

Azure App Service費用

我們需要為apps在處理requests時使用的 Azure compute resources付費。費用取決於我們選擇哪一種的App service plan。App service plan確定有多少專用硬體在我們的host。例如，Plan確定它是專用硬體還是共享硬體以及保留多少memory。我們可以為不同的apps制定不同的app service plan。

App service plan可以隨時擴大和縮小。例如，可以在免費的App service plan中開始測試 Web app，而無需支付任何費用。當想要將我們的自己 DNS 名稱添加到 Web app時，只需將plan scale up到Shared tier。

Authentication與authorization的選項

實施用於authentication 和authorization的安全解決方案可能需要付出巨大的人力與時間成本。 Azure app service提供內建的authentication 和authorization功能。因此，我們可以通過編寫最少的代碼或不編寫代碼來做到authentication 和authorization。這裡有一些效益。

Azure app service為Web app或 API 提供內建的authentication。不用自己搞。
它直接內建在平台中。我們不需要任何開發語言、SDK、資安專業知識，甚至任何代碼即可使用。
我們可以與多個驗證商整成。例如，Azure AD、Facebook、Google 和 Twitter。

Azure App Service的使用時機

Web App的考量。使用 ASP.NET、ASP.NET Core、Java、Ruby、Node.js、PHP 或 Python 的 Web apps。我們可以選擇 Windows 或 Linux 作為host OS。
API App的考量。使用選擇的語言和架構，建置類似 REST 型 Web API 的 API app。 Azure App Service 提供完整的 Swagger 支援，以及在 Azure Marketplace 中封裝及發佈 API 的能力。應用程式可以從任何 HTTP 或 HTTPS 用戶端取用。
WebJobs的考量。使用 App Service WebJobs 功能來執行程式或指令碼。程式範例包括 Java、PHP、Python 或 Node.js。指令碼範例包括 cmd、bat、PowerShell 或 Bash。我們可將 WebJobs 排程，或透過觸發程序來執行。 Web 工作通常是用來以應用程式邏輯之一部分的形式執行背景工作。
持續佈署的考量。選擇Standard App Service plan或更高等級，以啟用代碼的持續部署。將應用程式部署到stage，並使用測試回合來驗證應用程式。當應用程式準備好發布時，switch stage 跟 production。交換作業會準備必要的背景工作角色執行個體，以符合生產環境所需的規模，進而消除停機時間。
驗證與授權的考量。利用 Azure App Service 中的內建驗證功能。我們不需要任何語言、SDK、安全性專業知識，甚至是任何代碼，即可在 Web 應用程式或 API 中使用此功能。您以與多個登入提供者整合，例如 Microsoft Entra ID、Facebook、Google 和 X。Azure Functions 提供 App Service 中可用的相同內建驗證功能。
考量多種方案來降低成本。針對不同的應用程式設定不同的 Azure App Service 方案。隨時都能擴大和減低plan。開始在免費的 App Service 方案中測試 Web 應用程式，無須支付任何費用。當想要將自己的 DNS 名稱新增至 Web 應用程式時，只需將plan升級Shared tier。

Mobile apps的使用時機

使用 App Service 的mobile apps功能快速建立 iOS 和 Android apps的backend 。只需在 Azure portal中執行幾個步驟，我們就可以：

將mobile app data存儲在基於Azure的 SQL database中。
針對常見的社交平台（例如 MSA、Google、X 和 Facebook）對客戶進行身份驗證。
發送推送通知。
在 C# 或 Node.js 中執行自定義後端邏輯。

在mobile app方面，SDK 支持原生 iOS 和 Android、Xamarin 和 React 原生apps。

Azure Container instances的方案設計

與實體硬體所需的投資相比，VM是降低成本的方式之一。但是，每個VM仍然僅限於一個OS。如果想在單一host上運行Application的多個instances，容器是一個很好的選擇。

Azure Container Instances(類似AWS 的ECS)是在 Azure 上運行容器的一種快速而簡單的方法。 Azure Container Instances方案包括簡單的應用程式、task automation 與build jobs。以下是容器的一些效益。

Fast startup. 啟動容器只要幾秒的時間
Per second billing. 容器有在跑才算錢
Hypervisor-level security。高度隔離我們的application，就像安裝在個別的VM上.
Custom sizes。對CPU cores 與memory 定下精確的使用需求.
Persistent storage。將 Azure File shares直接掛載到容器.
Linux and Windows.。使用相同的 API call來呼叫Windows 和 Linux 容器.

Container groups

Azure Container Instances中的最高等級的資源是container group。 container group是在同一個host上調度的容器集合(collection)。 container group中的容器”共享生命週期、資源、本地網路和storage volumes(你可以把它想成是K8S的Pod)”。

Multi-container groups在我們想要將單一的functional task務劃分為多個container image的情況下很有效。然後，這些image可以由不同的團隊交付，並具有不同的資源要求。通常使用的狀況如下：

用於 Web application的容器和從source control中提取最新content的容器。
一個application container和一個logging container。 logging container收集main application輸出的logs和metrics，並將它們寫入long-term storage(Side car機制)。
一個application container 與一個 monitoring container。 monitoring container會定期向Application發出request，以確保它正在運行並正確回應，如果不是，則會發出告警。
一個front-end container 與一個back-end container。前端可能服務於一個 Web applications，而後端運行一個服務來取得資料。

Container instances的資安考量

使用container instances時，請考慮這些最佳實踐。

使用private registry。容器是從存儲在一個或多個repo中的images構建的。這些repo可以屬於public registry 或private registry。 private registry的一個範例是 Docker Trusted Registry，它可以安裝在on-premises 或在 virtual private cloud。
確保Images在整個生命週期內的完整性(integrity)。在整個容器生命週期中管理安全性的一部分是確保容器映像的完整性。不應該允許有漏洞的images，即使是輕微的，在生產環境中運行。盡量減少production image的數量，以確保可以有效地管理它們。
監控容器資源活動。監控資源活動，例如容器存取檔案、網路和其他資源。監控資源活動和消耗對於效能監控和安全措施都是有效的。

使用容器來取代VM

下標是根據容器與VM的功能來決定何時用VM何時用容器

Azure Kubernetes Service的方案設計

Kubernetes 是一個可移植、可擴展的開源平台，用於自動部署、擴展和管理容器化的工作負載。這個orchestration platform為我們提供了與PaaS 和IaaS產品相同的易用性和靈活性。 Kubernetes 同時提供容器管理(container management)和容器編排(container orchestration)。

容器管理是組織、新增、刪除或更新大量容器的過程。大多數這些作業都是手動的並且容易出錯。
容器編排是一個自動部署和管理容器化應用程式的系統。例如，編排器可以動態增加或減少託管應用程式的deployed instance。或者，如果發布了新版本的程是，它可以確保所有已部署的container instance都有update到。

Azure Kubernetes Services(AKS)

AKS管理託管的 Kubernetes 環境，並使在 Azure 中部署和管理容器化應用程式變得簡單。我們的 AKS 環境啟用了自動更新、自我修復和容易擴展等功能。

Kubernetes cluster由 Azure 管理並且是免費的。我們管理cluster中的agent nodes，並且只需為運行nodes的VM付費。
可以在 Azure portal中create cluster，也可以使用 Azure CLI。 create cluster時，可以使用Resource Manager templates自動create cluster。使用這些template，我們可以指定Advanced network、 Azure Active Directory (AD) integration和monitoring等功能。
借由 AKS，我們獲得了開源 Kubernetes 的效益。我們不用運行地端機房的 Kubernetes cluster的複雜性或維運成本/人力。

使用AKS的時機

在這裡，我們將討論如何確定 AKS是否適合我們的需求。我們可以從green field 或 lift-and-shift project的角度來處理我們的決策。 Green fields project將允許我們基於預設的功能評估 AKS。 lift-and-shift project將迫使我們檢查哪些功能最適合支援我們的搬遷。以下有幾個因素需要考慮。

上述所有功能均可在我們建立 cluster或deployment後進行配置。AKS的指標客戶 Mercedes-Benz R&D is using AKS.

Azure Function 的方案設計

Azure Functions

Azure Functions 是一個serverless應用程式平台。當我們想在雲端中運行一小段code時使用Functions，而不用擔心基礎設施。 Functions提供內在的可擴展性，只需為使用的資源付費。可以用我們選擇的開發語言編寫Function code。 Function以兩種重要的方式提供“compute on demand”。

Azure Functions 允許我們將系統邏輯實現為readily available blocks of code。這些code blocks (functions)可以在我們需要回應critical events的任何時間運行。
隨著request的增加，Azure Functions 會根據需求使用盡可能多的資源和function instances來滿足需求。隨著request的完成，任何額外的資源和application instances都會自動下降。

Azure Functions的使用場景

Azure Functions 最適合處理由event觸發的特定可定義操作。例如，Functions可以處理 API call，然後將處理後的資料存儲在 Cosmos DB 中。一旦發生data transfer，另一個Functions可以會觸發通知。

Azure Function提供了多種開發語言的sample code可供參考．

Azure Functions的最佳實踐

避免長時間運行的函數。大型、長時間運行的函數可能會導致意外的逾時問題。只要有可能，將大型函數重構為更小的函數集，它們可以一起作業並更快地return response。 Consumption Plan functions的 default timeout為 300 秒，任何其他plan的default timeout為 30 分鐘。
知道何時使用durable functions。 Durable functions讓我們可以編寫stateful functions。因此，這個函數在背後管理應用程式的狀態、檢查點與重啟。 Durable function的一個範例模式是函數鏈( function chaining)。函數鏈以特定順序執行一系列函數。一個函數的輸出應用於另一個函數的輸入。所以如何用小的函數集或Durable functions來處理逾時端看我們的現有人力/時間/資源．

針對效能與擴展性來組織函數。考慮如何對具有不同load profiles的功能進行分組。例如，假設我們有兩個函數。一個函數處理數千條queued messages並且對memory的要求很低。另一個函數只是偶爾呼叫，但對memory的要求很高。我們就需要部署單獨的function apps，以便每個函數都有自己的一組資源。單獨的資源意味著可以獨立擴展該函數。
編寫defensive functions。設計我們的函數來對應隨時可能發生異常。Downstream services, network outages或memory限制可能會導致Function fail。設計好如何從failure point繼續作業。例如將執行的作業的狀態寫在NoSQL DB中．
避免共享stroage account。建立 function apps時，必須將其與storage account相關聯。如果您的Function產生大量storage transaction且要最大限度地提高效能，請為每個function apps使用單獨的storage account，這一點很重要。

請參閱更多的Azure Function best practices.

Azure Logic App的方案設計

Azure Logic App是另一種serverless 運算解決方案。 Azure Logic App是一個基於雲端的平台，用於建立和運行自動化工作流。工作流程是整合我們的apps, data, services和系統的逐步過程。借助 Azure Logic All，我們可以為我們公司的B2B方案快速開發高度可擴展的整合解決方案。

Logic Apps是 Azure Integration Services的成員。 Logic Apps 簡化了跨雲、地端和混合環境連接傳統、現代和先進系統的方式。以下列表僅描述了可以使用邏Logic Apps自動執行的幾個範例作業、業務流程和工作負載。

發生特定事件時，使用 Office 365 排程和發送電子郵件通知。例如，上傳了一個新文件。
跨地端系統和雲端服務路由和處理客戶訂單。
將上傳的文件從 SFTP 或 FTP 服務器移動到 Azure storage。
監控推文，分析情緒，並為需要審查的作業建立告警或作業。

Azure Logic Apps與Azure Functions的不同

Azure Logic Apps 和 Azure Functions 可能看起來相似，但存在基本差異。 Azure Functions 是一種code-first技術。 Azure Logic Apps是一種design-first(也就是流程優先)的技術。

下表為不同之處

LogicApps的決策標準

在為Logic Apps設計時，要考量整合，效能，條件式，還有各種系統的連接。

整合(Integration)。當我們考量Logic Apps時要問的關鍵問題是“我需要integrate services嗎？”當我們需要讓多個applications和systems一起工作時，Logic Apps可以很好的用在這裡。這就是設計目的。如果我們正在建立不需要外部連接的Application，Logic Apps可能不是最佳選擇。
效能(Performance)。下一個考慮因素是效能。Logic Apps execution engine會自動擴展我們的apps。Logic Apps可以平行處理大型資料集，讓我們實現high throughput。但是，fast activation time不是被永遠保證都有的，也不能保證執行時間的real-time constraints。也就是量大但不即時。
條件式(Conditionals)。Logic Apps提供Boolean expressions、 switch 語句和loops等control constructs，因此我們的apps可以根據我們的資料做出決策。可以在Logic Apps中建立高度複雜且巢狀式條件。
連接(Connectors)。我們需要存取的所有服務是否有預先建立的connectors。如果是這樣，那麼我們準備好了。如果沒有，那麼我們需要建立一個自定義connector。如果該服務具有現有的 REST 或 SOAP API，我們可以在幾個小時內製作自定義connector，而無需編寫任何code。如果沒有，那麼我們需要先建立 API，然後再建立connector。

小提示：知道何時不使用Logic Apps也很重要。 Logic Apps可能不是最佳選擇的情況包括real-time request、複雜的業務規則或使用非標準服務。