운영 환경 Postgres 점검 체크리스트

운영 환경의 Postgres에서 문제가 터지면 난장판이 된다. 데이터 손실, 응답 지연, 또는 완전한 서비스 중단까지 가능하다.

먼저 마이그레이션이 모두 적용됐는지 확인한다

npx prisma migrate status

"All migrations have been successfully applied" 메시지가 나와야 정상이다. 만약 pending migration이 있으면 반드시 배포 전에 실행해야 한다.

npx prisma migrate deploy

마이그레이션은 배포와 동시에 또는 배포 직전에 실행하되, 롤백 계획을 미리 준비해야 한다.

데이터베이스 권한을 테스트한다

운영 환경의 DB 사용자는 제한된 권한을 가질 수 있다:

# 환경 변수로 운영 DB 설정 후
export DATABASE_URL="postgresql://prod_user:password@prod-db:5432/production"

# Prisma로 권한 테스트
npx prisma db execute --stdin < test.sql

CREATE TABLE, ALTER TABLE, INSERT, UPDATE, DELETE 등의 권한이 모두 있는지 확인한다. 권한 부족이면 마이그레이션이나 쿼리 실행이 실패한다.

연결 풀 설정을 확인한다

Prisma는 CONNECTION_POOL_SIZE 환경 변수로 풀 크기를 설정한다:

export DATABASE_URL="postgresql://user:pass@db:5432/prod?schema=public&pool_size=20"

동시 연결 수를 너무 많이 설정하면 데이터베이스가 연결을 거부할 수 있다. 너무 적으면 요청 대기 시간이 길어진다.

슬로우 쿼리 로그를 활성화한다

Postgres에서 느린 쿼리를 추적한다:

ALTER SYSTEM SET log_min_duration_statement = 1000;  -- 1초 이상
SELECT pg_reload_conf();

배포 후 몇 시간 동안 로그를 보면서:

• 어떤 쿼리가 느린가
• 얼마나 자주 실행되는가
• N+1 쿼리 문제는 없는가

을 파악할 수 있다.

데이터베이스 크기와 여유 공간을 확인한다

# Postgres 클라이언트에서
SELECT pg_size_pretty(pg_database_size('production'));

스토리지가 거의 가득 차면 INSERT/UPDATE가 실패할 수 있다. 배포 전에 여유 공간을 확인해야 한다.

백업 계획을 점검한다

운영 Postgres는 자동 백업이 설정되어 있어야 한다:

1. 자동 백업 스케줄 (매일 자정 같은)
2. 백업 보관 기간 (최소 7일)
3. 백업 복구 테스트 (실제로 복구 가능한가)

백업이 있어야 데이터 손실 시 복구할 수 있다.

WAL(Write-Ahead Logging) 설정을 확인한다

SHOW wal_level;  -- replica 이상이어야 함
SHOW max_wal_senders;  -- 복제가 필요하면 0 이상

WAL 설정이 잘못되면 복제나 백업이 제대로 작동하지 않는다.

운영 배포 후 모니터링 계획

배포 직후 1시간 동안:

1. 데이터베이스 연결 수
2. 쿼리 실행 시간
3. 에러 로그
4. 디스크 사용량

을 계속 모니터링한다. 비정상이 보이면 즉시 대응해야 한다.

롤백 계획을 미리 작성한다

마이그레이션이 실패하거나 성능이 나빠졌을 때:

# 이전 마이그레이션으로 돌리는 방법
npx prisma migrate resolve --rolled-back <migration_name>

또는 데이터베이스 스냅샷에서 복구하는 방법도 있다. 미리 계획해두면 문제 발생 시 신속히 대응할 수 있다.