高可用性架構
概觀
AWS 邊緣服務是建立具有高可用性的 Web 應用程式的重要元件。除了分散式特性帶來的原生高可用性之外，AWS 邊緣服務還可以作為 Web 應用程式的入口點，並可將請求路由到來源基礎架構的可用分割區 (例如可用區或地區)。
架構決策
高可用性 Web 應用程式可根據您在可用性 SLO、成本及複雜性方面的要求，以多種方式設計。您至少需要根據您的業務需求做出以下技術決策：
- 是否有主動式/主動式或主動式/被動式架構？
- 是否有不同的來源？不同的 AZ？不同的地區？
- 主動式/主動式架構的跨來源之路由邏輯是什麼？ 主動式/被動式架構的容錯移轉標準是什麼？
管理暫時性來源錯誤
CloudFront 可協助您減輕暫時性 5xx 錯誤的影響，這些錯誤有時會影響少量使用者請求。通常，這是由於突然流量暴增或暫時性網絡問題所導致來源不堪重負。您可以透過不同方式使用 CloudFront 緩解暫時性 5xx 錯誤。
重試。CloudFront 可設定為在無法與來源建立連線時，最多可重試 TCP 連線三次，並具有可設定的連線逾時。CloudFront 也會根據設定的重試次數重試等冪 GET/HEAD。
使用過時內容進行回應。如果重試失敗並顯示源，CloudFront 會在預設情況提供快取可用的物件舊版本，而不會傳回錯誤回應。可以使用 Cache-Control: stale-if-error=0 指令停用此行為。
來源容錯移轉至次要來源。您可以使用來源容錯移轉功能將 CloudFront 設定為無法將特定的失敗請求轉移到次要來源。來源容錯移轉僅適用於等冪 GET/HEAD 請求。請注意，如果您在來源事件使用 Lambda@Edge，CloudFront 也會在容錯移轉時執行該函數。在此案例中，您可以在 Lambda@Edge 函數推斷請求是針對主要來源還是次要來源，以區分其邏輯。為此，請在兩個來源設定相同的來源自訂標頭，但使用 Lambda@Edge 可以讀取的不同值。
從容進行容錯移轉。如果不希望將來源容錯移轉到另一個來源 (例如，維護另一個來源基礎架構)，請考慮使用自訂錯誤頁面來容錯移轉到託管在不同位置 (例如 S3 儲存貯體) 的靜態檔案。根據預設，所有導致錯誤的請求都會使用相同的頁面，但是您可以透過遵循此部落格的第三種模式來建立更動態的回應。
來源中斷期間的狀態容錯移轉
根據 Route 53 政策進行容錯移轉
您可以使用 Route 53 容錯移轉路由政策，對在 CloudFront 設定為來源的來源網域進行運作狀態檢查。當主要來源變得不良時，Route 53 會偵測到它，然後開始使用次要來源的 IP 地址解析原始網域名稱。CloudFront 遵循來源 DNS TTL，這表示流量將開始流向 DNS TTL 內的次要來源。最佳組態 (已啟動快速檢查，容錯移轉臨界值為 1，以及 60 秒 DNS TTL) 表示容錯移轉至少需要 70 秒才能發生。當發生這種情況時，所有流量都會切換到次要來源，因為這是有狀態的容錯移轉。請注意，可以使用 Route 53 應用程式復原控制進一步擴展此設計，以實現跨多個 AWS 區域、可用區域及內部部署的更複雜的應用程式容錯移轉。此方法可以與 GET/HEAD 請求的 CloudFront 來源容錯移轉功能結合使用，以減少當 Route 53 容錯移轉到次要來源時的錯誤。本部落格對此模式進行了介紹。
當不同的來源不共用相同的網域名稱時 (例如基於 S3 的來源)，則無法以上述提議的方式使用 Route 53。在這種情況下，您需要根據來源請求事件設定的 Lambda@Edge 函數來查詢 Route 53 要選取哪個來源，然後透過變更原始網域名稱及主機標頭將請求重新路由到選定的來源。若要深入瞭解此實作，請參閱下列內容豐富的案例研究。
使用 Global Accelerator 進行容錯移轉
使用 Global Accelerator 的應用程式可從其原生容錯移轉功能受益。使用 Global Accelerator 後，您的應用程式就可以在多個可用區域或跨多個 AWS 區域部署在單一 AWS 區域。Global Accelerator 使用運作狀態檢查來監控應用程式端點的運作狀況，並在數十秒內將流量從不良端點路由出去。
主動式-主動式架構
延遲為基礎的路由
CloudFront 可以與 Route 53 延遲為基礎的政策結合使用，將使用者請求路由到您在主動式-主動式多區域架構複製來源的最近 AWS 區域。若要執行此操作，請在 Route 53 使用延遲為基礎的來源網域名稱設定 CloudFront 的來源網域名稱。當 CloudFront 解析來源網域以進行連線並將請求傳送到來源時，Route 53 根據延遲傳回最近的來源 IP。請注意，CloudFront 解析來源網域名稱的位置取決於發布組態及流量類型。通常，網域名稱會在動態請求的邊緣節點，以及可快取內容的區域邊緣快取解析。本部落格會引導您完成 API Gateway 的主動式-主動式多區域部署。
當不同的來源不共用相同的網域名稱時 (例如基於 S3 的來源)，則無法以上提議的方式使用 Route 53。在這種情況下，您需要在來源請求事件設定 Lambda@Edge 以路由到最近的來源。若要瞭解有關此實作的更多資訊，請閱讀以下部落格：
- 使用 Amazon CloudFront 和 Amazon S3 建立多區域主動式-主動式地理接近應用程式
- 透過 CloudFront 減少使用多區域 API 終端使用者的延遲。 在本部落格，您將瞭解如何實作以 GraphQL API 為基礎的多區域 AppSync。
進階路由
在某些情況下，請求路由需要應用程式層級邏輯。當邏輯簡單時，例如根據路徑路由到不同的來源 (例如路由 /api1 到來源 1 和 /api2 到來源 2)，您可以簡單使用 CloudFront 的原生快取行為功能。如果邏輯更複雜，則來源請求事件 Lambda@Edge 讓您可根據應用程式層級的屬性 (例如 URL、Cookie、標頭、國家/地區等) 來路由流量。邏輯可以是無狀態且完全嵌入到函數程式碼，也可以儲存在外部位置，例如 S3 或 DynamoDB，Lambda@Edge 從中擷取路由規則來執行它。
