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

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

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

簡介

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

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

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

什麼是 PgBouncer？

PgBouncer 是專為 PostgreSQL 設計的高效連線共用器，可降低處理時間，並將資源使用狀況最佳化，以管理一或多個資料庫的多個用戶端連線。 PgBouncer 併入三種不同的共用模式以進行連線輪替：

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

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

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

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

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

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

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

如果您的應用程式在 Azure VM 上執行，您可以在相同的 VM 上設定 PgBouncer。 若要安裝和設定 PgBouncer 作為與「適用於 PostgreSQL 的 Azure 資料庫」彈性伺服器的連線共用 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 Container Instance (ACI)、Azure 容器應用程式 (ACA) 或 Azure Red Hat OpenShift (ARO)，就可以利用 PgBouncer 作為側車容器。 側車模式從附加至摩托車的側車概念中汲取靈感，其中輔助容器稱為側車容器，會附加至父應用程式。 此模式藉由擴充父應用程式的功能並提供補充支援來擴充父應用程式。

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

此側車模式通常會與共同排程為不可部分完成的容器群組搭配使用。 側車模式會強力繫結應用程式和側車生命週期，並具有主機名和網路等共享資源。 藉由使用此設定，PgBouncer 會最佳化連線管理，並促進應用程式與「適用於 PostgreSQL 的 Azure 資料庫」彈性伺服器執行個體之間高效的通訊。

Microsoft 已在 Microsoft 容器登錄中發佈 PgBouncer 側車 Proxy 映像。

如需更多詳細資料，請在此處參閱。

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

優點：

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

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

限制：

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

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

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

使用此方法時，PgBouncer 會部署為集中式服務，與應用程式無關。 PgBouncer 服務可以部署在傳統虛擬機器上，或部署在微服務型的結構內，醒目提示如下：

I. PgBouncer 已部署在 Azure Load Balancer 背後的 ubuntu VM

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

請參閱連結，了解如何搭配「適用於 PostgreSQL 的 Azure 資料庫」彈性伺服器，安裝和設定 PgBouncer 連線共用 Proxy。

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

優點：

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

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

限制：

• 管理額外負荷：因為 VM 中已安裝 PgBouncer，管理多個組態檔可能會產生管理的額外負荷。 這會導致難以處理版本升級、新版本和產品更新。
• 功能同位：如果您要從傳統 PostgreSQL 移轉至「適用於 PostgreSQL 的 Azure 資料庫」彈性伺服器，並使用 PgBouncer，則可能會有一些功能差距。 例如，「適用於 PostgreSQL 的 Azure 資料庫」彈性伺服器缺少 md5 支援。

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

如果您要在包含數百個 Pod 的 Azure Kubernetes Service (AKS) 上使用高度可擴充且大型的容器化部署，或是有多個應用程式需要連線到共用資料庫，則 PgBouncer 可以當作獨立服務使用，而非側車容器。

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

Microsoft 容器登錄中發佈的 PgBouncer 側車 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 時，使用者可以享有簡化設定的便利性、受控服務的可靠性、各種共用模式的支援，以及在容錯移轉案例期間順暢的高可用性。

限制：

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

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

選取準則	應用程式 VM 上的 PgBouncer	使用 ALB 在 VM 上的 PgBouncer*	AKS 側車上的 PgBouncer	PgBouncer 作為服務	「適用於 PostgreSQL 的 Azure 資料庫」彈性伺服器中的內建 PgBouncer
簡化的管理
HA
容器化應用程式
降低網路額外負擔與延遲
監視和偵錯的精細控制

圖例

難度	符號
簡單
中
困難

*ALB：Azure Load Balancer。