Strategia buforowania połączeń przy użyciu narzędzia PgBouncer na serwerze elastycznym Azure Database for PostgreSQL

Ten artykuł zawiera strategiczne wskazówki dotyczące wybierania mechanizmu buforowania połączeń dla serwerów elastycznych Azure Database for PostgreSQL.

Wprowadzenie

W przypadku korzystania z serwera elastycznego Azure Database for PostgreSQL połączenie z bazą danych jest tworzone przez ustanowienie kanału komunikacyjnego między aplikacją kliencką a serwerem. Ten kanał zarządza danymi, wykonuje zapytania i inicjuje transakcje. Po nawiązaniu połączenia aplikacja kliencka może wysyłać polecenia do serwera i odbierać odpowiedzi. Jednak utworzenie nowego połączenia dla każdej operacji może spowodować problemy z wydajnością aplikacji o znaczeniu krytycznym. Za każdym razem, gdy tworzysz nowe połączenie, Azure Database for PostgreSQL rozpoczyna nowy proces przy użyciu procesu postmaster, który zużywa więcej zasobów.

Aby rozwiązać ten problem, użyj puli połączeń, aby utworzyć pulę połączeń, które usługa Azure Database for PostgreSQL będzie mogła ponownie wykorzystać. Gdy aplikacja lub klient żąda połączenia, jest ono pobierane z puli połączeń. Po zakończeniu sesji lub transakcji połączenie wraca do puli w celu ponownego użycia. Ponowne użycie połączeń pozwala zmniejszyć użycie zasobów i zwiększyć wydajność.

Chociaż istnieją różne narzędzia do buforowania połączeń, w tej sekcji omówiono różne strategie używania buforowania połączeń przy użyciu narzędzia PgBouncer.

Co to jest PgBouncer?

PgBouncer to wydajny moduł puli połączeń przeznaczony dla bazy danych PostgreSQL. Skraca czas przetwarzania i optymalizuje użycie zasobów podczas zarządzania wieloma połączeniami klientów z co najmniej jedną bazą danych. Narzędzie PgBouncer oferuje trzy różne tryby buforowania na potrzeby rotacji połączeń:

• Buforowanie sesji: ta metoda przypisuje połączenie serwera do aplikacji klienckiej przez cały czas trwania połączenia klienta. Gdy aplikacja kliencka się rozłącza, PgBouncer natychmiast zwraca połączenie z serwerem z powrotem do puli połączeń. Buforowanie sesji jest trybem domyślnym w open source PgBouncer. Aby uzyskać więcej informacji, zobacz Konfiguracja narzędzia PgBouncer.
• Pula transakcji: W przypadku puli transakcji połączenie z serwerem jest przypisane do aplikacji klienckiej na czas trwania transakcji. Po pomyślnym zakończeniu transakcji PgBouncer zwalnia połączenie z serwerem, dzięki czemu jest ono ponownie dostępne w puli. Buforowanie transakcji jest trybem domyślnym w wbudowanym narzędziu PgBouncer Azure Database for PostgreSQL i nie obsługuje przygotowanych transakcji.
• Buforowanie instrukcji: w przypadku buforowania instrukcji połączenie serwera jest przydzielane do aplikacji klienckiej dla każdej instrukcji. Po zakończeniu instrukcji połączenie serwera jest zwracane do puli połączeń. Transakcje z wieloma instrukcjami nie są obsługiwane w tym trybie.

Narzędzia PgBouncer można używać w trzech odrębnych wzorcach użycia:

• Wdrożenie współlokacji PgBouncera i aplikacji
• Scentralizowane wdrożenia PgBouncer niezależne od aplikacji
• Wbudowane wdrożenie narzędzia PgBouncer i bazy danych

Każdy z tych wzorców ma własne zalety i wady.

Wdrażanie PgBouncer i współlokacji aplikacji

W przypadku korzystania z tego podejścia należy wdrożyć narzędzie PgBouncer na tym samym serwerze, na którym jest hostowana aplikacja. Aplikację i narzędzie PgBouncer można wdrożyć na tradycyjnych maszynach wirtualnych lub w architekturze opartej na mikrousługach, jak wyróżniono:

Narzędzie PgBouncer wdrożone na maszynie wirtualnej aplikacji

Jeśli aplikacja działa na maszynie wirtualnej platformy Azure, możesz skonfigurować narzędzie PgBouncer na tej samej maszynie wirtualnej. Aby zainstalować i skonfigurować PgBouncer jako serwer proxy puli połączeń dla serwera elastycznego Azure Database for PostgreSQL, zobacz Instrukcje instalacji i konfiguracji serwera proxy puli połączeń PgBouncer.

Wdrażanie narzędzia PgBouncer na serwerze aplikacji może zapewnić kilka zalet, zwłaszcza podczas pracy z elastycznymi bazami danych serwera usługi Azure Database for PostgreSQL. Oto niektóre z najważniejszych korzyści i ograniczeń tej metody wdrażania:

Korzyści:

• Mniejsze opóźnienie: Dzięki wdrożeniu narzędzia PgBouncer na tej samej maszynie wirtualnej aplikacji komunikacja między podstawową aplikacją a modułem puli połączeń jest wydajna ze względu na ich bliskość. Wdrażanie narzędzia PgBouncer na maszynie wirtualnej aplikacji minimalizuje opóźnienia i zapewnia bezproblemowe i szybkie interakcje.
• Ulepszone zabezpieczenia:Narzędzie PgBouncer może pełnić rolę bezpiecznego pośrednika między aplikacją a bazą danych, zapewniając dodatkową warstwę zabezpieczeń. Może wymuszać uwierzytelnianie i szyfrowanie, zapewniając, że tylko autoryzowani klienci mogą uzyskiwać dostęp do bazy danych.

Ogólnie rzecz biorąc, wdrażanie narzędzia PgBouncer na serwerze aplikacji zapewnia wydajniejsze, bezpieczne i skalowalne podejście do zarządzania połączeniami z elastycznymi bazami danych serwera usługi Azure Database for PostgreSQL, zwiększając wydajność i niezawodność aplikacji.

Limitations:

• Pojedynczy punkt awarii: Jeśli wdrożysz narzędzie PgBouncer jako pojedyncze wystąpienie na serwerze aplikacji, stanie się to potencjalnym pojedynczym punktem awarii. Jeśli instancja PgBouncer ulegnie awarii, może zakłócić działanie całej puli połączeń z bazą danych, powodując niedostępność aplikacji. Aby ograniczyć skutki tego pojedynczego punktu awarii, skonfiguruj wiele instancji PgBouncera za modułem równoważenia obciążenia, aby zapewnić wysoką dostępność.
• Ograniczona skalowalność: skalowalność narzędzia PgBouncer zależy od pojemności serwera, na którym jest wdrożony. Jeśli serwer aplikacji osiągnie limit połączenia, narzędzie PgBouncer może stać się wąskim gardłem, ograniczając możliwość skalowania aplikacji. Może być konieczne rozłożenie obciążenia połączenia między wieloma wystąpieniami narzędzia PgBouncer lub rozważ alternatywne rozwiązania, takie jak buforowanie połączeń na poziomie aplikacji.
• Złożoność konfiguracji: Konfigurowanie i dostrajanie narzędzia PgBouncer może być złożone, szczególnie w przypadku uwzględniania czynników, takich jak limity połączeń, ustalanie rozmiaru puli i równoważenie obciążenia. Administratorzy muszą dokładnie dostosować konfigurację narzędzia PgBouncer do wymagań aplikacji i zapewnić optymalną wydajność i stabilność.

Należy rozważyć te ograniczenia dotyczące korzyści i ocenić, czy narzędzie PgBouncer jest właściwym wyborem dla określonej aplikacji i konfiguracji bazy danych.

PgBouncer wdrożony jako sidecar w AKS

Narzędzie PgBouncer można użyć jako kontenera przyczepki, jeśli aplikacja jest konteneryzowana i uruchomiona na Azure Kubernetes Service (AKS), Azure Container Instance (ACI), Azure Container Apps (ACA) lub Azure Red Hat OpenShift (ARO). Wzór przyczepki czerpie inspirację z koncepcji przyczepki, która dołącza się do motocykla. Kontener pomocniczy, znany jako kontener przyczepki, jest dołączony do aplikacji nadrzędnej. Ten wzorzec wzbogaca aplikację nadrzędną, rozszerzając jej funkcje i zapewniając dodatkową pomoc techniczną.

Wdrażanie narzędzia PgBouncer w przyczepce usługi AKS ściśle łączy cykle życia aplikacji i przyczepki oraz udostępnia zasoby, takie jak nazwa hosta i sieć, aby efektywnie korzystać z zasobów. Kontener pomocniczy PgBouncer działa obok kontenera aplikacji w tym samym podzie usługi Azure Kubernetes Service (AKS) w relacji 1:1, pełniąc funkcję proxy puli połączeń dla serwerów Azure Database for PostgreSQL — Flexible Server.

Microsoft udostępnia obraz pomocniczego serwera proxy typu PgBouncer sidecar w rejestrze kontenerów firmy Microsoft.

Aby uzyskać więcej informacji, zapoznaj się z tym tematem.

Oto niektóre z najważniejszych korzyści i ograniczeń tej metody wdrażania:

Korzyści:

• Niższe opóźnienia: dzięki wdrożeniu PgBouncer jako sidecara w AKS komunikacja między główną aplikacją a menedżerem puli połączeń jest płynna i wydajna dzięki ich bliskości. Wdrożenie PgBouncer jako kontenera sidecar w AKS minimalizuje opóźnienia i zapewnia płynne oraz szybkie działanie.
• Uproszczone zarządzanie i wdrażanie: ścisłe sprzężenie narzędzia PgBouncer z kontenerem aplikacji upraszcza proces zarządzania i wdrażania. Oba składniki są ściśle zintegrowane, dzięki czemu można je łatwiej administrować i bezproblemowo je koordynować.
• Wysoka dostępność i odporność połączeń: Jeśli wystąpi awaria kontenera aplikacji lub zostanie on ponownie uruchomiony, kontener sidecar PgBouncer podąża za nim, co zapewnia wysoką dostępność. Ta konfiguracja gwarantuje odporność połączenia i utrzymuje przewidywalną wydajność nawet podczas pracy w trybie failover, przyczyniając się do niezawodnego i niezawodnego systemu.

Biorąc pod uwagę usługę PgBouncer jako przyczepkę usługi AKS, możesz użyć tych zalet, aby zwiększyć wydajność aplikacji, usprawnić zarządzanie i zapewnić ciągłą dostępność modułu puli połączeń.

Limitations:

• Problemy z wydajnością połączeń: Aplikacje na dużą skalę, które korzystają z tysięcy zasobników, z których każdy ma uruchomiony kontener sidecar PgBouncer, mogą napotkać problemy związane z wyczerpaniem puli połączeń z bazą danych. Taka sytuacja może spowodować obniżenie wydajności i przerwy w działaniu usługi. Wdrożenie sidecara PgBouncer dla każdego poda zwiększa liczbę jednoczesnych połączeń z serwerem bazy danych, co może przekroczyć jego możliwości. W związku z tym baza danych może mieć trudności z obsługą dużej liczby połączeń przychodzących, co prowadzi do problemów z wydajnością, takich jak zwiększone czasy odpowiedzi, a nawet awarie usługi.
• Złożone wdrożenie: wykorzystanie wzorca sidecar wprowadza dodatkową złożoność do procesu wdrażania, ponieważ obejmuje uruchamianie dwóch kontenerów w obrębie tego samego poda. Ta złożoność może potencjalnie komplikować rozwiązywanie problemów i debugowanie działań, co wymaga dodatkowego wysiłku w celu zidentyfikowania i rozwiązania problemów.
• Wyzwania związane ze skalowaniem: Wzorzec przyczepki może nie być idealnym wyborem dla aplikacji wymagających wysokiej skalowalności. Uwzględnienie kontenera sidecar może zwiększyć wymagania dotyczące zasobów, co może ograniczyć liczbę zasobników, które można skutecznie tworzyć i którymi można zarządzać.

Biorąc pod uwagę ten wzorzec przyczepki, dokładnie oceń kompromisy między złożonością wdrożenia i wymaganiami dotyczącymi skalowalności, aby określić najbardziej odpowiednie podejście dla konkretnego scenariusza aplikacji.

Niezależne od aplikacji — scentralizowane wdrożenie narzędzia PgBouncer

W przypadku korzystania z tego podejścia należy wdrożyć narzędzie PgBouncer jako scentralizowaną usługę, która jest niezależna od aplikacji. Usługę PgBouncer można wdrożyć na tradycyjnych maszynach wirtualnych lub w architekturze opartej na mikrousługach, jak pokazano w poniższych sekcjach:

PgBouncer wdrożony na maszynie wirtualnej Ubuntu za modułem równoważenia obciążenia Azure

Skonfiguruj serwer proxy połączeń PgBouncer między warstwą aplikacji a warstwą bazy danych za modułem równoważenia obciążenia Azure, jak pokazano na poniższej ilustracji. W tym wzorcu wdraża się wiele instancji PgBouncer za mechanizmem równoważenia obciążenia jako usługę, aby ograniczyć ryzyko wystąpienia pojedynczego punktu awarii. Ten wzorzec jest również odpowiedni w scenariuszach, w których aplikacja działa w usłudze zarządzanej, takiej jak aplikacja systemu Azure Services lub Azure Functions, oraz łączy się z usługą PgBouncer w celu łatwej integracji z istniejącą infrastrukturą.

Aby zainstalować i skonfigurować serwer proxy puli połączeń PgBouncer dla elastycznych serwerów Azure Database for PostgreSQL, zobacz Kroki instalacji i konfiguracji serwera proxy puli połączeń PgBouncer.

Oto niektóre z najważniejszych korzyści i ograniczeń tej metody wdrażania:

Korzyści:

• Eliminacja pojedynczego punktu awarii: Na łączność aplikacji nie wpływa awaria pojedynczej maszyny wirtualnej PgBouncer, ponieważ kilka wystąpień PgBouncer jest obsługiwanych przez usługę Azure Load Balancer.
• Bezproblemowa integracja z usługami zarządzanymi: jeśli aplikacja jest hostowana na zarządzanej platformie usług, takiej jak usługi aplikacja systemu Azure lub Azure Functions, wdrożenie narzędzia PgBouncer na maszynie wirtualnej umożliwia łatwą integrację z istniejącą infrastrukturą.
• Uproszczona konfiguracja na maszynie wirtualnej platformy Azure: jeśli aplikacja jest już uruchomiona na maszynie wirtualnej platformy Azure, konfigurowanie narzędzia PgBouncer na tej samej maszynie wirtualnej jest proste. Wdrożenie narzędzia PgBouncer na maszynie wirtualnej zapewnia, że narzędzie PgBouncer jest wdrażane w bliskiej odległości od aplikacji, minimalizując opóźnienie sieci i maksymalizując wydajność.
• Konfiguracja nieinwazyjna: Wdrażając PgBouncer na maszynie wirtualnej, można uniknąć zmiany parametrów w usłudze Azure Database for PostgreSQL — Flexible Server. Ta konfiguracja jest przydatna, gdy chcesz skonfigurować narzędzie PgBouncer na serwerze elastycznym Azure Database for PostgreSQL. Na przykład zmiana parametru SSLMODE na "wymagane" na serwerze Azure Database for PostgreSQL elastycznym może spowodować niepowodzenie niektórych aplikacji korzystających z protokołu SSLMODE=FALSE. Wdrażanie narzędzia PgBouncer na oddzielnej maszynie wirtualnej umożliwia zachowanie domyślnej konfiguracji serwera podczas korzystania z korzyści narzędzia PgBouncer.

Biorąc pod uwagę te korzyści, wdrożenie narzędzia PgBouncer na maszynie wirtualnej oferuje wygodne i wydajne rozwiązanie zwiększające wydajność i zgodność aplikacji działającej w infrastrukturze platformy Azure.

Limitations:

• Obciążenie związane z zarządzaniem: Podczas instalowania narzędzia PgBouncer na maszynie wirtualnej może istnieć obciążenie związane z zarządzaniem wieloma plikami konfiguracji. Ta konfiguracja utrudnia radzenie sobie z uaktualnieniami wersji, nowymi wersjami i aktualizacjami produktów.
• Parzystość funkcji: Jeśli przeprowadzasz migrację z tradycyjnego programu PostgreSQL do serwera elastycznego Azure Database for PostgreSQL i korzystasz z narzędzia PgBouncer, mogą istnieć pewne luki w funkcjach. Na przykład brak obsługi oprogramowania md5 w usłudze Azure Database for PostgreSQL.

Scentralizowany PgBouncer wdrożony jako usługa w ramach AKS

Jeśli pracujesz z wysoce skalowalnymi i dużymi wdrożeniami konteneryzowanymi na Azure Kubernetes Service (AKS), składającymi się z setek zasobników lub w sytuacjach, gdy wiele aplikacji musi łączyć się z udostępnioną bazą danych, użyj narzędzia PgBouncer jako usługi autonomicznej, a nie kontenera przyczepki.

Korzystając z narzędzia PgBouncer jako oddzielnej usługi, można wydajnie zarządzać buforowaniem połączeń i obsługiwać je dla aplikacji na szerszą skalę. Takie podejście umożliwia scentralizowanie funkcji buforowania połączeń, umożliwiając wielu aplikacjom łączenie się z tym samym zasobem bazy danych przy zachowaniu optymalnej wydajności i wykorzystania zasobów.

Użyj obrazu proxy sidecar PgBouncer opublikowanego w rejestrze kontenerów firmy Microsoft, aby utworzyć i wdrożyć usługę.

Oto niektóre z najważniejszych korzyści i ograniczeń tej metody wdrażania:

Korzyści:

• Zwiększona niezawodność: Wdrożenie narzędzia PgBouncer jako usługi autonomicznej umożliwia skonfigurowanie go w sposób wysoce dostępny. Ta konfiguracja zwiększa ogólną niezawodność infrastruktury buforowania połączeń, zapewniając ciągłą dostępność nawet w przypadku awarii lub zakłóceń.
• Optymalne wykorzystanie zasobów: Jeśli aplikacja lub serwer bazy danych mają ograniczone zasoby, korzystne może być oddzielne maszyny dedykowane do uruchamiania usługi PgBouncer . Wdrażając narzędzie PgBouncer na maszynie z dużą ilością zasobów, zapewniasz optymalną wydajność i zapobiegasz problemom z rywalizacją o zasoby.
• Scentralizowane zarządzanie połączeniami: gdy wymagane jest scentralizowane zarządzanie połączeniami bazy danych, autonomiczna usługa PgBouncer zapewnia bardziej usprawnione podejście. Konsolidując zadania zarządzania połączeniami w scentralizowaną usługę, można skutecznie monitorować i kontrolować połączenia bazy danych w wielu aplikacjach, upraszczając administrację i zapewniając spójność.

Biorąc pod uwagę usługę PgBouncer jako autonomiczną usługę w usłudze AKS, możesz użyć tych korzyści, aby uzyskać lepszą niezawodność, wydajność zasobów i scentralizowane zarządzanie połączeniami bazy danych.

Limitations:

• Zwiększone opóźnienie N/W: Podczas wdrażania narzędzia PgBouncer jako usługi autonomicznej należy rozważyć potencjalne wprowadzenie większego opóźnienia. To opóźnienie występuje, ponieważ aplikacja i usługa PgBouncer muszą przekazywać połączenia za pośrednictwem sieci. Oceń wymagania dotyczące opóźnień aplikacji i rozważ kompromis między scentralizowanym zarządzaniem połączeniami i potencjalnymi problemami z opóźnieniami.

Chociaż narzędzie PgBouncer działające jako autonomiczna usługa oferuje korzyści, takie jak scentralizowane zarządzanie i optymalizacja zasobów, oceń wpływ potencjalnego opóźnienia na wydajność aplikacji, aby upewnić się, że jest ona zgodna z konkretnymi wymaganiami.

Wbudowany program PgBouncer w Azure Database for PostgreSQL

Usługa Azure Database for PostgreSQL oferuje narzędzie PgBouncer jako wbudowane rozwiązanie do buforowania połączeń. Tę opcjonalną usługę można włączyć dla poszczególnych serwerów baz danych. Narzędzie PgBouncer działa na tej samej maszynie wirtualnej co serwer elastyczny Azure Database for PostgreSQL. Wraz ze wzrostem liczby połączeń powyżej kilkuset lub kilku tysięcy Azure Database for PostgreSQL może napotkać ograniczenia dotyczące zasobów. W takich przypadkach wbudowane narzędzie PgBouncer może zapewnić znaczącą przewagę dzięki poprawie zarządzania bezczynnością i krótkotrwałych połączeń na serwerze bazy danych.

Aby dowiedzieć się, jak włączyć i skonfigurować buforowanie połączeń PgBouncer w Azure Database for PostgreSQL, zobacz PgBouncer na serwerze elastycznym Azure Database for PostgreSQL.

Oto niektóre z najważniejszych korzyści i ograniczeń tej metody wdrażania:

Korzyści:

• Bezproblemowa konfiguracja: Korzystając z wbudowanego narzędzia PgBouncer na serwerze elastycznym Azure Database for PostgreSQL, nie potrzebujesz oddzielnej instalacji ani złożonej konfiguracji. Można go łatwo skonfigurować bezpośrednio w parametrach, co zapewnia bezproblemową obsługę.
• Wygoda usługi zarządzanej: Jako usługa zarządzana możesz korzystać z zalet innych usług zarządzanych Azure. Ta korzyść obejmuje aktualizacje automatyczne, eliminując konieczność ręcznej konserwacji i zapewniając, że narzędzie PgBouncer jest aktualne dzięki najnowszym funkcjom i poprawkom zabezpieczeń.
• Obsługa połączeń publicznych i prywatnych: Wbudowany mechanizm PgBouncer na serwerze elastycznym Azure Database for PostgreSQL zapewnia obsługę zarówno połączeń publicznych, jak i prywatnych. Ta obsługa umożliwia nawiązywanie bezpiecznych połączeń za pośrednictwem sieci prywatnych lub nawiązywanie połączenia zewnętrznego w zależności od konkretnych wymagań.
• Wysoka dostępność (HA): W przypadku przełączenia awaryjnego, w którym serwer zapasowy zostaje awansowany do roli serwera podstawowego, PgBouncer jest bezproblemowo uruchamiany ponownie na nowo awansowanym serwerze zapasowym bez konieczności wprowadzania jakichkolwiek zmian w parametrach połączenia aplikacji. Ta funkcja zapewnia ciągłą dostępność i minimalizuje zakłócenia aplikacji.
• Opłacalne: Jest to opłacalne, ponieważ nie trzeba płacić za dodatkowe obliczenia, takie jak maszyna wirtualna lub kontenery, choć ma jakiś wpływ na procesor CPU, ponieważ jest to inny proces uruchomiony na tej samej maszynie.

Korzystając z wbudowanego serwera PgBouncer w Azure Database for PostgreSQL serwera elastycznego, możesz cieszyć się wygodą uproszczonej konfiguracji, niezawodności usługi zarządzanej, obsługi różnych trybów buforowania i bezproblemowej wysokiej dostępności podczas scenariuszy trybu failover.

Limitations:

• Nieobsługiwane w warstwie obliczeniowej serwera Burstable:PgBouncer nie jest obecnie obsługiwany w warstwie obliczeniowej serwera Burstable. Jeśli zmienisz warstwę obliczeń z warstwy Ogólnego przeznaczenia lub Zoptymalizowanej pod kątem pamięci na warstwę Burstable, utracisz funkcję PgBouncer.
• Ponownie nawiązuj połączenia po restartach: Za każdym razem, gdy serwer jest uruchamiany ponownie podczas operacji skalowania, przełączania awaryjnego HA lub restartu, PgBouncer jest uruchamiany ponownie wraz z maszyną wirtualną serwera. W związku z tym należy ponownie ustanowić istniejące połączenia.

W tym artykule omówiono różne sposoby implementowania narzędzia PgBouncer. W poniższej tabeli podsumowano, którą metodę wdrażania należy wybrać:

Kryteria wyboru	Narzędzie PgBouncer na maszynie wirtualnej aplikacji	Narzędzie PgBouncer na maszynie wirtualnej przy użyciu usługi ALB*	PgBouncer w kontenerze pomocniczym na platformie AKS	PgBouncer jako usługa	Wbudowany mechanizm PgBouncer w usłudze Azure Database for PostgreSQL
Uproszczone zarządzanie
wysoka dostępność
Aplikacje konteneryzowane
Mniejsze obciążenie sieci i opóźnienie
Precyzyjna kontrola monitorowania i debugowania

Legenda

Poziom trudności	symbol
Easy
Średni
Trudne

*ALB: Azure Load Balancer.

Treści powiązane

• Serwer elastyczny PgBouncer w usłudze Azure Database for PostgreSQL
• Biblioteki połączeniowe