PostgreSQL 최적화 설정과 MSA 아키텍처에서의 전략적 활용

📌 1. 서론 — 왜 PostgreSQL 최적화가 중요한가

MSA 환경에서는 서비스 수가 늘어나면서 DB는 단순 저장소가 아니라 병목의 중심이 된다.
특히 PostgreSQL은 강력하지만, 기본 설정 그대로 쓰면 성능을 못 뽑는다.

👉 결론 먼저:

• PostgreSQL 성능 = 설정 + 쿼리 + 아키텍처
• MSA에서는 DB 튜닝이 아니라 DB 전략 설계까지 포함된다

---

📌 2. PostgreSQL 핵심 최적화 설정

2.1 메모리 튜닝 (가장 영향 큼)

 

shared_buffers = 25% of RAM
work_mem = 16MB ~ 64MB
maintenance_work_mem = 256MB ~ 1GB
effective_cache_size = 50~75% of RAM

 

✔ 핵심 포인트

• shared_buffers: DB 캐시 → 너무 작으면 디스크 IO 폭발
• work_mem: 정렬/조인 → 쿼리 성능 직결
• effective_cache_size: 옵티마이저 판단 기준

👉 실무 기준:

• shared_buffers 8GB 이상이면 대부분 충분
• work_mem 과도 설정하면 커넥션 수 × 메모리 터짐

---

2.2 WAL / 체크포인트 튜닝

 

wal_buffers = 16MB
checkpoint_completion_target = 0.9
max_wal_size = 2GB ~ 8GB
min_wal_size = 1GB

 

✔ 핵심 포인트

• WAL은 쓰기 성능 핵심
• checkpoint 자주 발생하면 성능 급락

👉 실무 기준:

• TPS 높은 시스템 → WAL 튜닝 필수
• 특히 결제/정산 시스템에서 중요

---

2.3 커넥션 관리 (MSA에서 매우 중요)

 

max_connections = 100~300

 

👉 하지만 진짜 핵심은:

✔ PgBouncer 사용

이유

• MSA → 서비스 수 많음 → DB 커넥션 폭증
• PostgreSQL은 커넥션 비용이 비쌈

👉 결론:

• max_connections 늘리는 게 아니라
• connection pool 계층 추가가 정답

---

2.4 Autovacuum 튜닝

 

autovacuum = on
autovacuum_max_workers = 5
autovacuum_naptime = 10s

 

✔ 핵심 포인트

• PostgreSQL은 MVCC 구조 → dead tuple 발생
• vacuum 안 돌면 성능 계속 떨어짐

👉 실무 팁:

• 대용량 테이블은 manual vacuum 전략 필요

---

2.5 인덱스 전략

✔ 필수

• B-tree (기본)
• Partial Index
• Composite Index

✔ 고급

• GIN (Full-text / JSONB)
• BRIN (대용량 로그 테이블)

👉 실무 핵심:

• 인덱스 = 성능이 아니라 쓰기 비용과 트레이드오프

---

📌 3. MSA에서 PostgreSQL의 역할 변화

MSA에서는 DB가 단순 저장소가 아니라
👉 서비스 경계(boundary)의 핵심 요소

---

3.1 Database per Service

구조

User Service → user_db
Order Service → order_db
Payment Service → payment_db

 

✔ 장점

• 서비스 독립성 확보
• 장애 격리
• 스키마 충돌 없음

✔ 단점

• 데이터 조인 불가
• 분산 트랜잭션 필요

---

3.2 스키마 분리 vs DB 분리

방식특징

DB 분리	완전 격리, 운영비 증가
Schema 분리	비용 절감, 격리 약함

👉 실무 기준:

• 초기: schema 분리
• 확장: DB 분리

---

3.3 트랜잭션 전략 변화

MSA에서는 ACID 대신:

👉 Eventually Consistent

사용 패턴

• Saga Pattern
• Outbox Pattern
• Event-driven (Kafka)

---

📌 4. PostgreSQL + MSA 조합의 장점

4.1 강력한 JSON 지원

 

SELECT data->>'name' FROM users;

 

👉 장점:

• 스키마 유연성 확보
• NoSQL 일부 대체 가능

---

4.2 확장성 (Extension)

• pg_stat_statements → 쿼리 분석
• PostGIS → 위치 기반
• TimescaleDB → 시계열

👉 즉:

• PostgreSQL = 단순 RDB가 아니라 플랫폼

---

4.3 Read Replica 전략

Primary → Write
Replica → Read

 

👉 MSA에서:

• 조회 서비스 분리 가능
• CQRS 구조에 적합

---

📌 5. 실무 아키텍처 예시

[API Gateway]
↓
[Service Layer]
├ auth-service → PostgreSQL (auth_db)
├ order-service → PostgreSQL (order_db)
├ payment-service → PostgreSQL (payment_db)
↓
[PgBouncer]
↓
[PostgreSQL Cluster]
├ Primary
├ Replica 1
├ Replica 2

 

---

📌 6. 결론 — PostgreSQL은 설정이 아니라 전략이다

정리하면:

✔ 단일 서비스:

• 튜닝 중심 (메모리, WAL, 인덱스)

✔ MSA:

• 설계 중심 (DB 분리, 트랜잭션 전략, 커넥션 관리)

---

📌 핵심 한 줄

👉 “PostgreSQL 성능은 설정이 아니라 아키텍처에서 결정된다”