AWS活用術｜善用EC2靈活彈性的3個實例

使用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雲端服務活用術」