CaryHsu - 學無止盡: 建置Azure App Service for Web的建議實務

2017年2月25日星期六

建置Azure App Service for Web的建議實務 - 進階篇

上一篇我們已介紹完基礎建置的部份，接下來我們來介紹進階管理與應用的部份，功能的部份我也逐一介紹，如有不清楚或較深入整合的應用，我會考慮再加開文章進一步的介紹，也歡迎大家討論。

相關介紹：
建置Azure App Service for Web的建議實務 - 基礎篇
http://caryhsu.blogspot.tw/2017/02/azure-app-service-for-web.html

1、部署位置(Deployment Slot)

一般我們在開發上如果要進行部署時，通常建議先將程式放置在測試機上進行確認，以後我們都需要找二台相同的機器進行正式機與測試機的運作，在App Service for Web上，你可以透過部署位置(Deployment Slot)來完成。

在Standard Tier或Premium Tier等級上可以透過建立部署位置(Deployment Slot)來完成測試的動作，在建立後，你可以將程式先部署至此，然後再進行測試，到時候再透過切換的方式，即可達到快速的換版動作，一來可以先行測試程式，二來也可以減少前端離線的影響，最重要的是此功能在Standard Tier或Premium Tier等級上是免費的，所以強烈推薦進行使用。

從網站 -> 部署位置中即可看到目前已建立的項目，如下圖我們已先建立好一個部署位置。

從Visual Studio上來看，你也可以看到部署時我們可以選擇將專案部署到特定的位置上。

在應用程式設定的部份，也可以進行位置區分，當進行切換時，也可以保留特定部署位置上的設定值。

2、快取(Cache)

在快取的部份，除了在網站的部份啟用Local Cache外，在App Service for Web中大家常用的有Redis Cache與CDN，二個是不同層級的應用，Redis Cache屬於應用程式中的資料快取，在某些資料上沒有即時性的需求時，即可考慮透過此服務來加快讀取，藉以提升速度。

另外由於我們的Web Apps部署時會選定一個資料中心(Data Center)進行存放，但是當使用者的區域與資料中心(Data Center)的位置不同時，可能會造成使用者在讀取上因為網路的傳遞過遠而造成頁面回應過慢的情況，此時你就可以考慮啟用CDN，藉以減少因地理環境不同而造成的讀取回應上過慢的問題。

快取等級：
Local Cache -> 網站內容快取
Redis Cache -> 網站內容中特定資料的快取
CDN -> 網站內容快取，並提供給其他地理位置的使用者進行讀取

3、Application Insights

在網站架設後，我們要隨時觀察網站的使用量與健康程度，以往我們可以要透過IIS Log進行或是加入Google Analytics等進行網站的分析，其實可以不用這樣麻煩，你可以直接透過Application Insights進行即可，啟用後即可快速的透過此服務進行網站的監控。

3-1 預設上網站並沒有特別啟用Application Insights，請先進行建立。

建立時由於存放Application Insights的Data Center並沒有太多的選擇，所以可以先指定一個先行存放，基本上不會有太大的影響。

3-2 在程式中也需要同時啟用Application Insights，在Visual Studio非常簡單，只需啟用此服務並設定後即可。

3-3 啟用後即可透過即時計量資料流看到即時的資料。

3-4 Dashboard即可顯示監控的資訊，在監控的項目上也非常的多，可以將一些常見的都加入進行觀察。

3-4 在啟用Application Insights後，可以設定警示功能當監控的數值超過一定的數量主動透過E-Mail進行提示。

4、自動調整(Auto-Scaling)

在基礎篇有特別的提過，基本上網站可以應該忙碌的情況進行調整站台的執行個體，在預設的情況下是透過手動的方式進行，但在Standard Tier(含)以上的架構，可以透過CPU百分比與排程及效能規則的方式進行自動調整的動作，此部份強烈建議你在啟用Application Insights後對網站的使用率有深入的了解後，即可進行彈性的調整，假設今天你知道晚上有有促銷的活動時，你就可以透過自動調整的規則進行，藉以穩定網頁的回應與整體速度。

5、Traffic Manager

在雲端上的服務基本上在一定的等級上都有服務層級協議(SLA)，如App Service的部份只要是Basic Tier(含)以上的等級，就有保證每月最多只會有21分鐘左右的斷線(SLA 99,95)，所以基本上也不會是100%保持服務，所以Traffic Manager會是你一個很好的選擇。

下圖是從官網截取而來的圖，從此圖上來看，概念類似負載平衡器，將使用者依據Traffic Manager的設定，如效能、優先權、權重等方式，一般來說常見的就是效能模式，效能模式上可以將使用者導向 "網路延遲" 最少的Data Center，問題當其中的一個Data Center發生問題無法提供服務時，Traffic Manager也可以將使用者導向其他的Data Center。

一般來說使用者最常考量的就是要同時租用多個Data Center，只為了那每個月的可能21分鐘斷線，但換個方向想每次的斷線可能造成當下的交易損失與多一個Data Center的成本相比，我想對大部份的企業來說決對是值得的，而且另一個節點還是有同時提供服務，並不是一般Cluster上的Standby模式，所以相信此服務絕對值得投資。

Traffic Manager架構圖