Legacy DB 백업 시스템 개편하기

EC2 환경에서 운영 중인 DB 백업 시스템 문제를 해결하기 위해 EBS를 활용하여 백업 경로를 분리한 과정을 소개합니다.

회사의 DB 는 AWS EC2 위에서 위에서 운영되고 있다. RDS나 Aurora 와 같은 관리형 DB 를 사용하는 것이 아니고, 팀 내에 인프라 담당자가 딱히 없는 상황이어서 DB 서버에 들어가서 인프라 점검을 하려 노력하는 편이다. 최근에는 쿠폰 시스템 도입 프로젝트로 인해 정신이 없었다가, 오랜만에 DB 서버에 접속해 보니 다음과 같은 상황이 펄쳐졌다.

회사 DB 는 Windows Server 위에서 운영되고 있다. Windows Server 를 운영해본 적은 이번 회사가 처음이어서 GUI 가 있음에도 많은 삽질을 하고 있다.

회사의 DB 규모가 200GB 가 절대 넘을리가 없는데 (내가 모르는 사이에 그정도로 회사가 성장했을리 없다.), 어떠한 일이 벌어지고 있는지 가서 확인해 보았다. 놀랍게도 운영중인 DB 의 크기는 약 70GB 정도 크기였고, 나머지 스토리지는 모두 DB 백업 파일이 차지하고 있었다. 운영DB 의 크기가 크지 않다는 점은 다행이었지만, 원 데이터와 백업 데이터가 같은 파티션 안에 저장되어 있다는 사실은 또다른 충격이었다. 회사의 비즈니스 규모가 커지면, 백업 파일도 동시에 커지므로 디스크는 점점 더 빠른 속도로 차오르게 될 것이다. 중요도를 두고 해결해야 할 인프라 문제라고 생각해서, 틈틈이 시간을 내서 해결책을 찾아보았다.

팀 내에 사태의 심각성을 알리고, 가능한 방법을 제시해보았다.

크게 다음의 세 가지 방안 중 고민하였다.

백업 경로를 AWS S3/Glacier 로 옮긴다.
DB Instance 에 새로운 EBS 를 할당받아, 백업용 파티션을 별도로 구축한다.
관리형 DB (RDS/Aurora) 로 Migration 한다.

가장 하고싶었던 것은 3번이었지만,

관리형 DB 마이그레이션을 테스트 해보았을 때 Stored Procedure 가 일부 제대로 동작하지 않음
RDS 에서 여러 DB 로 나누어진 것을 제대로 인식하지 못함

위와 같은 문제에 봉착하였다. 결론적으로, 2번 (별도의 EBS 를 생성) 방법을 선택하였다. gp3 EBS 를 생성하여, Windows Server 에 mount 시키고, Sql Server 의 백업 위치를 새로 할당받은 파티션으로 변경하였다.

해결된 모습. 앞으로 비즈니스가 3배 정도 성장할 때까지는 현재 인프라로도 무리없이 운영 가능할 것 같다.

이것도 읽어보세요