還在苦苦搜索資料,論證云服務能夠帶來哪些優勢?今天我們將一同深入探討如何利用Amazon Web Services來運行一套由數據驅動的網站方案。
云計算技術在過去幾年當中無疑迎來了迅猛發展并開始快速走向成熟,如今我們已經能夠在其現場部署名單當中看到眾多令人信服的成功案例。特別是對于那些可能無力購買服務器及其它硬件設備的小型及初創企業,云服務更是一條能夠快速幫我們構建起業務體系的康莊大道。
除了成本優勢之外,公有云還提供各類完善的功能特性,諸如可擴展性與資源彈性等等。更重要的是,企業能夠利用公有云快速——只需要數分鐘,而不再像過去使用物理基礎設施時那樣需要耗時數周甚至數月——完成基礎設施設置。
下面我們將具體探究Amazon Web Services(簡稱AWS)——目前人氣最高的云服務方案之一——的方方面面,從而了解如何利用它幫助小型企業在激烈的市場競爭中占據主動。
AWS生態系統與基本實施條件
值得注意的是,雖然設置一套云部署方案并不像火箭科學那么高端復雜——至少從基礎角度來看是如此——但還是會對大家的IT專業背景或者特定技術能力提出一定要求,這也是保障一切得以正確配置的前提條件。舉例來說,熟知關于LAMP(即Linux、Apache、MySQL以及PHP)堆棧相關知識的技術人員很可能是負責AWS使用工作的最佳人選。
盡管以通用作為前提性設計思路,AWS通常也能夠完成專有云體系的實現工作——這一點已經沒有什么爭議了。因此,雖然不同云產品之間往往在概念上存在著不少相似之處,但AWS之上的特定使用經驗通常無法被直接沿用至微軟Azure或者谷歌Compute Engine當中,同時也不能被簡單套用到內部部署工作之內。
AWS還提供了多種實施手段,幫助企業客戶快速建立并運行多種通用部署場景:事實上,我們通常可以通過不止一種辦法實現特定解決方案。不過為了幫助大家更清晰地認知AWS云,我們會盡可能壓縮本次服務清單的長度,以免增加不必要的學習難度。
Amazon Web Services主控制臺。
Web托管工作中的部分核心組件
EC2(即Elastic Compute Cloud,彈性計算云)虛擬服務器構成了AWS云部署體系中的主干部分。這些虛擬服務器可以多種不同配置方案進行交付,每套配置都擁有不同的CPU、內存、存儲與網絡性能水平,且以小時為單位計算使用成本。值得注意的是,某些較為陳舊的實例類型可能隨時間推移而陸續被淘汰。
S3(即Simple Storage Service,簡單存儲服務)是一套對象存儲系統,能夠容納最高5TB的單一對象,且可以通過必要的命令行操作、API調用甚至是專門設計以與其協作的桌面應用從任意位置發起網絡訪問。
EBS(即Elastic Block Store,彈性塊存儲)提供傳統文件系統功能,但使用成本也更高一些。EBS分卷功能與磁盤驅動器類似,能夠直接接入服務器并充當存儲驅動器,甚至能夠在計算實例被關閉之后仍然持續存在。(值得注意的是,大家可以對EC2實例進行設置以確保其被關閉后,對應EBS分卷亦同時被刪除。)
RDS(即Relationship Database Service,關系數據庫服務)是一項Web服務,能夠幫助用戶輕松完成關系數據庫管理系統(簡稱RDBMS)的設置、運維以及規模擴展工作。大家可以從多種現有數據庫引擎當中作出選擇,具體包括MySQL、甲骨文、SQL Server、PostgreSQL以及Amazon Aurora。
Route 53主要面向DNS與域名注冊體系。Route 53提供極具競爭力的計費標準,其使用成本往往比某些域名注冊商提供的方案更為低廉。從另一方面講,不少Web托管企業也會以捆綁方式提供類似服務,包括免費提供域名或者在使用的前幾年內提供更為低廉的計費方案。
最后,如果大家希望采用AWS云方案,那么我要向各位公布一條好消息:AWS產品目前提供最長達一年的計算實例免費使用周期,此外以上列出的各項產品及服務亦有不同免費機制可供選擇。
起步:從機器鏡像到選擇區域
AWS提供涵蓋范圍極廣的預構建且經過優化的Amazon Machine Images(即Amazon機器鏡像,簡稱AMI),大家可以將其直接載入到剛剛創建完成的實例當中,從而大大簡化首個計算實例的啟動過程。目前AWS Marketplace當中還包含有大量由第三方創建的鏡像方案,而AWS社區亦創建并共享多種公共AMI成果。
在建立自己的云基礎設施之前,大家首先需要為這套虛擬基礎設施選定一個位置或者說“區域”。在這方面,我們的基本選擇思路應當遵循兩大原則:要么保證設施位置與大部分用戶保持接近,要么保證其與大部分開發人員的物理位置保持接近。在后一種情況下,大家可能會在上傳數據及開發網站的過程中獲得更為良好的載入時間與速度表現。開發人員與數據庫管理員可能會擔心不同區域內的數據庫副本能否得到確切同步,但沒必要太過憂慮——副本之間一定會得到正確同步。最后,某些服務,特別是那些新型或者尚處于beta測試階段的產品,可能只會在特定區域當中供大家使用。
當然,具體情況取決于大家網站的實際架構。在大多數情況下,使用良好的內容交付網絡(簡稱CDN)服務能夠確切模擬我們的部署區域。除了AWS CloudFront CDN之外,大家也可以使用其它備選方案。除此之外,AWS還提供多種工具選項,幫助大家輕松將工作負載遷移至多個區域當中。
最后,值得指出的是,雖然大部分AWS服務的使用成本在各個區域之間完全一致,但也存在著成本不同的特殊情況。大家可以在后文的“監控使用成本”章節來更為深入地了解AWS成本結構。
正常運行時間架構
如果大家誤以為云計算永遠不會發生停機等故障,請再仔細思考一番。雖然AWS家族中的一部分服務擁有非常出色的可靠性,而且AWS方面也提供大量功能以簡化停機事故發生后的恢復工作,大家仍然需要將可靠性規劃與工程技術機制作為部署流程中的重要組成部分。
舉例來說,大家可能會在AWS所使用的底層Xen虛擬機管理程序當中發現嚴格漏洞,而且一部分AWS設備需要在補丁安裝的過程中進行重啟。此外,負責在后臺處理各類任務的物理服務器有可能——或者說一定會發生故障。如果缺少內置自動化機制的支持,在AWS之上建立而成的網站方案可能出現意料之外的運行狀態,甚至在服務器崩潰或者后端重啟時導致業務不可用。
一般來講,大家應當確保重要站點能夠在同一區域內的多個可用區中正常運行。通常情況下,這要求我們從起步之初就將多可用區部署思路納入數據庫后端設計當中。在內部基礎設施中部署更多數據庫服務器肯定會帶來更高使用成本,因此大家要選擇多可用區數據庫選項時也要做好承擔更多支出的心理準備。
最典型的設置當中需要引入一套彈性負載均衡器(簡稱ELB),其作用在于將輸入應用程序的流量分配到多個計算實例當中。與此同時,流量還會被自動從存在故障的實例處被轉移到正常運行的實例當中,這相當于在特定可用區遭遇災難性事故時將負載遷移至其它正常可用區。
別忘了安全性議題
AWS一直高度重視安全問題,對于一家只需要鼠標點擊幾下就能建立或者移除數百臺服務器的供應商來說,關注安全自然也在意料之中。舉例來說,一家擁有光明發展前景的初創企業很可能由于黑客入侵Amazon EC2控制面板而導致業務體系徹底崩潰——甚至整套基礎設施都被完全移除。
為了實現更出色的管理安全水平,AWS方面建議客戶為用戶設定受到嚴格限制的權限內容,從而管理其負責范疇之內 的資源——而不能設置“root”用戶并允許其進行無限制訪問。正如典型Linux系統,用戶可以被分配至多個組,而其它角色早可被創建并分配至至用戶或者對應組。
AWS同時支持虛擬與基于硬件的MFA(即多因素驗證)方案,上圖所示為Gemalto安全令牌。
除此之外,AWS還提供多因素驗證(簡稱MFA)方案,且同時具備硬件與虛擬選項。在硬件MFA方面,AWS支持來自第三方供應商Gemalto公司的安全令牌產品。再有,AWS還支持虛擬MFA應用,例如在Android、iPhone以及黑莓設備平臺上的谷歌Authenticator,外加Android平臺上專有的AWS Virtual MFA應用程序。
監控使用成本
最后,在云計算方面,大家聽到的最多的可能其降低基礎設施使用成本的能力。不過企業用戶可能會逐漸發現,云服務的運營成本會隨時間推移而不斷增加,在某些特定情況下其短期成本甚至會高于內部部署方案。
為了幫助用戶更為明確地了解自己的云部署成本,AWS設計一款以月為單位的計算工具,幫助用戶以數字為基礎了解自己所使用服務項目的部署成本。其中的評估指標包括磁盤及網絡資源的使用水平。這能夠幫助企業在無需針對特定可靠性或服務項目的前提下決定現有運營成本是否符合預期。
企業當然希望根據現有部署方案對使用成本進行優化,在這種情況下大家不妨根據現有資源使用水平購買“臨時”或者“保留”計算實例。簡而言之,前者允許企業以較低價格使用整體云環境下的閑置計算能力,而后者則允許企業客戶預先登記及/或預先支付未來需要使用的資源成本。很明顯,臨時實例所調用的資源未必始終來自同區域。
大家可以預先登記最多三年的預期資源使用量,預先支付機制也同樣支持最多一年周期,二者都能帶來更為實惠的運營成本。
AWS自身還提供一套值得依賴的咨詢服務,能夠幫助企業用戶調整AWS部署流程中的各方面項目,包括安全保障與運維成本優化。當然,要獲得真正全面的顧問建議,大家需要購買付費支持計劃。
在今天的文章中,我們僅僅涉及到了AWS所提供的全部可行性提示中的一小部分,但相信這已經足以幫助大家建立正確的云計算發展思路。如果想要選擇AWS作為自身業務基礎,首先要做的就是提出關于邁出下一步的正確問題。
原文標題:How to set up Amazon Web Services for your small business