AWS 的EMR服務是可用來執行大量運算的MapReduce服務。

使用AWS中的EC2 (Elastic Compute Cloud)服務時,我們的使用經驗可以和用傳統硬體沒什麼差別,只是多了API等自動化的工具。我們的重點在於心態,EC2有許多靈活的作法,可以節省時間和人力成本。所以如果只是把既有的系統搬上EC2,常常還是無法運用出很有彈性的作法,因為既有系統不是依照雲端運算的心態去設計的,自然很多地方無法配合,發揮這些特性。

以下介紹一些簡單常見的作法,也可以看出一些EC2與傳統硬體的特性差別。我們可以從這裡開始,利用EC2的優勢到我們的系統上。

用EBS快速複製檔案

EBS作為EC2的長期儲存服務,補足原本EC2只有暫時儲存的缺陷。我們能夠用API、命令列或圖形界面,輕鬆地加一個儲存空間(EBS volume)到EC2虛擬機器上。並且對EBS儲存空間作快照(snapshot),提供高耐久性的備份儲存。快照可以再回復成EBS儲存空間,且掛載到EC2虛擬機器上。

所以,如果你的系統裡需要大量相同的檔案,那就可以利用EBS的快照及還原儲存空間的功能,快速地讓每一個EC2虛擬機器,都有這些檔案,提供之後的運算使用。

用EBS回復掛掉的EC2虛擬機器

如果是使用EBS-boot的 虛擬機器,如果EC2虛擬機器掛掉的話,可以很快地回復。我比較常使用的流程如下:

Step1.有一個EBS-boot的AMI,假設ID叫ami-11111111。從這個AMI開了一個虛擬機器,ID叫i-11111111。這個虛擬機器在開機時,掛載(attach)了一個新的EBS儲存空間,作為虛擬機器的開機磁碟,假設這個EBS儲存空間ID叫vol-11111111。

Step2.有一天,很不幸地,i-11111111掛了,怎麼重開也回復不了。這時候,vol-11111111上的資料還在,而且保留著i-11111111最後的狀態。

Step3.使用ami-11111111再開一個新的EC2虛擬機器,新的ID假設叫i-22222222。這個新的虛擬機器也掛載了新的EBS儲存空間,作為開機磁碟,假設ID叫vol-22222222。

Step4.把vol-11111111從i-11111111卸載(detach),因為i-11111111已經掛了,所以這一步有可能會久一點。

Step5.把i-22222222暫停(stop),不是關機(terminate),然後把vol-22222222卸載(detach)。

Step6.神奇的地方來了,把vol-11111111掛載到i-22222222,然後把i-22222222啟動(start)。i-22222222上面有之前i-11111111的最新資料,就像沒有事發生一樣。

最後,要記得把不會再用到的i-11111111和vol-2222222都關掉,免得多花錢。

最好的事是,這一切都坐在自己位子上就可以完成了,我們甚至可以做自動化工具。但是有一些環境會不同了,最常見的就是由於i-22222222的IP已經改了,所以需要做一些環境設定。這個問題可以用一些方法處理,例如EIP或內部DNS、host檔。另外,如果EC2虛擬機器除了開機磁碟用EBS儲存空間外,還掛載了別的EBS儲存空間,也要記得再處理。

用EC2處理大量運算的需求

有很多人認為如果長期開EC2虛擬機器,就失去使用IaaS的意義,還不如買實體機器,價錢也比較划算。所以在EC2剛興起的那幾年,其實最多、最有名的使用案例,還是短時間內,處理固定量資料的用法。

另外,因為許多企業通常已經有不少的機器,要一下子全部搬到EC2也是不太可能的。所以AWS提供VPC,讓新的或者說是動態增減的機器,都在EC2上面生成,透過VPN達成同一內網的效果。

AWS對大資料(Big Data)運算或高性能運算(HPC)有提供許多服務,例如EMR是提供Hadoop的服務,Cluster Compute及Cluster GPU Compute是提供高性能運算,Dedicated Instances提供實體靠近並與其它人區隔的環境。

最近這幾年大資料運算越來越紅,可以說是趁著雲端運算的風潮,成為下一個熱門的話題。由於資料量爆炸性的成長,所以常利用雲端運算服務來儲存。儲存之後,又可以利用雲端運算動態分配運算資源的長處,計算出使用者的的答案。如果問題比較急或比較大,那就多分配一些資源。反之,如果想省錢,也有省錢的用法。

在開放源始碼的大資料運算工具裡,最常用的就是Hadoop了。依照Hadoop的規格所開發出來的工作(job),就可以利用Hadoop的平行運算、工作分配、容錯等優勢。如果是使用在IaaS上,例如在EC2裡自己管理一個Hadoop的叢集,或者是使用EMR,就能發揮雲端運算的優點,也就是動態資源配置。

當然,我們也可以不用Hadoop,但是至少還是會使用一種分散式、可容錯的檔案系統,如HDFS來儲存資料。將這些工作搬到EC2或EMR上是相對比較容易且可達成的,因為這些工作的獨立性比較高。通常都能在不影響主系統的情況下,搬到EC2上,來善用動態資源的優點。

不同使用Spot Instances的策略

「Spot Instances」是很特殊的EC2計價方式,也就是使用類似競標的方式來租用運算資源。這種前所末有的計價方式,讓我們有更多種靈活規劃要使用的運算資源與花費的平衡。

會有這種計價方式,可以說是資源運用的極致。因為使用者租用EC2的總體使用量,一定會有尖峰和離峰的情況。在尖峰時,EC2會調高Spot Instances的價格,而離峰時EC2希望你來租,當然就調低價格。由於EC2的固定操作成本已經在那裡了,如果目前EC2的總體使用量偏低,EC2可以把價格調低,吸引使用者來開機器。

我們先鎖定我們要開EC2的地區、機器大小、作業系統等,確定好規格,這是因為Spot Instances的標價依這些規格而不同。鎖定規格好之後,可以觀察過去一個星期、或三個月內的價格走勢。

然後,要注意你想開機周期的最高和最低價格,如果你出的價格比最低的還低,就不太可能會有機器開起來。而相對的,如果你出的價格比最高的還高,這些機器大概就不會被關掉。雖然過去的績效,不代表未來的表現。不過總是要有一個參考,來定出我們使用Spot Instances的策略。

所以,當你出的價錢比目前的Spot Instances標價還低時,EC2會自動幫你開機,而套用的價錢是目前的標價,而不是你出的標價。不過,當你出的價錢比目前的Spot Instances標價還低時,這些Spot Instances就會被EC2給關掉了。

因為這些Spot Instances的特性,所以要使用Spot Instances的工作就有一些限制。例如,開起來的Spot Instances一定要可以自動加入叢集並且工作,工作的輸入、輸出和中間檔案,也要能存在不會因為Spot Instances被關掉而消失的地方,例如S3、SimpleDB、EBS等,或其它非Spot Instances的EC2虛擬機器上。

因為這些流程是和工作內容相關,所以通常需要為Spot Instances客製化一套系統。不過通常少不了以下這些元件:流程管理、分散式儲存、狀態監控及示警等。而這些元件通常是不會放在Spot Instances之內的,所以這部份的花費和開發及管理也要記得算進來。另外,即使我們完成了自動化伸縮的Spot Instances叢集,也不能太頻繁的增減節點。因為增減節點對系統是額外負擔,如果這些負擔太大,很容易對效能造成不好的影響。

就像我常說的,雲端運算是給了我們更多可能性,而不是單純的和原本硬體系統相比較規格與花費。尤其是AWS,有這麼多的服務,每個服務有許多的細節,服務之間又能互相組合,製造了許多系統架構及管理上的伸縮性及方便性。目前AWS仍然不斷推進服務,提供給我們系統更多新的組合。而未來最大的限制,可能是我們的想像力。

 

《作者簡介》

林允溥

《AWS雲端企業實戰聖經》一書的作者,也是資深軟體工程師,曾任職於美商Sosauce軟體公司,參與社群網站及3D遊戲網站的開發。從2006年Amazon Web Services推出 後,就開始運用AWS服務來建置網站,因而熟知AWS各種優勢、缺點、使用策略與問題解決方法。


相關報導請參考「Amazon雲端服務活用術」


Advertisement

更多 iThome相關內容