FrontierStack으로 Docker에서 PostgreSQL 실행 및 모니터링하기

게시일 2026-09-02

PostgreSQL은 MySQL과 다르게 장애를 일으킵니다. 느린 것은 쿼리인 경우가 드뭅니다. 누군가 열어 둔 채 방치한 트랜잭션이 잠금을 쥐고 있고, 그 뒤에서 다른 백엔드들이 얌전히 줄을 서서 기다리는 것입니다. 이 가이드는 PostgreSQL을 운영하는 방법과 그런 트랜잭션을 빠르게 찾아내는 방법을 다룹니다.

네이티브인가, 컨테이너인가

서비스 ▸ Postgres는 Homebrew와 brew services 항목으로 네이티브 설치하며, 패널에서 시작, 중지, 다시 로드를 처리합니다. PostgreSQL 하나가 그 기기를 맡는다면 이것으로 충분합니다.

컨테이너가 진가를 발휘하는 것은 버전이 필요할 때입니다. PostgreSQL 메이저 업그레이드에는 덤프와 재적재가 필요하므로, 마이그레이션하는 동안 15와 16을 나란히 실행할 수 있다는 것은 실제로 유용합니다. 네이티브로는 번거롭지만, 포트가 다른 컨테이너 두 개라면 간단합니다.

컨테이너 만들기

Docker 패널 ▸ 컨테이너 생성…에서 PostgreSQL 프리셋을 고르십시오. 다음 구성이 준비됩니다.

• 이미지 postgres:16 — 여기서는 메이저 버전을 의도적으로 고정하십시오. 재시작을 거치며 postgres:latest를 쓰다가 데이터베이스가 실수로 업그레이드되는 경우가 많습니다.
• 포트 5432, 기본적으로 127.0.0.1에만 바인딩되므로 따로 정하기 전까지는 기기 밖에서 접근할 수 없습니다.
• 볼륨 pgdata를 /var/lib/postgresql/data에 — 컨테이너는 버려도 되고 데이터는 영구히 남게 해 주는 이름 있는 볼륨입니다.
• 환경 변수 POSTGRES_PASSWORD, 비밀 값으로 표시되며 표시되는 모든 곳에서 가려집니다.

첫 번째 버전과 나란히 두 번째 버전을 실행하려면 이미지 postgres:15, 호스트 포트 5433, 그리고 다른 볼륨 이름으로 컨테이너를 하나 더 만드십시오. 데이터베이스 두 개가 충돌 없이 동작하며, 어느 쪽이든 버릴 수 있습니다.

실행하기 전에 명령을 읽으십시오

시트는 암호가 가려진 정확한 docker run 명령줄을 미리 보여 줍니다. 읽어 보거나 스크립트에 복사해 두십시오. 생성을 누르면 이미지를 가져오고, 만들고, 시작합니다. 그런 다음 컨테이너가 로그와 셸과 함께 Docker 패널에 나타납니다.

연결된 서버에서도

플릿의 어느 호스트든 대상으로 지정하면 SSH를 통해 그곳에 같은 컨테이너가 만들어집니다. 같은 작업을 반복하지 않고 스테이징 장비에 동일한 데이터베이스를 띄울 때 유용합니다.

백엔드 읽기

데이터베이스 상태는 모든 백엔드를 상태, 실행 중인 쿼리, 그 상태가 지속된 시간과 함께 나열합니다. 중요한 상태는 idle in transaction(트랜잭션을 연 채 자리를 비운 클라이언트로, 그동안 계속 잠금을 쥐고 있습니다)과 잠금을 기다리는 모든 것입니다. 둘 다 pg_stat_activity 쿼리를 기억에 의존해 작성하지 않아도 여기에 나타납니다.

명백히 문제의 원인인 백엔드는 패널에서 종료할 수 있습니다. 종료하기 전에 확인을 요청합니다.

“왜 느리거나 멈췄을까?”

진단은 실행 중인 서버를 대상으로 수행됩니다. 무엇이 실행 중인지, 무엇이 누구 때문에 막혀 있는지, 연결 한도에 얼마나 가까운지, 그리고 어떤 트랜잭션이 문제가 될 만큼 오래 열려 있는지 살펴봅니다. 결과는 순위대로 정렬되고 각 항목이 책임 있는 백엔드와 연결되므로, 답은 “무언가가 잠금을 쥐고 있다”가 아니라 “11분 전에 열린 이 트랜잭션”이 됩니다.

검사와 복구 작업도 여기서 사용할 수 있으며, 동작 및 기록 보기는 지금 이 순간의 모습뿐 아니라 서버가 어떤 추세를 보여 왔는지 차트로 보여 줍니다.

AI 관리자에게 물어보기

아니면 읽는 과정을 건너뛰십시오. “Postgres 서버에서 무언가가 쓰기를 막고 있어. 그게 뭐야?” 어시스턴트가 실행 중인 서버를 검사하고, 발견한 내용을 쉬운 말로 설명하고, 해결책을 제안합니다. 여러분의 승인 없이는 아무것도 적용하지 않습니다.

앱에서 이 기능이 있는 곳

실제 작업은 데이터베이스 ▸ 데이터베이스 상태 패널이 담당합니다. 대상을 고르면 살아 있는 연결을 모두 나열하고, 주의가 필요한 연결을 표시하며, MySQL과 PostgreSQL에 대해서는 로그로 추측하는 대신 실행 중인 서버를 대상으로 “왜 느리거나 멈췄을까?”에 답합니다.

데이터베이스 호스트에 에이전트를 설치할 필요는 없습니다. FrontierStack은 이미 사용 중인 키로 SSH를 통해 연결된 서버에 접속하고, 데이터베이스 자체의 관리 인터페이스를 통해 정보를 읽습니다.

필요해지기 전에 알림을 설정하십시오

모니터링이 쓸모 있는 순간은 무언가 고장 나기 전입니다. 플릿에 호스트를 추가하고, 데이터베이스 상태가 그 호스트를 보도록 지정한 뒤, 점검이 일정에 따라 실행되게 하십시오. 죽은 데이터베이스는 “문제 없음”이 아니라 “데이터 없음”으로 보이므로, 명시적인 알림이 있어야 조용한 장애가 실제로 받아 보는 알림으로 바뀝니다.