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