AWS活用術｜善用容量無上限的S3儲存服務

通常介紹Amazon的AWS（Amazon Web Services）服務，最先介紹的就是S3（Simple Storage Service）了，因為S3至少聽起來是一個簡單的服務。要用S3也真的很簡單，它是一個檔案（S3的術語叫物件）儲存服務，只要申請好帳號，產生secret key就可以用了。

雖然S3可以單獨使用，所以可以成為我們整個系統的一個子系統，但是因為S3服務規畫得非常龐大，最常用來支援AWS的其它服務 。儲存檔案是一個無論如何都會需要的服務，S3就提供一個高可用性（HA）的儲存服務。透過REST 介面，可以很容易地與程式界接，也可以使用圖形化或是命令列工具來操作。

在簡單的外表下，S3的細節非常多，功能也很眾多。所以我們可以拿S3來組合、塑造出許多種的服務，提供給最終使用者（end user）來使用。像是著名的Dropbox、Netflix都是使用了S3服務來做儲存。

儲存日誌及資料庫備份

備份可以說是日常系統管理員一定要做的工作，而且一定要自動化，減少管理員的負擔。使用S3來做備份，最大的好處當然就是不用管硬碟是不是快要爆了，而且要拿回某一份備份，也是直接從S3抓回來就好。

至於資料隱密性的問題，通常使用加密後，再上傳到S3，可以很大程度的確保這個問題不會發生。S3也提供http與https兩種服務端點，確保效率與傳輸的安全性。目前至少在S3的Java SDK上，可整合客戶端加密再上傳。

安裝AWS PHP SDK

S3的工具非常的多，在這裡我使用AWS PHP SDK來示範，首先讓我們安裝這套SDK。先到PHP SDK的首頁中（http：//aws.amazon.com/sdkforphp/），在這個網頁中可以看到有pear channel套件安裝、獨立安裝或是git clone安裝等方法。在這裡我們使用獨立安裝的作法，也就是下載壓縮檔案後解壓縮。

再來就是編輯設定檔，把安裝PHP SDK目錄裡的「config-sample.inc.php」改名為「config.inc.php」，再編輯裡面的access key及secret key。

資料庫備份

在裝好PHP SDK，以及設定好secret key之後，就可以寫一個簡單的PHP程式，讓我們可以很方便的，把MySQL資料庫備份，丟上S3儲存。

容器應該要在使用之前就先建立好，所以可以用下面這一行來建立。

再來是我們的備份腳本程式。

在這邊，可以看出一些我的慣例。首先，我習慣使用斜線分隔，並且用日期來快速區分這些備份檔，也就是$dataprefix的部份。由於大部份的S3工具，都可以自動使用斜線把容器裡的物件作成清單顯示，這樣要找一個檔案就方便多了。

另外，檔案名稱本身，我也是會把這個檔案的完整名稱寫上去，不會只寫一個db-backup.sql.tar.gz。這是因為在下載下來的時候，還是可以很容易的知道這是什麼檔案，什麼時候備份的等等這些性質。所以就這個資料庫備份的情況，整個物件的名稱大概會像這樣子：

最後，就是加上crontab，讓系統幫我們自動備份。

當然，這個流程還有很多可以改進的地方，比如說，通常你需要備份不止一個資料庫，所以檔名和前綴（prefix）都應該要加上這個資料庫的識別碼。還有，完整備份很花系統資源，所以不可能作得太頻繁，可能可以採用其它的方式作差異性備份，例如binlog。

儲存log及其它檔案

系統裡要儲存的絕對不止是資料庫備份而已，我們常常需要備份大量的檔案。在這個使用案例，我們只是改變S3物件的檔案前綴及檔名而已，其它就交給S3儲存了。

所以，我們仍然使用同一個「s3put.php」上傳程式，但是寫一個新的備份腳本。

這裡可以看到，我使用一樣的檔案名稱前綴以及檔名規則，所以備份檔案再多，我也不會找不到檔案。最後，一樣加到crontab裡就可以了。

以上這些備份，都是存到S3上，利用S3的超高耐久性和可用性，省去管理儲存空間的麻煩。這些備份檔案的來源，可以是EC2上的虛擬機器，更可以是原本系統的實體機器。只要可以連網際網路，就能進行備份。由於一般機房內的設定，是不能隨意連到網際網路。所以通常會依備份計畫，收集檔案，再由專門的機器上傳。

另外，因為S3通常比EC2有更高的可用性，所以也可以用S3來作為在不同地區（region）間，移動資料的簡單方法。舉個例子，如果EC2在美東地區暫時無法提供服務，而我們備份到S3的資料庫和檔案夠新的話，可以快速地在其他沒有當機的地區，比如說美西，重新上線系統。如果擔心資料一致性的問題的話，也可以先在別的地區提供「唯讀」的服務，等待完整的資料救回來以後，再提供全部的服務。

用S3服務靜態網站資源

另一個S3的用法，就是拿來服務網站上靜態的資源。例如服務小圖檔、JavaScript檔、CSS檔、或是Flash檔等。另外有一些檔案沒那麼靜態，例如使用者產生的檔案，是寫入一次而之後一直讀取的特性，也可以用S3來服務。用S3來服務這些檔案的好處，首先當然是降低主網站的負擔，把動態和靜態的內容分開，對提高延展性是有幫助的。再來S3是高可用性的服務，可以減輕我們設計一個這樣服務的負擔。還有，S3是無限容量的，所以不用去管硬碟是不是快爆了。

我們可以簡單使用AWS Management Console開一個容器，例如叫作「mysite」。然後把我們的靜態檔案，依照目錄結構，為這些檔案取名。例如，原本在網站上的路徑是「/image/logo.jpg」，那物件名稱就叫「image/logo.jpg」。而每個S3物件都有獨立的URL，以剛剛這個物件，URL就是：

如果是內部使用，這樣就可以了。但是如果是要給使用者看的，我們一定會使用我們的網域。使用我們自己的網域也很簡單，只要開容器時名稱符合網域的要求，並設定好CNAME，就可以了。都規畫好了之後，我就可以把我的靜態檔案，依照它們的相對路徑，取作物件名稱（object key），然後全部部署上S3。這個作法可以進一步改成，使用CloudFront去服務這些靜態資源，而來源可以是S3、我們本身原本的伺服器、甚至是第3方網站。

用S3存動態檔案

網路或服務常常有許多動態增長的檔案，最常見的就是使用者上傳的照片。要處理這些檔案並且達成高可用性及高延展性，是一大難題。我們可以利用S3的無限容量，來輕鬆的處理這一個問題。

不過，這些檔案不像前面提的「網站靜態檔案」，通常都具有一定的私密性。也就是要經由我們的網站服務授權，使用者才可以讀取。S3有提供認證及授權（AA），可以讓我們用程式在系統裡管理權限。實際上的作法，就是如果使用者可以存取這個資源的話，我們的系統就產生一個在一段時間後就會失效的連結URL。使用者如果在這段時間之後，再用這個URL，S3就不允許存取。在這裡要提醒的是，使用者仍然可以下載這個資源，並且再散布。所以如果是需要更嚴謹的認證及授權，不能只依賴S3或CloudFront的認證及授權機制，而要再加上資料加密或網路啟用等作法才行。

一但我們把動態檔案的配置規畫好，並且把程式開發完成，就沒有什麼太需要擔心的了。新的檔案會丟到S3上，不用擔心儲存空間不夠或是可用性的問題。要讀取時，也不用擔心因為資料暴增隨之而來的延展性問題。

前面有提到AWS的服務通常可以互相合作，在這個情況裡，我們可以使用S3來做為網站的決定性版本，並且使用CloudFront來幫我們達成使用者快速讀取的功能。而且由於現在CloudFront不一定要使用S3作為決定性的檔案版本來源，我們也可以只使用CloudFront來幫我們快速發佈網站的檔案。不過這都需要以網站整體資料先設計考量，規畫好之後，才可以享受運用AWS服務的優勢。

《作者簡介》

林允溥

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

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