진행하고 있던 프로젝트의 프리티어 만료 후 운영해보려 했으나 다음과 같이 비용이 너무 많이 나오는 관계로 팀원들과 상의하여 새로운 계정으로 마이그레이션을 진행하기로 결정하였다.
기존 계정에서는 엘라스틱 빈스톡을 통해 EC2, 로드 밸런서 등을 손쉽게 구성할 수 있었다. 그러나 이러한 구성 요소들은 의존성이 강하기 때문에, 그것들을 가장 마지막에 진행하기로 하였다.
대신, 의존성이 덜한 RDS, S3, Elastic Cache를 먼저 마이그레이션 하기로 하였다.
오늘의 핵심 목표는 기존 데이터를 손실시키지 않고 마이그레이션 하는 것이다.
A 계정 : 기존 계정
B 계정 : 새로운 계정
B 계정의 ID 값을 추가해 준다.
테이블이 잘 생성 되었고 데이터도 잘 복원된 모습이다!
그 뒤에는 애플리케이션 서버에서 지정한 기존 RDS 엔드포인트를 새로운 RDS 엔드포인트를 변경해주면 RDS 마이그레이션이 완료 된다.
복사를 할 대상인 Target-Bucket S3에서 S3 Bucket권한을 갖는 IAM 객체를 만들어 해당 키값을 이용하고 복사할 객체를 가지고 있는 Source-Bucket의 Bucket Policy를 수정한 후 IAM 객체의 키 값을 이용하여 AWS CLI를 통해 S3 복사하기를 진행할 것이다
복사를 할 대상인 Target-Bucket S3에서 S3 Bucket 권한을 갖는 IAM 객체를 만들어 해당 키값을 이용하고 복사할 객체를 가지고 있는 Source-Bucket의 Bucket Policy를 수정한 후 IAM 객체의 키 값을 이용하여 AWS CLI를 통해 S3 복사하기를 한다.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:ListBucket",
"s3:GetObject"
],
"Resource": [
"arn:aws:s3:::Source-Bucket",
"arn:aws:s3:::Source-Bucket/*"
]
},
{
"Effect": "Allow",
"Action": [
"s3:ListBucket",
"s3:PutObject",
"s3:PutObjectAcl"
],
"Resource": [
"arn:aws:s3:::Target-Bucket",
"arn:aws:s3:::Target-Bucket/*"
]
}
]
}
Source-Bucket → A 계정의 버킷이름
Target-Bucket → B 계정의 버킷 이름 으로 수정해서 집어 넣어준다.
생성된 정책(s3-copy)을 사용자의 권한 정책에 추가해준뒤,
추가적으로 AWS CLI 를 사용하기 위해 액세스키를 발급 받아 준다.
S3 > A의 버킷 > 권한 > 버킷 정책으로 접근하여 버킷 정책을 추가해 준다.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DelegateS3Access",
"Effect": "Allow",
"Principal": {
"AWS": "Account B's AccountID" << B 계정의 ID 값 입력
},
"Action": [
"s3:ListBucket",
"s3:GetObject"
],
"Resource": [
"arn:aws:s3:::Source-Bucket/*", << A 계정의 버킷 이름 입력
"arn:aws:s3:::Source-Bucket"
]
}
]
}
버킷 정책 설정을 마쳤으면 AWS CLI 에 접속하여 S3에 접근하여야 한다.
https://rainbound.tistory.com/entry/AWS-CLI-설치-및-접속-설정-방법MAC
해당 블로그를 참고하여 설치 및 설정을 하였다( 액세스 키 필요 )
aws s3 ls s3://Bucket-Source
다음과 같이 해당 버킷의 파일들을 확인할 수 있다.
aws s3 sync s3://Bucket-Source s3://Bucket-Target
복사를 진행해준뒤
성공적으로 파일들이 복사된 것을 확인할 수 있다.
백업 파일 내보내기를 하기 전 ElastiCache가 스냅샷을 Amazon S3 버킷에 복사할 수 있으려면 버킷 정책을 업데이트하여 버킷에 대한 ElastiCache 액세스 권한을 부여해야 한다.
s3 버킷 → 권한 → ACL → 피부여자 추가 → 객체 (나열,쓰기) , 버킷 ACL(읽기,쓰기) 체크
540804c33a284a299d2547575ce1010f2312ef3da9b3a053c8bc45bf233e4353 << 피부여자 ID 값
그리고 버킷정책에 들어가서
{
"Version": "2012-10-17",
"Id": "Policy15397346",
"Statement": [
{
"Sid": "Stmt15399483",
"Effect": "Allow",
"Principal": {
"Service": "ap-east-1.elasticache-snapshot.amazonaws.com"
},
"Action": [
"s3:GetObject",
"s3:ListBucket",
"s3:GetBucketAcl"
],
"Resource": [
"arn:aws:s3:::example-bucket",
"arn:aws:s3:::example-bucket/backup1.rdb",
"arn:aws:s3:::example-bucket/backup2.rdb"
]
}
]
}
다음과 같이 추가해준다.
다음으로
S3 버킷으로 .rdb 백업파일을 내보낸다.
해당 백업파일을 다운로드 받는다.
B 계정의 S3에 다운로드 받은 백업 파일을 업로드 해준다.
B계정도 마찬가지로 Redis 캐시를 생성하기 전 s3 의 .rdb 파일에 접근할 수 있도록 읽기 액세스 권한을 부여해줘야 한다.
A 계정에서 진행했던 ACL 과 더불어 버킷정책에 다음과 같이 .rdb 백업 파일에 대한 읽기 액세스 권한을 부여해준다.
540804c33a284a299d2547575ce1010f2312ef3da9b3a053c8bc45bf233e4353 << 피부여자 ID
{
"Version": "2012-10-17",
"Id": "Policy15397346",
"Statement": [
{
"Sid": "Stmt15399483",
"Effect": "Allow",
"Principal": {
"Service": "ap-northeast-2.elasticache-snapshot.amazonaws.com"
},
"Action": [
"s3:GetObject",
"s3:ListBucket",
"s3:GetBucketAcl"
],
"Resource": [
"arn:aws:s3:::jurumarble-bucket", << 본인 버킷 이름
"arn:aws:s3:::jurumarble-bucket/jurumarble-redis-backup-0001.rdb"
]
}
]
}
이렇게 권한을 부여 한뒤에 Redis 캐시를 생성해준다.
다음 그림과 같이 자체 캐시 설계 → 백업에서 복원 → 기타 백업 → 버킷이름/파일이름.rdb 를 넣어주고 기존 계정의 Redis 캐시와 동일하게 설정해주면 마이그레이션이 성공적으로 진행된다!
이렇게, RDS,S3,ElastiCache 마이그레이션 과정을 모두 마무리하게 되었다. 처음에는 데이터 손실이나 서버 연결 문제 등으로 인한 두려움이 있었지만, 차근차근 AWS 공식 문서를 따라가고, 필요한 부분에 대해 구글링을 통해 정보를 얻어가며, 생각했던 것보다 훨씬 수월하게 마이그레이션을 진행할 수 있었다.
이 경험을 통해, 어떤 문제든 조금씩, 단계적으로 접근하면 해결할 수 있다는 것을 다시 한번 깨달았다. 이번 프로젝트 마이그레이션 과정에서 배운 점들을 기록하여 다음 프로젝트에도 활용하고, 계속해서 배우고 성장하는 개발자가 되도록 해야겠다.
참고 :
https://programforlife.tistory.com/108
https://longtermsad.tistory.com/7
https://docs.aws.amazon.com/ko_kr/AmazonElastiCache/latest/red-ug/backups-seeding-redis.html#backups-seeding-redis-create-s3-bucket