[DB] 운영 중인 DB의 디스크 99% 사용 및 쓰기 오류 장애 발생시에 어떻게 해야할까
이런 상황을 상상해보자.
새벽 2시, 관제 알림이 울린다. 운영 중인 DB 서버의 디스크 사용률이 99%를 초과했고, 애플리케이션에서 쓰기 오류가 발생하기 시작했다.
최근에 이 시나리오를 놓고 대응 방안을 정리할 일이 있었는데, 고민했던 내용을 블로그에도 남겨본다. 순서는 세 단계다. 뭘 먼저 확인할지, 어떻게 조치할지, 그리고 팀에 어떻게 공유할지.
1. 가장 먼저 확인할 것
당황해서 아무 파일이나 지우기 전에, 상황 파악부터 해야 한다. 확인할 것은 크게 세 가지다.
영향 및 원인 범위
- 디스크 사용률, 증가 속도, inode 사용률
- 쓰기 오류가 시작된 시각, 건수, 영향받는 서비스
- 어느 영역이 증가했는지 확인 (데이터? 로그? 임시 파일? 백업?)
특히 증가 속도가 중요하다. 99%에서 멈춰 있는 것과 분당 1%씩 차오르는 건 완전히 다른 상황이다. 그리고 디스크 용량은 남았는데 inode가 고갈되는 경우도 있어서 둘 다 봐야 한다.
고가용성 및 데이터 보호
- Primary와 Replica 상태, Replication lag 확인
- 최신 백업이 성공한 시각과 복원 가능한 시점
최악의 경우 Failover나 백업 복원으로 가야 하니까, 그 카드가 지금 유효한지부터 확인해두는 것이다.
쓰기 결과
- 실패한 쓰기를 미반영 / 부분 반영 / 결과 불명으로 분류
- 실패 큐, 메시지, 애플리케이션 로그 확보
쓰기 오류가 이미 발생했다는 건 유실됐을 수 있는 요청이 존재한다는 뜻이다. 나중에 재처리하려면 지금 증거를 확보해둬야 한다.
2. 복구 경로 결정
상황 파악이 되면, 손실량과 복구 예상 시간(ETA)을 RPO/RTO에 대조해서 경로를 정한다.
| 손실 | ETA | 판단 |
|---|---|---|
| ≤ RPO | ≤ RTO | 정상 경로로 복구 |
| ≤ RPO | > RTO | 시간 회복 우선 → Failover |
| > RPO | ≤ RTO | 데이터 복구 우선 → 백업·PITR |
| > RPO | > RTO | 두 목표 모두 위험 → BCP 전환 |
감으로 정하는 게 아니라, 이 매트릭스에 넣으면 답이 나오게 만드는 것이 포인트다.
3. 즉각 조치와 근본 해결
즉각 조치 — 여유 확보와 쓰기 폭주 차단
- 비필수 배치 중단, 쓰기 제한, 자동 재시도 폭주 차단
- 로그·임시 파일·만료된 백업을 다른 곳으로 이관, 필요하면 디스크 증설
- ETA를 갱신하면서 RTO 초과가 예상되면 Failover 검토
재시도 폭주 차단이 은근 중요하다. 쓰기가 실패하면 애플리케이션이 자동으로 재시도하는데, 이게 오히려 디스크와 로그를 더 채우는 악순환을 만들 수 있다.
단기 — 다음엔 더 빨리 알아채기 (MTTD·MTTR 단축)
- 다단계 임계치 + 증가 속도 기반 예측 알람 (99%에 울리면 늦다. 80%, 90%에서 미리, 그리고 “이 속도면 2시간 뒤 가득 참” 같은 예측 알람)
- 로그 순환·보존 정책과 통제된 자동 확장
- Runbook과 체크리스트 표준화 (새벽 2시의 나는 머리가 안 돌아간다. 미리 적어둔 문서가 나를 구한다)
중기 — 구조적으로 재발 방지
- 데이터·로그·백업 저장 경로 분리, 백업은 외부로
- 아카이빙·파티셔닝·증가량 기반 용량 계획
- Failover와 복원 테스트 정례화 (복원 안 해본 백업은 백업이 아니다)
4. 미반영 쓰기 복구
디스크를 비웠다고 끝이 아니다. 장애 중에 실패한 쓰기를 되살려야 한다.
- 요청 확보 — 실패 큐, 메시지, 애플리케이션 로그에서 실패 요청 수집
- 조회·분류 — 미반영 / 부분 반영 / 결과 불명으로 나누기
- 멱등 재처리 — Request ID, Unique Key, upsert를 활용해서 두 번 실행돼도 안전하게
- 정합성 검증 — 건수 대조, 샘플 검증
핵심은 멱등성이다. “결과 불명”인 요청은 실제로 반영됐는지 알 수 없는데, 멱등하게 설계돼 있으면 그냥 다시 실행해도 된다.
5. 팀 공유
장애 대응은 혼자 하는 게 아니라서, 공유도 대응의 일부다. 시점별로 형식을 나눴다.
- 초기: 발생 시각 · 영향 범위 · 현재 조치 · ETA
- 진행: 정상화 상태 · 변경된 ETA · 다음 공유 시각
- 사후: 원인 · 재처리 결과 · 재발 방지 대책
초기 공유에서 “다음 공유 시각”을 못 박는 게 중요하다. 그래야 팀원들이 궁금해서 계속 물어보는 상황을 막고 대응에 집중할 수 있다.
마무리
정리하면서 느낀 건, 장애 대응의 절반은 기술이고 절반은 미리 정해둔 규칙이라는 것이다. RPO/RTO 기준, Runbook, 공유 템플릿이 있으면 새벽 2시에도 기계처럼 움직일 수 있다. 없으면 그때부터 고민을 시작해야 하는데, 그게 제일 비싸다.