PostgreSQL 장애 재현 테스트 2026, noisia 유해 워크로드 안전 운영 기준

PostgreSQL 장애 재현 테스트와 noisia 유해 워크로드를 격리 환경에서 점검하는 데이터베이스 테스트 장면 — 유해 워크로드 테스트는 장애를 잘 만드는 기술보다 안전하게 멈추고 복구하는 절차가 먼저다.

PostgreSQL 장애 재현 테스트를 검토한다면 먼저 운영 DB와 실험 DB를 완전히 분리했는지 확인해야 한다.

noisia는 PostgreSQL에 일부러 나쁜 워크로드를 넣어 연결 고갈, 잠금 대기, 교착 상태, 임시 파일 폭증, WAL 증가, 테이블 팽창 같은 실패 조건을 만드는 도구다.

이 도구의 README도 테스트 목적 한정 사용과 완전한 이해 없이 실행하지 말라는 주의를 앞에 둔다.

따라서 이 글의 목적은 실행 명령을 늘어놓는 것이 아니라, 어떤 장애를 어떤 격리 조건에서 재현하고 무엇을 관측한 뒤 어떻게 되돌릴지 정하는 데 있다.

핵심 요약

noisia는 벤치마크 도구가 아니라 실패 주입 도구에 가깝기 때문에 운영 DB 접속은 금지해야 한다.
pgbench는 처리량 기준선을 만들고, noisia는 잠금·WAL·연결·bloat 같은 장애 조건을 확인하는 식으로 역할을 나눈다.
실행 전에는 백업, 복구 스크립트, 시간 제한, 연결 한도, 디스크 중단 조건, 모니터 계정을 먼저 고정한다.
결과 평가는 TPS 하나가 아니라 pg_stat_activity, pg_stat_statements, WAL, temp file, replica lag, 알림 품질, 복구 시간까지 함께 본다.

이 글이 필요한 사람

PostgreSQL 운영 장애를 훈련 환경에서 재현하고 싶은 DBA와 SRE
클라우드 DB 비용과 장애 복구 시간을 줄이려는 데이터 플랫폼 책임자
락 대기, WAL 폭증, replication slot 방치, temp file 증가를 실제 지표로 보고 싶은 백엔드 리드
장애 대응 runbook과 알림 규칙이 작동하는지 검증해야 하는 운영팀
noisia 같은 도구를 발견했지만 어디까지 안전한지 판단해야 하는 보안·플랫폼팀

noisia를 벤치마크 도구처럼 쓰면 안 되는 이유

PostgreSQL 공식 문서의 pgbench는 반복 SQL을 여러 세션에서 실행하고 평균 TPS와 지연 시간을 계산하는 벤치마크 도구다.

반면 noisia는 정상 성능을 재는 것보다 시스템이 싫어하는 상태를 만들고, 관측·알림·복구 절차가 버티는지 확인하는 쪽에 가깝다.

예를 들어 deadlocks 워크로드는 교착 상태를 만들고, waitxacts는 잠금 뒤에 대기 세션을 쌓으며, tempfiles는 work_mem보다 큰 정렬로 디스크 임시 파일을 늘린다.

slot-bloat와 wal-flood는 WAL 보존과 복제 지연을 압박하므로 디스크, 아카이빙, 복제 모니터링이 약한 환경에서는 테스트 자체가 장애가 된다.

이 조건이면 noisia는 성능 수치를 예쁘게 뽑는 도구가 아니라, 이미 만든 장애 대응 체계를 흔드는 검증 장치로 봐야 한다.

noisia, pgbench, 트래픽 리플레이를 어떻게 나눌까

도구 또는 방식	주요 목적	좋은 사용 시점	주의할 리스크
pgbench	반복 트랜잭션으로 처리량과 지연 시간 기준선을 만든다	인스턴스 크기 변경, 파라미터 변경, 스토리지 비교 전후	초기화 옵션이 기존 pgbench 테이블을 지울 수 있으므로 테스트 DB를 분리해야 한다
noisia	잠금, WAL, 연결, bloat, 임시 파일 같은 실패 조건을 일부러 만든다	장애 runbook, 알림, 자동 복구, 모니터 계정 생존성을 검증할 때	무제한 실행이나 운영 DB 오접속은 인스턴스 재시작과 디스크 full로 이어질 수 있다
트래픽 리플레이	실제 애플리케이션 쿼리 패턴을 비슷하게 재현한다	릴리스 전 회귀 테스트와 캐시·인덱스 영향 평가	개인정보 마스킹과 쓰기 쿼리 격리가 없으면 보안 사고가 된다
수동 SQL 실험	특정 쿼리 계획과 인덱스 효과를 좁게 확인한다	EXPLAIN, ANALYZE, BUFFERS로 한 쿼리의 병목을 볼 때	단일 쿼리 결과를 전체 워크로드 대표값처럼 해석하면 안 된다

실무에서는 pgbench로 정상 기준선을 잡고, noisia로 실패 조건을 넣고, 트래픽 리플레이로 애플리케이션 특유의 병목을 확인하는 식이 안전하다.

한 도구에 모든 역할을 맡기면 결과 해석이 흐려진다.

특히 noisia 결과를 TPS 개선이나 클라우드 인스턴스 성능 비교 지표로 쓰면 도구의 의도와 맞지 않는다.

실행 전 격리 원칙부터 고정한다

PostgreSQL 장애 재현 테스트는 실행 명령보다 환경 검증이 먼저다.

테스트 대상은 운영 복제본도 아니고 고객 데이터가 있는 개발 공용 DB도 아니어야 한다.

가장 안전한 구조는 운영과 다른 계정, 다른 네트워크, 다른 스토리지 한도, 다른 알림 채널을 가진 스테이징 DB다.

백업과 스냅샷은 테스트 시작 전 성공 여부를 확인하고, 복구 담당자는 명령을 실행해 본 사람으로 지정한다.

모니터링 접속은 일반 애플리케이션 연결과 분리해야 한다.

waitxacts나 failconns 테스트 중 max_connections가 소진되면 앱 계정만 죽고 모니터 계정은 살아 있어야 원인과 중단 조건을 볼 수 있다.

이 경우는 보류가 맞다.

복구 절차가 문서에만 있고 실제로 실행해 본 적이 없다면 noisia부터 돌리는 대신 백업 복원과 모니터 권한 테스트를 먼저 해야 한다.

워크로드별로 관측 항목을 다르게 둔다

워크로드 묶음	재현하려는 실패	먼저 볼 지표	중단 기준
idlexacts, bloat-churn	오래 열린 트랜잭션과 과도한 UPDATE로 heap·index bloat가 커진다	pg_stat_activity, autovacuum 로그, 테이블 크기, dead tuples	테이블 크기 증가율이 기준선을 넘거나 복구 시간이 RTO를 넘길 때
waitxacts, deadlocks	잠금 대기와 교착 상태가 앱 요청을 멈춘다	wait_event_type, blocking PID, deadlock 로그, p95 latency	모니터 세션이 끊기거나 대기 세션이 연결 한도의 35%를 넘을 때
tempfiles	정렬·해시 작업이 work_mem을 넘겨 디스크 임시 파일을 만든다	temp_files, temp_bytes, log_temp_files, 스토리지 IOPS	temp_bytes 증가가 디스크 여유 공간을 압박할 때
failconns, forkconns	연결 고갈과 backend 프로세스 생성이 새 요청을 막는다	max_connections 사용률, FATAL 로그, connection pool 대기열	관리 연결이나 health check가 실패할 때
slot-bloat, wal-flood	WAL이 보존되거나 폭증해 복제 지연과 디스크 full을 만든다	pg_wal 크기, replica lag, archive 실패, checkpoint 로그	디스크 여유 비율이 25% 아래로 떨어지거나 lag가 60초를 넘을 때
backend-killer	단일 backend 메모리 증가가 OOM과 인스턴스 재시작을 유발할 수 있다	RSS, OOM 로그, restart count, plan cache 징후	컨테이너 또는 VM 메모리 상한에 접근할 때 즉시 중지한다

이 표는 실행 순서가 아니라 위험도 지도다.

첫 주에는 deadlocks나 rollbacks처럼 상대적으로 회복이 쉬운 항목부터 시작하고, WAL과 OOM 계열은 복구 훈련이 준비된 뒤로 미루는 편이 낫다.

실무 시나리오 1: 락 대기 알림이 실제로 울리는지 본다

쇼핑몰 주문 DB에서 특정 업데이트가 밀리면 결제 승인 이후 재고 반영이 늦어질 수 있다.

이 팀이 확인할 것은 noisia가 락을 잘 거는지가 아니라, lock wait 알림이 몇 초 만에 울리고 담당자가 어떤 PID와 쿼리를 보는지다.

테스트 전에는 pg_stat_activity에서 blocking PID를 찾는 쿼리와 앱 connection pool 대기열 지표를 대시보드에 올려둔다.

테스트 중에는 대기 세션 수, 대기 시간, 앱 p95 latency, timeout 비율을 동시에 본다.

검토할 만한 기준은 명확하다.

락 대기가 30초 안에 알림으로 잡히고, 담당자가 차단 세션과 피해 테이블을 바로 확인하며, 중단 후 앱 오류율이 정상으로 돌아오면 첫 단계는 통과다.

실무 시나리오 2: replication slot 방치가 디스크를 얼마나 빨리 먹는지 본다

논리 복제나 CDC를 쓰는 팀은 replication slot이 방치되면 WAL이 지워지지 않는다는 사실을 알고 있어도 실제 속도를 모르는 경우가 많다.

slot-bloat 계열 테스트는 이런 막연함을 숫자로 바꾸지만 위험도가 높다.

따라서 이 테스트는 작은 디스크와 짧은 제한 시간, 별도 스냅샷, slot cleanup 명령 검증이 끝난 뒤에만 실행한다.

관측 지표는 pg_wal 디렉터리 크기, archive 지연, replica replay lag, 디스크 여유 비율, checkpoint 경고다.

이 조건이면 바로 중단한다.

디스크 여유 공간이 25% 아래로 내려가거나 관리 접속이 두 번 실패하면 테스트를 멈추고 slot 제거와 복구 runbook을 실행해야 한다.

실무 시나리오 3: temp file 폭증과 work_mem 기준을 확인한다

분석 쿼리와 리포트 기능이 많은 서비스는 정렬이나 해시가 디스크로 spill되면서 스토리지 비용과 지연 시간이 같이 뛴다.

noisia의 tempfiles 계열은 work_mem보다 큰 정렬을 만들어 temp_files와 temp_bytes가 어떻게 증가하는지 보여준다.

PostgreSQL 공식 문서의 pg_stat_statements는 쿼리별 실행 통계와 temp block, WAL 관련 열을 제공하므로 전후 비교에 쓸 수 있다.

다만 work_mem을 크게 올리는 처방은 동시 세션 수와 곱해져 메모리 비용을 키울 수 있다.

이 경우는 단일 쿼리만 보고 결론을 내리지 말고, 동시성, connection pool, 쿼리 종류별 빈도, 클라우드 메모리 단가를 같이 본다.

관측 지표는 TPS 하나로 끝내지 않는다

pgbench 출력의 TPS와 latency는 기준선 확인에는 쓸모가 있다.

그러나 장애 재현 테스트에서는 평균 TPS보다 어떤 보호 장치가 언제 작동했는지가 더 중요하다.

PostgreSQL 공식 문서의 EXPLAIN은 실행 계획과 비용 추정, ANALYZE 실행 시 실제 실행 통계를 보여주지만, ANALYZE는 실제 문장을 실행한다는 점을 명시한다.

쓰기 문장에 EXPLAIN ANALYZE를 붙일 때는 트랜잭션으로 감싸고 ROLLBACK하는 습관이 필요하다.

pg_stat_statements는 쿼리 집계와 실행 시간, 블록 사용, temp block, WAL 관련 열을 제공하므로 테스트 전후 차이를 보는 데 적합하다.

pg_stat_activity와 monitoring stats는 현재 세션, 대기 이벤트, 복제 상태, 데이터베이스 활동을 확인하는 기본 관측면이다.

실행 전 안전 계획 스켈레톤

아래 YAML은 noisia 같은 유해 워크로드를 실행하기 전 승인, 한도, 중단 기준, 복구 절차를 한 파일로 고정하는 예시다.

# noisia-safety-plan.yaml
# 목적: PostgreSQL 장애 재현 테스트를 운영 DB가 아니라 격리된 스테이징에서만 실행한다.
# 실제 값은 조직의 RTO, 백업, 보안 정책, 클라우드 한도에 맞게 조정한다.

environment:
  name: staging-postgres-chaos
  production_access: forbidden
  network: isolated-subnet
  restore_point_required: true
  owner: database-platform-team
  approver: sre-oncall-lead

limits:
  max_runtime_minutes: 10
  max_parallel_workers: 4
  max_connection_pressure_ratio: 0.35
  disk_free_space_stop_ratio: 0.25
  replication_lag_stop_seconds: 60
  alert_channel: incident-test-room

allowed_workloads:
  safe_observation:
    - rollbacks
    - deadlocks
  controlled_pressure:
    - waitxacts
    - tempfiles
    - bloat-churn
  destructive_rehearsal:
    - slot-bloat
    - wal-flood
    - backend-killer

stop_rules:
  - stop when disk_free_space is below threshold
  - stop when monitor connection fails twice
  - stop when recovery script is not ready
  - stop when replica replay lag exceeds threshold

recovery:
  baseline_snapshot: required
  vacuum_or_repack_plan: required for bloat tests
  replication_slot_cleanup: required for slot tests
  postmortem_owner: database-platform-team

핵심은 workload 이름보다 stop_rules와 recovery가 먼저 채워지는지다.

복구 항목이 비어 있으면 테스트는 실패 주입이 아니라 장애 유발에 가깝다.

오접속 방지용 사전 점검 스크립트

아래 Python 예시는 운영 DB 문자열과 무제한 실행을 막기 위한 사전 점검 스켈레톤이다.

#!/usr/bin/env python3
# noisia_preflight_check.py
# 목적: noisia 같은 유해 워크로드를 실행하기 전에 운영 DB 오접속과 무제한 실행을 막는 사전 점검 예시다.
# 실제 실행기는 이 결과가 ok일 때만 별도 승인된 테스트 명령을 호출해야 한다.

import os
import re
import sys
from urllib.parse import urlparse

conn = os.environ.get("PG_TEST_DSN", "")
workload = os.environ.get("NOISIA_WORKLOAD", "")
runtime_min = int(os.environ.get("NOISIA_RUNTIME_MIN", "0"))
workers = int(os.environ.get("NOISIA_WORKERS", "0"))
allow_hosts = {"staging-db.internal", "127.0.0.1", "localhost"}
destructive = {"slot-bloat", "wal-flood", "backend-killer", "failconns", "forkconns"}

parsed = urlparse(conn)
host = parsed.hostname or ""
problems = []

if not conn:
    problems.append("PG_TEST_DSN is empty")
if host not in allow_hosts:
    problems.append(f"host is not in staging allowlist: {host}")
if re.search(r"prod|primary|customer|payment", conn, re.I):
    problems.append("connection string looks like production")
if runtime_min <= 0 or runtime_min > 10:
    problems.append("runtime must be between 1 and 10 minutes")
if workers <= 0 or workers > 4:
    problems.append("workers must be between 1 and 4")
if workload in destructive and os.environ.get("DESTRUCTIVE_TEST_APPROVED") != "yes":
    problems.append("destructive workload requires explicit approval")

print({"ok": not problems, "host": host, "workload": workload, "runtime_min": runtime_min, "workers": workers, "problems": problems})
if problems:
    sys.exit(1)

이 스크립트는 실제 noisia 명령을 대신하지 않는다.

승인된 테스트 실행기는 이런 사전 점검을 통과한 뒤에만 별도 runbook 명령을 호출하도록 묶는 편이 안전하다.

runbook은 명령보다 기록 양식이 중요하다

공식 README는 Docker 이미지와 Go 코드 사용 예시를 제공하지만, 조직 runbook은 그보다 더 보수적이어야 한다.

# noisia-runbook-outline.sh
# 실제 명령은 공식 README와 테스트 환경 값을 확인한 뒤 승인된 배포 파이프라인에서만 실행한다.
# 운영 DB, 고객 데이터 DB, 공유 개발 DB에서는 실행하지 않는다.

set -euo pipefail

python3 noisia_preflight_check.py

# 1. 기준선 수집: pg_stat_activity, pg_stat_statements, replica lag, disk free, WAL size
# 2. 짧은 시간 제한으로 단일 workload 실행
# 3. 중단 조건 감시: disk free, lag, blocked sessions, monitor connection
# 4. 복구 절차 실행: cancel, terminate, slot cleanup, vacuum, reindex, restore drill
# 5. 결과 기록: 원인, 지표 변화, 경보 품질, 복구 시간, 다음 개선 항목

runbook에는 실패를 만든 명령보다 기준선, 중단 시각, 복구 명령, 경보 누락, 다음 조치가 더 자세히 남아야 한다.

이 기록이 있어야 다음 인스턴스 크기 조정, connection pool 제한, WAL 보관 정책, autovacuum 튜닝에 돈을 쓸 근거가 생긴다.

비용 리스크: 장애 테스트는 클라우드 청구서도 흔든다

WAL flood, temp file, bloat 테스트는 스토리지 I/O와 디스크 사용량을 직접 늘린다.

클라우드 관리형 DB에서는 프로비저닝 IOPS, 스냅샷, 백업 보관, 로그 수집, 모니터링 지표 비용까지 함께 증가할 수 있다.

테스트 전에는 예산 한도와 중단 기준을 숫자로 정한다.

예를 들어 디스크 여유율, WAL 증가 속도, 로그 ingest 한도, 알림 이벤트 수, 테스트 총 시간은 청구 비용과 바로 연결된다.

비용 절감 관점에서는 큰 인스턴스를 쓰는 것보다 작은 스테이징에서 실패를 빠르게 재현하고 복구 시간을 줄이는 쪽이 낫다.

보안 리스크: 고객 데이터와 운영 권한을 떼어낸다

장애 재현 테스트에는 운영 데이터가 필요하지 않다.

데이터 분포가 필요하다면 익명화된 샘플이나 synthetic dataset을 만들고, 민감 컬럼은 스키마 수준에서 제외한다.

테스트 계정에는 운영 테이블 삭제 권한, 전체 슈퍼유저 권한, 외부 네트워크 접근 권한을 주지 않는다.

pg_stat_statements는 권한에 따라 다른 사용자의 SQL 텍스트 노출 범위가 달라질 수 있으므로, 관측 계정의 권한도 문서화해야 한다.

보안팀은 테스트 로그와 쿼리 샘플이 외부 이슈 트래커나 공개 채팅에 그대로 붙지 않도록 보존 범위를 정한다.

운영 리스크: 자동 복구가 더 큰 사고를 만들 수 있다

락 대기나 연결 고갈 알림이 울렸다고 무조건 pg_terminate_backend를 날리면 더 큰 롤백과 재시도를 만들 수 있다.

WAL 디스크 압박 상황에서 아카이브 실패를 무시하고 재시작만 반복하면 근본 원인이 남는다.

autovacuum이 bloat를 따라가지 못하는 경우에는 단순 VACUUM, VACUUM FULL, pg_repack, REINDEX CONCURRENTLY의 서비스 영향이 다르다.

운영팀은 noisia 결과를 자동화 신뢰 점수로 쓰기보다 사람이 승인해야 할 복구와 자동 처리해도 되는 복구를 나눠야 한다.

이 조건이면 자동화가 맞다.

증상이 명확하고 피해 범위가 작으며 중단 조건과 rollback이 검증된 작업만 자동 복구로 올리는 편이 안전하다.

도입 판단 체크리스트

운영 DB, 운영 복제본, 고객 데이터가 있는 개발 DB가 테스트 대상에서 빠졌는지 확인한다.
테스트 DB 스냅샷, 복구 명령, 모니터 계정, 알림 채널, 담당자를 먼저 고정한다.
pgbench로 정상 처리량 기준선을 만들고 noisia 실행 결과와 섞어 해석하지 않는다.
워크로드별로 pg_stat_activity, pg_stat_statements, WAL, temp file, replica lag, bloat, 로그를 다르게 본다.
destructive 계열은 짧은 실행 시간, 작은 병렬도, 낮은 디스크 중단 기준, 별도 승인 없이는 실행하지 않는다.
테스트 결과에는 장애가 만들어졌다는 사실보다 감지 시간, 복구 시간, 알림 누락, 비용 영향, 다음 조치를 남긴다.
같은 테스트를 정기적으로 반복할 때는 버전, 파라미터, 인스턴스 크기, 스키마 변경 이력을 함께 저장한다.
공식 문서와 noisia README 변경 내용을 주기적으로 확인하고, 확인되지 않은 명령을 운영 runbook에 넣지 않는다.