View a markdown version of this page

常見使用案例 - Amazon Aurora
應用程式可擴展性高可用性將多個代理與一個目標搭配使用

本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

常見使用案例

應用程式可擴展性

無伺服器和事件驅動應用程式中的連線處理

無伺服器和事件驅動的應用程式，例如 支援的 APIs 和 Web 服務 AWS Lambda，通常必須支援大量的短期用戶端請求。此使用模式可能會導致資料庫端的連線流失，而無法在應用程式端實作連線集區。資料庫效能可能會因為單獨使用並行連線的數量而降低，或者資料庫可能會超過其連線限制而導致用戶端面對錯誤。

在這些情況下，RDS Proxy 可以帶來下列好處：

  1. 它會將建立資料庫連線的成本卸載至代理，並提供連線集區和多工功能，將大量用戶端連線轉譯為數量較少的後端資料庫連線。這有助於減少連線額外負荷和資料庫爭用，尤其是在 PostgreSQL 等資料庫引擎中，建立和維護連線的成本相對較高。

  2. 它可以更正常地處理連線突增。例如，當資料庫超過其連線限制時，它會立即將錯誤傳回給用戶端。當 RDS Proxy 需要從集區借用連線，但集區已滿容量時，代理可以等待連線變成可用。此功能可以透過將硬錯誤轉換為稍微增加的查詢延遲來改善客戶體驗。

  3. 透過可設定的連線集區大小，您也可以使用 RDS Proxy 做為限流或負載卸載機制。如果連線數量超過您指定的限制，RDS Proxy 會等待連線在可設定的逾時內變成可用。在資料庫提供多個工作負載的情況下，這很有用，而且您想要限制特定工作負載在資料庫中可以建立的壓力量。

容器型分散式應用程式中的連線處理

容器型分散式應用程式架構可能會數百甚至數千個容器，每個容器都會執行應用程式程式碼的副本。即使個別容器能夠連線集區，這些集區也是容器特定的，因此非常小。容器數量乘以每個容器微型集區的大小，可能會超過 Amazon RDS 或 Aurora 資料庫的連線限制。

在這種情況下，RDS Proxy 執行連線集區 （重複使用連線） 和多工 （使用一個後端連線為多個用戶端提供服務） 的能力最有價值。您仍然可以使用每個容器內的連線集區來減少應用程式執行緒和 RDS Proxy 之間的流失，但代理可協助將後端資料庫連線的數量降低至可管理層級。

改善僅供讀取複本使用率

大量讀取的資料庫可能需要多個僅供讀取複本，才能支援唯讀流量。應用程式可以使用自己的邏輯來選擇要連接到哪個複本，或者更常見的是使用 DNS 型循環配置機制，例如 Aurora 叢集讀取器端點。不過，DNS 型方法可能會導致 DNS 快取導致複本使用率不均。例如，用戶端可能會「將自己釘選」至特定複本、無法辨識要新增至叢集的新複本，或者可能嘗試連線至不再存在的複本。

當您使用 RDS Proxy 唯讀端點時，代理會使用「最少未完成連線」邏輯，在所有可用的複本之間路由用戶端連線。RDS Proxy 不會根據 CPU 使用率等資料庫指標進行負載平衡流量，但會嘗試平衡每個複本上的用戶端連線數目，並以資料庫的連線限制加權。例如，如果您有三個執行 的 Aurora 複本，其max_connections設定為 500、500 和 1000 （分別），代理會嘗試傳送大約為第三個複本連線數目的兩倍。

您可以搭配 Aurora 叢集使用 RDS Proxy 讀取器端點，或搭配兩個可讀取待命的 Amazon RDS 多可用區域資料庫叢集部署。具有僅供讀取複本的 Amazon RDS 資料庫執行個體部署不支援 Proxy 讀取器端點。

改善連線效率

在用戶端應用程式和資料庫之間引入代理時，您的目標是提高連線處理效率，同時考慮透過代理額外網路跳轉的延遲成本。額外的中繼層對於提高連線效率來說似乎是相反的，因為直接針對資料庫開啟的任何連線現在都會針對代理開啟。在這兩種情況下，通訊協定交握步驟都相同，因此，如果您仍然將資源花費在連線交握上，效率改善的來源可能不明顯。

代理不一定會讓建立連線更便宜。相反地，它會將處理交握的大部分負擔從資料庫層移至代理層。當您支付資料庫資源的費用時，您希望這些資源用於資料庫工作，而不是輔助開銷。這在使用加密連線時特別重要：雖然透過現有連線傳輸加密資料的額外負荷並不重要，但設定加密連線的初始額外負荷非常重要。在每秒經過數百或數千個連線的環境中，額外的精力可能會快速累積。您可能不想將 CPU 時間花費在 （相對昂貴） 資料庫資源上，而是將其卸載至 （相對便宜） 代理層。

有關其他網路跳轉帶來的延遲，其重要的程度取決於您的應用程式是多大的 "chatty"，以及它在資料庫的每個 "conversation" 執行多少陳述式。在 RDS Proxy 中，您通常會在低個位數毫秒內觀察到增加的延遲，但不一定會對應用程式造成明顯影響。例如：

  • 查詢執行時間順序為數十或數百毫秒 （或更多） 的工作負載不太可能注意到代理開銷，因為它是總查詢時間的一小部分。

  • 執行單一位數毫秒或低於毫秒查詢的應用程式可能會注意到差異，因為查詢額外負荷 （每個查詢一個額外的網路跳轉） 與查詢執行時間相比非常重要。如果用戶端工作階段只涉及少量查詢，因此累積的額外負荷仍然很小，這可能不是問題。

如果您的情況中新增的延遲同時明顯和不良，您必須將其與使用代理的其他好處 （混合、多工、容錯移轉處理） 權衡。

高可用性

在 Amazon RDS 和 Aurora (Aurora DSQL 除外） 上執行的異地同步備份資料庫使用容錯移轉機制，在主要資料庫執行個體發生問題時還原可用性。容錯移轉也會做為操作工作流程的一部分使用，例如主要執行個體的運算擴展。容錯移轉涉及 DNS 變更，將主要 （具備讀取/寫入能力） 資料庫端點從先前的主要執行個體移至新提升的主要執行個體。用戶端應用程式必須觀察和識別此 DNS 變更，以便用戶端可以立即遵循主要伺服器。

有些應用程式可能會因為作業系統或應用程式層級的 DNS 快取，而無法及時辨識 DNS 變更。雖然解決應用程式層級的 DNS 快取問題是最佳實務，但由於應用程式複雜性或引入變更的成本，並不總是可行的。

在此案例中，RDS Proxy 是避免 DNS 相關容錯移轉延遲的有效方法。RDS Proxy 提供的讀取/寫入端點和選用的唯讀端點「穩定」，因為當資料庫執行個體交換其角色時，這些端點後方的 IP 地址不會變更。RDS Proxy 會持續追蹤後端資料庫的拓撲，並從用戶端抽象化執行個體角色變更。

有替代方法可以處理 DNS 快取問題，例如使用直接能夠偵測資料庫拓撲的進階驅動程式，而無需依賴 DNS。不過，在資料庫前部署單一代理可能更容易，而不是在應用程式層級引入程式碼變更和新的驅動程式。

讀取可用性

除了改善資料庫容錯移轉期間的用戶端體驗之外，RDS Proxy 還有助於在發生僅供讀取複本問題時提供應用程式可用性。它以兩種方式執行此操作：

  1. 如果僅供讀取複本無法使用，但叢集中還有其他可用的複本，代理可以將新的連線路由到可用的複本。用戶端不需要擔心 DNS 傳播延遲或 DNS 快取。

  2. 對於多工的現有用戶端連線，代理可以將後續查詢從該連線傳送至可用的不同複本。在這種情況下，用戶端甚至可能不會注意到後端複本遇到問題。使用此技術時，RDS Proxy 會確保新的複本在複寫延遲方面不會落後於先前的複本。如此一來，用戶端傳送的後續查詢就不會看到可能被視為過時的資料。

將多個代理與一個目標搭配使用

最佳實務是，每個資料庫目標使用一個 RDS Proxy，例如 Amazon RDS 執行個體或 Aurora 叢集。這在大多數情況下都很有效，它可以保持簡單的組態，並讓用戶端體驗更可預測。相較之下，使用多個代理需要您仔細調整所有代理的組態，以避免意外行為。例如，您必須確保所有代理集區的合併大小不超過單一資料庫目標的連線限制。

在某些情況下，您仍然可以探索使用多個代理的概念。以下各節討論最常見的案例，並概述單一代理與多代理方法的優缺點。

Proxy 可用性

RDS Proxy 基礎設施在設計上可在多個可用區域 (AZs) 上高度可用和部署。代理容量會透過持續運作狀態監控分散到許多節點，並根據佈建的執行個體大小或資料庫的 Serverless v2 最大 ACU 設定自動調整。由於代理的分散式多可用區設計，您不需要為了高可用性，在 Amazon RDS 或 Aurora 叢集前執行多個代理。

事實上，在單一資料庫目標前使用多個代理意味著應用程式堆疊現在負責偵測問題並做出反應，而不是依賴內建於代理的強大機制。因此，由於高可用性原因，強烈建議使用多個代理，因為它可能會引入比它可以解決更多的問題。

處理多個用戶端集區

每個代理都會提供一個讀取/寫入端點，以及 （選擇性） 額外的讀取/寫入或唯讀端點。當使用單一代理處理多個用戶端群組或多個工作負載時，這些工作負載可能會干擾。例如，一個工作負載可以將連線集區統一為沒有足夠的可用連線來處理其他工作負載。使用單獨的代理來隔離工作負載可能是令人信服的解決方案，但您可以先考慮其他選項：

  • 資料庫本身可能會提供執行多個代理的更簡單替代方案。例如，如果問題是由特定使用者控制集區所造成，您可以使用資料庫的許可系統來限制這些使用者可開啟的並行連線數量。

  • 同樣地，資料庫層級查詢逾時和閒置逾時可以解決孤立連線或失控查詢的問題。

  • 如果問題是由查詢或交易持續時間或每個查詢資源耗用量而非並行連線的數量造成，則使用其他代理不會有幫助，因為代理不會對查詢或交易權重施加限制。如果來源無法解決問題，您可以使用資料庫的事件排程器來執行程式碼，以根據任意條件偵測和終止用戶端活動，而不是將這些有問題的用戶端移至單獨的代理。

如果您決定在相同目標前使用多個代理，請確保所有連線集區的總大小不超過目標資料庫的功能。例如，MaxConnectionsPercent所有代理的 總和必須小於 100，否則代理可能會嘗試開啟比資料庫設定為處理的連線更多。

每個代理會個別計費，計費費率取決於基礎資料庫資源的大小，而非工作負載活動。如果存在，請考慮執行多個代理的成本與實作替代解決方案的成本。

獨立控制讀取和寫入集區

每個代理提供一個讀取/寫入端點和 （選擇性） 額外的讀取/寫入或唯讀端點，但限制和逾時是針對整個代理目標設定，而不是針對每個代理端點個別設定。

例如，您可能有一個 Aurora 叢集使用多個僅供讀取複本和代理的讀取器端點來處理大量唯讀查詢，但您想要限制讀取/寫入連線的數量，以減少單一寫入器的資源壓力。由於MaxConnectionsPercent設定是針對整個代理目標 （叢集） 定義，因此您無法限制讀取/寫入端點的連線數，也不會影響唯讀端點的限制。

有多種方式可以處理此挑戰：

您可以在叢集中啟動其他僅供讀取複本，並按比例減少代理MaxConnectionsPercent的設定。這可保留唯讀連線集區的總大小，同時減少寫入器上允許的連線數上限。不過，它也會增加叢集成本，而且您擁有的複本越多，其效能會逐漸降低。

您可以使用執行個體層級參數群組，將僅供讀取複本的資料庫連線限制 （例如在 Aurora MySQL 或 PostgreSQL max_connections中） 與寫入器分開設定。不過，您必須避免使用非對稱參數組態，因為複本可以在容錯移轉期間提升為寫入器角色，因此初始參數差異不會永久存在。您可能會考慮變更執行個體層級容錯移轉優先順序設定，以影響在容錯移轉期間選取要提升的複本，並使用它做為軟式容錯移轉排除機制，使非對稱組態更具可預測性。不過，容錯移轉優先順序僅做為提示，並非容錯移轉行為的確切保證。因此，不建議使用非對稱設定的多執行個體組態，因為它們需要持續監控，而且如果容錯移轉落在您不想使用的執行個體上，可能會產生非預期的行為。

在此案例中，使用多個代理可能是單獨管理讀取和寫入集區的最乾淨方式。您可以為單一資料庫目標建立兩個代理，然後將應用程式設定為使用來自第一個代理的寫入器端點和來自第二個代理的唯讀端點。一個代理僅處理寫入工作負載，另一個代理僅處理讀取工作負載，並且可以為每個代理獨立設定 MaxConnectionsPercent（以及其他設定）。此解決方案涉及執行第二個代理的額外成本，但比上述替代方案更簡單且可預測。