본문으로 건너뛰기

7.4 Capacity와 Postmortem

Reliability 운영은 incident 대응에서 끝나지 않습니다. 자원이 언제 한계에 도달할지 예측하고, 장애에서 얻은 사실을 시스템 변경으로 연결해야 합니다.

Capacity는 사용률 하나가 아니다​

PostgreSQL capacity는 여러 자원의 최소 여유로 결정됩니다.

  • CPU와 runnable process
  • memory와 connection당 사용량
  • storage latency/IOPS/throughput
  • volume free space와 증가율
  • WAL archive와 replication slot 보존량
  • connection와 pool queue
  • autovacuum 처리량
  • backup window와 recovery 시간

여러 자원의 최소 여유와 필요한 Headroom을 검증하는 구조

실제 한계점은 CPU뿐 아니라 storage latency나 connection slot에서도 먼저 나타납니다.

Headroom​

평균보다 peak와 장애 상태를 기준으로 여유를 둡니다. Replica 한 대가 빠졌을 때 남은 node가 traffic을 감당할 수 있어야 합니다.

필요 headroom = 정상 peak + 성장분 + 장애 시 재분배 부하 + 운영 여유

평균 CPU 40%인 2대 cluster도 한 대 장애 시 cache, lock 경쟁, storage, connection 분포가 달라집니다. Failover load test에서는 이 재분배 조건을 확인합니다.

추세 query​

Disk 사용량의 선형 예측은 출발점으로 사용할 수 있습니다.

predict_linear(node_filesystem_avail_bytes{mountpoint="/data"}[7d], 14 * 24 * 3600) < 0

성장이 선형이 아니거나 정기 purge가 있다면 오탐이 납니다. Business event와 retention job을 반영하고, alert는 volume 확보 lead time보다 먼저 울리게 합니다.

주간 증가율 기록 대상에는 database 크기, WAL 생성량, backup 크기가 포함됩니다.

Load test에서 볼 것​

  • throughput 증가에 따른 p95/p99 latency 곡선
  • connection 증가와 pool wait
  • CPU utilization과 throttling
  • disk latency와 queue depth
  • WAL bytes/s와 checkpoint
  • replica replay 처리량
  • autovacuum이 workload를 따라가는지
  • 장애 node 제거 후 남은 capacity

Load test 결과에는 최대 TPS와 함께 최초 포화 자원과 해당 시점의 latency를 기록합니다.

Postmortem 구성​

Postmortem은 사람을 평가하는 문서가 아니라 시스템의 실패 조건을 설명하는 문서입니다.

  1. 사용자 영향과 기간
  2. Detection과 대응 timeline
  3. 직접 원인
  4. 장애를 키운 기여 요인
  5. 잘 작동한 방어 장치
  6. 늦거나 없었던 signal
  7. 복구 과정과 위험
  8. 재발 방지 action item

Action item 품질​

모니터링 강화처럼 끝내지 않습니다.

나쁨: replication monitoring 강화

좋음: inactive slot retained WAL이 volume의 20%를 넘고
30분 연속 증가할 때 ticket alert 생성.
Owner: DB Platform, Due: 2026-09-15, 검증: promtool unit test

Action item의 필수 필드는 owner, due date, 완료 조건, 검증 방법이며 자동화하지 않는 항목에는 risk acceptance를 기록합니다.

관측성 gap을 고친다​

Postmortem마다 다음 질문을 추가합니다.

  • 사용자보다 먼저 탐지했는가?
  • 첫 dashboard에서 병목 계층을 구분했는가?
  • 필요한 SQL과 log가 남아 있었는가?
  • Alert가 올바른 사람과 runbook으로 연결됐는가?
  • 수집 비용 때문에 꺼 둔 signal이 원인 확인에 필요했는가?

Postmortem action item에는 새 metric뿐 아니라 불필요한 alert 삭제, label 정리, dashboard link 수정, runbook 검증도 포함합니다.

참고: Google SRE Postmortem Culture, Google SRE Capacity Planning