在今天的文章中，我整理出了大量當(dāng)初曾經(jīng)錯(cuò)過(guò)、而至今仍將我追悔莫及的Amazon Web Services（簡(jiǎn)稱AWS）使用心得。在幾年來(lái)的實(shí)踐當(dāng)中，我通過(guò)在AWS之上新手構(gòu)建及部署各類應(yīng)用程序而積累到了這些經(jīng)驗(yàn)。雖然內(nèi)容有些雜亂，但相信仍然能給各位帶來(lái)一點(diǎn)啟示。
從物理服務(wù)器向“云環(huán)境”轉(zhuǎn)移的過(guò)程不僅僅是一項(xiàng)技術(shù)任務(wù)，同時(shí)也意味著我們的思維方式需要作出針對(duì)性的轉(zhuǎn)變。總體而言，在物理環(huán)境下我們需要關(guān)注的只是每一臺(tái)獨(dú)立主機(jī); 它們各自擁有自己的靜態(tài)IP，我們能夠?qū)ζ浞謩e加以監(jiān)控。而一旦其中一臺(tái)發(fā)生故障，我們必須盡最大可能讓其快速恢復(fù)運(yùn)轉(zhuǎn)。大家可以以為只要將基礎(chǔ)設(shè)施轉(zhuǎn)移到AWS環(huán)境之下，就能直接享受到“云”技術(shù)帶來(lái)的種種收益了。遺憾的是，事情可沒(méi)那么簡(jiǎn)單(相信我，我親身嘗試過(guò)了)。在AWS環(huán)境之下，我們必須轉(zhuǎn)變思維，而且這方面的任務(wù)往往不像技術(shù)難題那么容易被察覺(jué)。因此，受到了SehropeSarkuni最近一篇帖子的啟發(fā)，我將自己幾年來(lái)積累得出的AWS 使用心得匯總于此，而且說(shuō)實(shí)話、我真希望自己當(dāng)初剛剛接觸AWS時(shí)能有人告訴我這些寶貴經(jīng)驗(yàn)。這些心得總結(jié)自我在AWS之上部署個(gè)人及工作應(yīng)用程序時(shí)的親身感受，其中一部分屬于需要高度關(guān)注的“疑難雜癥”(我自己就是直接受害者)，而另一部分則是我聽其他朋友說(shuō)起過(guò)、并隨后親自確認(rèn)有效的解決方案。不過(guò)總體而言，為了積累這些經(jīng)驗(yàn)，我確實(shí)付出了相當(dāng)慘痛的代價(jià)：)
應(yīng)用程序開發(fā)
千萬(wàn)不要把應(yīng)用程序狀態(tài)保存在自己的服務(wù)器上。
之所以這么說(shuō)，是因?yàn)橐坏┪覀兊姆?wù)器發(fā)生故障，那么應(yīng)用程序狀態(tài)很可能也隨之徹底消失。有鑒于此，會(huì)話應(yīng)當(dāng)被存儲(chǔ)在一套數(shù)據(jù)庫(kù)(或者其它某些集中式存儲(chǔ)體系、memcached或者redis當(dāng)中)而非本地文件系統(tǒng)內(nèi)。日志信息應(yīng)當(dāng)通過(guò)系統(tǒng)日志(或者其它類似方案)進(jìn)行處理，并被發(fā)送至遠(yuǎn)程位置加以保存。上傳內(nèi)容應(yīng)當(dāng)直接指向S3(舉例來(lái)說(shuō)，不要將其存儲(chǔ)在本地文件系統(tǒng)內(nèi)，并通過(guò)其它流程隨后遷移到S3)。再有，任何已經(jīng)處理過(guò)或者需要長(zhǎng)期運(yùn)行的任務(wù)都應(yīng)該通過(guò)異步隊(duì)列(SQS非常適合處理此類任務(wù))來(lái)實(shí)現(xiàn)。
編輯點(diǎn)評(píng):對(duì)于S3上傳內(nèi)容而言，HN用戶Krallin指出，我們可以徹底避免其與自有服務(wù)器的接觸，并利用預(yù)簽名URL保證用戶的上傳數(shù)據(jù)被直接發(fā)送至S3當(dāng)中。
將額外信息保存在日志當(dāng)中。
日志記錄通常包含有時(shí)間戳以及pid等信息。大家也可能希望將實(shí)例id、服務(wù)區(qū)域、可用區(qū)以及環(huán)境(例如分步環(huán)境或者生產(chǎn)環(huán)境等)添加進(jìn)來(lái)，而這些都能在日后的調(diào)試工作中作為參考。大家可以從instance metadata service當(dāng)中獲取到這些信息。我所采用的方法是將這些信息作為引導(dǎo)腳本的組成部分，并將其以文件形式存儲(chǔ)在文件系統(tǒng)當(dāng)中(例如/env/az或者 /env/region等)。這樣一來(lái)，我就用不著持續(xù)查詢?cè)獢?shù)據(jù)服務(wù)來(lái)獲取這些信息了。大家應(yīng)當(dāng)確保這些信息能夠在實(shí)例重新啟動(dòng)時(shí)得到正確更新，畢竟我們都不希望在保存AMI時(shí)發(fā)現(xiàn)其中的數(shù)據(jù)還跟上次完全一樣，這肯定屬于非正常狀況。
如果我們需要與AWS進(jìn)行交互，請(qǐng)?jiān)诋?dāng)前語(yǔ)言中使用對(duì)應(yīng)SDK。
千萬(wàn)不要試圖自己動(dòng)手。我當(dāng)初就犯過(guò)這個(gè)錯(cuò)誤，因?yàn)槲艺J(rèn)為自己只是單純需要向S3上傳內(nèi)容，但隨著后續(xù)服務(wù)的持續(xù)增加、我發(fā)現(xiàn)自己的決定簡(jiǎn)直愚蠢至極。AWS SDK的編寫質(zhì)量很高，能夠自動(dòng)處理驗(yàn)證、處理重試邏輯，而且由Amazon官方負(fù)責(zé)維護(hù)與迭代。此外，如果大家使用EC2 IAM角色(大家絕對(duì)應(yīng)該這么做，這一點(diǎn)我們后面會(huì)進(jìn)一步提到)，那么該SDK將幫助我們自動(dòng)獲取到正確的證書。
利用工具查看應(yīng)用程序日志。
大家應(yīng)當(dāng)采用管理員工具、系統(tǒng)日志查看器或者其它方案，從而幫助自己在無(wú)需在運(yùn)行中實(shí)例內(nèi)使用SSH的方式查看當(dāng)前實(shí)時(shí)日志信息。如果大家擁有集中式日志記錄系統(tǒng)(我強(qiáng)烈建議大家使用此類系統(tǒng))，那么當(dāng)然希望能在不使用SSH的情況下完成日志內(nèi)容查看任務(wù)。很明顯，將SSH引入正處于運(yùn)行狀態(tài)的應(yīng)用程序?qū)嵗龝?huì)引發(fā)諸多弊端。
運(yùn)營(yíng)心得
如果將SSH引入自己的服務(wù)器，那么自動(dòng)化機(jī)制恐怕將無(wú)法生效。
在全部服務(wù)器上禁用SSH訪問(wèn)。
這聽起來(lái)確實(shí)有點(diǎn)瘋狂，我知道，但在大家的安全組當(dāng)中、請(qǐng)務(wù)必確保端口22不向任何人開放。如果各位想從今天的文章中獲得什么啟示，那請(qǐng)千萬(wàn)牢記以下一點(diǎn)：如果將SSH引入自己的服務(wù)器，那么自動(dòng)化機(jī)制恐怕將無(wú)法生效。從防火墻級(jí)別(而非服務(wù)器本身)禁用SSH有助于整套框架實(shí)現(xiàn)思維轉(zhuǎn)變，因?yàn)檫@樣一來(lái)我們就能了解到哪些區(qū)域需要進(jìn)行自動(dòng)化改造，同時(shí)大家也能更輕松地恢復(fù)訪問(wèn)來(lái)解決當(dāng)前面臨的問(wèn)題。在意識(shí)到再也不必將SSH引入實(shí)例之后，大家肯定會(huì)像我一樣感到渾身輕松。沒(méi)錯(cuò)，這是我在實(shí)踐中了解到的最驚世駭俗、但也卻具實(shí)用性的心得。
編輯點(diǎn)評(píng):很多人對(duì)這項(xiàng)心得表現(xiàn)出了高度關(guān)注(HackerNews網(wǎng)站上還出現(xiàn)了不少值得一讀的評(píng)論意見)，因此我們要在這里多說(shuō)幾句。我個(gè)人也會(huì)通過(guò)禁用入站SSH來(lái)蒙騙自動(dòng)化機(jī)制(哦，我只是SSH一下來(lái)修復(fù)某個(gè)問(wèn)題，馬上就撤)。當(dāng)然，如果我需要在某個(gè)實(shí)例中進(jìn)行主動(dòng)調(diào)試，那么我仍然可以在安全組中將其重新啟用，因?yàn)橛袝r(shí)候我們確實(shí)沒(méi)有其它辦法來(lái)調(diào)試特定問(wèn)題。另外，具體情況還取決于我們實(shí)際使用的應(yīng)用程序類型：如果大家應(yīng)用程序的正常運(yùn)行要求各位能力通過(guò)SSH將信息傳遞至服務(wù)器，那么將其禁用肯定不是什么好主意。這種阻斷進(jìn)站SSH的辦法確實(shí)適合我，也迫使我對(duì)自己的自動(dòng)化機(jī)制加以精心打理，不過(guò)必須承認(rèn)、這種方式并不適合每一位用戶。
服務(wù)器只是暫時(shí)性手段，沒(méi)必要太過(guò)關(guān)注。我們要關(guān)注的僅僅是服務(wù)本身。
如果某臺(tái)服務(wù)器出現(xiàn)了故障，大家完全沒(méi)必要對(duì)其太過(guò)關(guān)注。這是我在利用AWS來(lái)替代物理服務(wù)器之后，親身獲得的最直接的便利成效。一般來(lái)講，如果一臺(tái)物理服務(wù)器無(wú)法正常工作，技術(shù)人員總會(huì)暫時(shí)陷入恐慌。但在AWS當(dāng)中，大家就完全不必?fù)?dān)心了，因?yàn)樽詣?dòng)伸縮機(jī)制會(huì)很快幫我們建立起新的實(shí)例。 Netflix公司在此基礎(chǔ)之上還跨出了更具前瞻意義的步伐，他們組建了Simian Army團(tuán)隊(duì)，并嘗試Chaos Monkey等極為激進(jìn)的測(cè)試項(xiàng)目——它會(huì)隨機(jī)關(guān)閉生產(chǎn)環(huán)境下的某些實(shí)例(他們還利用Chaos Gorilla項(xiàng)目隨機(jī)關(guān)閉可用區(qū)。我甚至得到消息，說(shuō)是Chaos Kong項(xiàng)目會(huì)直接關(guān)閉基礎(chǔ)設(shè)施大區(qū)……)。總而言之，我想表達(dá)的意思是：服務(wù)器總會(huì)發(fā)生故障，但這不該影響到我們的應(yīng)用程序。
不要為服務(wù)器提供靜態(tài)/彈性IP。
對(duì)于一款典型的Web應(yīng)用程序，大家應(yīng)當(dāng)將一切部署在負(fù)載均衡機(jī)制之下，并在不同可用區(qū)之間對(duì)資源使用情況加以平衡。雖然我也遇到過(guò)一些需要使用彈性IP機(jī)制的情況，但為了盡可能提高自動(dòng)伸縮效果，大家還是應(yīng)該利用負(fù)載均衡機(jī)制取代在每個(gè)實(shí)例中使用獨(dú)有IP的作法。
將自動(dòng)化普及到各個(gè)角落。
不只是AWS，自動(dòng)化機(jī)制應(yīng)該作為整體運(yùn)營(yíng)工作中的通用性指導(dǎo)方針，其中包括恢復(fù)、部署以及故障轉(zhuǎn)移等等。軟件包與操作系統(tǒng)更新都應(yīng)該由自動(dòng)化方案所管理，具體可表現(xiàn)為bash腳本或者Chef/Puppet等。我們不該把主要精力放在這些瑣碎的雜事上。正如前文中所提到，大家還需要確保禁用SSH 訪問(wèn)，從而快速了解到自己的執(zhí)行流程中還有哪些方面沒(méi)有實(shí)現(xiàn)自動(dòng)化改造。請(qǐng)記住前面提到的重要原則：如果將SSH引入自己的服務(wù)器，那么自動(dòng)化機(jī)制恐怕將無(wú)法生效。
每位員工都要擁有一個(gè)IAM賬戶。永遠(yuǎn)不要登錄主賬戶。
通常情況下，我們會(huì)為服務(wù)設(shè)置一個(gè)“運(yùn)營(yíng)賬戶”，而整個(gè)運(yùn)營(yíng)團(tuán)隊(duì)都將共享登錄密碼。但在AWS當(dāng)中，大家當(dāng)然不希望遵循同樣的處理方式。每位員工都要擁有一個(gè)IAM賬戶，其中提供與其需求相符的操作權(quán)限(也就是最低權(quán)限)。IAM用戶已經(jīng)可以控制基礎(chǔ)設(shè)施中的一切。截至本文撰寫時(shí)，IAM用戶惟一無(wú)法訪問(wèn)的就是計(jì)費(fèi)頁(yè)面中的部分內(nèi)容。
如果大家希望進(jìn)一步保護(hù)自己的賬戶，請(qǐng)確保為每位員工啟用多因素驗(yàn)證機(jī)制(大家可以使用谷歌Authenticator)。我聽說(shuō)有些用戶會(huì)將MFA令牌交付給兩名員工，并將密碼內(nèi)容交付給另外兩名員工，這樣主賬戶在執(zhí)行任意操作時(shí)、都至少需要兩名員工的同意。對(duì)我來(lái)說(shuō)這種作法有點(diǎn)小題大做，但也許您所在的企業(yè)確實(shí)需要如此高強(qiáng)度的控制機(jī)制。
我最后一次從CloudWatch收到操作警告大約是在一年之前……
將警告信息轉(zhuǎn)化為通知內(nèi)容。
如果大家已經(jīng)將一切步驟正確部署到位，那么運(yùn)行狀態(tài)檢查機(jī)制應(yīng)該會(huì)自動(dòng)清除故障實(shí)例并生成新的實(shí)例。在收到CloudWatch警告信息時(shí)，我們一般不需要采取任何行動(dòng)，因?yàn)樗袘?yīng)對(duì)措施都能以自動(dòng)化方式實(shí)現(xiàn)。如果大家得到警告稱相關(guān)問(wèn)題需要手動(dòng)干預(yù)，那么請(qǐng)做好事后檢查、看看能不能找到一種可以在未來(lái)通過(guò)自動(dòng)化方式將其解決的途徑。我最后一次從CloudWatch收到操作警告大約是在一年之前，而且對(duì)于任何一位運(yùn)營(yíng)人員來(lái)說(shuō)、能夠不再被警告消息打擾了清夢(mèng)都應(yīng)該算是天大的好消息。
計(jì)費(fèi)機(jī)制
建立起細(xì)化計(jì)費(fèi)警告機(jī)制。
大家應(yīng)當(dāng)始終設(shè)定至少一套計(jì)費(fèi)警告機(jī)制，但其內(nèi)容卻可以非常簡(jiǎn)單——例如只在我們超出了當(dāng)月資源用量限額時(shí)發(fā)出提醒。如果大家希望早點(diǎn)掌握計(jì)費(fèi)指數(shù)的動(dòng)向，則需要一套更為完備的細(xì)化方案。我解決這個(gè)問(wèn)題的辦法是以星期為單位設(shè)定預(yù)期使用量。如此一來(lái)，假如第一周的警告額度為1000美元，那么第二周應(yīng)該為2000美元，第三周為3000美元，依此類推。如果第二周的警告在當(dāng)月的14號(hào)或者15號(hào)之前就被觸發(fā)，那么我就能推定肯定發(fā)生了什么異常狀況。如果想更進(jìn)一步地實(shí)現(xiàn)細(xì)化控制，大家可以為每項(xiàng)服務(wù)設(shè)置獨(dú)立的警告方案，這樣就能快速了解到底是哪項(xiàng)服務(wù)把我們的資源預(yù)算早早耗盡了。如果大家每個(gè)月都在固定使用某幾項(xiàng)服務(wù)，而且其中一些非常穩(wěn)定、另一些則起伏較大，那么這種方法能夠收到良好的成效。在此類情況下，我們不妨為穩(wěn)定服務(wù)設(shè)置每周獨(dú)立警告，同時(shí)為起伏較大的服務(wù)設(shè)置周期更長(zhǎng)的整體警告。當(dāng)然，如果各項(xiàng)服務(wù)的資源使用量都很穩(wěn)定，那么上述方法就有點(diǎn)過(guò)分謹(jǐn)慎了，畢竟只要看一眼 CloudWatch、大家就能馬上了解到底是哪項(xiàng)服務(wù)出了問(wèn)題。
安全性保障
使用EC2角色，不要為任何應(yīng)用程序提供IAM賬戶。
如果大家在應(yīng)用程序當(dāng)中內(nèi)置有AWS證書，那么肯定屬于“處理失當(dāng)”的狀況了。前面之所以強(qiáng)調(diào)在開發(fā)語(yǔ)言中使用AWS SDK，最重要的理由之一就是我們能夠輕松借此使用EC2 IAM角色。角色的設(shè)計(jì)思路在于，允許大家為特定角色指定其所必需的恰當(dāng)權(quán)限，而后將該角色分配至對(duì)應(yīng)EC2實(shí)例當(dāng)中。而無(wú)論我們何時(shí)將AWS SDK應(yīng)用至實(shí)例當(dāng)中，都不必再指定任何驗(yàn)證憑證。相反，該SDK將回收我們?cè)谠O(shè)置當(dāng)中為該角色指定權(quán)限所使用的任何臨時(shí)性證書。整個(gè)流程都會(huì)以透明化方式處理，非常安全而且極具實(shí)用性。
將權(quán)限分配至組，而非用戶。
管理用戶往往是件令人頭痛的事情，特別是在使用Active Directory或者其它一些已經(jīng)與IAM相整合的外部驗(yàn)證機(jī)制時(shí)，而且這類作法的實(shí)際效果也不夠理想(當(dāng)然也有效果不錯(cuò)的情況)。不過(guò)我發(fā)現(xiàn)更輕松的辦法，即只將權(quán)限分配至組而非個(gè)別用戶，這將大大降低權(quán)限的管理難度。很明顯，相較于面向每位獨(dú)立用戶來(lái)查看為其分配的權(quán)限，以組為單位進(jìn)行權(quán)限交付能夠幫助我們更好地把握系統(tǒng)整體概況。
設(shè)置自動(dòng)化安全審計(jì)機(jī)制。
在日常工作中，很重要的一點(diǎn)是追蹤基礎(chǔ)設(shè)施內(nèi)安全設(shè)置的各項(xiàng)變更。實(shí)現(xiàn)這一目標(biāo)的辦法之一在于首先建立起一套安全審計(jì)角色(即JSON模板)。這一角色會(huì)對(duì)賬戶之內(nèi)與安全相關(guān)的各類設(shè)置進(jìn)行只讀訪問(wèn)。在此之后，大家就可以利用這一類似于Python腳本的方案達(dá)到目標(biāo)了，它將能夠?qū)~戶中的所有條目進(jìn)行審查并生成一整套與配置相關(guān)的規(guī)范比對(duì)結(jié)果。我們可以設(shè)置一個(gè)cronjob來(lái)運(yùn)行該腳本，并將輸出結(jié)果與上一次的結(jié)果相比較。其中的差異之處就代表著我們安全配置方案當(dāng)中所出現(xiàn)的變化。這種方式非常實(shí)用，而且能夠通過(guò)電子郵件將變更信息通知給大家。
使用CloudTrail來(lái)記錄審計(jì)日志。
CloudTrail通過(guò)通過(guò)API或者S3存儲(chǔ)桶內(nèi)的Web控制臺(tái)記錄所有執(zhí)行過(guò)的操作活動(dòng)。利用版本控制機(jī)制設(shè)置存儲(chǔ)桶可以確保任何人都無(wú)法修改這些日志內(nèi)容，而我們自己則可以隨后對(duì)賬戶內(nèi)的全部變更進(jìn)行徹底審計(jì)。我們當(dāng)然不希望遇到需要審計(jì)日志內(nèi)容的狀況，但正所謂有備無(wú)患，準(zhǔn)備好這么一套方案還是很有必要的。
S3
在存儲(chǔ)桶內(nèi)的SSL名稱中使用“-”而非“.”。
如果大家希望在SSL之上使用自己的存儲(chǔ)桶，那么使用“.”作為名稱的組成部分將導(dǎo)致證書不匹配錯(cuò)誤。一旦存儲(chǔ)桶創(chuàng)建完成，我們將無(wú)法再對(duì)其名稱進(jìn)行更改，所以大家只能將一切復(fù)制到新的存儲(chǔ)桶當(dāng)中。
我發(fā)現(xiàn)文件系統(tǒng)就像大型政府部門一樣“可靠”。
避免載入文件系統(tǒng)(例如FUSE)。
我發(fā)現(xiàn)在被用于關(guān)鍵性應(yīng)用程序時(shí)，這些文件系統(tǒng)就像大型政府部門那樣“可靠”。總之，使用SDK作為替代方案更加明智。
我們用不著在S3之前使用CloudFront(但這樣確實(shí)能夠起到助益)。
編輯評(píng)論:根據(jù)Hacker News網(wǎng)站用戶的最佳反饋內(nèi)容，我們對(duì)這條心得作出了部分修改。
如果大家對(duì)于可擴(kuò)展能力比較看重，那么最好是將用戶直接引導(dǎo)至S3 URL而非使用CloudFront。S3能夠?qū)崿F(xiàn)任意水平的容量擴(kuò)展(雖然一部分用戶報(bào)告稱其無(wú)法實(shí)現(xiàn)實(shí)時(shí)規(guī)模擴(kuò)展)，因此這也是充分發(fā)揮這一優(yōu)勢(shì)的最佳思路。除此之外，更新內(nèi)容在S3中的起效速度也夠快，雖然我們?nèi)匀恍枰谑褂肅DN查看變更時(shí)等等TTL的響應(yīng)(不過(guò)我相信大家現(xiàn)在已經(jīng)能夠在 CloudFront中獲得0延遲TTL，所以這一點(diǎn)也許存在爭(zhēng)議)。
如果大家需要良好的速度表現(xiàn)，或者需要處理對(duì)傳輸帶寬要求極高的數(shù)據(jù)(例如超過(guò)10TB)，那么大家可能更希望使用像CloudFront這樣的CDN方案與S3相配合。CloudFront能夠極大提升全球各地用戶的訪問(wèn)速度，因?yàn)樗鼤?huì)將相關(guān)內(nèi)容復(fù)制到各邊緣位置。根據(jù)實(shí)際用例的不同，大家可以通過(guò)較低數(shù)量的請(qǐng)求實(shí)現(xiàn)高傳輸帶寬(10TB以上)，并借此降低使用成本——這是因?yàn)橄噍^于S3傳輸帶寬，當(dāng)傳輸總量高于10TB時(shí)CloudFront的傳輸成本每GB比其低0.010美元。不過(guò)CloudFront的單次請(qǐng)求成本較直接訪問(wèn)S3中的文件卻要略高一點(diǎn)。根據(jù)具體使用模式，傳輸帶寬的成本節(jié)約額度也許會(huì)超過(guò)單一請(qǐng)求所帶來(lái)的額外成本。因?yàn)樵谥苯釉L問(wèn)S3存儲(chǔ)內(nèi)容時(shí)，我們只需以較低頻度從S3獲取數(shù)據(jù)(遠(yuǎn)較正常使用情況更低)，所以成本也就更加低廉。AWS官方提供的CloudFront說(shuō)明文檔解釋了如何將其與S3配合使用，感興趣的朋友可以點(diǎn)擊此處查看細(xì)節(jié)信息。
在密鑰開頭使用隨機(jī)字符串。
這初看起來(lái)似乎有點(diǎn)難以理解，不過(guò)S3所采取的一大實(shí)現(xiàn)細(xì)節(jié)在于，Amazon會(huì)利用對(duì)象密鑰來(lái)檢測(cè)某個(gè)文件到底保存在S3中的哪個(gè)物理位置。因此如果多個(gè)文件使用同樣的前綴，那么它們最終很可能會(huì)被保存在同一塊磁盤當(dāng)中。通過(guò)設(shè)置隨機(jī)性密鑰前綴，我們能夠更好地確保自己的對(duì)象文件被分散在各個(gè)位置，從而進(jìn)一步提升安全性。
EC2/VPC
別忘了使用標(biāo)簽!
幾乎每項(xiàng)服務(wù)都提供標(biāo)簽功能，別忘了善加利用!它們非常適用于進(jìn)行內(nèi)容歸類，從而大大簡(jiǎn)化后續(xù)出現(xiàn)的搜索與分組工作。大家也可以利用這些標(biāo)簽在自己的實(shí)例中觸發(fā)特定行為，例如env-debug標(biāo)簽可以確保應(yīng)用程序在部署之后進(jìn)入調(diào)試模式。
我遇到過(guò)這類問(wèn)題，感覺(jué)很不好，大家千萬(wàn)不要重蹈覆轍!
在非自動(dòng)伸縮實(shí)例中使用中止保護(hù)。以后你會(huì)感激我的建議的，絕對(duì)。
如果大家擁有某些不具備自動(dòng)伸縮機(jī)制的一次性實(shí)例，則應(yīng)當(dāng)盡可能同時(shí)使用中止保護(hù)，從而避免某些人無(wú)意中將這些實(shí)例給刪除掉。我就遇到過(guò)這類問(wèn)題，感覺(jué)很不好，大家千萬(wàn)不要重蹈覆轍。
使用VPC。
當(dāng)初我剛剛開始接觸AWS時(shí)，VPC要么還不存在、要么就是被我給忽視了。雖然剛開始上手感覺(jué)很糟糕，但一旦熟悉了它的特性并能夠順暢使用，它絕對(duì)能帶來(lái)令人喜出望外的便捷效果。它能夠在EC2之上提供各類附加功能，事實(shí)證明設(shè)置VPC花掉的時(shí)間完全物有所值——甚至物超所值。首先，大家可以利用 ACL從網(wǎng)絡(luò)層面上控制流量，此外我們還可以修改實(shí)例大小及安全組等等，同時(shí)無(wú)需中止當(dāng)前實(shí)例。大家能夠指定出口防火墻規(guī)則(在正常情況下，我們無(wú)法控制來(lái)自EC2的離站流量)。不過(guò)最大的助益在于，它能為我們的實(shí)例提供獨(dú)立的私有子網(wǎng)，這就徹底將其他人排除在外，從而構(gòu)成了額外的保護(hù)層。不要像我當(dāng)初那樣傻等著了，立刻使用VPC并讓一切變得更加輕松。
如果大家對(duì)于VPC抱有興趣，我強(qiáng)烈建議各位觀看《百萬(wàn)數(shù)據(jù)包的一日之期》這段資料。
利用保留實(shí)例功能來(lái)節(jié)約大量成本。
保留實(shí)例的本質(zhì)就是將一部分資金節(jié)約下來(lái)，從而使其保持較低的資源耗費(fèi)速率。事實(shí)證明，保留實(shí)例相較于按需實(shí)例能夠幫助我們省下大量經(jīng)費(fèi)。因此，如果大家意識(shí)到只需要繼續(xù)保持某個(gè)實(shí)例運(yùn)行一到三年，那么保留實(shí)例功能將是各位的最佳選擇。保留實(shí)例屬于AWS當(dāng)中的一類純邏輯概念，大家用不著將某個(gè)實(shí)例指定為需保留對(duì)象。我們要做的就是設(shè)定好保留實(shí)例的類型與大小，接下來(lái)任何符合這一標(biāo)準(zhǔn)的實(shí)例都將處于低速運(yùn)轉(zhuǎn)加低成本支出的運(yùn)行模式之下。
鎖定安全組。
如果有可能，千萬(wàn)不要使用0.0.0.0/0，確保使用特定規(guī)則來(lái)限制用戶對(duì)實(shí)例的訪問(wèn)。舉例來(lái)說(shuō)，如果大家的實(shí)例處于ELB之后，各位應(yīng)該將安全組設(shè)定為只允許接受來(lái)自ELB的流量，而非來(lái)自0.0.0.0/0的流量。大家可以通過(guò)將“amazon-elb/amazon-elb-sg”寫入 CIDR的方式實(shí)現(xiàn)這一目標(biāo)(它會(huì)自動(dòng)幫大家完成其余的工作)。如果大家需要為一部分來(lái)自其它實(shí)例的訪問(wèn)請(qǐng)求向特定端口放行，也不要使用它們的對(duì)應(yīng)IP，而最好利用其安全組標(biāo)識(shí)符來(lái)替代(只需要輸入‘sg-’，其它的部分將自動(dòng)完成)。
不要保留無(wú)關(guān)的彈性IP。
我們所創(chuàng)建的任意彈性IP都會(huì)成為計(jì)費(fèi)項(xiàng)目，無(wú)論其與實(shí)例是否相關(guān)，因此請(qǐng)確保在使用過(guò)后將其及時(shí)清理掉。
ELB
在負(fù)載均衡器上中止SSL。
大家需要將自己的SSL證書信息添加到ELB當(dāng)中，但在服務(wù)器上中止SSL能夠消除由此帶來(lái)的常規(guī)資源消耗，從而提高運(yùn)行速度。除此之外，如果大家需要上傳自己的SSL證書，則可以經(jīng)由HTTPS流量實(shí)現(xiàn)、而負(fù)載均衡器會(huì)為我們的請(qǐng)求添加額外的標(biāo)頭(例如x-forwarded-for等)，這有助于我們了解最終用戶究竟是何許人也。相比之下，如果我們經(jīng)由TCP流量實(shí)現(xiàn)，那么這些標(biāo)頭將不會(huì)被添加進(jìn)來(lái)、相關(guān)信息自然也就無(wú)從獲取。
如果打算執(zhí)行高強(qiáng)度流量，請(qǐng)對(duì)ELB進(jìn)行預(yù)熱。
對(duì)于ELB來(lái)說(shuō)，容量擴(kuò)展是需要一段時(shí)間周期才能完成的。如果大家意識(shí)到自己將會(huì)迎來(lái)流量峰值(例如銷售門票或者召開大型活動(dòng)等)，則需要提前對(duì) ELB進(jìn)行預(yù)熱。我們可以主動(dòng)增加流量規(guī)模，這樣ELB就會(huì)提前進(jìn)行容量添加，從而避免實(shí)際流量來(lái)臨時(shí)發(fā)生卡頓。不過(guò)AWS建議大家最好是與服務(wù)人員取得聯(lián)系，而非自行對(duì)負(fù)載均衡器進(jìn)行預(yù)熱。或者，大家也可以在EC2實(shí)例當(dāng)中安裝自己熟悉的負(fù)載均衡軟件并加以使用(例如HAProxy等)。
ElastiCache
使用配置端點(diǎn)而非獨(dú)立節(jié)點(diǎn)端點(diǎn)。
通常情況下，大家需要讓應(yīng)用程序識(shí)別出各可用Memcached節(jié)點(diǎn)的存在。但如果大家希望以動(dòng)態(tài)方式實(shí)現(xiàn)容量擴(kuò)展，那么這種作法可能會(huì)帶來(lái)新的問(wèn)題，因?yàn)槲覀儗⑿枰扇《喾N方式才能保證應(yīng)用程序識(shí)別到容量的變化。比較簡(jiǎn)便的解決方案在于使用配置端點(diǎn)，這意味著使用Memcached庫(kù)的AWS版本來(lái)對(duì)新節(jié)點(diǎn)自動(dòng)發(fā)現(xiàn)機(jī)制加以抽象并剝離。AWS使用指南中提供了更多與緩存節(jié)點(diǎn)自動(dòng)發(fā)現(xiàn)議題相關(guān)的解答，感興趣的朋友可以點(diǎn)擊此處查看細(xì)節(jié)信息。
RDS
為故障轉(zhuǎn)移設(shè)置事件訂閱機(jī)制。
如果大家正在使用多可用區(qū)方案，那么這可能是一種被各位所忽略、但在相關(guān)需求出現(xiàn)時(shí)卻又悔之晚矣的重要解決方案。
CloudWatch
使用CLI工具。
要利用Web控制臺(tái)創(chuàng)建警報(bào)機(jī)制，我們可能需要面臨大量繁的工作，特別是在設(shè)置眾多內(nèi)容類似的警報(bào)信息時(shí)，因?yàn)槲覀儫o(wú)法直接“克隆”現(xiàn)有警報(bào)并僅對(duì)其中一小部分作出修改。在這種情況下，利用CLI工具實(shí)現(xiàn)腳本化效果能夠幫助各位節(jié)約大量寶貴時(shí)間。
使用免費(fèi)監(jiān)測(cè)指標(biāo)。
CloudWatch監(jiān)控工具以免費(fèi)方式提供各類監(jiān)測(cè)指標(biāo)(包括傳輸帶寬、CPU使用率等等)，而且用戶能夠獲取到最多兩周的歷史數(shù)據(jù)。有鑒于此，我們根本用不著花錢購(gòu)置自己的工具來(lái)實(shí)現(xiàn)系統(tǒng)監(jiān)控。但如果大家需要超過(guò)兩周的歷史數(shù)據(jù)記錄，那沒(méi)辦法，只能使用第三方或者自行開發(fā)的監(jiān)控方案了。
使用自定義監(jiān)測(cè)指標(biāo)。
如果大家希望監(jiān)控免費(fèi)指標(biāo)之外的其它項(xiàng)目，則可以將自己的定制指標(biāo)信息發(fā)送至CloudWatch，并使用相關(guān)警報(bào)與圖形功能。這不僅可以用于追蹤諸如磁盤空間使用量等狀況，同時(shí)也可以根據(jù)實(shí)際需求自行設(shè)定應(yīng)用程序監(jiān)測(cè)方向。感興趣的朋友可以點(diǎn)擊此處查看AWS提供的發(fā)布自定義監(jiān)測(cè)指標(biāo)頁(yè)面。
使用詳細(xì)監(jiān)測(cè)機(jī)制。
這項(xiàng)服務(wù)每月每實(shí)例的使用成本約為3.5美元，但其提供的豐富額外信息絕對(duì)能夠值回票價(jià)。1分鐘的細(xì)化監(jiān)測(cè)甚至好過(guò)5分鐘的粗放查看。大家可以借此了解到某次時(shí)長(zhǎng)5分鐘的崩潰到底是因何而起，同時(shí)以非常明確的方式將其以1分鐘圖表的方式顯示出來(lái)。也許這項(xiàng)功能并不適用于每閏用戶，但就我個(gè)人而言、它確保幫我弄清了不少原本神秘的疑難雜癥。
自動(dòng)伸縮
利用INSUFFICIENT_DATA以及ALARM進(jìn)行規(guī)模縮減。
對(duì)于規(guī)模縮減操作而言，大家需要確保能夠在不具備指標(biāo)數(shù)據(jù)甚至觸發(fā)機(jī)制本身出現(xiàn)問(wèn)題時(shí)仍能正常實(shí)現(xiàn)規(guī)模縮減。舉例來(lái)說(shuō)，如果大家的某款應(yīng)用程序平時(shí)始終處于低流量狀態(tài)，但突然迎來(lái)了流量峰值，大家肯定希望其能夠在峰值結(jié)束且流量中止后將規(guī)模恢復(fù)至原有水平。如果沒(méi)有流量作為參考，大家可以使用 INSUFFICIENT_DATA來(lái)替代ALARM作為低流量閾值情況下的規(guī)模縮減執(zhí)行手段。
使用ELB運(yùn)行狀態(tài)檢查取代EC2運(yùn)行狀態(tài)檢查。
在創(chuàng)建擴(kuò)展組時(shí)系統(tǒng)會(huì)提供這樣一個(gè)配置選項(xiàng)，大家能夠指定是否使用標(biāo)準(zhǔn)的EC2檢查機(jī)制(當(dāng)該實(shí)例接入網(wǎng)絡(luò)時(shí))，或者使用自己的ELB運(yùn)行狀態(tài)檢查機(jī)制。ELB運(yùn)行狀態(tài)檢查機(jī)制能夠提供更出色的靈活性。如果大家的運(yùn)行狀態(tài)檢查機(jī)制發(fā)生故障，那么該實(shí)例將被移出負(fù)載均衡池，在這種情況下大家當(dāng)然希望能夠通過(guò)自動(dòng)伸縮中止該實(shí)例并創(chuàng)建新的實(shí)例加以替代。如果大家沒(méi)有利用ELB檢查設(shè)置出擴(kuò)展組，那么上述功能將無(wú)法實(shí)現(xiàn)。AWS在說(shuō)明文檔當(dāng)中就添加運(yùn)行狀態(tài)檢查機(jī)制作出了詳盡說(shuō)明，感興趣的朋友可以點(diǎn)擊此處進(jìn)行查看。
只使用ELB預(yù)先配置的可用區(qū)。
如果大家將擴(kuò)展組添加到多個(gè)可用區(qū)內(nèi)，請(qǐng)確保自己的ELB配置能夠正確使用全部可用區(qū)，否則在容量發(fā)生向上擴(kuò)展時(shí)，負(fù)載均衡器將無(wú)法正確識(shí)別出這些可用區(qū)。
不要在同一個(gè)組內(nèi)使用多個(gè)擴(kuò)展觸發(fā)器。
如果大家在同一個(gè)自動(dòng)伸縮組內(nèi)選擇了多種用于觸發(fā)規(guī)模調(diào)整的CloudWatch警報(bào)機(jī)制，那么它們可能無(wú)法如各位的預(yù)期那樣正常起效。舉例來(lái)說(shuō)，假設(shè)大家添加的觸發(fā)器會(huì)在CPU使用率過(guò)高或者入站網(wǎng)絡(luò)流量強(qiáng)度過(guò)大時(shí)進(jìn)行向上擴(kuò)展，并在情況相反時(shí)對(duì)規(guī)模進(jìn)行縮減。但在使用過(guò)程中，我們往往會(huì)發(fā)現(xiàn) CPU使用率持續(xù)增加，但入站網(wǎng)絡(luò)流量卻保持不變。這時(shí)高CPU負(fù)載觸發(fā)器會(huì)進(jìn)行容量擴(kuò)展操作，但低入站流量警報(bào)卻會(huì)立即觸發(fā)規(guī)模縮減操作。根據(jù)各自執(zhí)行周期的不同，二者之間的作用很可能會(huì)被抵消，導(dǎo)致問(wèn)題無(wú)法得到切實(shí)解決。因此，如果大家希望使用多種觸發(fā)器方案，請(qǐng)務(wù)必選擇多自動(dòng)伸縮組的方式。
IAM
使用IAM角色。
不要面向應(yīng)用程序創(chuàng)建用戶，而盡可能使用IAM角色。它們能夠簡(jiǎn)化所有相關(guān)工作，并保證業(yè)務(wù)環(huán)境的安全水平。創(chuàng)建應(yīng)用程序用戶只會(huì)帶來(lái)故障點(diǎn)(如果有人不小心刪除了API密鑰)，而且令管理工作更加難以完成。
用戶可以擁有多個(gè)API密鑰。
如果某些員工在同時(shí)處理多個(gè)項(xiàng)目，又或者大家希望能夠利用一次性密鑰對(duì)某些內(nèi)容進(jìn)行測(cè)試，那么這種方式將非常實(shí)用。我們完全不必?fù)?dān)心真正的密鑰被泄露出去。
IAM用戶可以使用多因素身份驗(yàn)證，請(qǐng)善加利用!
啟用多因素驗(yàn)證機(jī)制能夠?yàn)槲覀兊腎AM用戶提供額外的安全層。我們的主賬戶肯定應(yīng)該引入這項(xiàng)機(jī)制，面只要有可能、普通IAM用戶亦應(yīng)當(dāng)享受到由此帶來(lái)的保障。
Route53
使用ALIAS(即別名)記錄。
ALIAS記錄會(huì)將我們的記錄組直接鏈接到特定AWS資源處(即可以將某個(gè)域映射至某個(gè)S3存儲(chǔ)桶)，但其關(guān)鍵在于我們用不著為了ALIAS查找而支付費(fèi)用。因此與CNAME這類付費(fèi)機(jī)制不同，ALIAS記錄不會(huì)增加任何額外成本。另外，與CNAME不同，大家可以在自己的區(qū)索引當(dāng)中使用ALIAS。感興趣的朋友可以點(diǎn)擊此處查看AWS官方提供的ALIAS資源記錄集創(chuàng)建說(shuō)明頁(yè)面。
彈性MapReduce
在S3中為Hive結(jié)果指定一個(gè)目錄。
如果大家打算利用Hive將結(jié)果輸出至S3，則必須在存儲(chǔ)桶內(nèi)為其指定一個(gè)目錄——而非存儲(chǔ)桶根目錄。否則我們很可能遭遇NullPointerException，而且完全找不到引發(fā)這一問(wèn)題的理由。
京公網(wǎng)安備 11010502049343號(hào)