適用於 PostgreSQL 的 Azure 資料庫 的連線共用策略 - 使用 PgBouncer 的彈性伺服器

適用範圍：適用於 PostgreSQL 的 Azure 資料庫 - 彈性伺服器

針對 適用於 PostgreSQL 的 Azure 資料庫 彈性伺服器選取連線共享機制的策略指引。

簡介

使用 適用於 PostgreSQL 的 Azure 資料庫 彈性伺服器時，建立資料庫的連線牽涉到在用戶端應用程式與伺服器之間建立通道。 此通道負責管理數據、執行查詢及起始交易。 建立連線之後，用戶端應用程式就可以將命令傳送至伺服器並接收回應。 不過，為每個作業建立新的連線可能會導致任務關鍵性應用程式的效能問題。 每次建立新的連線時，適用於 PostgreSQL 的 Azure 資料庫 彈性伺服器都會使用 postmaster 程式繁衍新的程式，這會耗用更多資源。

為了減輕此問題，連線共用可用來建立可在 適用於 PostgreSQL 的 Azure 資料庫 彈性伺服器中重複使用的連線快取。 當應用程式或用戶端要求連線時，它會從連線集區建立。 會話或交易完成後，聯機會傳回集區以供重複使用。 藉由重複使用連線，資源使用量會降低，並改善效能。

雖然連線共用有不同的工具，但在本節中，我們會討論使用 PgBouncer 使用連線共用的不同策略。

什麼是 PgBouncer？

PgBouncer 是專為 PostgreSQL 設計的有效率連線共用器，可提供減少處理時間，並將資源使用量優化，以管理一或多個資料庫的多個客戶端連線。 PgBouncer 會納入三種不同的共用模式以進行連線輪替：

• 會話共用： 此方法會在用戶端連線的整個期間，將伺服器連線指派給用戶端應用程式。 在用戶端應用程式中斷連線時， PgBouncer 會立即將伺服器連線傳回集區。 會話共用機制是開放原始碼 PgBouncer 中的預設模式。 請參閱 PgBouncer 設定
• 交易共用： 使用交易共用時，伺服器連接會在交易期間專用於用戶端應用程式。 交易成功完成之後， PgBouncer 會以智慧方式釋放伺服器連線，使其可在集區內再次使用。 交易共用是彈性伺服器內建 PgBouncer 適用於 PostgreSQL 的 Azure 資料庫 的預設模式，且不支援備妥的交易。
• 語句共用： 在語句共用中，伺服器連接會配置給每個個別語句的用戶端應用程式。 語句完成時，會立即將伺服器連接傳回至連接集區。 請務必注意，此模式不支援多語句交易。

PgBouncer 的有效使用率可分類為三個不同的使用模式。

• PgBouncer 和應用程式共置部署
• 應用程式獨立集中式 PgBouncer 部署
• 內建的 PgBouncer 和資料庫部署

每個模式都有自己的優點和缺點。

1. PgBouncer 和應用程式共置部署

使用此方法時，PgBouncer 會部署在裝載應用程式的相同伺服器上。 應用程式與 PgBouncer 可以部署在傳統虛擬機上，或部署在微服務架構內，如以下醒目提示：

I. 部署在應用程式 VM 中的 PgBouncer

如果您的應用程式在 Azure VM 上執行，您可以在相同的 VM 上設定 PgBouncer。 若要使用 適用於 PostgreSQL 的 Azure 資料庫 彈性伺服器安裝及設定 PgBouncer 作為連線共用 Proxy，請遵循下列連結中提供的指示。

在應用程式伺服器中部署 PgBouncer 可以提供數個優點，尤其是在使用 適用於 PostgreSQL 的 Azure 資料庫 彈性伺服器資料庫時。 此部署方法的一些主要優點和限制如下：

優點：

• 降低延遲： 藉由在相同的應用程式 VM 上部署 PgBouncer ，主要應用程式與連線共用器之間的通訊會因為其鄰近性而有效率。 在應用程式 VM 中部署 PgBouncer 可降低延遲，並確保順暢且快速的互動。
• 改善的安全性：PgBouncer 可作為應用程式與資料庫之間的安全媒介，以提供額外的安全性層。 它可以強制執行驗證和加密，確保只有授權的用戶端可以存取資料庫。

整體來說，在應用程式伺服器中部署 PgBouncer 可提供更有效率、更安全且可調整的方法，以管理 適用於 PostgreSQL 的 Azure 資料庫 彈性伺服器資料庫的連線，以提高應用程式的效能和可靠性。

限制：

• 單一失敗點： 如果 PgBouncer 部署為應用程式伺服器上的單一實例，它就會變成潛在的單一失敗點。 如果 PgBouncer 實例關閉，可能會中斷整個資料庫連線集區，導致應用程式的停機時間。 若要減輕單一失敗點，您可以在負載平衡器後方設定多個 PgBouncer 實例，以達到高可用性。
• 有限的延展性： PgBouncer 延展性取決於部署伺服器的容量。 如果應用程式伺服器達到其連線限制，PgBouncer 可能會成為瓶頸，限制調整應用程式的能力。 您可能需要將連線負載分散到多個 PgBouncer 實例，或考慮替代解決方案，例如應用層級的連接共用。
• 組態複雜度： 設定及微調 PgBouncer 可能相當複雜，尤其是在考慮連線限制、集區大小調整和負載平衡等因素時。 系統管理員必須仔細調整 PgBouncer 組態，以符合應用程式的需求，並確保最佳的效能和穩定性。

請務必根據優點來權衡這些限制，並評估 PgBouncer 是否為特定應用程式和資料庫設定的正確選擇。

II. PgBouncer 部署為 AKS 側車

如果您的應用程式已容器化並在 Azure Kubernetes Service （AKS）、Azure 容器實例 （ACI）、Azure Container Apps （ACA）或 Azure Red Hat OpenShift （ARO） 上執行，就可以使用 PgBouncer 作為側車容器。 Sidecar 模式從附加至摩托車的側車概念中汲取靈感，其中輔助容器稱為側車容器，會附加至父應用程式。 此模式藉由擴充父應用程式的功能並提供補充支援來擴充父應用程式。

側車模式通常會與共同排程為不可部分完成的容器群組搭配使用。 在 AKS 側車中部署 PgBouncer 緊密結合應用程式和側車生命週期，並共用主機名和網路等資源，以有效率地使用資源。 PgBouncer Sidecar 會與 Azure Kubernetes Service （AKS） 中相同 Pod 內的應用程式容器一起運作，並搭配 1：1 對應，作為 適用於 PostgreSQL 的 Azure 資料庫 彈性伺服器的連線共用 Proxy。

此側車模式通常會與排程為不可部分完成的容器群組搭配使用。 sidecar 模式會強式系結應用程式和 Sidecar 生命週期，並具有主機名和網路等共享資源。 藉由使用此設定，PgBouncer 會將連線管理優化，並協助應用程式與 適用於 PostgreSQL 的 Azure 資料庫 彈性伺服器實例之間的有效通訊。

Microsoft已在Microsoft容器登錄中發佈 PgBouncer Sidecar Proxy 映射。

如需詳細資訊，請參閱 此 專案。

此部署方法的一些主要優點和限制如下：

優點：

• 降低延遲：藉由將 PgBouncer 部署為 AKS 側車，主要應用程式和連線共用器之間的通訊會因為鄰近性而順暢且有效率。 部署 AKS 側車的 PgBouncer 可最小化延遲，並確保順暢且快速的互動。
• 簡化管理和部署：PgBouncer 與應用程式容器緊密結合可簡化管理和部署程式。 這兩個元件都緊密整合，可讓您更輕鬆地進行管理和順暢的協調。
• 高可用性和連線復原：如果應用程式容器失敗或重新啟動，PgBouncer Sidecar 容器會緊隨其後，確保高可用性。 此設定保證即使在故障轉移期間也能維持連線復原能力，並維護可預測的效能，這有助於可靠且健全的系統。

藉由將 PgBouncer 視為 AKS 側車，您可以使用這些優點來增強應用程式的效能、簡化管理，並確保連線共用器持續可用性。

限制：

• 線上效能問題： 利用數千個 Pod 的大型應用程式，每個執行中的 Sidecar PgBouncer 都可能會遇到與資料庫連線耗盡相關的潛在挑戰。 這種情況可能會導致效能降低和服務中斷。 為每個 Pod 部署 Sidecar PgBouncer 會增加資料庫伺服器的並行連線數目，這可能會超過其容量。 因此，資料庫可能難以處理大量的連入連線，可能會導致效能問題，例如回應時間增加，甚至服務中斷。
• 複雜部署： 側車模式的使用率會對部署程式帶來複雜度層級，因為它牽涉到在相同 Pod 內執行兩個容器。 這可能會導致疑難解答和偵錯活動複雜，需要額外努力找出並解決問題。
• 調整挑戰： 請務必注意，側車模式可能不是需要高延展性之應用程式的理想選擇。 包含 Sidecar 容器可能會施加更多資源需求，而可能會限制可有效建立和管理的 Pod 數目。

考慮此側車模式時，請務必仔細評估部署複雜度和延展性需求之間的取捨，以判斷特定應用程式案例最適當的方法。

2. 應用程式獨立 - 集中式 PgBouncer 部署

使用此方法時，PgBouncer 會部署為集中式服務，與應用程式無關。 PgBouncer 服務可以部署在傳統虛擬機上，或在微服務架構內部署，如反白顯示：

I. 部署在 Azure Load Balancer 後方的 ubuntu VM 中的 PgBouncer

PgBouncer 連線 Proxy 會在 Azure Load Balancer 背後的應用程式和資料庫層之間設定，如下圖所示。 在此模式中，多個 PgBouncer 實例會部署在負載平衡器作為服務後方，以減輕單一失敗點。 此模式也適用於應用程式在受控服務上執行的案例，例如 Azure App 服務 或 Azure Functions，並連線到 PgBouncer 服務，以便與現有的基礎結構輕鬆整合。

請參閱連結，以使用 適用於 PostgreSQL 的 Azure 資料庫 彈性伺服器安裝及設定 PgBouncer 連線共用 Proxy。

此部署方法的一些主要優點和限制如下：

優點：

• 拿掉單一失敗點： 應用程式連線可能不會受到單一 PgBouncer VM 失敗的影響，因為 Azure Load Balancer 後有數個 PgBouncer 實例。
• 與受控服務無縫整合：如果您的應用程式裝載在受控服務平臺上，例如 Azure App 服務 或 Azure Functions，在 VM 上部署 PgBouncer 可讓您輕鬆地與現有的基礎結構整合。
• Azure VM 上的簡化設定： 如果您已在 Azure VM 上執行應用程式，請在相同的 VM 上設定 PgBouncer 很簡單。 在 VM 中部署 PgBouncer 可確保 PgBouncer 部署在應用程式附近，將網路等待時間降至最低，並將效能最大化。
• 非侵入式組態：藉由在 VM 上部署 PgBouncer，您可以避免在 適用於 PostgreSQL 的 Azure 資料庫 彈性伺服器上修改伺服器參數。 當您想要在 適用於 PostgreSQL 的 Azure 資料庫 彈性伺服器實例上設定 PgBouncer 時，這會很有用。 例如，將sslMODE參數變更為 適用於 PostgreSQL 的 Azure 資料庫彈性伺服器上的「必要」，可能會導致某些依賴 SSLMODE=FALSE 的應用程式失敗。 在個別的 VM 上部署 PgBouncer 可讓您維護預設伺服器設定，同時仍使用 PgBouncer 的優點。

藉由考慮這些優點，在 VM 上部署 PgBouncer 可提供方便且有效率的解決方案，以提升在 Azure 基礎結構上執行之應用程式的效能和相容性。

限制：

• 管理額外負荷： 當 PgBouncer 安裝在 VM 中時，可能會有管理額外負荷來管理多個組態檔。 這使得難以應付版本升級、新版本和產品更新。
• 功能同位：如果您要從傳統 PostgreSQL 遷移至 適用於 PostgreSQL 的 Azure 資料庫 彈性伺服器，並使用 PgBouncer，可能會有一些功能差距。 例如，適用於 PostgreSQL 的 Azure 資料庫 彈性伺服器中缺乏 md5 支援。

II. 在 AKS 中部署為服務的集中式 PgBouncer

如果您要在 Azure Kubernetes Service （AKS） 上使用高度可調整且大型的容器化部署，其中包含數百個 Pod，或在多個應用程式需要連線到共用資料庫的情況下， 可以使用 PgBouncer 作為獨立服務，而不是側車容器。

藉由使用 PgBouncer 做為個別服務，您可以更有效率地管理及處理應用程式連線共用的範圍。 這種方法可讓您集中處理連線共用功能，讓多個應用程式連線到相同的資料庫資源，同時維持最佳效能和資源使用率。

Microsoft容器登錄中發佈的 PgBouncer Sidecar Proxy 映像可用來建立及部署服務。

此部署方法的一些主要優點和限制如下：

優點：

• 增強的可靠性：將 PgBouncer 部署為獨立服務可讓您以高可用性方式進行設定。 這可改善連線共用基礎結構的整體可靠性，即使在發生失敗或中斷時也能確保持續可用性。
• 最佳資源使用率： 如果您的應用程式或資料庫伺服器的資源有限，則選擇專用於執行 PgBouncer 服務的個別計算機可能比較有利。 藉由在具有豐富資源的計算機上部署 PgBouncer ，您可以確保最佳效能並防止資源爭用問題。
• 集中式連接管理： 當需要集中管理資料庫連線時，獨立 PgBouncer 服務會提供更精簡的方法。 藉由將連線管理工作合併為集中式服務，您可以有效地監視和控制多個應用程式之間的資料庫連線，簡化管理並確保一致性。

藉由將 PgBouncer 視為 AKS 內的獨立服務，您可以使用這些優點來改善資料庫連線的可靠性、資源效率及集中式管理。

限制：

• 增加 N/W 延遲：將 PgBouncer 部署為獨立服務時，請務必考慮可能引進更多延遲。 這是因為需要透過網路在應用程式和 PgBouncer 服務之間傳遞連線。 請務必評估應用程式的延遲需求，並考慮集中式連線管理與潛在延遲問題之間的取捨。

雖然 以獨立服務身分執行的 PgBouncer 提供集中式管理和資源優化等優點，但請務必評估潛在延遲對應用程式效能的影響，以確保其符合您的特定需求。

3. 適用於 PostgreSQL 的 Azure 資料庫 彈性伺服器中的內建 PgBouncer

適用於 PostgreSQL 的 Azure 資料庫 彈性伺服器供應專案PgBouncer 作為內建聯機共享解決方案。 這會以選擇性服務的形式提供，可在每一資料庫伺服器上啟用。 PgBouncer 會在與 適用於 PostgreSQL 的 Azure 資料庫 彈性伺服器實例相同的虛擬機中執行。 當連線數目超過數百或數千個時，適用於 PostgreSQL 的 Azure 資料庫 彈性伺服器可能會遇到資源限制。 在這種情況下，內建的 PgBouncer 可以藉由改善資料庫伺服器閒置和短期連線的管理，來提供顯著優勢。

請參閱在 適用於 PostgreSQL 的 Azure 資料庫 彈性伺服器中啟用和設定 PgBouncer 連線共用的連結。

此部署方法的一些主要優點和限制如下：

優點：

• 無縫設定：在 適用於 PostgreSQL 的 Azure 資料庫 彈性伺服器中使用內建的 PgBouncer，就不需要個別安裝或複雜的設定。 它可以直接從伺服器參數進行設定，以確保無麻煩的體驗。
• 受控服務便利性： 身為受控服務，使用者可以享有其他 Azure 受控服務的優點。 這包括自動更新、不需要手動維護，並確保 PgBouncer 隨時掌握最新的功能和安全性修補程式。
• 公用和私人連線支援：適用於 PostgreSQL 的 Azure 資料庫 彈性伺服器中的內建 PgBouncer 同時支援公用和私人連線。 這可讓使用者透過專用網建立安全連線，或根據其特定需求從外部連線。
• 高可用性 （HA）：在故障轉移時，當待命伺服器升級為主要角色時，PgBouncer 會在新升級的待命上順暢地重新啟動，而不需要對應用程式進行任何變更 連接字串。 這可確保持續可用性，並將應用程式的中斷降到最低。
• 符合成本效益： 由於使用者不需要支付 VM 或容器之類的額外計算費用，所以其成本效益很高，雖然它確實對 CPU 有一些影響，因為它是在同一部計算機上執行的另一個進程。

在 適用於 PostgreSQL 的 Azure 資料庫 彈性伺服器中使用內建的 PgBouncer，使用者可以享受簡化設定的便利性、受控服務的可靠性、各種共用模式的支援，以及在故障轉移案例期間順暢的高可用性。

限制：

• 高載伺服器計算層目前不支援 Burstable：PgBouncer 。 如果您將計算層從一般用途或記憶體優化變更為高載層，則會失去 PgBouncer 功能。
• 重新啟動後重新建立連線： 每當在調整作業、HA 故障轉移或重新啟動期間重新啟動伺服器時， PgBouncer 也會與伺服器虛擬機一起重新啟動。 因此，必須重新建立現有的連線。

我們已討論實作 PgBouncer 的不同方式，而數據表摘要說明要選擇的部署方法：

選取準則	應用程式 VM 上的 PgBouncer	使用 ALB 的 VM 上的 PgBouncer*	AKS Sidecar 上的 PgBouncer	PgBouncer 即服務	適用於 PostgreSQL 的 Azure 資料庫 彈性伺服器內建 PgBouncer
簡化的管理
HA
容器化應用程式
降低網路負荷和延遲
監視和偵錯的精細控制

圖例

難度層級	符號
簡單
中
困難

*ALB：Azure Load Balancer。