[Database] 실수하기 어려운 환경 만들기

• 문제 상황 발생

• 문제 상황 분석

• 저희 액션플랜은요.

• 1. DB 자동 백업 시스템

• 2. ddl-auto 옵션 삭제

• 3. DB 서비스 계정 분리

• 4. bin log 활성화

• 결론

서버 개발하면서 DB 관리와 관련된 중요한 부분을 간과하고 있었던 것이 있었습니다. 바로 로컬 환경에서 프로덕션 DB로의 연결이 쉽게 가능했고, ddl-auto 옵션을 사용하여 언제든지 DB가 초기화될 위험을 안고 개발해 왔던 점입니다.

https://www.youtube.com/watch?v=SWZcrdmmLEU&t=32s

 

위 영상과 같이 ddl-auto: create로 인한 이슈는 흔치 않지만, 누구나 한 번쯤은 겪을 수 있는 문제라고 생각했어요. 저희 팀도 이 점을 알고 있었으나, 바쁜 기능 개발에 치여 이 문제를 나중에 개선하자는 식으로 미루어 왔습니다.

문제 상황 발생

결국 운영 DB에서 이슈가 발생하고 말았습니다. 테스트 편의성 때문에 프로덕션 DB에 직접 테스트를 진행하는 경우가 있었고, local.yml 파일에 설정된 ddl-auto: create 옵션으로 인해 운영 DB가 초기화되는 문제가 발생한 것입니다.

문제를 악화시킨 요인으로 트랜잭션 로그들에 대한 체계적인 관리가 부족했고, 백업 작업도 제대로 이루어지지 않았으며, 최후의 복구 수단인 bin log 설정도 미흡했다는 점이 있었습니다.

여러가지 복구 방법을 모두 도입했지만 결국 DB를 완전히 정상 복구하는 것은 불가능하다고 판단했어요.

문제 상황 분석

위는 문제를 유발한 local.yml 설정입니다.

특정 옵션들만 바꾸면 누구나 쉽게 실수를 저지를 수 있는 환경이었습니다. 이로 인해 저희는 "실수하기 어려운 환경을 만들자" 라는 목표로 개발 환경을 재정비하기로 했습니다.

또한, 실수를 하더라도 누구나 쉽게 복구할 수 있는 환경을 만들자는 목표도 세웠습니다.

저희 액션플랜은요.

다음 네 가지 개선책을 계획했습니다:

 

1. DB 자동 백업 시스템
2. ddl-auto 옵션 삭제
3. DB 서비스 계정 분리
4. bin log 활성화

1. DB 자동 백업 시스템

가장 중요한 것은 백업이며, 이를 자동화하는 것이 핵심이라고 생각했습니다. 저희는 DB 서버에서 자체적으로 스케줄러를 실행하여 백업을 간단하게 구현했습니다.

#!/bin/bash

# date formmat
NowTime=$(date +%Y_%m_%d_%H_%M)

# home dir
HomeDirPath="/path"

# DataBase backup path
BackDirPath="/path/to/backup"

# mysqldump : create dump file
mysqldump --ssl-mode=DISABLED -u[name] -p[pwd] [db_name] > ${BackDirPath}/"[db_name]_"${NowTime}.sql

# After 7 Days, DB backup file deleted 
find ${BackDirPath} -type f -name "*.sql" -mtime +7 -exec rm -f {} \\;

이 백업 시스템의 핵심 정책은 다음과 같습니다:

• 매일 오전 9시에 자동 백업
• 생성된 백업 파일은 7일 후 자동 삭제

이 시스템을 적용하면, 아래와 같이 특정 시간마다 백업 데이터가 차곡차곡 쌓이게 됩니다.

2. ddl-auto 옵션 삭제

저희는 처음에 ddl-auto 옵션을 삭제하려고 했습니다. JPA에 의존하는 것이 너무 위험하다고 판단했기 때문입니다. Flyway 같은 데이터베이스 마이그레이션 도구를 사용해 수동으로 스키마를 관리하려 했으나, 현재 개발 진행 중인 프로젝트에서는 엔티티 수정이 잦고 기능 확장이 많아 이러한 방법이 오히려 개발 효율성을 저하시킬 수 있었습니다.

따라서 ddl-auto 옵션은 유지하돼, 다른 안전장치를 마련하는 방향으로 결정했습니다.

3. DB 서비스 계정 분리

프로덕션 서버에서 사용되는 DB 계정을 테스트 환경의 계정과 분리하기로 했습니다. 서비스 서버에서는 기본적인 CRUD 작업이 가능하지만, 개발환경에서 접근할 때 사용하는 계정은 읽기 전용(ReadOnly)으로 설정했습니다.

또한, 개발자의 secret 파일과 실제 프로덕션에 주입되는 secret 파일을 분리하여 관리했습니다. 이로 인해 개발자는 프로덕션 DB에서 SELECT와 UPDATE만 수행할 수 있게 되었습니다.

이 방법으로 프로덕션 DB에 대한 직접적인 접근 위험을 최소화했습니다. 프로덕션 디버깅이 불가피하게 꼭 필요한 경우에만 예외적으로 프로덕션에 연결하도록 제한했습니다.

4. bin log 활성화

이전에는 활성화하지 않았던 바이너리 로그(bin log)도 이번에 활성화했습니다. 바이너리 로그는 백업과 사고 발생 시점 사이의 데이터 복구에 유용한 중요한 도구입니다. 따라서, 이 로그를 통해 데이터 복구 가능성을 최대화할 수 있도록 설정했습니다.

결론

이번 일을 계기로 저희 팀은 DB 관리의 중요성을 다시 한번 깨닫는 계기가 되었습니다.

작은 설정 하나가 큰 문제를 일으킬 수 있다는 것을 알았고, 이를 통해 환경을 재정비해 실수하기 어려운 안전한 환경을 만들었습니다.

개선책을 통해 미래의 사고를 예방하고, 실수가 발생하더라도 빠르게 복구할 수 있는 환경을 만들어 나갈 것입니다.