通常介紹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雲端服務活用術」


Advertisement

更多 iThome相關內容