高可用AWS S3故障波及北美多項服務,雲使用者該如何自救?

ADVERTISEMENT
本文首先對事件進行了客觀回溯。隨後,引用了陳天先生的一篇評價文章。雲使用者該如自救?要知道,Netflix 重度使用 AWS,卻在歷次 AWS 的宕機中毫髮無損。想提前知道答案的同學,請迅速翻到文章後部分。

作者 | Jordan Novet、陳天

編譯 | 核子可樂、木環

雲基礎設施服務供應商Amazon Web Services(簡稱AWS)證實,其正在立足位於北弗吉尼亞州的美國東一資料中心服務區對其擁有廣泛使用者的S3儲存服務進行故障排查。除S3之外,亦有其它數項雲服務遭受影響。

在其服務狀態頁面當中,AWS表示“我們正在對美國東一服務區內出現的Amazon S3請求錯誤率增高問題進行調查。”

就目前來看,此次故障似乎影響到了 Adobe公司多項服務、Amazon Twitch、Atlassian的Bitbucket與HipChat、Autodesk Live and Cloud Rendering、Buffer、Business Insider、Carto、Chef、Citrix、Clarifai、Codecademy、Coindesk、Convo、Coursera、Cracked、Docker、Elastic、Expedia、Expensify、FanDuel、FiftyThree、Flipboard、Flippa、Giphy、GitHub、GitLab、Google旗下Fabric、Greenhouse、Heroku、Home Chef、iFixit、IFTTT、Imgur、Ionic、isitdownrightnow.com、Jamf、JSTOR、Kickstarter、Lonely Planet、Mailchimp、Mapbox、Medium、微軟HockeyApp、MIT Technology Review、MuckRock、New Relic、News Corp、OrderAhead、PagerDuty、Pantheon、Quora、Razer、Signal、Slack、Sprout Social、StatusPage (最近已被Atlassian收購)、Travis CI、Trello、Twilio、Unbounce、美國證券交易委員會 (簡稱SEC)、The Verge、Vermont Public Radio、VSCO、Wix、Xero以及Zendesk等多家廠商與服務。

Airbnb、Down Detector、Freshdesk、Pinterest、SendGrid、Snapchat公司的 Bitmoji以及時代公司目前則處於執行緩慢狀態。

蘋果公司亦在其系統狀態頁面之上表示,目前其App Store、Apple Music、FaceTime、iCloud各服務、iTunes、Phtots及其它服務亦存在問題,不過尚不確定這一切與今天曝出的S3故障是否存在關聯。

截至目前,Amazon購物網站本身似乎也遇到了一些技術問題。不過,Amazon方面AWS錯誤資訊的不能正常顯示。

儀錶板顏色無法正常改變的問題與S3故障有關。請參閱儀錶板中的頂部橫幅訊息以瞭解更多動態。— Amazon Web Services (@awscloud) 2017年2月28日

AWS在Amazon公司的財務構成當中扮演著越來越重要的角色;2016年第四季度,AWS為其母公司貢獻了高達35.3億美元營收,利潤則為9.26億美元。

ADVERTISEMENT
AWS 資訊公告更新

更新於上午10:30(太平洋時間):AWS針對S3服務停機給出了一點額外資訊。“我們已經發現美國東一服務區內的S3服務存在請求錯誤率增高問題,這亦給依賴於S3的各類應用程式與服務造成了影響。我們正在積極努力以解決此問題,”AWS在其狀態頁面中指出。

更新於上午10:51(太平洋時間):AWS釋出了另一條S3狀態更新。“我們正在繼續努力以解決發生於美國東一服務區中的Amazon S3可用性問題。依賴於S3的其它AWS服務及客戶應用程式將繼續存在高錯誤率情況。我們正積極努力以解決Amazon S3中出現的錯誤,”AWS在同一狀態頁面中表示。

更新於上午11:40(太平洋時間):Amazon終於迎來了一點好訊息。“我們現在已經恢復了對服務執行狀態儀錶板進行更新的能力。服務更新如下。我們位於美國東一服務區內的S3服務仍然存在高錯誤率問題,我們應該已經找到了問題根源,並在努力實施舉措並相信能夠將其解決,”AWS在狀態頁面中更新稱。

更新於上午11:52(太平洋時間):根據狀態頁面中的說明,今天北弗吉尼亞州之外區域受到影響的服務包括Athena、CloudWatch、EC2、Elastic File System(彈性檔案系統)、Elastic Load Balancing(彈性負載均衡,簡稱ELB)、Kinesis Analytics、Redshift、Relational Database Service(關聯式資料庫服務,簡稱RDS)、Simple Email Service(簡單郵件服務,簡稱SES)、Simple Workflow Service(簡單工作流服務)、WorkDocs、WorkMail、CodeBuild、CodeCommit、CodeDeploy、Elastic Beanstalk(簡稱EBS)、Key Management Service(金鑰管理服務,簡稱KMS)、Lambda、OpsWorks、Storage Gateway以及WAF(Web應用防火牆)。影響範圍還真不小。

ADVERTISEMENT

更新於上午11:59(太平洋時間):根據狀態頁面的說明,AppStream、CloudWatch、Elastic MapReduce(簡稱EMR)、Kinesis Firehose、WorkSpaces、CloudFormation、CodePipeline目前仍然受到故障影響。

更新於中午12:06(太平洋時間):部分服務目前處於離線狀態。目前受到影響的服務包括API Gateway、CloudSearch、Cognito、EC2 Container Registry、ElastiCache、Elasticsearch Service、Glacier冷門資料儲存服務、Lightsail、Mobile Analytics、Pinpoint、Certificate Manager、CloudTrail、Config、Data Pipeline、Mobile Hub以及QuickSight。哇哦。

更新於中午12:15(太平洋時間):新增關於影響蘋果服務的相關問題說明。

關於 AWS S3

S3 是 AWS 最早釋出的雲服務,simple storage service,解決儲存的問題。儲存是任何網際網路服務的基石 —— 隻要有大的資料物件,無論是圖片,視訊還是文字,我們都需要一個合適的儲存方案儲存它們。在沒有雲的日子裡,這些內容要麼儲存在無比昂貴的 SAN (Storage Area Network) 中,要麼儲存在大量 PC 伺服器的磁碟陣列中,通過一些特殊的檔案系統,如 HDFS 來訪問。為了維護這些資料的永續性和可用性,網際網路公司需要在這樣的基礎設施上花費巨大的人力物力,無法集中所有的工程能力處理業務。當 S3 和類似 S3 的服務誕生後,對於很多初創的網際網路公司,簡直是久旱逢甘霖, 99.999999999% 的永續性(durability),和 99.9% 的可用性(availability)爽的不能再爽,於是紛紛把自個的儲存架構布在了 S3 上。時至今日,使用 S3 的網站,已經多達 148, 213 個(資料來自 Techrunch)。

所以,當今早 S3(主要是 North Virginia)宕機時,整個北美的網際網路呈現一片哀鴻遍野的景象。

宕機後,北美網際網路的哀鴻遍野

美西太平洋時間早上 10 點(北京時間淩晨 2 點),AWS S3 開始出現異常。很多創業公司的技術人員發現他們的服務無法正常上傳或者下載檔案。有人在 hacker news 上問:Is S3 down? 然後迅速得到大夥的確認。

然而,AWS 自己的 status page 卻後知後覺,放眼望去,一片讓人喜滋滋的綠油油。就在大夥兒以為自己神經過敏,一切都是虛妄的猜測時,AWS 的工程師驚悚地發現,由於這個頁面依賴於 S3,所以它實際上也掛了,於是趕緊放了個 banner 上去說明狀況,然後在 Twitter 上昭告天下綠油油是假象:

11:35am,經過一番努力,這個頁面總算顯示正常的狀態了:

可以看到,重災區是 North Virginia 的 S3。由於 S3 不工作,那些高度依賴 S3 的服務,比如 Elastic Map Reduce(需要 S3 儲存中間過程和結果),以及去年 re:invent 剛釋出的 Athena(查詢的資料要放在 S3 上),也完全掛掉。依賴 S3 不那麼重的服務,狀態也不是太好。

Slack 無法上傳檔案,進度條永遠在走:

Trello 表示老子都被收購了,休息,休息一會也無妨:

收購了 Trello 的 Atlassian 也不遑多讓

文案好一本正經撲克臉(我都懷疑他們的工程師發現問題了麼):

最近 VC 的寵兒 Giffy

表面上一切正常(CDN 扛起了 gif 的下載),但如果你要上傳 gif,對不起,偶們也不知道發生了神馬事情:

至於高冷的 Quora,乾脆連個暖心的頁面都不給:

直接說不玩了

。。。

照理來說像 Quora 這樣的服務,面向使用者閱讀的部分本不該高度依賴 S3,要掛也不該全站掛,頂多是掛使用者撰寫答案的部分,不知道為何死的這麼徹底。

S3返回了什麼?

我們看看當問題出現時,一個普通的 S3 GET 返回什麼:

AWS 赤果果地告訴你,Internal Error 了。

從 error handling 的角度,我們在寫程式碼的時候都應該捕捉這個異常,然後做合適的錯誤處理。很遺憾的是,S3 這樣的服務是如此基礎,就像網際網路的水和電一樣,大家預設為它永遠不會出錯。

因此,好多工程師乾脆不做錯誤處理,像 Slack 那樣,任由進度條一直傻乎乎地跑;或者,讓錯誤一路冒泡,直到把整個服務掛掉了事,像 Quora / Trello 那樣。這樣對使用者都不太友好。

Murphy 定律告訴我們,凡事可能發生,就將要發生。所以比較好的處理方法是,捕捉到異常,讓錯誤隻侷限在特定的頁面,如:Atlassian / Giffy。

或者,有個 plan B 應對突發事件。

使用 S3 的使用者如何自救?

類似的事情發生在任何公司上都是不幸的,尤其是給客戶以 SLA 保障的 SaaS 公司。大家能做得就是:

當雲服務商的宕機發生時,儘量控製它影響面。

像 Trello 這樣連 landing page 都一併掛掉實在不可取,起碼 S3 影響不到的頁面,如 landing page,使用者註冊 / 登入頁面,應該還保持正常服務;而像 Quora 這樣的服務,其實是可以準備一個靜態化的映象,一旦出問題,起碼讓讀者可以無障礙地閱讀。

儘可能地把動態內容快取起來,甚至靜態化。

Redis cache、Nginx cache、HA proxy、CDN 都是把內容快取甚至靜態化的一些手段。儘管多級快取維護起來是個麻煩,但當底層服務出現問題時,它們就是難得的戰略緩衝區。cache 為你爭取到的半個小時到幾個小時幾乎是續命的靈芝,它能幫你撐過最艱難的時刻(這次 S3 宕機前後大概 4 小時,最嚴重的時候是 11點到1點),相對從容地尋找解決方案,緊急釋出新的頁面,或者遷移服務,把損失降到最低。否則,只能像這次事件中的諸多公司一樣,聽天由命,雙手合十祈禱 AWS 的工程師給力些解決問題。

使用 simian army 在平日裡操練系統的容錯性。

Netflix 重度使用 AWS,卻在歷次 AWS 的宕機中毫髮無損,是因為他們之前也深深地被雲的「不穩定性」刺痛過。他們的 chaos monkey(之後發展為 simian army)服務,會隨時隨地模擬各種宕機情況,擾亂生產環境。比如說對於此次事件的演練,你可以配置 simian army 去擾亂 S3:simianarmy.chaos.fails3.enabled = true。這樣,這群討厭的猴子就會在你不知情的情況下隨機把你的伺服器的/etc/hosts改掉,讓所有的 S3 API 不可用。這樣你就可以體驗平時很難遇到的 S3 不可訪問的場景,進而找到相應的對策(注意:請在 staging 環境下謹慎嘗試,否則老闆把你開了不要賴程式君)。

如果 AWS 真的發生大規模宕機,而你又沒有採取任何措施,天也不一定就塌下來了。此時此刻,你的投資人,你的客戶,你的合作夥伴也許都忙著解決他們各自的宕機問題呢,hacker news 上(https://news.ycombinator.com/item?id=13755673)有個笑話這麼說:

Why do we host on AWS?

Because if it goes down then our customers are so busy worried about themselves being down that they don't even notice that we're down!

看,這就是 CIO / CTO 們的狡黠之處(自建的出了問題都得自己擦屁股)。

網友反響

如何利用這樣的宕機機會?Google 的工程師忙不迭地過來補刀加教育使用者:

你看,這個社會就是這麼群狼環飼。你別說不努力了,你努力著,但隻要摔上一跤,就有猛獸過來蹭肉吃。對於甲方來說,狼越多選擇越多,開心都來不及;作為乙方,則欲哭無淚。

這次事故,我們作為乙方,看看熱鬧。但要知道,每家公司,甚至每個人,都在不同的上下文中扮演不同的角色,一會是甲方,一會是乙方。看熱鬧娃哈哈時,不要忘了有一天自己也可能遇到相同的境地,被自己的客戶放在火上烤。

畫外音:你問 Tubi TV 宕沒宕機?雖然我們有我們無敵痛苦的煩惱,但是託 CDN 的福,在過去的幾個小時,我們好好的。扛過宕機的,都是英雄什麼?)

今日薦文

常在IT界,哪有不宕機?點選下方圖片即可閱讀


» 高效開發運維

ADVERTISEMENT
ADVERTISEMENT