多區域基礎 3：了解工作負載相依性

特定工作負載在區域中可能有數個相依性，例如 AWS 服務 已使用、內部相依性、第三方相依性、網路相依性、憑證、金鑰、秘密和參數。為了確保在故障案例期間操作工作負載，主要區域和待命區域之間應該沒有相依性；每個區域都應該能夠獨立運作。若要達成此目的，請仔細檢查工作負載中的所有相依性，以確保它們在每個區域中可用。這是必要的，因為主要區域中的失敗不應影響待命區域。此外，您必須了解當相依性處於降級狀態或完全無法使用時，工作負載的運作方式，以便您可以設計適當的解決方案來處理此問題。

3.a： AWS 服務

當您設計多區域架構時，請務必了解將使用 AWS 服務 的 、這些服務的多區域功能，以及您需要設計哪些解決方案才能實現多區域目標。例如，Amazon Aurora 和 Amazon DynamoDB 可以將資料非同步複寫到待命區域。工作負載將從中執行的所有區域都需要提供所有 AWS 服務 相依性。若要確認您使用的服務可在所需區域中使用，請檢閱AWS 服務 依區域清單。

3.b：內部和第三方相依性

確保每個工作負載的內部相依性在其操作所在的區域中可用。例如，如果工作負載由許多微服務組成，請識別構成商業功能的所有微服務，並確認所有這些微服務都部署在工作負載運作所在的每個區域中。或者，定義策略來正常處理無法使用的微服務。

不建議在工作負載內的微服務之間進行跨區域呼叫，並應維持區域隔離。這是因為建立跨區域相依性會增加相互關聯失敗的風險，這會抵銷工作負載隔離區域實作的優勢。內部部署相依性也可能是工作負載的一部分，因此請務必了解如果主要區域發生變更，這些整合的特性可能會如何變更。例如，如果待命區域離現場部署環境較遠，增加的延遲可能會產生負面影響。

了解軟體即服務 (SaaS) 解決方案、軟體開發套件 (SDKs) 和其他第三方產品相依性，並能夠練習這些相依性降級或無法使用的情況，將有助於更深入地了解系統鏈在不同故障模式下的運作和行為。這些相依性可能在您的應用程式程式碼內，例如使用 在外部管理秘密AWS Secrets Manager，或者可能涉及第三方保存庫解決方案 （例如 HashiCorp)，或依賴 進行聯合登入AWS IAM Identity Center的身分驗證系統。

在相依性方面具有備援可以提高彈性。如果 SaaS 解決方案或第三方相依性使用 AWS 區域 與工作負載相同的主要節點，請與廠商合作，判斷其彈性狀態是否符合您的工作負載需求。

此外，請注意工作負載與其相依性之間的共同命運，例如第三方應用程式。如果在容錯移轉後次要區域中 （或從中） 無法使用相依性，工作負載可能無法完全復原。

3.c：容錯移轉機制

DNS 通常用作容錯移轉機制，將流量從主要區域轉移到待命區域。嚴格檢閱和仔細檢查容錯移轉機制所需的所有相依性。例如，如果您的工作負載使用 Amazon Route 53，了解控制平面託管於 ，us-east-1表示您正在對該特定區域中的控制平面取得相依性。如果主要區域也是us-east-1因為它建立單一故障點，則不建議將其作為容錯移轉機制的一部分。如果您使用另一個容錯移轉機制，您應該深入了解容錯移轉無法如預期運作的情況，然後視需要規劃應變或開發新的機制。檢閱部落格文章使用 Amazon Route 53 建立災難復原機制，以了解您可以用來成功容錯移轉的方法。

如上一節所述，屬於業務功能的所有微服務都需要在部署工作負載的每個區域中提供。作為容錯移轉策略的一部分，所有屬於業務能力的微服務都應一起容錯移轉，以消除跨區域呼叫的機會。或者，如果微服務獨立容錯移轉，則可能會有不良行為，例如微服務可能會進行跨區域呼叫。這會導致延遲，並可能導致工作負載在用戶端逾時期間變得無法使用。

3.d：組態相依性

憑證、金鑰、秘密、Amazon Machine Image (AMIs)、容器映像和參數是設計多區域架構時所需的相依性分析的一部分。在可能的情況下，最好將這些元件當地語系化，以便它們在這些相依性的區域之間沒有共同命運。例如，您應該變更憑證的過期日期，以防止過期憑證 （警示設定為「預先通知」) 影響多個區域的案例。

加密金鑰和秘密也應該是區域特定的。如此一來，如果金鑰或秘密的輪換發生錯誤，則影響僅限於特定區域。

最後，任何工作負載參數都應儲存在本機，以便在特定區域中擷取工作負載。

關鍵指引

• 多區域架構受益於區域之間的實體和邏輯分離。應用程式層的跨區域相依性簡介會破壞此優勢。避免此類相依性。

• 容錯移轉控制應該在主要區域上沒有相依性的情況下運作。

• 容錯移轉應跨使用者旅程進行協調，以消除跨區域呼叫延遲增加和相依性增加的可能性。