99.999% 或更高情境,復原時間低於 1 分鐘 - 可靠性支柱

99.999% 或更高情境,復原時間低於 1 分鐘

應用程式的可用性目標要求在特定時間幾乎沒有停機時間及資料丟失。可能具有此可用性目標的應用程式包括,例如某些銀行、投資、金融、政府和關鍵業務應用程式,它們是產生巨大收入之業務的核心業務。期望在所有層上具有高度一致的資料存放區和完全冗餘。我們選擇了一個基於 SQL 的資料存放區。但是,在某些情況下,我們發現很難實現非常小的 RPO。如果可以對資料進行分區,則可能不會丟失資料。這可能需要您新增應用程式邏輯和延遲,從而確保在地理位置之間具有一致的資料,並具有在分區之間移動或複製資料的功能。如果您使用 NoSQL 資料庫,執行此分區可能會更容易。

我們可以透過跨多個 AWS 區域使用 主動-主動 跨多個 AWS 區域的方法。工作負載將部署在所有跨區域 靜態穩定的 所需區域中 (因此剩餘區域可以處理遺失一個區域的負載)。路由層 會將流量 定向到運作狀態良好的地理位置,並在位置運作狀態不佳時自動變更目的地,並暫時停止資料複寫層。Amazon Route 53 可提供 10 秒的間隔運作狀態檢查,並且還為您的記錄集提供 TTL (低至一秒)。

監控資源

與 99.95% 情境相同,且當某個區域被偵測為運作狀態不佳並從中將流量路由離開時發出提醒。

適應需求變更

與 99.95% 情境相同。

實作變更

部署管道將包含完整的測試套件,包括效能、負載和故障注入測試。我們將使用 Canary 或藍/綠部署,一次將更新部署到一個區域中的一個隔離區域,然後再開始另一個區域。在部署期間,舊版本仍將在執行個體上繼續執行,以加快回復速度。這些是完全自動化的,如果 KPI 指示存在問題,則包括回復。監控將包括成功指標,並會在出現問題時發出提醒。

我們擁有符合嚴格報告需求及效能追蹤的執行手冊。如果成功營運趨向於無法達到效能或可用性目標,則將使用程序手冊來確定導致這種趨勢的原因。我們擁有針對未發現的故障模式和安全事故的程序手冊。我們還擁有可用於確定失敗的根本原因的程序手冊。

建立網站的團隊也經營該網站。該團隊將識別任何意外故障的錯誤糾正措施,並在實作修補程序後優先考慮部署該修補程序。我們還將與 AWS Support for Infrastructure Event Management 接洽。

備份資料

與 99.95% 情境相同。

彈性架構師

應使用軟體/應用程式彈性模式來建置應用程式。可能需要許多其他路由層來實現所需的可用性。不應低估此附加實作的複雜性。該應用程式將在部署故障隔離區域中實作,並進行分區和部署,如此一來,即使是區域範圍的事件也不會影響所有客戶。

測試彈性

我們將在演練日期間驗證架構,使用執行手冊可確保我們能執行任務並且不會偏離程序。

災難復原 (DR) 計畫

主動-主動 多區域部署,可在多個區域提供完整的工作負載基礎設施和資料。透過使用讀取本機、寫入全域策略,一個區域是所有寫入的主要資料庫,且會複寫資料以讀取到其他區域。如果主要資料庫區域失敗,則需要提升新的資料庫。透過讀取本機、寫入全域,將使用者指派給處理資料庫寫入的主區域。這讓使用者可以從任何區域讀取或寫入,但需要複雜的邏輯來管理不同區域中跨寫入的潛在資料衝突。

當某個區域被偵測為運作狀態不佳時,路由層會自動將流量路由到其餘運作狀態良好的區域。不需要手動介入。

資料存放區在區域之間的複寫方式必須能夠解決潛在的衝突。由於延遲的原因,將需要建立工具和自動化程序來在分區之間複製或移動資料,並平衡每個分區中的請求或資料數量。補救資料衝突的方法也將需要其他營運執行手冊。

可用性設計目標

我們假設已為自動化所有復原進行了大量投資,並且在一分鐘內完成了復原。我們假設沒有手動觸發的復原,但是每季度最多執行一次自動復原動作。這意味著每年需要四分鐘才能復原。我們假設應用程式可透過更新持續聯網。因此,我們的 可用性設計目標 為 99.999%。

總結

主題 實作
監控資源 在所有層和 KPI 上執行運行狀態,包括 AWS 區域層級上的 DNS 運行狀態及 KPI;觸發已設定提醒時傳送的提醒;進而提醒所有故障。營運會議將嚴格偵測趨勢並管理設計目標。
適應需求變更 適用於 Web 和自動調整規模應用程式層的 ELB;針對 Aurora RDS 在主動和被動區域的多個區域中自動調整儲存空間和僅供讀取複本規模。在 AWS 區域之間同步資料和基礎設施以實現靜態穩定性。
實作變更 當 KPI 或提醒揭示應用程式中未檢測到問題時,可透過 Canary 或藍/綠自動部署並自動還原,一次在一個 AWS 區域的一個隔離區域進行部署。
備份資料 透過 RDS 在每個 AWS 區域中進行自動備份,以滿足 RPO 和在演練日定期進行的自動復原。Aurora RDS 和 S3 資料會自動非同步地從主動區域複寫到被動區域。
彈性架構師 為應用程式實作了故障隔離區;自動擴展以提供我修復的 Web 和應用程式層;RDS 是多可用區域;自動化區域故障移轉。
測試彈性 元件和隔離區域的故障測試正在進行中,並會在演練日定期與營運人員進行練習;存在用於診斷未知問題的程序手冊;並且存在根本原因分析流程,其中該流程帶有通訊路徑以查找問題的根源以及糾正和預防的方式。RCA 糾正應優先於功能發佈,以便即時實作和部署。
災難復原 (DR) 計畫 主動-主動部署到至少兩個區域。基礎設施可在區域全面擴展並實現靜態穩定。資料會跨區域分割和同步。透過 RDS 加密備份。區域故障在演練日練習,並與 AWS 協調。在還原期間,可能需要提升新的主要資料庫。