我的部落格已經移往 Microsoft Azure Web Sites (MAWS) 代管數月，剛搬上去的時候確實不太穩定，畢竟我原本的伺服器有 8GB 記憶體，搬上 MAWS 之後只剩下 1.7GB 可用 (為了省錢)，可使用的資源差很多，也因此發現自己的部落格在資源不足的情況下，穩定度極差。為了讓我的網站能夠穩定運作，我研究了一下，發現今年年初 MAWS 有個 ALWAYS ON 更新，可以讓網站在出問題時「自動復原」，這功能拯救了我，網站也從此穩定許多，來看看這要怎麼用吧！
由於 MAWS 上面的網站，預設會在沒有人點擊網站的情況下被關閉，這樣會導致網站在接受下一個 HTTP 要求時速度較慢，因此你必須先啟用該網站的 ALWAYS ON 功能，如下圖示：
※請注意：ALWAYS ON 功能僅適用於「標準」模式下的 Azure 網站。
啟用之後，要設定「自動復原」就相對簡單的多，我們先看一下以下網站的 web.config 設定範例：
<system.webServer>
<monitoring>
<triggers>
</triggers>
<actions value="ACTION" />
</monitoring>
</system.webServer>
上述設定區段中，<monitoring> 就是 MAWS 支援的網站監控功能設定區段，在這設定裡面 <triggers> 是用來定義「觸發的事件」，可以一個以上，稍後會有些實際範例。而 <actions> 就是當事件觸發時要執行什麼動作，通常都會把 value 指定為 Recycle，也就是回收應用程式集區的意思。
以下有幾種需要「自動復原」網站的使用情境：
1. 依據「記憶體使用量」來回收 (Recycle) 應用程式集區
這也是我網站主要的設定，也就是針對記憶體使用超量時執行應用程式集區的回收工作，讓負責執行網站的應用程式集區重新啟動。以下範例即設定當記憶體用量超過 700MB 時自動回收應用程式集區！
<system.webServer>
<monitoring>
<triggers>
<memory privateBytesInKB="700000" />
</triggers>
<actions value="Recycle" />
</monitoring>
</system.webServer>
2. 依據網站的回應速度來回收 (Recycle) 應用程式集區
這也是我部落格的一個考量指標，依據那些回應時間非常長的狀況，來強制回收應用程式集區。如下範例即設定當 HTTP 要求的執行的時間超過 45 秒，而且在 10 分鐘以內發生超過 20 次的話，即觸發回收動作！
<system.webServer>
<monitoring>
<triggers>
<slowRequests timeTaken="00:00:45" count="20" timeInterval="00:10:00" />
</triggers>
<actions value="Recycle" />
</monitoring>
</system.webServer>
※這裡的 timeInterval 屬性，會在該網站第一個 HTTP 要求進來並啟動應用程式集區後開始計時，並開始累積 slowRequests 發生的數量，等到了定義的 timeInterval 時間區間 (例如 10 分鐘) 之後，就會將累計的次數歸零，並重新開始計算。如果在 timeInterval 時間內到達觸發的條件，就會引發回收應用程式集區，因此 timeInterval 將會重新開始計算，原本累計的次數也會歸零。
3. 依據 HTTP 要求的執行次數到達一定數字後，自動回收應用程式集區
這也是一個常見的解決方法，當你不確定網站到底是因為什麼而當掉時，可以設定當 HTTP 要求次數達到一個數字後，自動回收應用程式集區。以下設定即代表當在 10 分鐘以內 HTTP 要求次數達 1 萬次後，自動回收應用程式集區。
<system.webServer>
<monitoring>
<triggers>
<requests count="10000" timeInterval="00:10:00" />
</triggers>
<actions value="Recycle" />
</monitoring>
</system.webServer>
※上述觸發條件成立後，都會自動被記錄一筆事件到事件檢視器紀錄中，而儲存事件的檔案就放在你的 Azure 網站目錄的上層目錄中。如下圖示，我用 FileZilla 登入該網站，然後回上兩層，這時你會看到一個 LogFiles 資料夾，在裡面有個 eventlog.xml 檔案，裡面紀錄了你的 Azure 網站所有的事件紀錄。
4. 依據特定 HTTP 回應狀態碼，記錄到事件紀錄檔中
如果你已經知道有特定 HTTP 回應狀態碼會不定時發生，但你想要監控這些壞掉的 HTTP 要求，可以參考以下設定。以下設定為，當 1 分鐘以內，網站回應 500.100 的狀態碼超過 10 次，就要自動記錄該資訊到 eventlog.xml 事件紀錄檔中。
<system.webServer>
<monitoring>
<triggers>
<statusCode>
<add statusCode="500" subStatusCode="100" win32StatusCode="0" count="10" timeInterval="00:01:00" />
</statusCode>
</triggers>
<actions value="LogEvent" />
</monitoring>
</system.webServer>
5. 當觸發條件時，執行自訂動作
如果你想當觸發條件成立時，立即取得 w3wp.exe 處理序的完整資訊，這時你可以利用 Windows Sysinternals 工具集中的 ProcDump 工具幫你把所有 w3wp.exe 的處理序都收集下來，供日後分析。
由於處理的動作比較複雜，這時你就可以設定「自訂動作」，來完成這些工作。執行自訂動作的方式很簡單，就是直接執行一個 exe 執行檔，並指定參數。在參數列中，你可以用 %1% 變數來代表 PID (Process ID)，如下範例：
<system.webServer>
<monitoring>
<triggers>
<memory privateBytesInKB="700000" />
</triggers>
<actions value="CustomAction">
<customAction exe="d:\home\procdump.exe" parameters="-accepteula w3wp d:\home\w3wp_PID_%1%_" />
</actions>
</monitoring>
</system.webServer>
這裡比較值得一提的地方有：
- 這個 d:\home 路徑，是 Azure 網站預設的根目錄，所有網站都一樣，這是一個虛擬目錄，所以你要存取檔案，都用這個路徑就是了！所以請透過 FTP 把主程式上傳上去，如下圖示：
- ProcDump 工具在第一次執行時，都會先問你要不要同意 EULA (End User License Agreement)，需要你跟程式互動，由於你無法看到命令提示字元介面，所以執行時請務必加上 -accepteula 參數，否則程式可能會無法執行。
結語
我剛把網站搬上雲端時，真的會不太理性。第一，原本網站好好的，搬上去才掛掉，會第一時間怪罪雲端平台太爛。第二，從以前吃到飽的方案換成用多少算多少的計價模式，會覺得越省越好，所以只要被多扣個幾塊錢，就會覺得很貴，心理覺得划不來。第三，以前用遠端桌面隨時可以連到主機看狀況，現在用了超便宜的 Azure 網站，很多東西都碰不到，必須在限制的環境下調整網站設定，心中自然有些抗拒感。
不過，各位也許很難想像，我的部落格一直以來流量都不小，網站擺在公司的機房內以為共用機房比較省錢，誰知道自從把網站搬上 Azure 雲端之後，每個省下的機房費用將近 NT$ 8,000 之多，真是太嚇人了，心中難免會想 “早知道早點搬上去就好了，可以省下不少錢呢！"。
所以，自己的網站搬上雲端後不太穩定，當然不能怪 MAWS 不穩定，上了雲端，很多事情都不太一樣，最重要也最迫切需要改變的是「對資源的思考模式必須做出調整」，為了省錢，你必須斤斤計較，否則你沒辦法享受到飛上雲端的各種好處。
當然，上雲端絕對不單單只有「省錢」這樣簡單而已，對於巨量資料與超大流量的網站服務，透過雲端所帶來的實質效益，也絕對不是金錢可以衡量的，例如可橫向延展(Scale out)的架構、近乎無限的儲存空間、高可用性的架構、全球負載平衡的機制、…等等，都是非常值得投入與學習的部分。
不過，記得不要用傳統 IT 的心態去思考雲端架構的運作，想要飛上雲端，總不能用走在陸地上的邏輯思考，所以腦袋要先跟著變，才會飛的順利。這邊我推薦一本免費電子書 Building Cloud Apps with Microsoft Azure，本書會教你如何利用 Microsoft Azure 建構雲端應用程式，大概將近兩百頁篇幅，有興趣的可以下載回來看看。
相關連結