雲端服務與經驗談 [1] 由於需求的變更，意外進入雲端服務的世界

「雲端運算」一詞已經廣泛被使用在各種情境。對身處於 IT 領域的工作者來說，多數情況「雲端」是否省略掉「運算」，常用來辨別「流行」與「技術」上的差異。雲端的「流行」在於行銷與吸引消費者，對於使用知識技術過活的 IT 人來說，只是一種融入世間的社交話題。每每看到一篇以「雲」為題的文章，都得耽憂一下最後讀完的心得是否為「又在掛羊頭賣狗肉」。因此，得先界定一下我想要談論的範圍。這系列的分享，我們不會觸碰到高深的理論、技術。純粹以使用者的經歷來談如何踏入這個領域成為雲端服務的「使用者」。

接觸的契機

「解決問題」是程式開發工作重要的目標。當舊方法無法搞定問題時，必需引入新的解法。我有機會接觸雲端服務全是因為解題的條件變得更加嚴苛。網路媒體資料偵測是我工作內容的一部分，它正讓我有機會開始使用雲端服務的契機。問題是這樣的：我有一份媒體資料清單，我需要定時去掃瞄它的資訊並記錄它的狀態。撇開資料偵測的細節，一開始我們實作成下面的結構：

for(String source : getMediaList()) {
    update(probe(source));
}

隨著這個新工作項目的展開，蒐集資料的維度因需求增加、清單的長度加長。開始收到新的回饋：執行的時間太長，跑完一批完整的清單可能要幾天的時間。我們試著以多執行緒解決這個問題，但總執行時間仍不足降至目標的時間。採用多執行緒確實能提昇單位時間內的完成數量。不過，每一台機器不可能無限制地增加多執行緒的數量。特別資料偵測的工作極為佔用 CPU 時間的情況。當 CPU 負載率過高時，它會擠壓到系統上的其他資源，例如：網路存取的效率。原先針對網路資料進行分析就會增加網路的使用量，再減少其 CPU 被分配到的時間，最終就是許多偵測的工作因為太久沒讀取到資料而逾時斷線。基於上述的觀察，若想提昇整體的效率，直觀且簡易的方法：將資料偵測的工作分散至多台機器執行。

這個思維的轉變即是多數程式要上雲端會遇到的問題，您得先問自己：目前的架構是可以擴充、延展的嗎？也就架構設計上必需能 scale out 的方式橫向擴充服務的規模。對第一次接觸擴展性(scalability)問題的人可能覺得抽象，就以上面的例子來說，若它是您正在進行的專案，試著問問自己：「現行的設計會因為部署在更多的機器上而提昇整體效率嗎？」答案明顯是否定的！假設我同時部署至二台機器上執行，在單一執行緒的模式下，他們各自執行 getMediaList() 取得同一份清單，獨立執行完所有工作。若以執行時間為效率的主要指標，這表示投入二倍的資源，但花費的時間沒有變快，所以效率是原先的 50%。

效率無法提昇的問題在於「工作分配」並不是針對多個執行個體而設計的。在概念上，我們要提出一個新的 getMediaList() 實作，它得支援有多個客戶端(client)會向它索取清單。要將原先的程式放入雲端的問題就是由此入門，您必需開始意識到，新的設計必需滿足軟體擴展性：投入運算資源，可期待整體效能也會等比例提昇。

架構的調整

為了讓同一批工作清單在不同的機器上都可以取用，將原先的 getMediaList() 變成網路應用程式是最直覺的做法，它是個典型的 Client/Server 架構。最原始的設計如下，單純由 Database 取得一份完整的清單並交給程式（Executor）執行，執行完的結果直接更新回 Database 內：

新的架構多增加一個 Web Server，將原先 Executor 直接索取媒體清單的工作，透過 Servlet 實作由它向 Database 取得工作清單，並提供 getJob() 的功能讓 Executor 利用簡單的 Http Request 取得下一份需要執行的工作項目。原本該有的功能都透過 Http Request 解決，並設計簡單的驗證機制。Executor 的功能幾乎與原先一樣，切割出 getMediaList() 的部分，反而讓它更符合原本的責任區域：

單純增加一個 Web Server 透過它將取得清單的機制變成可跨多台機器存取，這樣的調整大致符合新增 Executor 就能使效能等比例提昇的目標。不過這樣的調整帶來額外的優點：

• 減少 Database 連線。Database 的資源是相當寶貴的，對於不直接服務使用者的應用儘少用 Database 資源，例如：減少 Lock、減少連線數量、減少連線佔用時間。一旦非直接服務使用者的功能，佔用 Database 資源，那麼會直接影響到使用者觀感，這也是為什麼新的設計不是改成讓 Executor 直接對 Database 建立連線取得自己需要的資料！即便是 Database 伺服器夠強悍，也不太考慮直接存取原始資料。不同的資料偵測工作需要額外的「暫存」資料是原先 Database 定義時沒有的欄位，這會使得新增需求時，會在遷就舊設計或變更舊設計之間游移。當一份 Table 的定義充斥太多「設計意圖」時，還可能落入需求矛盾的風險。
• 簡化安全策略。Database 存放的通常是公司的重要資料，一般來說應設置於防火牆保護的範圍。以 iptables 來說，它是以授權的 IP 來決定是否外界有權透過網路連上 Database。若我們的 Executor 是動態產生的，公司的安全管理政策是否能配合動態變更防火牆規則呢？這樣的設計通常會難為 MIS 單位，透過 Web 的方式與簡單的安全管理設計。既能滿足 Executor 動態生成的需要，對於 MIS 只是加一組 Web Server 的 IP 至信任名單。

新架構上線，我們在自己的機器上部署 Web Server 作為「工作分派器」。使用的機器是一台老舊的 P4 機器，那是當時目前唯一閒置可供自由使用的設備。單純分派工作，不參與執行的負擔是很輕鬆的。接下來的問題是，「執行者」該部署在哪？去哪生出機器來呢？

成為雲端服務的使用者

解決工作分配的問題後，將原先的程式邏輯套上新的流程，終於開啟了可擴充架構的道路。利用一些機器的剩餘運算資源來試跑幾回合，運作起來與預想相去不遠，最終的問題是需要找到可以完全利用的機器（完整的 CPU 使用權利，不用擔心影響使用者服務的部分）。

這些事情發生還沒滿二年，但對我來說仍是挺新鮮的事件。在這之前，壓根不覺得雲端會跟我的開發活動扯上邊。聽人提過的主題大多是 Big Data 或 Map Reduce 這類還沒機會接觸到的「雲端運算」，在完成新的架構後，該去哪找運算資源尚無頭緒。在許多討論雲端運算的文章，有提及的服務如 Google App Engine 或 Amazon Web Server，那時對於 PaaS 或 IaaS 的區別仍未明白。只知道我需要一些可以完全掌握的機器，尋問一些對外部服務租用有經驗的 MIS 友人，有提到我需要的其實是 VPS 服務。同時有提及，多數的 VPS 都會嚴格控管 CPU 的使用！因為 VPS 是利用虛擬化技術將一台強而有力的伺服器切割成 N 台小機器租給人使用，若是其中一些使用者佔用 CPU 太久，在同一台實體機器的其他使用者可能會覺得訂購的服務沒達到應有的效能被客訴。

在我們的應用案例，有些偵測工作是關係到多媒體格式轉換的，這類工作格外耗費 CPU 資源。依據商談的結果，單純依價格評比挑選 VPS 服務最終可能會無法使用，或是租用較多的 VPS 服務來均攤 CPU 負載率。同時，我們也在評估若使用 AWS EC2 是否會因為 CPU 使用率過高而被停止動作。那時對於雲端服務還算陌生，但看到 AWS 提供的應用案例是有許多影音轉換的個案分享。推測應該不至於與一般的 VPS 服務有相同的隱憂。相較之下，選擇 AWS EC2 作為部署的平台是比 VPS 更為合適。初次使用 AWS EC2 時，有許令人眼花撩亂的選項。除了 OS 確定我們要用 linux（比 Windows 便宜，而且也與開發環境相同）之外，較難決定的是「我們要開多好的機器呢？」

依 AWS EC2 將機器的單位稱為 instance，它提供幾種 instance 規格的組合稱為 instance type。我們先由最小規格的 micro instance 試驗它的穩定性，接著試過 small instance 與 medium instance。測試 micro instance 時，遇到了 CPU 負載太高偵測工作的失敗率就過高的問題，這應該與先前原始程式在無法獲得網路資源讀取偵測內容的原因相同。於是決定改變 instance 等級，試了 small instance 明顯結果與一般實體機器花幾天做出來的結果一致，額外試了 medium instance 看起來可以更快做完，但考量價格與效率已經滿足的問題，我們啟用二台 small instance 與設定同時間並行工作的數量完成了工作。

原本只是一個效能提昇的需求，外加沒有可用的機器，並且短時間內不會獲得新的硬體設備。這些機緣讓我誤打誤撞下成為雲端服務的使用者。在後續的系列，我將繼續談論新的需求，來帶新的應用與架構演化。

後續 >> 雲端服務與經驗談 [2] 雲端服務與架構演化