PostgreSQL을 일부러 망가뜨려 보는 도구, noisia

PostgreSQL을 일부러 망가뜨려 보는 도구, noisia

IT & AI 뉴스 썸네일

운영 중에는 만나고 싶지 않은 PostgreSQL 장애를 테스트 환경에서 미리 일으켜 볼 수 있어요. noisia는 연결 고갈, 잠금 대기, 교착 상태, 메모리 부족, WAL 증가, 디스크 부족을 재현하는 오픈소스 도구예요. 장애가 난 뒤 알람과 복구 절차가 제대로 움직이는지 확인할 때 쓸 수 있지만, 일부 워크로드는 데이터베이스 전체를 재시작시킬 만큼 위험해요. 1

핵심 요약

구분	핵심	왜 볼 만한가요
목적	PostgreSQL에 의도적으로 유해한 워크로드를 만들어요	장애 대응 절차를 실제 증상에 가깝게 점검할 수 있어요
범위	연결, 잠금, 메모리, WAL, 스토리지 문제를 다뤄요	단순 쿼리 부하보다 다양한 실패 경로를 확인할 수 있어요
사용법	Docker 이미지나 Go 패키지로 실행할 수 있어요	실험 환경에 맞춰 전체 도구나 개별 워크로드를 고를 수 있어요
주의점	일부 실험은 PANIC, OOM 종료, 전체 재시작을 일으켜요	운영 DB와 분리된 폐기 가능한 환경에서만 써야 해요

1. 장애 대응 훈련을 실제 PostgreSQL 증상으로 바꿔요

느린 쿼리보다 더 까다로운 실패를 만들어요

일반 부하 테스트는 쿼리 처리량이나 응답 시간을 측정하는 데 초점을 둬요. noisia는 데이터베이스가 나쁜 상태에 빠지는 과정을 직접 만들어요. 한 세션이 테이블 잠금을 잡는 동안 다른 연결을 줄 세우거나, 모든 연결 슬롯을 차지해 새 클라이언트의 접속을 막을 수 있어요. 상대방의 잠금을 기다리게 만들어 교착 상태도 재현해요. 2

이런 실험은 모니터링 화면이 예쁘게 보이는지 확인하는 데서 끝나지 않아요. 잠금 대기 시간이 늘 때 어떤 경보가 먼저 울리는지, 접속 풀이 고갈되면 애플리케이션이 재시도 폭주를 일으키는지, 관리용 연결을 별도로 남겨 뒀는지 확인할 수 있어요. 장애 대응 문서에 적힌 명령이 실제 상황에서도 통하는지도 점검할 수 있어요.

728x90

WAL과 디스크 문제도 재현해요

`slot-bloat`는 소비되지 않는 물리 복제 슬롯이 WAL을 계속 붙잡게 해요. `pg_wal`이 파일시스템을 채우면 PostgreSQL이 더 이상 기록하지 못하고 PANIC 상태에 빠질 수 있어요. `wal-flood`는 여러 워커가 병렬로 `UPDATE`를 반복해 WAL 생성량과 입출력 압력을 높여요. 복제본이 따라오지 못하는 상황과 스토리지 병목을 관찰하는 데 맞아요.

`temporary files` 워크로드는 `work_mem`보다 큰 데이터를 정렬해 디스크 임시 파일을 만들어요. 설정을 바꾼 뒤 임시 파일과 처리 시간이 어떻게 달라지는지 비교할 수 있어요. `bloat-churn`은 autovacuum이 처리하는 속도보다 빠르게 갱신을 반복해 테이블과 인덱스를 부풀려요. 실험을 멈춘 뒤 `VACUUM FULL`, `pg_repack`, `REINDEX CONCURRENTLY` 같은 복구 작업도 연습할 수 있어요. 2

메모리와 프로세스 한계까지 건드려요

`backend-killer`는 한 세션에 prepared statement를 계속 쌓아 백엔드 메모리를 키워요. 환경에 따라 OOM 종료와 인스턴스 재시작으로 이어질 수 있어요. `fork connections`는 짧은 쿼리마다 새 연결을 열어 PostgreSQL 백엔드 프로세스 생성을 늘려요. `failed connections`는 `max_connections`를 모두 소진해 다른 클라이언트가 접속하지 못하게 해요.

이 워크로드들은 서로 영향 범위가 달라요. 교착 상태처럼 PostgreSQL이 감지하고 한 트랜잭션을 취소하는 경우도 있어요. 반면 복제 슬롯과 디스크 고갈 실험은 인스턴스 전체에 영향을 줄 수 있어요. 이름만 보고 실행하기보다 각 워크로드 문서에서 종료 조건, 관찰 지표, 복구 순서를 먼저 확인해야 해요.

Docker와 Go 코드에서 실행할 수 있어요

공개 Docker 이미지를 이용하면 별도 빌드 없이 도움말과 워크로드 옵션을 확인할 수 있어요. 필요한 실패만 애플리케이션 테스트에 넣고 싶다면 Go 코드에서 개별 패키지를 가져올 수도 있어요. 프로젝트 예제는 `context.WithTimeout`으로 실행 시간을 제한해요. 무한 실행을 막으려면 context 취소와 제한 시간을 반드시 두어야 해요. 2

안전한 시작점은 운영 데이터와 자격 증명이 전혀 없는 임시 클러스터예요. 네트워크도 운영 환경과 분리하고, 스토리지 용량 제한과 자동 폐기 조건을 걸어 두는 편이 좋아요. 첫 실행에서는 동시 연결 수와 워커 수를 낮게 잡고, PostgreSQL 로그와 운영체제 메모리, 디스크 사용량을 함께 관찰해야 해요.

왜 중요한가요

장애 대응 훈련은 실패 조건을 구체적으로 만들수록 쓸모가 커져요. "DB가 느려졌을 때"라는 문장만으로는 접속 풀 고갈, 잠금 대기, WAL 적체, 디스크 부족을 구분하기 어려워요. noisia는 각 증상을 따로 만들어 경보 기준과 대응 순서를 검증할 수 있게 해요. 2

다만 이 도구의 위험성은 기능의 일부예요. 프로젝트도 테스트 목적으로만 쓰고, 동작을 충분히 이해하지 못한 상태에서는 실행하지 말라고 경고해요. 운영 복제본이나 공유 스테이징처럼 다른 팀이 의존하는 환경도 안전하지 않아요. 스냅샷에서 복구할 수 있고 실험 후 통째로 버릴 수 있는 클러스터에서 시작해야 해요.

SRE 팀이라면 실험 전후의 성공 조건을 숫자로 정해 둘 수 있어요. 예를 들어 연결 고갈 감지 시간, 경보 도착 시간, 관리용 세션 확보 여부, 복제 지연 회복 시간, 디스크 임계치 도달 전 자동 차단 여부를 기록해요. 이렇게 측정하면 장애 주입이 단순한 시연이 아니라 복구 체계의 빈틈을 찾는 훈련이 돼요.

참고 자료

1. noisia - PostgreSQL용 유해한 워크로드 생성기 — GeekNews
2. lesovsky/noisia — GitHub