PostgreSQL 한 서버에 여러 인스턴스 vs 여러 DB 구조와 장단점 비교

PostgreSQL 한 서버에 여러 인스턴스 vs 여러 DB: 어떤 구성이 좋을까?

한 대의 서버에서 여러 업무 시스템의 PostgreSQL을 운영할 때는 두 가지 구성을 검토할 수 있습니다. PostgreSQL 인스턴스를 여러 개 실행하거나, 하나의 인스턴스에 업무별 데이터베이스를 만드는 방식입니다.

선택 기준은 단순한 DB 개수보다 서비스 재시작, 설정 변경, 백업 복구를 업무별로 얼마나 독립적으로 수행해야 하는가에 있습니다.

먼저 알아둘 핵심

여러 DB 구성은 관리가 간단하고 자원 활용에 유리합니다. 여러 인스턴스 구성은 업무별 운영과 장애 영향 범위를 나누는 데 유리합니다. 다만 같은 서버에서 실행하는 이상 OS·CPU·메모리·스토리지 장애까지 완전히 분리되지는 않습니다.

1. 인스턴스와 데이터베이스의 차이

이 글에서 인스턴스는 독립된 데이터 디렉터리와 서버 프로세스 집합으로 운영하는 PostgreSQL 실행 단위를 뜻합니다. 하나의 인스턴스 안에 여러 데이터베이스를 만들 수 있습니다.

PostgreSQL 공식 문서에서는 한 서버 인스턴스가 관리하는 데이터베이스 집합을 데이터베이스 클러스터라고 부릅니다. 여기서 클러스터는 여러 서버를 묶은 HA 구성을 뜻하는 용어와 구분해야 합니다. :chatgpt-content-reference{index="0"}

서버·인스턴스·DB·스키마의 구분

구분	의미	예시
서버	PostgreSQL이 실행되는 물리 서버 또는 VM	DB용 Linux VM 1대
인스턴스	독립적으로 시작·종료하는 PostgreSQL 운영 단위	PMS 인스턴스, 개인정보 인스턴스
데이터베이스	인스턴스 내부에서 업무 데이터를 논리적으로 구분하는 단위	pms, privacy
스키마	DB 내부에서 테이블·함수 등의 이름과 권한을 구분하는 단위	com, cpms, log

2. 한 서버에 여러 인스턴스를 구성하는 방식

한 서버에서 PostgreSQL을 여러 개 독립적으로 실행합니다. 각 인스턴스는 데이터 디렉터리, 설정, WAL, 접속 정보와 서비스 관리 단위를 구분합니다.

동일 서버에서 PostgreSQL 인스턴스 4개 운영 예시

인스턴스	포트	데이터 경로	업무 DB
PMS	15432	/data/pg-pms	pms
개인정보	15433	/data/pg-privacy	privacy
전자결재	15434	/data/pg-approval	approval
모니터링	15435	/data/pg-monitor	monitor

포트와 경로는 예시입니다. 실제 인스턴스에는 업무 DB 외에 기본 관리용 DB 등이 존재할 수 있습니다. 인스턴스마다 여러 업무 DB를 만드는 구성도 가능합니다.

장점

• 업무별 재시작: 개인정보 인스턴스만 재시작하고 PMS 인스턴스는 계속 운영할 수 있습니다.
• 설정 분리: shared_buffers, max_connections, WAL 및 로그 정책을 인스턴스별로 다르게 구성할 수 있습니다.
• 복구 단위 분리: 인스턴스별 물리 백업과 시점 복구 정책을 설계할 수 있습니다.
• DB 관리자 권한 분리: PostgreSQL 역할과 슈퍼유저 권한 범위가 인스턴스별로 구분됩니다.
• 버전 운영 유연성: 실행 파일과 확장 모듈, 서비스 경로를 구분하면 서로 다른 PostgreSQL 버전을 운영할 수 있습니다.

단점

• 기본 자원 사용 증가: 인스턴스마다 공유 메모리와 백그라운드 프로세스를 운영합니다.
• 관리 항목 증가: 서비스, 포트, 계정, 설정, 로그, 백업, 모니터링을 각각 관리해야 합니다.
• 자원 경쟁 지속: 같은 CPU와 디스크를 사용하면 한 인스턴스의 부하가 다른 인스턴스에 영향을 줄 수 있습니다.
• 공통 파일 의존성: 같은 PostgreSQL 실행 파일이나 확장 라이브러리를 공유하면 패키지 업데이트의 영향이 겹칠 수 있습니다.

위 장단점은 독립된 서버 프로세스와 데이터 디렉터리로 구성한다는 구조를 기준으로 한 운영상 판단입니다. PostgreSQL 시작·종료 방식은 공식 서버 기동 문서에서 확인할 수 있습니다.

3. 하나의 인스턴스에 여러 DB를 구성하는 방식

PostgreSQL 인스턴스 하나를 실행하고 내부에 업무별 DB를 생성합니다. 접속 주소와 포트는 같고, 접속할 때 DB 이름을 구분합니다.

하나의 인스턴스에 업무 DB 4개 구성 예시

접속 주소	포트	DB 이름	용도
192.0.2.10	15432	pms	업무 관리
192.0.2.10	15432	privacy	개인정보 관리
192.0.2.10	15432	approval	전자결재
192.0.2.10	15432	monitor	모니터링

장점

• 운영 단순화: 서비스와 주요 설정, 물리 백업 체계를 하나로 관리할 수 있습니다.
• 자원 활용: 공유 버퍼와 서버 프로세스 기반을 함께 사용하므로 인스턴스별 기본 자원 할당을 줄일 수 있습니다.
• 업무 데이터 구분: DB별 소유자와 접속 권한을 설정해 업무를 논리적으로 분리할 수 있습니다.
• 개별 논리 백업: pg_dump를 사용해 필요한 DB만 백업할 수 있습니다.

단점

• 공통 재시작: 인스턴스를 재시작하면 내부 DB 전체의 연결이 영향을 받습니다.
• 핵심 설정 공유: shared_buffers와 인스턴스 전체 연결 수 한도 등을 공유합니다.
• 복구 정책 결합: WAL 기반 물리 복구는 전체 인스턴스 단위로 수행합니다.
• 관리자 권한 공유: 역할은 인스턴스 전체에 정의되며 슈퍼유저 권한이 특정 DB 하나로 제한되지 않습니다.
• 공통 버전 사용: DB마다 PostgreSQL 서버 버전을 다르게 실행할 수 없습니다.

PostgreSQL 공식 문서도 여러 DB가 WAL을 공유하고, 관리자 관점에서는 서로 밀접하게 연결된다고 설명합니다. :chatgpt-content-reference{index="1"}

4. 두 방식의 주요 차이 비교

운영 관점의 비교

비교 항목	여러 인스턴스	하나의 인스턴스에 여러 DB
분리 수준	서버 프로세스·데이터 디렉터리 분리	업무 데이터와 권한의 논리적 분리
시작·종료	인스턴스별 수행	전체 DB가 함께 영향
접속 포트	같은 IP를 사용하면 서로 다른 포트 필요	같은 포트에서 DB 이름으로 구분
설정	인스턴스별 설정	공통 설정과 DB·역할별 설정 조합
공유 버퍼	인스턴스별 할당	전체 DB가 공유
WAL	인스턴스별 분리	전체 DB가 공유
역할·슈퍼유저	인스턴스별 구분	인스턴스 전체 범위
물리 백업·PITR	인스턴스별 수행	전체 인스턴스 단위
논리 백업	DB별 가능	DB별 가능
물리 복제	인스턴스별 구성	전체 인스턴스 복제
운영 난이도	상대적으로 높음	상대적으로 낮음
서버·OS 장애	같은 서버의 모든 인스턴스에 영향 가능	전체 DB에 영향

이 표의 물리 백업·복구 범위는 PostgreSQL의 기본 백업 및 WAL 복구 방식을 기준으로 합니다. 논리 복제나 외부 관리 도구는 별도의 설계가 필요합니다. :chatgpt-content-reference{index="2"}

5. 장애 발생 시 실제로 얼마나 분리되는가?

여러 인스턴스의 효과를 판단할 때는 장애를 구분해야 합니다. 업무 SQL 오류와 PostgreSQL 인스턴스 장애, OS 장애는 영향 범위가 다릅니다.

대표적인 장애 상황 비교

상황	여러 인스턴스	여러 DB
일반 SQL 오류	보통 해당 작업 중심으로 영향	보통 해당 작업 중심으로 영향
특정 인스턴스 중지	해당 인스턴스의 DB에 영향	내부 DB 전체에 영향
공유 메모리 오염 가능성이 있는 프로세스 충돌	해당 인스턴스의 연결과 복구에 영향 가능	같은 인스턴스의 다른 DB 연결에도 영향 가능
대량 쿼리로 CPU·I/O 포화	공유 서버 자원을 통해 다른 인스턴스에 영향 가능	다른 DB에 영향 가능
공유 파일시스템 용량 부족	같은 파일시스템의 다른 인스턴스에도 영향 가능	전체 인스턴스 운영에 영향 가능
OS 중단·VM 종료	전체 인스턴스 중단	전체 DB 중단

“인스턴스 분리 = 완전한 장애 격리”는 아닙니다.

데이터 경로를 다르게 만들어도 같은 파일시스템이면 용량 부족을 공유합니다. 다른 가상디스크라도 같은 스토리지를 사용하면 I/O 병목과 스토리지 장애가 공통으로 발생할 수 있습니다.

이러한 영향 범위는 공통 자원을 사용하는 구조에서 도출되는 설계 판단입니다. 강한 격리가 필요하면 인스턴스 분리와 함께 OS 자원 제한, 별도 VM, 스토리지 구성 및 HA를 검토해야 합니다.

6. CPU와 메모리는 자동으로 나뉘지 않는다

인스턴스를 4개 만들었다고 CPU와 메모리가 자동으로 4등분되지는 않습니다. PostgreSQL 설정과 OS 자원 제어를 함께 설계해야 합니다.

여러 인스턴스의 메모리 합산

예를 들어 인스턴스 4개에 각각 shared_buffers=8GB를 설정하면 공유 버퍼 설정값의 합계만 32GB입니다. 여기에 세션 작업 메모리, 유지보수 작업, 프로세스와 OS 캐시 등을 추가로 고려해야 합니다.

work_mem은 서버 전체에서 한 번만 사용하는 메모리 한도가 아닙니다. 여러 세션의 정렬·해시 작업과 병렬 실행이 겹치면 메모리 사용량이 크게 증가할 수 있습니다. :chatgpt-content-reference{index="3"}

여러 DB에서도 일부 설정은 다르게 줄 수 있다

단일 인스턴스라고 모든 설정이 동일해야 하는 것은 아닙니다. 허용되는 매개변수는 DB별 또는 역할별로 기본값을 다르게 지정할 수 있습니다.

다음은 설정 예시입니다. 운영에 바로 적용할 권장값은 아니며, DB 기본값 변경은 새 연결부터 확인해야 합니다.

ALTER DATABASE pms SET statement_timeout = '60s';
ALTER DATABASE privacy SET statement_timeout = '30s';

다만 이런 설정으로 DB별 CPU나 메모리 총사용량을 강제로 분리할 수는 없습니다. 인스턴스별 자원 제한도 systemd와 cgroup 등의 별도 제어가 필요하며, 과도한 제한은 성능 저하나 프로세스 종료를 유발할 수 있습니다.

7. 백업과 복구에서 가장 큰 차이가 발생한다

DB별 논리 백업은 두 방식 모두 가능

pg_dump는 DB 하나를 논리 백업합니다. 역할과 테이블스페이스 같은 공통 객체는 별도로 관리해야 합니다. :chatgpt-content-reference{index="4"}

# 접속 주소와 포트는 예시
pg_dump -h 192.0.2.10 -p 15432 -U backup_user \
  -d pms -Fc -f /backup/pms.dump

WAL 기반 시점 복구는 전체 인스턴스 단위

하나의 인스턴스에 PMS와 개인정보 DB가 함께 있는 경우, 운영 인스턴스를 과거 시점으로 물리 복구하면 두 DB가 함께 해당 시점으로 돌아갑니다. 기본 PITR은 특정 DB 하나만 선택해 복구하는 방식이 아닙니다. :chatgpt-content-reference{index="5"}

PMS만 과거 데이터가 필요하다면 별도 임시 인스턴스에 전체 클러스터를 해당 시점으로 복구한 뒤, PMS 데이터만 논리적으로 추출하여 복원하는 절차를 사용할 수 있습니다. 이때 복구 공간과 시간, 다른 업무 데이터와의 정합성을 검토해야 합니다.

반면 PMS와 개인정보가 다른 인스턴스에 있다면 PMS 인스턴스의 물리 복구를 별도로 진행할 수 있습니다. 업무별 복구 시점과 보관 정책이 다를수록 여러 인스턴스 방식의 이점이 커집니다.

8. IP와 서비스 이름을 나누면 독립 구성이 되는가?

IP나 서비스 이름만 나눈다고 인스턴스가 분리되지는 않습니다. 실제 데이터 디렉터리와 서버 프로세스가 각각 독립적으로 실행되어야 합니다.

• 같은 IP에 서로 다른 포트를 사용해 여러 인스턴스를 운영할 수 있습니다.
• 서로 다른 IP에만 바인딩하면 동일한 TCP 포트를 사용하는 구성도 가능합니다.
• 같은 포트를 사용할 때는 와일드카드 주소 바인딩과 Unix 소켓 경로 충돌도 확인해야 합니다.
• 여러 IP나 DNS 이름이 같은 인스턴스를 가리키면 재시작·WAL·물리 복구 범위는 그대로 공유됩니다.

클라이언트의 연결 설정 이름이나 pg_service.conf의 서비스 별칭도 접속 정보를 묶는 기능입니다. 별칭을 만들었다고 PostgreSQL 인스턴스가 추가되지는 않습니다.

9. 계정과 보안 관리 차이

하나의 인스턴스에서는 역할이 전체 인스턴스 범위에 정의됩니다. PMS와 개인정보 DB의 소유자를 나누더라도, 슈퍼유저는 특정 DB에만 한정된 관리자가 아닙니다. :chatgpt-content-reference{index="6"}

여러 DB 구성에서는 업무별 역할을 만들고 pg_hba.conf, DB의 CONNECT 권한, 스키마 및 객체 권한을 함께 설정해야 합니다. DB를 생성하는 것만으로 업무별 접근 통제가 완성되지는 않습니다.

여러 인스턴스로 나누면 DB 관리자 권한 범위를 구분할 수 있습니다. 다만 같은 OS 계정으로 모든 인스턴스를 실행한다면 해당 계정의 파일 접근 범위도 공유될 수 있습니다. 운영체제 계정과 디렉터리 권한까지 함께 설계해야 합니다.

10. 어떤 상황에서 선택하면 좋을까?

요구사항에 따른 선택 기준

요구사항	우선 검토할 구성	이유
소규모 업무 여러 개, 운영 인력 제한	하나의 인스턴스에 여러 DB	운영과 모니터링 단순화
업무별 점검·재시작 시간 상이	여러 인스턴스	재시작 단위 분리
업무별 PITR·물리 백업 정책 상이	여러 인스턴스	복구 단위 분리
DB 관리자 권한 범위 분리	여러 인스턴스	슈퍼유저와 역할 영역 구분
여러 업무에서 대규모 배치 실행	부하 측정 후 인스턴스·자원 분리 검토	같은 서버의 자원 경쟁 고려
OS 장애에도 다른 업무 유지	별도 VM·서버와 HA 설계	공통 OS 장애 범위 제거 필요
서로 다른 PostgreSQL 버전 필요	여러 인스턴스	실행 파일·확장 모듈 관리 필요

예를 들어 PMS·개인정보·전자결재·모니터링의 재시작과 복구 정책이 서로 다르다면, 한 서버에 4개 인스턴스를 구성하는 안이 적합할 수 있습니다. 반대로 모두 같은 점검 시간과 복구 정책을 사용하고 부하가 작다면 하나의 인스턴스에 DB 4개를 만드는 방식이 운영상 효율적입니다.

“한 업무의 PostgreSQL 장애가 다른 업무로 번지는 범위를 줄인다”는 요구에는 인스턴스 분리가 도움이 됩니다. “한 업무의 어떤 장애도 다른 업무에 영향을 주지 않아야 한다”는 요구라면 서버 자원과 OS, 스토리지까지 포함한 추가 분리가 필요합니다.

11. 구축 전 확인할 항목

• 운영 단위: 업무별 재시작과 패치 일정을 따로 가져가야 하는가?
• 복구 단위: 업무별 목표 복구 시점과 복구 시간이 다른가?
• 자원: 피크 시간의 CPU·메모리·I/O를 합산해도 수용 가능한가?
• 스토리지: 경로만 다른지, 파일시스템과 용량 한도도 나누었는가?
• 권한: DB 관리자와 OS 운영 계정을 어디까지 구분할 것인가?
• 이중화: 인스턴스별 복제·장애 감지·접속 전환을 어떻게 관리할 것인가?
• 검증: 복원 테스트와 한 인스턴스의 부하가 다른 업무에 미치는 영향을 확인했는가?

운영 복잡도와 독립성 사이의 균형을 결정한 뒤 인스턴스 개수를 정하는 것이 좋습니다. 인스턴스 수를 늘리는 것만으로 성능이나 가용성이 자동으로 향상되지는 않습니다.

공식 참고문서

• PostgreSQL 데이터베이스 구조와 관리 범위
• 데이터베이스 클러스터 생성과 인스턴스 개념
• PostgreSQL 서버 기동과 관리
• 메모리 및 자원 설정
• pg_basebackup 물리 백업
• SQL 덤프와 DB별 논리 백업
• WAL 아카이빙과 시점 복구