개요
클라우드 컴퓨팅의 시대가 오면서 DB 서버 운영에도 많은 변화가 생겼다.
그 중에서도 AWS의 rds서비스는 개발자에게 강력한 편의를 제공하고 있다.
나도 개인 프로젝트를 진행할 때에 모두 rds를 이용해 DB 관리를 하고 지금 재직 하고 있는 회사에서도 유용하게 사용하고 있다.
최근 회사에서 업무 중에 Dev DB의 설정을 바꾸고 Prod DB 의 데이터를 복사해야 하는 상황이 생겼는데 rds 스냅샷 을 이용해 편리하게 업무를 진행 할 수 있었다.
해당 과정에 대해 기록하고 조심해야될 부분을 복기해보자 !
스냅샷
스냅샷이란 특정 시점의 데이터 저장 장치 상태를 파일 이나 이미지로 저장 하는 것을 의미한다.
윈도우즈 환경에서 문제가 생겼을 때 복원 시스템을 사용해본 적이 있을 것이다.
이 때 특정 이슈나 주기적인 스케줄에 맞춰서 운영체제는 데이터 저장 장치의 모든 상태를 저장하고 유저의 필요에 따라 해당 시점으로 데이터를 복원 할 수 있도록 한다.
즉 백업 및 복원을 할 수 있도록 데이터 저장 장치의 특정 시점으로 기록하는 행위 또는 그 행위를 통해 나온 정보를 가지고 있는 이미지 파일을 의미한다.
AWS rds에서의 스냅샷
AWS rds 스냅샷은 크게 자동, 수동 두 종류로 나뉜다.
- 자동
- 사용자가 정해둔 일정에 따라 주기적으로 rds 인스턴스의 상태를 저장
- 사용자의 설정에 따라 각각의 스냅샷은 보존기간을 가지고 있음
- 특정 패턴에 따라 이름이 설정되어 저장됨
- 공유 불가능
- 수동
- 사용자가 원하는 시점에 스냅샷을 만듬
- 공유 가능
- 별도의 보존기간을 가지고 있지 않음 (무기한)
일반적인 서비스 환경에선 자동 스냅샷 방식을 주로 사용할 것이다.
꼭 기록해야 하는 중요한 시점이나 이슈가 발생할 만한 가능성이 큰 작업 직전에는 수동 스냅샷 기능을 사용한다면 적절할 것으로 생각된다.
두 가지 모두 공통의 주의 사항이 있는데 바로 DB 스냅샷을 만드는 동안 다소 시간이 걸리는데 문제는 이 때 DB 인스턴스 설정에 따라 I/O가 중지 될 수도 있고 유지될 수도 있다는 것이다.
중지가 될지 안 될지를 결정하는 것은 다중 AZ 설정 여부이다.
다중 AZ
다중 AZ란 하나의 리전에서 여러개의 가용 영역을 사용하는 것을 의미한다.
예를 들어 아시아 서울 리전의 경우 4개의 가용영역이 존재하는데 단일 AZ의 경우 4개 중 하나의 가용 영역만을 사용 하는 것이고 다중일 경우 2개 이상의 다수의 가용 영역을 사용 하는 것이다.
다중 AZ를 사용할 경우 DB에 문제 상황이 발생했을 때 다른 가용영역에 존재하는 DB 복제본을 이용하여 실제 서비스에 영향이 없도록 도와 준다.
- DB에 변화가 생길 경우 다른 가용 영역에 복제본 생성
- DB에 문제가 생겼을 때 자동으로 만들어두었던 복제본 사용
이런 시스템으로 동작하기 때문에 다중 AZ의 경우 스냅샷을 만들더라도 DB 운영에는 특별한 이슈 없이 진행할 수 있게 된다.
주의 할 점은 다중 AZ의 경우 더 많은 가용 영역을 사용하게 되는 만큼 비용이 많이 발생 (약 2배 가까이 발생.. ㅎㄷㄷ,,) 할 수 있고, 성능 향상과는 무관 하다는 것이다.
성능 향상을 원한다면 읽기 전용 DB를 만드는 방식을 사용 하는 것이 좋다.
https://aws.amazon.com/ko/about-aws/global-infrastructure/regions_az/
스냅샷 생성
AWS에서 수동으로 스냅샷을 만드는 법은 아주 간단하다.
우선 AWS 콘솔에 접속해야 한다.
이후 rds의 탭으로 이동하여 좌측의 스냅샷 메뉴로 이동하면 된다.
생성 탭에서 스냅샷을 만들 인스턴스와 저장될 스냅샷의 이름을 설정해주면 된다.
약간의 시간을 기다리면 스냅샷이 생성 된다.
스냅샷 복원
스냅샷 복원은 스냅샷에 담긴 데이터 정보를 토대로 완전히 같은 DB 인스턴스를 새로 만드는 과정이다.
기존 DB에 백업 데이터를 Import 하는 것과는 차이가 있다.
우선 스냅샷 메뉴로 다시 이동해보면 방금 생성한 스냅샷이 존재한다.
해당 스냅샷을 체크한 이후에 우측 작업에서 스냅샷 복원 메뉴를 클릭 하면 된다.
그러면 DB 인스턴스를 만들 때 보았던 설정 화면이 나온다.
사용 목적에 맞게 적절하게 설정하면 DB 복원 완료다 !
주의 할 점
본인 회사에서는 장고를 메인 프레임 워크를 사용하는데 스냅샷 복원 이후 dev 환경에서 마이그레이션 에러가 발생했다.
원인을 파악해보니 prod db를 물리적으로 다 복제하다보니 장고가 마이그레이션 기록을 확인는데 쓰이는 테이블인django_migrations 까지 복제되어 실제 프로젝트내부의 마이그레이션 파일과 DB 정보가 어긋나게 되어 생긴 일이었다.!
아무래도 특정 테이블의 DB 덤프를 만드는 것이 아닌 인스턴스의 모든 상태를 저장하는 방식이라 세심한 조정은 어려운 부분이 있다.
이런 이슈에 대해서 미리 알고 혹시라도 유지되어야 할 데이터가 있다면 덤프 파일을 만들어서 보관 하는 조심성이 필요하다.
