[Mybrary] AWS 계정 이전 일기: #1. RDS 마이그레이션

VPC 구축이 완료되었으니, 이제 차례차례 리소스를 마이그레이션 해보자.

당시 제일 만만해보였던 RDS부터 데이터를 옮겨주고자 했다.

왜 만만해보였냐면,,

RDS > 스냅샷 > 작업 > 스냅샷 공유 탭

요렇게 스냅샷만 공유해주면, 공유된 계정에서 그대로 RDS 인스턴스를 복구할 수 있을 것이라고 생각했기 때문,,

 

그런데 반은 맞고 반은 틀렸음

나의 작고 소중한 기억들과 휘날려 쓴 메모들을 기반으로 어떤 이슈가 있었는지 찬찬히 되짚어보자

 

Background

본 게시글은 1331 계정에서 0851 계정으로 RDS 인스턴스를 마이그레이션하는 과정과 그 사이의 이슈들을 다룬다.

• 1331 계정: SW마에스트로에서 700만원 가량의 크레딧을 지원받은 그룹 계정으로, 14기 수료식 이후로는 개인 카드로 과금된다고 하여 급하게 리소스를 모두 삭제한 계정
• 0851 계정: 팀원들과 함께 사용하는 서비스 전용 계정으로, 깜찍하게 @mybrary.kr 도메인도 달려있다😄 팀쟝님 체크카드로 과금되도록 해둔 개인 계정이라 볼 수 있다 (but 좋은 기회로 크레딧을 지원 받고 있긴 하다 ^-^v)

기존 1331 계정에는 2개의 RDS 인스턴스를 굴리고 있었다.

• userservice-db: 사용자 계정, 프로필, 관심사, 팔로우 등에 대한 데이터 저장
• bookservice-db: 검색된 도서, 소장 도서, 도서 리뷰, 도서 추천 피드 등에 대한 데이터 저장

요 인스턴스들로 스냅샷을 떠서 0851 계정으로 공유한 다음에,

0851 계정에서 스냅샷 복원을 하면 될 것이라 생각했다.

 

#1.  스냅샷 공유를 통한 RDS 마이그레이션

https://devocean.sk.com/blog/techBoardDetail.do?ID=164941&boardType=techBlog

계정간 Migration 방법 I : AWS RDS 스냅샷

위의 글을 참고해서

1. KMS Customer managed key 생성 (Key policy에서 계정 권한 추가 필요)
2. 생성된 Customer managed key로 RDS 인스턴스 스냅샷 생성(또는 기존 스냅샷 복제)
3. 마이그레이션 할 계정으로 스냅샷 공유
4. 공유된 스냅샷을 통해 인스턴스 생성

단계를 거쳐서 1331 계정에 있던 RDS 인스턴스를 그대로 0851 계정으로 옮길 수 있었다.

 

ㅎㅎ근데 처음엔 Customer managed key로 스냅샷을 떠야하는 줄 몰랐다.

이미 1331 계정의 RDS 인스턴스는 삭제해버렸고,

AWS managed key(default key)로 만들어진 스냅샷만 남아 있어서 식은 땀이 났다.

 

다행히 기존 스냅샷을 복제한 담에 Customer managed key로 암호화되도록 설정 하는 방법이 있었다.

🙃천만다행

제법 뿌듯했나보다

호다닥 Bastion 서버를 통해 접속하여 데이터들이 무사한지 확인해봤다 모두 무사했다!!

 

#2. 1331 계정 탈퇴 이후,, 돌연 죽어버린 데이터베이스

ㅋㅎㅋㅎ,, 말 그대로 리소스를 모두 이전한 다음 1331 계정을 탈퇴 신청 해두었는데

계정이 탈퇴 처리된 후 기가 막히게 데이터베이스가 죽어버렸다.

돌연 집이 무너져버린 비버와 같은 심정이었다.

 

이유가 무엇인고 하니,,

Inaccessible-encryption-credentials-recoverable

1331 계정에서 만든 Customer managed key가 삭제되어 그런 것이라 파악했다.

음,, 그렇지 아무래도 기존 key arn으로는 더이상 리소스를 찾을 수 없을테니,, 🥲

 

일단 계정부터 복원해야겠다고 판단했다.

해지한 AWS 계정은 90일 내로 복원 신청이 가능했다!

🙃천만다행22

 

1331 계정 복원 이후, 다음과 같은 과정을 거쳐

1331 계정과 완전히 독립된 RDS 인스턴스를 0851 계정에 생성했다.

 

1. 1331 계정 복원 후에도 기존 Customer managed key를 찾을 수 없음 -> 새로운 Customer managed key 생성 (1331-custom)
2. 1331-custom 키로 스냅샷 사본 생성
3. 스냅샷 사본 공유
4. 공유된 스냅샷으로 0851 계정에서 인스턴스 생성, 실행
5. 실행 중인 인스턴스의 스냅샷 생성 (여전히 1331-custom 키로 암호화된 상태)
6. 0851 계정에서 Customer managed key 생성 (rds-kms-custom)
7. rds-kms-custom 키로 스냅샷 사본 생성
8. 해당 스냅샷 사본으로 다시 인스턴스 복원 -> rds-kms-custom 키로 암호화된 것으로 확인!

요약하자면 스냅샷 복사 -> 공유 -> 복구 -> 스냅샷 생성 -> 복사 -> 복구 과정을 거침

 

친절하고 빠르게 계정 복구를 진행해주신 AWS 문의처(?)에게 감사할 따름,,

 

#3. 느낀점

1331 계정이 해지됨에 따라, 이에 종속적이었던 데이터베이스에 아예 접근 조차 못한 귀한 경험을 했다고 생각한다.

음,, 계정 탈퇴는 신중히 진행해야 되는 것이 맞지만, 다시 그 전으로 돌아가도 kms 리소스 종속성은 못찾아내지 않았을까,,

자원에 대한 가시성이 떨어진다 였나,, 아무튼 클라우드 도입 시 고려할 부분이라고 어디선가 읽었는데 이번에 조금 체감됐던 것 같다.

 

그럼에도 계정 간 DB 마이그레이션이 뚝딱 된다는 점에서 RDS는 매우 편리한 관리형 DB 서비스임이 분명하다고 생각한다.

인스턴스 생성, 읽기 전용 복제본 구성, 파라미터 편집, 스냅샷 생성, 복원 외에도 다양한 기능이 있겠지

더 공부해보면 좋을 것 같다~! (비싸서 이 이상 직접 써보지는 못하겠음^^,,)

 

Wrap Up

계정 간 스냅샷 공유를 통한 RDS 인스턴스 마이그레이션 과정에 대해서 살펴 보았다.

원본 계정이 해지되면 공유된 계정에서 key arn을 찾을 수 없어 돌연 DB가 죽어버릴 수 있다는 사실을 널리 알리고 싶다.

 

다음에는 S3 버킷에 있는 데이터를 어떻게 옮겼는지 작성해 보겠다. (제일 간단했음)