데이터베이스 시니어 배포·운영 기술면접

무중단 스키마 변경은 최소 3단계로 진행합니다. 1단계에서는 NULL 허용 컬럼을 추가하고 애플리케이션을 배포하여 신규 데이터부터 값을 입력하도록 합니다. 2단계에서는 배치 작업으로 기존 레코드의 NULL 값을 채우되, 락 경합을 피하기 위해 작은 청크 단위로 UPDATE를 수행합니다. 3단계에서는 모든 데이터 마이그레이션이 완료된 후 ALTER TABLE로 NOT NULL 제약조건을 추가합니다. 각 단계 사이에는 모니터링 기간을 두어 문제 발생 시 롤백할 수 있도록 합니다. Blue-Green 배포나 Feature Flag를 활용하면 더욱 안전하게 진행할 수 있습니다.

먼저 슬로우 쿼리 로그와 쿼리 실행 계획을 분석하여 어떤 쿼리가 느려졌는지 파악합니다. 동시에 CPU, 메모리, 디스크 I/O, 네트워크 대역폭 등 시스템 리소스 메트릭을 확인하여 인프라 병목을 확인합니다. Connection pool 사용률, Active connection 수, Lock wait time을 점검하여 동시성 이슈를 진단합니다. 캐시 히트율과 버퍼 풀 상태를 확인하여 메모리 부족 여부를 판단합니다. APM 도구로 애플리케이션 레벨의 트랜잭션 패턴 변화를 분석하고, 최근 배포나 트래픽 증가 이벤트와 상관관계를 찾습니다. 이를 위해 Prometheus, Grafana, Datadog 같은 통합 모니터링 스택과 알림 임계값 설정이 필수적입니다.

RPO 5분을 만족하기 위해 바이너리 로그(또는 WAL) 기반 연속 백업과 Point-in-Time Recovery를 구성합니다. 물리 백업은 매일 전체 백업을 수행하고, 증분 백업을 매시간 실행하여 복구 시간을 단축합니다. RTO 1시간을 위해 Hot Standby 레플리카를 구성하여 장애 시 즉시 승격할 수 있도록 합니다. 백업 데이터는 다른 리전의 오브젝트 스토리지에 저장하여 재해 복구 시나리오에 대비합니다. 정기적으로(최소 월 1회) 복구 훈련을 수행하여 RTO 목표 달성 가능성을 검증하고, 복구 절차를 자동화 스크립트로 문서화합니다. 백업 무결성 검증을 위해 별도 환경에서 자동으로 복구 테스트를 수행하는 파이프라인을 구축합니다.

먼저 AWS DMS나 Debezium 같은 CDC 도구로 Oracle에서 PostgreSQL로 실시간 데이터 복제 파이프라인을 구축합니다. 스키마와 저장 프로시저는 사전에 변환하고, 애플리케이션 코드의 SQL 방언 차이를 수정합니다. Dual write 패턴으로 일정 기간 두 데이터베이스에 동시 쓰기를 수행하며 데이터 정합성을 검증합니다. 트래픽 전환은 Canary 배포 방식으로 진행하여 먼저 읽기 트래픽의 일부를 PostgreSQL로 라우팅하고, 문제가 없으면 점진적으로 비율을 높입니다. 롤백 계획으로는 DNS 또는 프록시 레벨에서 즉시 Oracle로 트래픽을 되돌릴 수 있도록 구성하고, 최소 2주간 Oracle 데이터베이스를 유지합니다. 마이그레이션 전후 성능 벤치마크를 수행하여 쿼리 응답 시간과 처리량을 비교 검증합니다.

먼저 잘못된 배치 작업을 즉시 중단하고 추가 피해를 막습니다. 별도의 임시 데이터베이스 인스턴스를 생성하여 백업에서 30분 전 시점으로 Point-in-Time Recovery를 수행합니다. 삭제된 데이터만 추출하는 SQL 쿼리를 작성하고, 복구된 임시 DB에서 프로덕션 DB로 선택적으로 데이터를 복원합니다. 이때 트랜잭션 로그를 분석하여 복구 시점 이후 정상적으로 발생한 변경사항은 유지되도록 주의합니다. 복구 전에 영향받은 테이블의 현재 상태를 덤프하여 롤백 포인트를 확보합니다. 복구 완료 후 데이터 정합성을 검증하고, 배치 작업에 대한 사전 검증 프로세스와 Dry-run 절차를 추가하여 재발을 방지합니다.