Стратегия объединения подключений для гибкого сервера Базы данных Azure для PostgreSQL с помощью PgBouncer

Стратегическое руководство по выбору механизма пула подключений для экземпляров гибкого сервера Базы данных Azure для PostgreSQL.

Введение

При использовании гибкого экземпляра базы данных Azure для PostgreSQL подключение к базе данных включает создание канала связи между клиентским приложением и сервером. Этот канал отвечает за управление данными, выполнение запросов и инициирование транзакций. После установки подключения клиентское приложение может отправлять команды на сервер и получать ответы. Однако создание нового подключения для каждой операции может привести к проблемам с производительностью критически важных приложений. Каждый раз при создании нового подключения База данных Azure для PostgreSQL создает новый процесс с помощью процесса postmaster, который потребляет больше ресурсов.

Чтобы устранить эту проблему, пул подключений используется для создания кэша подключений, которые можно повторно использовать в Базе данных Azure для PostgreSQL. Когда приложение или клиент запрашивает подключение, оно создается из пула подключений. После завершения сеанса или транзакции подключение возвращается в пул для повторного использования. При повторном использовании подключений использование ресурсов уменьшается, а производительность улучшается.

Хотя в этом разделе существуют различные средства для пула подключений, мы обсудим различные стратегии использования пула подключений с помощью PgBouncer.

Что такое PgBouncer?

PgBouncer — это эффективный пул соединений, предназначенный для PostgreSQL, который позволяет сократить время обработки и оптимизировать использование ресурсов при управлении несколькими клиентскими подключениями к одной или нескольким базам данных. PgBouncer поддерживает три различных режима пула соединений для ротации соединений:

• Пул сеансов. Этот метод назначает серверу подключение к клиентскому приложению в течение всего периода подключения клиента. При отключении клиентского приложения PgBouncer быстро возвращает подключение сервера к пулу. Механизм пула сеансов — это режим по умолчанию в PgBouncer с открытым исходным кодом. См. конфигурацию PgBouncer
• Пул транзакций. При использовании пула транзакций подключение к серверу выделено клиентскому приложению во время транзакции. После успешного завершения транзакции PgBouncer интеллектуально освобождает подключение к серверу, что делает его доступным снова в пуле. Пул транзакций — это режим по умолчанию в встроенной PgBouncer базы данных Azure для PostgreSQL и не поддерживает подготовленные транзакции.
• Пул инструкций: в пуле инструкций подключение к серверу выделяется клиентскому приложению для каждой отдельной инструкции. После завершения инструкции подключение к серверу быстро возвращается в пул подключений. Важно отметить, что транзакции с несколькими операторами не поддерживаются в этом режиме.

Эффективное использование PgBouncer можно разделить на три различных шаблона использования.

• Развертывание PgBouncer и Application Colocation
• Централизованные развертывания PgBouncer, не зависящие от приложений
• Встроенное развертывание PgBouncer и базы данных

Каждый из этих шаблонов имеет свои собственные преимущества и недостатки.

1. Совместное развертывание PgBouncer и приложения

При использовании этого подхода PgBouncer развертывается на том же сервере, где размещено приложение. Приложение и PgBouncer можно развернуть как на традиционных виртуальных машинах, так и в микросервисной архитектуре, как показано ниже:

I. PgBouncer, развернутый на виртуальной машине приложения

Если приложение выполняется на виртуальной машине Azure, вы можете настроить PgBouncer на той же виртуальной машине. Чтобы установить и настроить PgBouncer в качестве прокси-сервера пула подключений с гибким экземпляром сервера Базы данных Azure для PostgreSQL, следуйте инструкциям, приведенным по следующей ссылке.

Развертывание PgBouncer на сервере приложений может дать ряд преимуществ, особенно при работе с базами данных База данных Azure для PostgreSQL — Flexible Server. Ниже приведены некоторые основные преимущества и ограничения этого метода развертывания.

Преимущества:

• Снижение задержки. Путем развертывания PgBouncer на одной виртуальной машине приложения взаимодействие между основным приложением и пулом подключений эффективно из-за их близости. Развертывание PgBouncer на виртуальной машине приложений сводит к минимуму задержку и обеспечивает плавное и быстрое взаимодействие.
• Улучшенная безопасность:PgBouncer может выступать в качестве безопасного посредника между приложением и базой данных, обеспечивая дополнительный уровень безопасности. Он может применять проверку подлинности и шифрование, обеспечивая доступ только авторизованных клиентов к базе данных.

В целом развертывание PgBouncer на сервере приложений обеспечивает более эффективный, безопасный и масштабируемый подход к управлению подключениями к гибким базам данных сервера База данных Azure для PostgreSQL, повышая производительность и надежность приложения.

Limitations:

• Единая точка сбоя: если PgBouncer развертывается как один экземпляр на сервере приложений, он становится потенциальной точкой сбоя. Если экземпляр PgBouncer выходит из строя, это может нарушить работу всего пула подключений к базе данных, что приведёт к простою приложения. Чтобы исключить единую точку отказа, можно настроить несколько экземпляров PgBouncer за балансировщиком нагрузки для обеспечения высокой доступности.
• Ограниченная масштабируемость: масштабируемость PgBouncer зависит от емкости сервера, на котором он развернут. Если сервер приложений достигает лимита подключений, PgBouncer может стать узким местом, ограничивая возможность масштабирования приложения. Возможно, потребуется распределить нагрузку подключения между несколькими экземплярами PgBouncer или рассмотреть альтернативные решения, такие как пул подключений на уровне приложения.
• Сложность конфигурации: Настройка и тонкая настройка PgBouncer могут быть сложными, особенно при учёте таких факторов, как лимиты подключений, размер пула и балансировка нагрузки. Администраторы должны тщательно настроить конфигурацию PgBouncer для соответствия требованиям приложения и обеспечить оптимальную производительность и стабильность.

Важно взвесить эти ограничения на преимущества и оценить, является ли PgBouncer правильным выбором для конкретного приложения и настройки базы данных.

II. PgBouncer, развернутый как сайдкар в AKS

Можно использовать PgBouncer в качестве sidecar-контейнера, если приложение упаковано в контейнеры и работает в Azure Kubernetes Service (AKS), Azure Container Instance (ACI), Контейнеры приложений Azure (ACA) или Azure Red Hat OpenShift (ARO). Паттерн Sidecar основан на концепции коляски, прикрепляемой к мотоциклу, где вспомогательный контейнер, известный как контейнер Sidecar, подключается к родительскому приложению. Этот шаблон дополняет родительское приложение, расширяя функциональные возможности и предоставляя дополнительную поддержку.

Развертывание PgBouncer в сайдкаре AKS тесно связывает жизненные циклы приложения и сайдкара и разделяет ресурсы, такие как хостнейм и сеть, для более эффективного использования. Сайдкар PgBouncer работает вместе с контейнером приложения в том же поде в Azure Kubernetes Service (AKS) с сопоставлением 1:1, служа прокси-сервером для пула подключений для гибких серверных экземпляров Azure Database для PostgreSQL.

Корпорация Майкрософт опубликовала образ прокси-сервера на стороне PgBouncer в реестре контейнеров Майкрософт.

Дополнительные сведения см. в этой статье.

Ниже приведены некоторые основные преимущества и ограничения этого метода развертывания.

Преимущества:

• Сокращение задержки: При развертывании PgBouncer в качестве сайдкара в AKS взаимодействие между основным приложением и пулером соединений становится бесперебойным и эффективным благодаря их близкому расположению. Развертывание PgBouncer в качестве sidecar-контейнера в AKS минимизирует задержки и обеспечивает стабильную и быструю работу.
• Упрощенное управление и развертывание. Тесное взаимодействие PgBouncer с контейнером приложения упрощает процесс управления и развертывания. Оба компонента тесно интегрированы, что позволяет упростить администрирование и простую координацию.
• Высокая доступность и отказоустойчивость подключений: в случае сбоя или перезапуска контейнера приложения sidecar-контейнер PgBouncer перезапускается вслед за ним, что обеспечивает высокую доступность. Такая конфигурация гарантирует отказоустойчивость соединения и поддерживает предсказуемую производительность даже при аварийном переключении, повышая надежность и устойчивость системы.

Учитывая PgBouncer в качестве бокового автомобиля AKS, вы можете использовать эти преимущества для повышения производительности приложения, упрощения управления и обеспечения непрерывной доступности пула подключений.

Limitations:

• Проблемы с производительностью подключения: крупномасштабные приложения, использующие тысячи модулей pod, каждый запущенный боковик PgBouncer, могут столкнуться с потенциальными проблемами, связанными с исчерпанием подключения к базе данных. Эта ситуация может привести к снижению производительности и нарушению работы служб. Развертывание бокового модуля PgBouncer для каждого модуля pod увеличивает количество одновременных подключений к серверу базы данных, что может превышать его емкость. В результате база данных может бороться с большим объемом входящих подключений, может привести к проблемам производительности, таким как увеличение времени отклика или даже сбоя служб.
• Сложное развертывание: Использование паттерна sidecar усложняет процесс развертывания, так как требует запуска двух контейнеров в одном pod'е. Это может усложнить устранение неполадок и отладку действий, требуя дополнительных усилий для выявления и устранения проблем.
• Проблемы масштабирования: Важно отметить, что паттерн sidecar может быть не лучшим выбором для приложений, требующих высокой масштабируемости. Использование sidecar-контейнера может повысить требования к ресурсам, тем самым потенциально ограничивая количество подов, которые можно эффективно создавать и которыми можно управлять.

При рассмотрении паттерна sidecar важно тщательно оценить компромисс между сложностью развертывания и требованиями к масштабируемости, чтобы выбрать наиболее подходящий вариант для конкретного сценария использования вашего приложения.

2. Независимое от приложения — централизованное развертывание PgBouncer

При использовании этого подхода PgBouncer развертывается как централизованная служба независимо от приложения. Служба PgBouncer может быть развернута на традиционных виртуальных машинах или в архитектуре на основе микрослужб, как выделено:

I. PgBouncer, развернутый на виртуальной машине Ubuntu за балансировщиком нагрузки Azure

Прокси-сервер подключений PgBouncer развернут между уровнем приложения и уровнем базы данных за Azure Load Balancer, как показано на рисунке. В этой архитектуре несколько экземпляров PgBouncer развертываются за балансировщиком нагрузки в виде сервиса, чтобы избежать единой точки отказа. Этот шаблон также подходит в случаях, когда приложение работает в управляемом сервисе, таком как приложение Azure Service или Функции Azure, и подключается к службе PgBouncer для удобной интеграции с существующей инфраструктурой.

См. ссылку на установку и настройку прокси-сервера пула подключений PgBouncer с помощью гибкого экземпляра сервера Базы данных Azure для PostgreSQL.

Ниже приведены некоторые основные преимущества и ограничения этого метода развертывания.

Преимущества:

• Устранение единой точки отказа: на подключение приложения может не повлиять отказ одной виртуальной машины PgBouncer, поскольку за Azure Load Balancer находятся несколько экземпляров PgBouncer.
• Простая интеграция с управляемыми службами. Если приложение размещено на управляемой платформе служб, таких как службы приложение Azure или Функции Azure, развертывание PgBouncer на виртуальной машине позволяет легко интегрироваться с существующей инфраструктурой.
• Упрощенная настройка на виртуальной машине Azure. Если приложение уже запущено на виртуальной машине Azure, настройка PgBouncer на той же виртуальной машине проста. Развертывание PgBouncer на виртуальной машине гарантирует, что PgBouncer развертывается в близком расположении к приложению, минимизируя задержку сети и максимизируя производительность.
• Конфигурация без внесения изменений: Развернув PgBouncer на виртуальной машине, можно избежать изменения параметров экземпляра гибкого сервера База данных Azure для PostgreSQL. Это полезно, если вы хотите настроить PgBouncer на экземпляре гибкого сервера База данных Azure для PostgreSQL. Например, изменение параметра SSLMODE на "обязательно" в гибком экземпляре сервера Базы данных Azure для PostgreSQL может привести к сбою некоторых приложений, использующих SSLMODE=FALSE. Развертывание PgBouncer на отдельной виртуальной машине позволяет поддерживать конфигурацию сервера по умолчанию при использовании преимуществ PgBouncer.

Учитывая эти преимущества, развертывание PgBouncer на виртуальной машине предлагает удобное и эффективное решение для повышения производительности и совместимости приложения, работающего в инфраструктуре Azure.

Limitations:

• Затраты на управление. При установке PgBouncer на виртуальной машине может потребоваться управление несколькими файлами конфигурации. Это затрудняет работу с обновлениями версий, новыми выпусками и обновлениями продукта.
• Соответствие функций: Если вы мигрируете с традиционного сервера PostgreSQL на адаптивный экземпляр сервера базы данных Azure для PostgreSQL и используете PgBouncer, могут возникнуть некоторые функциональные ограничения. Например, отсутствие поддержки md5 в Базе данных Azure для PostgreSQL.

II. Централизованный PgBouncer, развернутый в виде сервиса в AKS

Если вы работаете с крупномасштабными контейнеризированными развертываниями в Azure Kubernetes Service (AKS), состоящими из сотен подов, или в ситуациях, когда нескольким приложениям необходимо подключаться к общей базе данных, PgBouncer можно использовать как автономную службу, а не как sidecar-контейнер.

Используя PgBouncer в качестве отдельной службы, вы можете эффективно управлять пулом подключений для приложений в более широком масштабе. Этот подход позволяет централизованно использовать функции пула подключений, что позволяет нескольким приложениям подключаться к одному ресурсу базы данных при сохранении оптимальной производительности и использования ресурсов.

Образ sidecar-прокси PgBouncer, опубликованный в реестре контейнеров Microsoft, можно использовать для создания и развертывания службы.

Ниже приведены некоторые основные преимущества и ограничения этого метода развертывания.

Преимущества:

• Улучшенная надежность. Развертывание PgBouncer в качестве автономной службы позволяет настроить высокодоступную конфигурацию. Это повышает общую надежность инфраструктуры пулов подключений, обеспечивая непрерывную доступность даже при сбоях или нарушениях.
• Оптимальное использование ресурсов: если приложение или сервер базы данных имеют ограниченные ресурсы, то можно выбрать отдельный компьютер, выделенный для запуска службы PgBouncer . Развернув PgBouncer на машине с достаточными ресурсами, вы сможете обеспечить оптимальную производительность и избежать конфликтов за ресурсы.
• Централизованное управление подключениями. При централизованном управлении подключения к базе данных является требованием, автономная служба PgBouncer обеспечивает более упрощенный подход. Консолидируя задачи управления подключениями в централизованную службу, вы можете эффективно отслеживать и контролировать подключения к базе данных в нескольких приложениях, упрощая администрирование и обеспечивая согласованность.

Учитывая PgBouncer в качестве автономной службы в AKS, вы можете использовать эти преимущества для повышения надежности, эффективности ресурсов и централизованного управления подключения к базе данных.

Limitations:

• Увеличение задержки N/W. При развертывании PgBouncer в качестве автономной службы важно учитывать потенциальное введение дополнительной задержки. Это связано с необходимостью передавать подключения между приложением и службой PgBouncer по сети. Важно оценить требования к задержке приложения и рассмотреть компромиссы между централизованным управлением подключениями и потенциальными проблемами задержки.

Хотя PgBouncer , работающий в качестве автономной службы, предлагает такие преимущества, как централизованное управление и оптимизация ресурсов, важно оценить влияние потенциальной задержки на производительность вашего приложения, чтобы обеспечить соответствие конкретным требованиям.

3. PgBouncer, встроенный в Базу данных Azure для PostgreSQL

База данных Azure для PostgreSQL предлагает PgBouncer в качестве встроенного решения для пула подключений. Это предлагается в качестве необязательной службы, которая может быть включена на каждом сервере базы данных. PgBouncer работает на той же виртуальной машине, что и экземпляр гибкого сервера База данных Azure для PostgreSQL. Поскольку число подключений превышает несколько сотен или тысяч, База данных Azure для PostgreSQL может столкнуться с ограничениями ресурсов. В таких случаях встроенный PgBouncer может обеспечить значительное преимущество путем улучшения управления неактивными и короткими подключениями на сервере базы данных.

См. ссылку, чтобы включить и настроить пул подключений PgBouncer в Базе данных Azure для PostgreSQL.

Ниже приведены некоторые основные преимущества и ограничения этого метода развертывания.

Преимущества:

• Простая конфигурация: С помощью встроенного PgBouncer в гибком экземпляре сервера Базы данных Azure для PostgreSQL нет необходимости в отдельной установке или сложной установке. Его можно легко настроить прямо в параметрах, что обеспечивает удобство использования.
• Удобство использования управляемой службы: Как управляемая служба, она позволяет пользователям воспользоваться преимуществами других управляемых служб Azure. Это включает в себя автоматическое обновление, устранение необходимости обслуживания вручную и обеспечение актуальности PgBouncer с последними функциями и исправлениями безопасности.
• Поддержка общедоступных и частных подключений: Встроенный PgBouncer в гибком экземпляре сервера Базы данных Azure для PostgreSQL обеспечивает поддержку общедоступных и частных подключений. Это позволяет пользователям устанавливать безопасные подключения через частные сети или подключаться внешне в зависимости от их требований.
• Высокая доступность (HA): В случае переключения при отказе, когда резервный сервер переводится в роль основного, PgBouncer без перебоев перезапускается на этом новом основном сервере без каких-либо изменений в строке подключения приложения. Это обеспечивает непрерывную доступность и сводит к минимуму нарушения работы приложения.
• Экономично: это экономично, так как пользователям не нужно платить за дополнительные вычислительные ресурсы, такие как виртуальная машина или контейнеры, хотя он имеет некоторое влияние на ЦП, так как это другой процесс, выполняемый на том же компьютере.

В гибком экземпляре сервера Azure Database для PostgreSQL со встроенным PgBouncer пользователи могут наслаждаться удобством упрощенной конфигурации, надежностью управляемой службы, поддержкой различных режимов пулинга и простой высокой доступностью во время сценариев отработки отказа.

Limitations:

• Не поддерживается с уровнем Burstable:PgBouncer в настоящее время не поддерживается для уровня вычислительных ресурсов сервера Burstable. Если вы измените уровень вычислений с «Общего назначения» или «Оптимизированного для памяти» на уровень Burstable, вы потеряете возможность использования PgBouncer.
• Повторное установление подключений после перезапуска: Каждый раз, когда сервер перезапускается во время операций масштабирования, аварийного переключения высокой доступности или обычного перезапуска, PgBouncer также перезапускается вместе с виртуальной машиной сервера. Поэтому необходимо повторно установить существующие подключения.

Мы обсудили различные способы реализации PgBouncer и в таблице приведены сведения о том, какой метод развертывания следует выбрать:

Критерии выбора	PgBouncer на виртуальной машине приложения	PgBouncer на виртуальной машине с помощью ALB*	PgBouncer в sidecar-контейнере AKS	PgBouncer как услуга	PgBouncer, встроенный в Azure Database для PostgreSQL
Упрощенное управление
Высокая доступность
Контейнерные приложения
Снижение сетевых накладных расходов и задержки
Точное управление мониторингом и отладкой

Условные обозначения

Уровень сложности	Символ
Easy
Средний
Сложно

*ALB: Azure Load Balancer.