|
雲端架構學(2)：分析應用程式以決定如何使用雲端能力
前回的雲端架構學（1）中，筆者已大概得向大家說明一般的應用程式和雲端上的應用程式有什麼樣的不同，其中最明顯的不同，就是雲端應用程式（Cloud-enabled Application）可以自由運用雲端供應商所提供的雲端資源（Cloud Resources），不論是運算能力資源、儲存能力資源、網路能力或是由供應商所提供的各種應用程式元件等，一個合格雲端應用程式應該能夠靈活運用上述的資源，以達到最大的資源成本效益比（即常聽到的 C/P 值）。
一個網路應用程式的組成要件，不外乎就是運算+儲存+網路，因此要分析應用程式如何使用雲端能力，也須分成這三個部份來探討。
運算能力
不論是何種雲端平台，若是夠資格稱為雲端的，都一定具備相當大量的運算資源，不論是實體伺服器或是虛擬機器，只要應用程式需要取用時，就能立即利用雲端供應商的自動化管理工具（例如 Windows Azure 的 Windows Azure Fabric Controller，或是 Dynamic Datacenter Toolkit for Hosters）自動的配給必要的運算資源給應用程式，而應用程式如何配置以使用這些動態資源，則是雲端應用程式架構中的重點項目。例如：將應用程式自動部署到新增的運算資源內以備使用，或是以一個 template 化的資源樣板（例如 VM Role 中的 VHD，內含作業系統與必要的應用程式部署套件）交由自動化管理工具來生成運算資源，並設計一個中控系統管理這些資源等等，都是可有效運用 Scalable Compute Instances（可擴充式運算資源）的方法。
應用程式有時也需要在執行的過程中評估運算資源是否可用，是否需要做 Scale-Up（提升運算資源本身的 CPU/RAM 能力）或是 Scale-Out（增加運算資源的數量），當然也有可能需要 Scale-Down 以及 Scale-In，以符合雲端的 On-demand 特性，以及 Self-Service 的需求。那麼應用程式如何操作這些特性，則也是個必修的課題。以 Windows Azure Platform 為例，管理人員可以自由利用 Management Portal 中的 Edit Configuration 功能，調整目前線上應用程式的組態檔，以增加或減少應用程式所需的運算執行個體數量：
NOTE
線上的 Scale-Out 可透過組態方式做，且如果原本就有兩個 instance 的話，那麼修改 instance count 到三個以上時，或需要 Scale-In 時，只要保持 instance count=2，就可以確保原本的高可用度。不過目前若是要 Scale-Up 的話，由於需要替換原本的 VM，故可能需要將原有的 instance 關閉再重新部署（remove-and-redeploy）。
在 Windows Azure Platform 中，應用程式可應用服務管理 API（Service Management APIs）來自動化 Scale-Out/In 這件事，若需要 Scale-Up/Down 時，也可以利用服務管理 API 來實作自己的運算資源分段式升級，以確保應用程式的高可用度。
NOTE
有關 Windows Azure 上的 Dynamic Scaling 能力，可參考 Microsoft 提供的範例程式：https://archive.msdn.microsoft.com/azurescale
儲存能力
雲端應用程式由於多數都是在自己的虛擬機器（VM）中運行，且在未知虛擬機器何時會因為當機而停擺，雲端供應商的自動化機制通常在偵測到 VM 沒有心跳（heartbeat）時，會自動再找一個適合的伺服器產生一個新 VM 並接手服務，而原本當機的 VM 也會被自動化機制回收，若此時應用程式是將資料儲存在 VM 中，那麼那些資料會隨著 VM 回收而消失無蹤。因此雲端應用程式必須要將資料保存在雲端供應商提供的儲存機制。通常雲端供應商都會提供至少一種資料保存的功能，例如儲存二進位資料的 BLOB 儲存體或是儲存結構化資料的 Table 儲存體等，而一般來說雲端的儲存服務都具有接近無限空間的儲存能力，因此儲存空間問題不大，關鍵的問題是在散布速度（distribution speeds）以及查詢速度（query speeds）。
散布速度關係著使用者需要花多久時間才可以得到需要的資料，雲端應用程式可運用像 Windows Azure CDN 或是 Akamai CDN 來散布，若應用程式需要大量散布資料（如Video, Audio 或是檔案下載）時，CDN 可以有效加速資料的傳播速度；而查詢速度就和應用程式的設計會相關，因為多數的雲端供應商使用的儲存方式是分散式海量儲存架構，海量儲存架構會切割資料的儲存為 Index Layer（索引伺服器）與 Data Layer（資料儲存伺服器），Index Layer 的查詢速度會影響應用程式在查詢資料時的效率，因此雲端供應商多半會提出一些設計上的注意事項，以確保 Index Layer 可以在較短的時間內回應查詢的結果，應用程式的儲存層需要注意這部份的設計，以確保查詢儲存資料時不會拖垮應用程式的效能。
另外，如果應用程式會產生一些快取資料（Cache Data）或是不需要永續保存的資料時，可以選擇保存在 VM 本地的儲存空間中，以加快存取速度，或是運用 Caching Service（如 Windows Azure AppFabric Caching Services 或 memcached 服務）來協助保存快取資料。
結語
本文說明了一個應用程式在雲端化之前需要分析的各種面向，從運算、儲存到網路能力等，都有不同的分析重點，但目的都是相同的，讓應用程式能更有效的運用雲端所有的資源。本文尚有一個部份未提及：安全性。這個部份會在後續的文章中提及。
|