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

ОБЛАСТЬ ПРИМЕНЕНИЯ: База данных Azure для PostgreSQL — гибкий сервер

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

Введение

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

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

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

Что такое PgBouncer?

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

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

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

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

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

1. Развертывание совместного размещения приложений и PgBouncer

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

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

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

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

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

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

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

Ограничения:

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

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

II. PgBouncer, развернутый в качестве бокового автомобиля AKS

Можно использовать PgBouncer в качестве контейнера на стороне, если приложение контейнеризировано и работает на Служба Azure Kubernetes (AKS), экземпляре контейнеров Azure (ACI), приложениях контейнеров Azure (ACA) или Azure Red Hat OpenShift (ARO). Шаблон бокового автомобиля рисует свое вдохновение из концепции бокового автомобиля, присоединенного к мотоциклу, где вспомогательный контейнер, известный как контейнер бокового автомобиля, прикрепляется к родительскому приложению. Этот шаблон дополняет родительское приложение, расширяя функциональные возможности и предоставляя дополнительную поддержку.

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

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

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

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

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

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

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

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

Ограничения:

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

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

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

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

I. PgBouncer, развернутый в виртуальной машине ubuntu за Azure Load Balancer

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

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

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

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

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

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

Ограничения:

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

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

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

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

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

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

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

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

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

Ограничения:

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

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

3. Встроенный PgBouncer на гибком сервере База данных Azure для PostgreSQL

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

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

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

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

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

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

Ограничения:

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

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

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

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

Уровень сложности	Символ
Легко
Средняя
Сложно

*ALB: Azure Load Balancer.