🔧 阿川の電商水電行
自從成為與AWS有關的工程師以來，這是一個特別濃厚的星期一。
因為是日本公司，雖然在US-EAST-1（維吉尼亞北部）區域沒有承載重的工作負載，但無法提出支援請求，管理控制台也無法正常使用的情況，讓我感到某種「非日常」的氛圍。
（對我個人而言，Perplexity的宕機對我來說是相當大的打擊。）
看到這個時候，真的讓人冷汗直流。
對於此次事件，許多人質疑「AWS難道不是高可用性嗎？」
我非常理解這種疑惑。然而，不論是多麼大型的服務，都是從零開始建構起來的，雖然有些元件仍屬於遺留系統，也不易動手。根據我個人的看法，這次的故障可能也和這一點有關。
經過一番波折後，我希望能夠了解發生了什麼，並將這篇文章作為備忘錄留下來。
由於我對網路相關的知識僅止於基本，因此如果有不妥之處，請不吝指正。
發生了什麼？
在故障當天已經很明顯，US-EAST-1區域負責DynamoDB端點解析的DNS突然失效，返回了空的記錄，導致DynamoDB及依賴DynamoDB的服務相繼宕機，這是一個簡潔的總結。
當然這樣的描述還不夠詳盡。此次事件的回顧官方文章已經發布，我們可以一同閱讀。
時間軸
| 日本時間 | 狀態 | |
|---|---|---|
| 10/20 15:48 | 事件發生 | US-EAST-1區域服務的訪問錯誤和延遲明顯上升 |
| 10/20 17:26 | 原因正在確認中 | 確認到US-EAST-1區域的DynamoDB出現大量錯誤及對其他服務的影響 |
| 10/20 18:01 | 真正原因確認 | 確認DynamoDB的DNS解析失敗是原因，並著手修復 |
| 10/20 18:27 | 出現恢復跡象 | 看到恢復情況，新請求成功 |
| 10/20 19:35 | 初步解決 | 雖然還有待處理的背後工作，但大多數服務已經恢復。再次確認EC2實例啟動的錯誤。 |
| 10/21 07:53 | 完全解決 | 所有問題已得到解決。 |
從確定真正原因到快速恢復的過程比預期的快。也就是說，推測是出於操作上的問題或系統故障，而非外部攻擊。
DNS的原理與為何這次失效
首先，DynamoDB等AWS服務是通過DNS來保證可擴展性的。在其背後，一個處理DynamoDB DNS記錄更新的內部系統存在，為了提供大量的處理能力給用戶（內外部），這個系統實現了高度自動化，除了DNS記錄的更新，還能自動恢復和故障處理，不會因為一般的故障而停擺。
DNS自動更新系統
該系統主要由兩個組件構成：
-
DNS規劃者
- 監控負載均衡器的健康狀態和容量狀況，定期生成新的DNS計劃
- 端點：除了公開區域端點
dynamodb.us-east-1.amazonaws.com之外，還控制IPv6端點和帳號特有的端點 - DNS計劃：為所有端點設置與哪個負載均衡器的連接及其權重
- 在不同的端點間共享資源，以提高抗故障能力
-
DNS執行者
- 定期檢查新DNS計劃的可用性，獲取可用計劃並應用於Route 53
- 三台完全獨立的實例在三個可用區（這一點很重要）執行相同的功能
- 在應用DNS計劃前，通過與現有計劃進行比較來檢查是否是最新，從而發出應用的授權（這一點也很重要）
- 應用後，刪除較舊的計劃（這是真正重要的）
到這裡，即使是初級架構師也會感到疑惑。將相同的DNS計劃發送給三台實例，並重複執行檢查和應用操作三次，這樣的冗餘是否過於多餘？為什麼不改為事件驅動模式，通過消息隊列進行控制？
當然這裡有其理由。如果把每個實例完全切離，是為了確保高可用性。這有其道理。無論是負載均衡器還是消息隊列，故障轉移的處理都需要時間，因此如果不進行控制，隨便發送事件，也許是目前最快的方式。而且，由於這是一個較低層的系統，依賴性越少，其運行會越穩定。
- 在DNS計劃適用過程中，若引入還原機制（尤其是DynamoDB）或鎖機制，反而會增加复杂度，增高故障風險。而且，只要適用過程能在足夠短的時間內完成（其實到目前為止都是可以的），那麼競爭的可能性會降至極低。另外，只要在Route 53的事務中保障所有端點的記錄更新原子性，即使兩台實例同時進行應用操作，最終也只會有一個計劃被採用。
這樣一看，似乎這不算壞的解決方案，但隱藏著潛在的風險。
預想中的競爭
我們先來看看預想中的情境。正如上圖所示，偶爾會出現兩台執行者同時進行DNS計劃應用的情況。如果由較新的計劃觸發，兩者幾乎同時發出應用的授權，便會導致二者進入應用過程，產生衝突。衝突的端點將發生重試，並在重試結束後應用計劃。雖然可能會兩次應用，但因為這兩者都是新計劃，且事務保證了原子性，所以雖然冗餘，但沒有實質性的損失。
然而這次發生的卻是「隱藏模式」的競爭。
「隱藏模式」的競爭
當第一個齒輪出現問題時，上述正常競爭中原本應在短時間內結束的重試卻異常延長（這裡指的是發生長重試的實例EnactorA）。在這段期間內，新的計劃不斷生成，並在EnactorB中一一應用。當EnactorA的重試結束時，已經是相當舊的計劃了，但因為應用的授權最先發出，所以這個舊的計劃成功應用了。
即便到這裡，僅是舊的DNS計劃被應用而已，但麻煩的是應用後的清理過程。不巧的是，正當EnactorB不斷應用計劃時，EnactorA的舊計劃卻被覆蓋了，幾乎同時EnactorB的清理過程也開始運作。隨著覆蓋的瞬間，EnactorB的清理過程判斷應該刪除EnactorA的舊計劃（當前DNS計劃），最終將其刪除。結果，Route 53中DynamoDB端點的DNS記錄完全不存在，形成「真空」。
以上就是事件的經過。
從直觀上來看，我們都能明白的是，清理過程的確是可疑的。若發生競爭時，別處的清理過程導致現有計劃消失，是容易想像的情況。因此，應該有判定是否刪除的邏輯存在。根據官方文件，提到的刪除準則是「相對於應用的計劃，顯著較舊的計劃」會成為刪除目標，但具體的判定標準並未公開。至少，若Route 53中可用的計劃數量不為0的控制，或者將授權判定放在首次及最後進行檢查，或許情況會有所不同。
高聲批評外部的做法並不妥當，所以到此為止。我們無法完全理解一個軟體架構中所經歷的無數決策帶來的波折。
影響服務
DynamoDB本身不必多說，其他如EC2、NLB、Lambda等核心服務也以不同的方式受到影響。
EC2
EC2通過DropletWorkflow Manager (DWFM)系統來管理實例的啟動。DWFM通過DynamoDB定期進行狀態檢查，以掌握EC2實例狀態變更是否正確執行。
在無法進行這項狀態檢查的情況下，雖然對現有實例的影響不大，但卻無法啟動新的實例。
NLB
NLB幾乎是在EC2實例上運行，因此受到EC2實例故障的影響。
Lambda
Lambda的函數元數據獲取也依賴DynamoDB。同樣地，Lambda也無法創建或更新。此外，來自SQS等的事件輪詢系統也使用DynamoDB，因此事件處理出現延遲。
等等，幾乎所有聽過的服務都受到影響，這是一場前所未有（？）的故障。在此不再詳述。
詩篇
（這是筆者個人的看法，並不代表其所屬組織的官方觀點）
我們可能正在走一條單行道。然而，這也並非壞事。
正如股價所顯示的，此次事件在市場和投資者中意外地獲得了相對正面的看法。AWS一直被批評在與GCP和Azure之間的市場份額被削弱，在AI時代被拋到腦後，但以最壞的方式展示了其驚人的影響力。當今的互聯網若沒有包括AWS在內的巨大供應商，根本無法運行，這正是最佳的例證。
在這種情況下，回歸本地運行等試圖恢復過去美好時代的聲音也開始出現，但我敢肯定地說——這是困難的。而且，即使能回去也不會有太多好處。
大型供應商承擔了運營的責任，這是一個極其優秀的系統。任何規模的公司都能構建具有高可用性的服務，同時只需簡單的操作就能制定DR（災難恢復計劃）。
更重要的是，這個系統地主場將責任稀釋並擴大分攤，讓個人能更加輕鬆。用戶與SaaS企業，SaaS企業與AWS，彼此之間建立了SLA/OLA，從而形成合理的責任轉嫁機制。參與整個過程的個人或企業只需在規定範圍內承擔責任，且不必受到過度的懲罰。
若是自行展開服務，並遭遇此次的故障，對某些特定企業或個人而言，將會成為更難以承受的局面。過度自信於自身的「責任承擔能力」並不會解決問題，反而只會讓弱小企業和個人更加不幸。
作為開發者，我們能做些什麼？
當然，制定適當的備份計劃及高可用性的架構設計等，持續提升架構師的能力是必要的，但說實話，我覺得究竟能做的其實也有限。
不少人提出多雲的對策，但將它實現的話，成功運行的IT服務的利潤用於支撐基礎設施成本翻倍、三倍的情況是完全不被允許的。如果將供應商進行（非AWS之外）分散，分散先的上游也可能有AWS的服務。因此，願意承擔金錢以獲得比金字塔頂端的0.01%可用性的企業又有幾個呢？
事情不止於此。選擇AWS/GCP/Azure/等大型供應商並非僅僅得到每月的發票而已。必須圍繞這些供應商進行採購、組織建設、技術堆疊。而這同時會讓轉換至其他供應商的難度大幅增加。這是CTO們所頭痛的困境。
作為一名開發者，我們只能信任自己所選擇的道路並向前推進。
（喔！從現在開始不使用US-EAST-1而是積極使用US-WEST-2，這是可以立即做的事情。）
原文出處：https://qiita.com/zhang_hang/items/e63468ec53a95bb605a3
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式
