http://ria.richtechmedia.com/ ＊緣起 最近因為工作需要，又再度開始接觸 Amazon EC2/S3(早在2006初這個服務剛推出不久時 曾用過一次，那時是 RoR 加一堆 merb，不過後來隨著專案結束也就漸漸忘了這玩意)， 結果這次隨便查了些資料卻發現 cloud 這個字似乎已無所不在泛濫成災，也讓我一時興 起想瞭解一下到底現在大家口中所謂的 cloud 是在指什麼。 會這樣好奇主要的原因是在許多地方都看到有人自稱在提供 cloud service, 但這些服務 間彼此的性質、形態與做法差異性卻很大，例如 ec2 與 gae 兩者就不太一樣，gae 與 salesforce 又很不同，搞到最後，似乎處處是雲端，人人在漫步… 根據 wikipedia 的定義，cloud 最寬鬆的定義是這樣的(擷錄): It is a style of computing in which resources are provided “as a service” over the Internet to users who need not have knowledge of, expertise in, or control over the technology infrastructure (”in the cloud”) that supports them 如果你對這樣的定義沒問題，那非常好，不用再浪費時間看下去，去喝杯咖啡吧。 (紐約25街上最棒的咖啡館，三明治也值得一試) 很可惜這樣的定義在我聽來似乎寬鬆的有點誇張了，因為這樣說來，我在家裏擺幾支 iphone 跑些服務並開放 api 給人用，其實也算是 cloud 囉(還是高雅的 apple cloud 哩)？XD 就因為這該死的好奇心，我花了幾天時間調查並整理了些相關資料，現在總算比較有個頭 緒了。 請注意這只是我個人的心得整理，文中對於名詞的定義與詮釋，尤其是 cloud，只是我個 人的想法，如果有錯歡迎各方大德賜教。 ＊from hosting to VPS, is it really cloud ? 基本上如果要細究到底 cloud 是什麼，可能可以先吵上個三天三夜還沒定論，因為根據 眾多前輩的說法，cloud 這個字本來就是個 buzz word, 想用的人就隨喜取用了，其實根 本沒啥定義好談的啊~ 因此，我打算先跳過試圖去定義這個字的破題法，從實際的 deployment 方式來看這件事 。 以往一般人要 hosting，大多是去租虛擬主機，有錢一點就丟機器到機房去 (co-location)，這是最常見也最傳統的手法，這個手法最大的缺點在於 - 如果臨時有大 流量需求，例如辦個 campaign，很難迅速的擴充服務能量，不論是要搞到大量的機器， 或無窮盡的頻寬，都是個問題。 因此，這幾年來比較流行的玩法是所謂的 VPS/VDS (Virtual Private Server)，透過類 似 XEN 這樣的軟體，將一台實體 server 虛擬化(virtualization) 成多台虛擬機器然後 出租，這樣一來當臨時有大流量需求時，可以很容易的加買幾台虛擬機器就撐過去了。 前面開頭談到的 EC2 就是這樣一個服務，另外這一兩年頗受好評的 Slicehost也是，在 EC2 的例子裏，每一個虛擬出來的機器叫做一個 instance，因此要應付大流量 campaign 時，可以狂開 instances 撐過去，這比狂買實體機器便宜多了。 由於 VPS 真的超方便而且很好用，因此迅速受到大家歡迎，久而久之，VPS 這樣的服務 似乎也就跟 cloud 畫上了等號，但這個等號裏，有個地方卻值得進一步討論。 簡單來說，今天一個人在 ec2 買了 100 個 instances，它們並不會自動聯合起來工作， 而是要靠人工去規畫，例如最常見的是在前面放個 reverse proxy 然後把 request 平均 導向到這 100 台機器上(round robin load balancing)，並且，更重要的，app 本身在 撰寫時就要考慮到將來能支援跑在多個分散的機器上，例如 session 要怎麼維持？ global memory 如何分享？database 是否也要散聚在不同機器上？如果分散要怎麼維持 資料同步？等等這一大堆相關的細節要處理，一個沒弄好，呃，就成了 twitter 第二 ..XD 從這個角度看來，VPS (不論是 ec2 or slicehost)提供的其實是 virtualization 與 load balancing 服務，至於在這個基礎服務之上，user 要怎麼玩就是各顯神通。但 load balancing 與 cloud 似乎並不盡然相同呀！ ＊那世界上還有其它種類的 cloud 嗎？ 有，例如 google app engine (簡稱 GAE) 提供的服務。 簡單來說 gae 是由三個東西組成的，分別是 MapReduce, BigTable, GFS(google file system)，其中最重要的特色就是 MapReduce。 MapReduce 可說是一個演算法，也可說是一個 framework (看你讀的文獻來源)，但它基 本上是由 map 與 reduce 兩者組合，運作方式也很簡單： map: master node 將工作切割成許多小塊丟給 worker (child) nodes 去執行，worker node 可能會再切割工作成各多的小塊給其下的 worker node 去執行，因此這是一個樹狀 的結構。當 worker nodes 完成計算後會將結果傳回給 master node。 reduce: master node 拿到 worker node 傳回的結果後，將它組合起來，就完成工作了 。 對 MapReduce 有興趣又閒的發慌的朋友可以去看看 google 發表的一篇論文 與簡報(保 証會睡的很香甜 :P)。 類似 GAE 這樣的服務，它們最大的特色就是會將工作切割成很多小塊，然後經由多台電 腦聯合起來一起運算，也因為要切割，因此通常會伴隨者一個 distributed file system (在 gae 的例子裏，叫做 GFS)，通常也會有一個分散式的資料庫，例如 gae 裏 叫 bigtable。 當然前面講的都是針對底層架構的設計，但對最前端的開發者來說它代表什麼意義呢？很 簡單，開發者可以完全不用管它有100台或10000台電腦在運作，只要照著 gae 提供的 sdk (呼叫它的 API，操作 bigTable，或用台灣之光 ericsk 大開發的 gaeo)開發程式 ，將來佈署到 gae 上後就會自動去調用一堆電腦(而且很有可能是分散在世界各地 data center 裏)來發功，從這個角度來說，開發者要擔心或處理的細節是比較少的，也因此理 論上 time to market 也是比較短的。 ＊如果不想用 gae 有其它選擇嗎？ 有，Hadoop 是 Aapche Foundation 裏一個 java-based 的主要計畫，基本上可視為開源 版的 gae(很多關鍵技術是依據 google 開放的學術論文來實作的，例如 MapReduce, distributed file system 等)， 目前最力挺的開發者是 yahoo，用於該公司的 search engine 上，而 hadoop 的創始者目前也在 yahoo 上班(今年紅利會不會很傷？:P)，這裏 有一篇 iThome 的中文報導值得一看。 Hadoop 主要由下列三者組成(其它詳細說明請看官網) Hadoop Core: 主要就是 implement MapReduce HDFS(Hadoop Distributed File System)：參考 GFS 而來的分散式檔案系統 HBase: 基於 HDFS 的分散式資料庫(功能等同於 google bigtable) ＊所以 hadoop/gae 與 ec2 是互斥的嗎？ 不見得，要看比較的面向為何？但實際上它們是可能合作的，其中最著名的例子是紐約時 報在 ec2 上用 hadoop 轉了4TB 的 PDF (這篇文章超級精彩不看可惜)。 故事大略是這樣： NYT 有一狗票 1851-1922 年間掃描的一千一百萬份文章要從 TIFF 圖檔格式轉換為 PDF ，由於數量實在太龐大，轉換起來不但耗時甚久，也需要極大數量的機器，就算有錢如 NYT 也不想當凱子爺投資這麼多啊~(而且因為轉換時間太久，也不太可能跑去 Best Buy 刷它個幾千台 pc 回來，然後速速轉完就退回去 XD) 最後 NYT 的工程師將所有檔案傳到 s3 放著，然後到 ec2 開了 100 個 instances，再 裝個 hadoop 利用這100台電腦跑分散運算，結果是只花了 24hrs 跟大約3000美金就搞定 (由於處理速度實在太快，他們實際上還跑了兩次吶…) 這個例子也正好帶出下一個主題。 ＊那 ec2 到底是不是 cloud ？ 這要看你怎麼定義 cloud 這個字，以我而言，我傾向認為 MapReduce 與 distributed file system 是 cloud computing 的主要特色，因此在這個定義之上，EC2 並不符合首 要條件。 但如果我們把問題轉成：ec2 可以成為 cloud 嗎？ 那答案就是肯定的，從上面 NYT 的例子可以看出，EC2 提供100個 instances 只是基礎 架構，之後再上面跑 hadoop 才是真正發功之所在。 由此我們也可以得到另一個結論：硬體本身有無 virtualization 並不重要(你可以買100 台真的電腦連起來，也可以用 ec2 開100個 instance)，重要的是在其上協同運算的方式 ( MapReduce 是這裏的關鍵) 更簡單的二分法則是這樣： *Amazon 只是把硬體虛擬化，然後賣 raw-level computing power *GAE/Hadoop 則是提供分散式協同運算, packaged computing solution 因此，或許我們可以把 ec2 視為 cloud 的前奏曲，擁有它之後，要不要做成 cloud (例 如裝上 hadoop) 則是個人選擇。 ＊所以，何時該選 ec2 或 cloud 呢？ 這是更重要也更實際的問題，而答案也很單純，主要就是考慮下列因素 1、你要解決的問題是否能符合 MapReduce 的矩陣分割方式？ 或是更白話一點的講，你要做的事能不能被切割成小小的一塊塊來個別擊破？例如 log file 的分析就很適合，但 friend of friend database 就不見得適合。 如果你的問題可切割成許多小塊，那就可以考慮下一點。 2、vendor lock-in 是否是個問題？ 這個主要是針對 gae 而來的，現在如果用了 gae，基本上它的 lock-in 特質非常強烈， 例如一定要用 python 與 bigtable，整個資料庫欄位的規畫方式跟傳統 RDB 完全不同， 操作語法也不一樣，將來幾乎無法迅速移轉到其它 hosting 上(雖然有人寫了 GAE to EC2 conversion kit, 但有沒有膽用是另回事)，喔，更別提市場上 python 的人才有多 貧乏這件事，會 RoR 的人搞不好還多一點。 當然這裏可能的另一個選擇就是效法 NYT，用 EC2 + Hadoop 搞客製化分散式運算，而且 用的是 java ，人才四處可得相對門檻就低一點(結果最後是死在 MapReduce 搞不定 ? :P) ＊那 SaaS 是 cloud 嗎？ 這也是個好問題。 現在很多 Software as Service 的服務商，例如 Salesforce 也都宣稱自已有提供 cloud computing 服務，這又是怎麼回事？ 我認為比較合理的看法是將 cloud 分成三個層次來看： 第一層是硬體層(100台真的電腦，或100個 ec2 instances) 第二層是 framework (hadoop, gae, ms azure) 第三層才是 service (accounting, pdf generation…) 在這樣的架構下，SaaS 是屬於第三層的 service 這個 scope。 也就是服務商先搞定第一、二層後，在其上建構自已的 domain service，例如 salesforce 的主力服務是 CRM，因此它透過 cloud 提供一系列的 CRM API 給開發者使 用。舉個誇張的例子(注意，這例子是假想的)，搞不好 salesforce 也是租 ec2 然後搞 了個 hadoop，接著在上面用 java 寫了一堆 api 給人 call。這時它就是三層皆備，可 稱 cloud 而無愧了 XD 另外類似的例子則是像 gmail, google reader 等，這些都是 software services based on GAE (先搞定一、二層，然後建構第三層的 domain service) ＊附錄 原本我曾認為 ec2 的 virtualization 可以做到將許多台實體電腦虛擬化成一大台 server，這樣工程師就只需要針對一台『超級電腦』來寫程式即可，如果是這樣，那 ec2 其實也符合分散式運算的標準，但我查來查去只不斷看到類似下面的解釋： EC2 is more designed for applications that scale well across many hosts, rather than larger applications that require huge resources. IMHO, the xlarge instance is quite fast. Maybe you can identify a bottleneck in the application and address that? Is it really CPU bound? Scalability: Amazon supports easily adding or removing servers, not adding more power/memory/disk to an existing server (instance). This works well when your application is architected to scale across multiple servers to support increased load. 因此目前先初步認定 ec2 並沒有提供這方面的能力，當然如果有錯，歡迎指正。 ＊後記 在研究期間叨擾了無數前輩，感謝他們犧牲週未時間情義相挺回答各種無趣的問題，在此 致上最高謝意 另外關於 ec2 vs. slicehost 的成本或用哪家比較划算這檔事，我也小小想了一下，從 實際數據看來，如果只是小型的網站或是 newly startups，從省錢的角度來看，應該要 選 slicehost，因為它的初始成本最低，例如花個 $20 美元就可以有頗大的空間與流量 可上線 run 了。 但 ec2/s3 的好處則是安全性、穩定性與擴充性，而它最大的缺點則是成本相對較高，一 個 instance 開著不用一個月就要 $72元，如果生意好流量大那要交的費用就更多。 目前台灣地區用 ec2 的的網站似乎並不多(pixnet ? 但把資料存在 s3 的站就多一點)， 可能主要是連線反應時間不夠快所以接受度不高吧，但我們服務的客戶本來就多在北美， 所以沒差 XD --

※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 218.161.52.240