데이터베이스 운영자의 책임 범위: 가용성, 내구성, 성능, 비용

DBA의 일은 "DB가 켜져 있는지"를 넘어서야 한다

운영 데이터베이스는 애플리케이션 뒤에 숨어 있지만, 장애가 나면 가장 먼저 사용자가 느끼는 계층이다. 로그인은 되는데 주문이 안 되거나, API는 살아 있는데 조회가 30초씩 걸리거나, 장애 복구 후 데이터가 10분 전으로 돌아가 있으면 사용자는 "DB 문제"라는 내부 사정을 알 필요가 없다. 서비스가 깨진 것이다.

그래서 DBA와 데이터 플랫폼 엔지니어의 책임 범위는 단순히 서버를 설치하고 계정을 만드는 일이 아니다. 핵심은 네 가지 질문으로 정리된다.

1. 가용성: 사용자가 필요할 때 DB를 사용할 수 있는가?
2. 내구성: 이미 기록된 데이터가 사라지거나 손상되지 않는가?
3. 성능: 정상 부하와 피크 부하에서 예측 가능한 응답 시간을 유지하는가?
4. 비용: 위 세 가지를 과도한 비용 없이 지속 가능한 구조로 제공하는가?

이 네 축은 서로 독립적이지 않다. 99.999% 가용성을 목표로 잡으면 복제, 장애조치, 관측성, 테스트, 인력 운영 비용이 올라간다. 비용을 아끼려고 백업 보존 기간을 줄이면 RPO가 나빠진다. 성능을 위해 읽기 복제본을 늘리면 복제 지연과 읽기 일관성 문제가 생긴다. 운영자는 이 트레이드오프를 숫자로 설명하고, 시스템이 그 약속을 지키도록 만드는 사람이다.

네 가지 책임 축

1. 가용성: 장애가 없다는 뜻이 아니다

가용성은 장애가 절대 나지 않는 상태가 아니다. 장애가 나도 사용자가 감당 가능한 수준으로 서비스를 계속 쓰거나, 약속한 시간 안에 복구되는 상태다. Google SRE 문서가 SLO를 강조하는 이유도 여기에 있다. "얼마나 안정적이어야 하는가"를 정하지 않으면 모든 장애는 같은 우선순위가 되고, 모든 개선은 끝이 없는 일이 된다.

DB 가용성을 볼 때는 다음을 분리해야 한다.

가용성을 높이는 대표 수단은 복제와 장애조치다. 하지만 복제본이 있다고 자동으로 안전해지는 것은 아니다. 복제 지연이 크면 읽기 결과가 과거를 보여줄 수 있고, 자동 failover가 잘못 설계되면 split-brain으로 두 노드가 동시에 primary처럼 동작할 수 있다. 운영자는 "복제본이 있다"가 아니라 "어떤 장애에서, 어떤 데이터 손실 허용치로, 몇 분 안에, 누가 전환하는가"를 문서화해야 한다.

2. 내구성: 백업 파일이 아니라 복구 가능성이 목표다

내구성은 INSERT가 성공했다고 끝나지 않는다. 디스크 장애, 사람의 실수, 버그 배포, 잘못된 배치, 랜섬웨어, 스토리지 손상 이후에도 필요한 지점으로 돌아갈 수 있어야 한다.

AWS Reliability Pillar는 백업을 RTO/RPO 요구사항에 맞춰 수행하고, 백업 자동화뿐 아니라 주기적 복구 테스트로 백업 무결성과 절차를 검증하라고 정리한다. 운영 현장에서는 이 문장이 중요하다. 백업 성공 알림은 복구 성공을 보장하지 않는다.

내구성 운영의 최소 단위는 다음 네 가지다.

• 백업 대상: 데이터 파일, WAL/binlog, 설정, 계정/권한, schema migration 이력
• 백업 방식: logical dump, physical backup, snapshot, incremental backup
• 복구 목표: RTO와 RPO
• 복구 검증: staging restore, checksum, row count/sample query, 애플리케이션 smoke test

RPO = 장애 시점 기준으로 허용 가능한 데이터 손실량
RTO = 장애 발생 후 서비스가 다시 사용 가능해져야 하는 시간

예를 들어 RPO 5분이면 binlog/WAL 보관과 전송 지연이 5분 안에 들어와야 한다. RTO 30분이면 백업을 다운로드하고 restore하고 애플리케이션 연결을 전환하는 절차가 30분 안에 끝나야 한다. "매일 새벽 3시에 백업"은 RPO 최대 24시간을 의미할 수 있다. 이 값을 비즈니스가 받아들일 수 없다면 백업 전략은 이미 틀린 것이다.

3. 성능: 평균이 아니라 꼬리 지연과 예측 가능성

DB 성능 문제는 CPU 사용률 하나로 설명되지 않는다. 흔한 원인은 다양하다.

• 잘못된 인덱스 또는 통계 정보로 인한 full scan
• 대량 업데이트와 긴 트랜잭션으로 인한 lock contention
• connection pool 고갈 또는 connection storm
• 디스크 IOPS/latency 병목
• 캐시 적중률 저하와 working set 증가
• replica lag로 인한 읽기 품질 저하
• 배치 작업과 온라인 트래픽의 리소스 경합

운영자는 "느리다"를 쪼개서 봐야 한다. 평균 latency는 괜찮아도 p95/p99가 튀면 일부 사용자는 장애를 경험한다. QPS는 낮아도 특정 hot row에 쓰기가 몰리면 전체 트랜잭션이 대기한다. DB CPU가 낮아도 애플리케이션은 connection을 못 얻어 timeout 날 수 있다.

성능 운영의 좋은 기준은 다음이다.

성능 튜닝은 "인덱스 하나 추가"로 끝내면 위험하다. 새 인덱스는 읽기를 빠르게 하지만 쓰기 비용과 저장 공간을 늘린다. 쿼리 하나를 빠르게 만들다가 다른 쿼리의 실행계획을 바꿀 수도 있다. 그래서 튜닝은 항상 before/after 측정, rollback 계획, 배포 후 plan regression 확인까지 포함해야 한다.

4. 비용: 신뢰성의 일부다

운영 비용은 단순히 예산 문제가 아니다. 비용이 지속 불가능하면 결국 백업 보존 기간을 줄이고, 모니터링을 끄고, 복제본을 줄이고, 장애 대응 인력을 줄이게 된다. 그러면 신뢰성이 무너진다.

데이터베이스 비용은 보통 다음에서 커진다.

• peak 기준으로 과하게 잡은 CPU/메모리
• 증가량을 통제하지 않은 스토리지와 백업 보존
• 목적 없이 늘어난 읽기 replica
• 무거운 분석 쿼리를 OLTP DB에서 직접 실행
• 오래된 파티션/로그/임시 테이블 미정리
• 필요 이상으로 낮게 잡은 RTO/RPO

비용을 줄인다는 것은 무조건 사양을 낮추는 일이 아니다. 워크로드를 분리하고, 보존 정책을 명확히 하고, 오래된 데이터를 archive하고, 읽기 패턴에 맞는 캐시/검색/분석 저장소를 붙이는 일이다. DBA와 데이터 플랫폼 엔지니어는 "더 큰 DB"와 "더 적절한 구조" 사이에서 판단해야 한다.

운영 약속을 숫자로 바꾸기

DB 운영을 잘하려면 추상적인 목표를 숫자로 바꿔야 한다.

Google SRE 관점에서 SLO는 단순한 대시보드 지표가 아니라 의사결정 기준이다. error budget이 소진되면 기능 배포보다 안정화가 우선이다. DB에도 같은 원칙을 적용할 수 있다. 예를 들어 이번 달 replica lag SLO를 이미 소진했다면, 읽기 분산을 늘리기 전에 lag 원인과 consumer 쿼리를 먼저 봐야 한다.

DBA / 데이터 플랫폼 엔지니어의 운영 산출물

실무에서 운영자의 가치가 드러나는 산출물은 대개 문서와 자동화다.

1. 서비스 등급표

- DB별 Tier, owner, RTO/RPO, 업무 영향도, 연락 경로

1. 대시보드와 알림 규칙

- availability, latency, error, saturation, replication, backup status

1. 백업·복구 런북

- 어떤 백업을 어디서 찾고, 어떤 순서로 restore하며, 어떻게 검증하는지

1. 장애조치 런북

- failover 조건, 승인자, 실행 명령, 애플리케이션 전환, rollback 기준

1. 변경 관리 체크리스트

- DDL, 인덱스, 파라미터, 버전 업그레이드, 대량 배치 작업의 사전 점검

1. 용량 계획 리포트

- CPU, memory, disk, IOPS, connection, QPS, data growth 추세

1. 사후 분석 문서

- 원인 비난이 아니라 탐지 지연, 완화 지연, 복구 지연을 줄이는 액션

좋은 운영자는 장애를 한 번도 안 겪은 사람이 아니다. 장애가 났을 때 무엇을 먼저 볼지, 어떤 조치를 하면 부작용이 생길지, 복구 후 어떤 증거로 정상화를 판단할지 준비해둔 사람이다.

실전 체크리스트

신규 DB를 운영 대상으로 받을 때

• [ ] 이 DB의 owner와 업무 영향도를 아는가?
• [ ] 읽기/쓰기 경로와 의존 서비스가 그려져 있는가?
• [ ] RTO/RPO가 숫자로 합의되어 있는가?
• [ ] 백업 대상과 보존 기간이 정해져 있는가?
• [ ] 실제 restore 테스트를 해봤는가?
• [ ] replication/failover 구조와 수동 개입 기준이 문서화되어 있는가?
• [ ] slow query와 connection 지표를 볼 수 있는가?
• [ ] 디스크 증가율과 capacity cliff를 예측할 수 있는가?
• [ ] 보안/권한/감사 로그 책임자가 정해져 있는가?

장애 중 먼저 확인할 것

1. 애플리케이션 에러가 DB 접속 실패인지, query timeout인지, 쓰기 실패인지 분리한다.
2. primary가 쓰기를 받고 있는지 확인한다.
3. connection pool과 DB connection 사용률을 본다.
4. lock wait, long transaction, disk latency, replication lag를 확인한다.
5. 최근 배포, DDL, 배치, 트래픽 증가, 파라미터 변경을 확인한다.
6. 완화 조치가 데이터 손실이나 추가 장애를 만들지 검토한다.
7. 복구 후 SLO 영향, 데이터 정합성, 재발 방지 액션을 남긴다.

기억할 문장

DBA의 책임은 "DB 서버가 살아 있다"가 아니다. 서비스가 약속한 수준으로 데이터를 읽고 쓸 수 있게 만드는 것이다. 그 약속은 가용성, 내구성, 성능, 비용의 균형으로 결정된다.

다음 장에서는 장애를 더 구체적으로 분류하고, 어떤 장애를 어떤 SLO와 알림으로 잡아야 하는지 다룬다.

References

• Google SRE Book, Chapter 4: Service Level Objectives — https://sre.google/sre-book/service-level-objectives/
• Google SRE Workbook, Chapter 2: Implementing SLOs — https://sre.google/workbook/implementing-slos/
• AWS Well-Architected Framework, Reliability Pillar — https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/welcome.html
• AWS Well-Architected Reliability Pillar, Back up data — https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/back-up-data.html
• AWS Cloud Operations Blog, Establishing RPO and RTO Targets for Cloud Applications — https://aws.amazon.com/blogs/mt/establishing-rpo-and-rto-targets-for-cloud-applications/