Postgres, 잘 쓰다가 갑자기 터지는 이유
스타트업 백엔드의 기본값은 이제 Postgres라고 해도 과언이 아닌데요. 문제는 처음엔 아무 설정 없이도 잘 돌아가다가, 서비스가 크면서 어느 날 갑자기 장애로 돌아온다는 거예요. Postgres 기반 작업 큐를 만드는 Hatchet 팀이 수많은 스타트업의 Postgres 운영을 지켜보며 정리한 '생존 가이드'를 공개했는데요. 실전에서 진짜 자주 터지는 지점들만 모아놔서 소개해 드릴게요.
첫 번째 복병: 커넥션 고갈
가장 흔한 사고는 커넥션 고갈이에요. Postgres는 클라이언트 접속 하나마다 별도의 프로세스를 하나씩 만들거든요. 그래서 커넥션 하나하나가 꽤 무겁고, 기본 설정으로는 최대 100개 정도밖에 못 받아요. 그런데 요즘 서버는 오토스케일링으로 인스턴스가 늘어나고, 서버리스 함수는 요청마다 커넥션을 새로 만들기도 하잖아요. 트래픽이 몰리는 순간 'too many connections' 에러가 터지면서 서비스 전체가 멈추는 거예요. 해법은 커넥션 풀러인데요. PgBouncer 같은 도구를 데이터베이스 앞에 세워두면, 애플리케이션의 수천 개 커넥션 요청을 실제 DB 커넥션 수십 개로 모아서 재사용해 줘요. 식당에 손님이 1000명 와도 테이블 20개를 회전시키며 받는 것과 같은 원리거든요.
두 번째: 아무 생각 없이 실행한 마이그레이션
배포하다가 서비스가 멈추는 단골 원인이 스키마 마이그레이션이에요. ALTER TABLE로 컬럼을 추가하는 것 자체는 금방 끝나는데, 문제는 이 작업이 테이블 전체에 락(lock)을 걸어야 한다는 거예요. 만약 그 순간 오래 걸리는 쿼리 하나가 테이블을 붙잡고 있으면, ALTER TABLE은 그 뒤에서 기다리고, 그 뒤로 들어오는 모든 일반 쿼리들까지 줄줄이 대기하게 되거든요. 쿼리 하나 때문에 서비스 전체가 몇 분간 얼어붙는 거죠. 그래서 마이그레이션 전에 lock_timeout을 짧게 설정해서 '락을 몇 초 안에 못 잡으면 그냥 실패해라'라는 안전장치를 걸어두는 게 필수고요. 인덱스를 만들 때도 CREATE INDEX 대신 CREATE INDEX CONCURRENTLY를 써야 테이블을 잠그지 않고 만들 수 있어요.
세 번째: 롱 트랜잭션과 청소부의 파업
조금 더 깊은 문제로 들어가면 VACUUM 이야기가 나와요. Postgres는 MVCC라는 방식으로 동작하는데요, 이게 뭐냐면 데이터를 UPDATE하거나 DELETE해도 실제로는 바로 지우지 않고 옛 버전을 남겨두는 방식이에요. 여러 트랜잭션이 서로 다른 시점의 데이터를 동시에 읽을 수 있게 하려는 거거든요. 이 옛 버전들('죽은 튜플')은 VACUUM이라는 청소부가 나중에 치워주는데, 문제는 오래 실행되는 트랜잭션이 하나라도 열려 있으면 청소부가 일을 못 한다는 거예요. '저 트랜잭션이 아직 옛 데이터를 볼지도 모르니까' 못 지우는 거죠. 그렇게 죽은 튜플이 쌓이면 테이블이 비대해지고(bloat) 쿼리가 점점 느려져요. 그래서 트랜잭션은 짧게 유지하고, 트랜잭션 안에서 외부 API 호출 같은 오래 걸리는 작업을 절대 하지 말라는 게 철칙이에요.
그래도 결론은 '그냥 Postgres 쓰세요'
재미있는 건 이런 함정들을 다 나열하고도 결론이 Postgres를 떠나라는 게 아니라는 거예요. 오히려 반대거든요. 메시지 큐가 필요하면 Kafka부터 붙이지 말고 Postgres의 SKIP LOCKED로, 검색이 필요하면 Elasticsearch 전에 Postgres 전문 검색으로, JSON 저장은 MongoDB 대신 JSONB로 — 웬만한 규모까지는 Postgres 하나로 다 커버된다는 게 요지예요. 인프라 종류가 하나 늘어날 때마다 운영 부담은 곱절로 늘어나니까, 작은 팀일수록 기술 스택을 하나로 모으는 게 생존 전략이라는 거죠. 여기에 pg_stat_statements 확장을 켜서 어떤 쿼리가 시간을 잡아먹는지 상시 모니터링하는 것까지 더하면 기본기는 갖춘 셈이에요.
정리하면, Postgres는 기본 설정만으로 시작하기 쉽지만, 커넥션 풀링·마이그레이션 락·롱 트랜잭션 이 세 가지만 미리 챙겨도 대부분의 장애를 예방할 수 있어요. 여러분의 서비스는 이 중 몇 개나 대비되어 있나요? 그리고 큐와 검색까지 Postgres 하나로 버티는 전략, 어느 규모까지 유효하다고 보시나요?
🔗 출처: Hacker News