AWS 프리티어 유목민을 위한 계정 이전 과정 정리 (MySQL, S3)

사람·2025년 4월 29일
1

Backend

목록 보기
5/11

얼마 전에, AWS로부터 4월 30일에 프리티어가 만료된다는 슬픈 메일을 받았다...ㅜㅜ
곧 서비스가 론칭될 상황이라 본격적으로 리소스가 많이 사용될 예정이었기 때문에 걱정이 되지 않을 수 없었다.
서비스가 론칭된 이후에는 지금처럼 새롭게 세팅하고 할 여유가 더 없어질 것 같아서, 결국에는 새로운 AWS 계정으로 갈아 타기로 결정했다.
프리티어 유목 생활을 하는 가난한... 대학생들이 나 말고도 많을 것 같아 이렇게 글로 정리해 보았다.

본인의 경우 기존 서버, 새로운 서버 모두 Ububntu 24.04 LTS이다.

MySQL 데이터 백업 및 복원

새로운 EC2 서버에 MySQL을 설치하고, 설정까지 완료한 상태로 다음의 작업들을 수행해야 한다.
서버 이전을 한다는 것은 이미 설정해서 운영 중인 서버가 있었다는 것이니 이 글을 읽는 사람이라면 서버 생성 및 설정 방법은 대략 알고 있을 것 같지만, 혹시 어려움이 있다면 제가 이전에 작성했던 글을 참고해주세요!

1. mysqldump 명령을 사용해 데이터를 SQL 파일로 추출

mysqldump -u [username] -p[password] [database_name] > backup.sql


ls 명령어로 확인해 보면 위와 같이 sql 백업 파일이 새롭게 생성되었음을 확인할 수 있다.

2. 백업 데이터를 새로운 서버에 전송

2-1. 로컬에 저장되어 있는 새로운 서버의 key 파일을 기존 서버에 전송

새로운 서버에 파일을 전송하려면 scp 명령을 이용하면 된다.
그런데 새로운 서버에 접속하기 위해서는 key가 필요한데, 기존 서버에는 새로운 서버의 key 파일이 존재하지 않기 때문에 일단 기존 서버에 새로운 서버의 key 파일을 옮겨둬야 한다.

로컬 터미널에 다음과 같이 입력한다.
(저는 맥북을 사용합니다. 윈도우 터미널 명령어는 다소 다를 수 있습니다.)

scp -i [기존-서버의-key.pem] [새로운-서버의 key.pem] ubuntu@[기존-서버의-public-ip]:[전송 경로]

2-2. 전송 받은 새로운 서버의 key를 이용해 새로운 서버에 백업 데이터 전송

기존 서버에 다음과 같이 입력한다.

scp -i [새로운-서버의-key.pem] backup.sql ubuntu@[새로운-서버의-public-ip]:[전송 경로]


새로운 서버에서 ls 명령어로 확인해 보면 위와 같이 sql 백업 파일이 전송되어 있음을 확인할 수 있다.

3. 새로운 서버에서 MySQL에 데이터 복원

3-1. MySQL에 데이터베이스 생성

새로운 서버에 mysql -u [사용자명] -p를 입력해 MySQL에 접속한 후,

CREATE DATABASE [백업한-db명];

위와 같이 백업한 db와 동일한 이름으로 database를 생성해준다.

3-2. 백업 파일 import

mysql -u [username] -p [백업되어-있는-db명] < backup.sql

위 명령을 입력하면 백업 파일을 새로운 서버의 MySQL에 import할 수 있다.


import후 확인해 보면 이전 서버에서 생성했던 테이블들과 그 안의 레코드들이 모두 그대로 들어와 있다.

MySQL 데이터 이동 성공...!

2. S3 파일 백업 및 복원

2-1. AWS CLI 설치

이미 설치가 되어 있다면 넘어가면 된다.
설치가 안 되어 있다면 공식 사이트에 나와 있는 대로 설치하면 된다.

2-2. AWS CLI 계정 확인

AWS CLI가 새로운 계정의 IAM 사용자로 로그인되어 있어야 한다.

aws sts get-caller-identity

터미널에 위 명령어를 입력해 새로운 계정에 로그인되어 있는지 확인한다.

만약 새로운 계정에 로그인되어 있지 않다면, 터미널에

aws config

를 입력하면 새로운 계정으로 전환할 수 있다.

위 명령을 입력하면 다음과 같이 뜨는데,

AWS Access Key ID [None]: 로그인하려는 IAM 사용자의 Access Key 입력
AWS Secret Access Key [None]: 로그인하려는 IAM 사용자의 Secret Access Key 입력
Default region name [None]: ap-northeast-2 (서울 리전)
Default output format [None]: json

위와 같이 입력해주자.
(Access Key와 Secret Access Key는
AWS 콘솔 → IAM → 사용자 → 보안 자격 증명 탭 → 새 Access Key 발급
에서 발급받을 수 있다.)

2-3. ListBucket 권한 부여 설정

이 역시 이미 권한 부여가 되어 있다면 넘어가면 된다.
(2-4를 수행할 때 An error occurred (AccessDenied) when calling the ListObjectsV2 operation: Access Denied라는 오류가 뜬다면 ListBucket 권한 부여가 되어 있지 않다는 뜻이다.)

권한 탭에 들어가 기존 계정의 S3 버킷과 새로운 계정의 S3 버킷에 모두 다음의 버킷 정책을 추가한다.

"Statement": [
  {
  "Sid": "AllowListBucketForEveryone",
  "Effect": "Allow",
  "Principal": "*",
  "Action": "s3:ListBucket",
  "Resource": "arn:aws:s3:::bucket-name-itself"
  }
]

Resource의 버킷명은 현재 정책을 수정하고 있는 자기 자신의 버킷명을 적어주면 된다.
나는 어차피 이 ListBucket 권한은 파일 복사가 끝나면 삭제할 생각이라 Principal을 "*"로 두어 누구나 ListBucket 권한을 가지도록 했는데, 보안을 위해 특정 IAM 유저에게만 ListBucket 권한을 주고 싶다면 Principal의 value 값으로 "arn:aws:iam::123456789012:user/your-username"와 같이 IAM 유저의 ARN을 주면 된다.

2-4. 기존 S3 버킷의 파일을 새로운 계정의 S3 버킷으로 복사

로컬 터미널에 다음과 같이 입력하자.

aws s3 sync s3://이전-버킷명 s3://새로운-버킷명 --source-region ap-northeast-2 --region ap-northeast-2

그러면 이런 식으로 복사가 이뤄질 것이다.

3. DB에 저장된 S3 URL을 새로운 URL로 일괄 변경

기존 계정의 S3 버킷을 삭제하면 당연히 기존에 DB에 저장되어 있던 URL로는 파일에 접근할 수가 없게 된다. DB에 저장되어 있는 URL을 새롭게 할당된 URL로 변경해보자.

S3 버킷 URL은 항상

https://your-bucket.s3.ap-northeast-2.amazonaws.com/image1.jpg

위와 같은 형태이기 때문에, 위 URL에서 'your-bucket' 부분만 새로운 버킷명으로 변경해 주면 된다.
다음과 같은 형태의 쿼리를 통해 일괄 변경이 가능하다.

UPDATE table_name
SET file_url = REPLACE(
  file_url,
  'https://old-bucket.s3.ap-northeast-2.amazonaws.com',
  'https://new-bucket.s3.ap-northeast-2.amazonaws.com'
)
WHERE file_url LIKE 'https://old-bucket.s3.ap-northeast-2.amazonaws.com%';

나는 이번에 S3 직접 URL 대신 CloudFront URL을 통해 파일에 접근하도록 변경했기 때문에, 아래와 같은 쿼리로 일괄 변경을 해주었다.

UPDATE table_name
SET file_url = REPLACE(
   file_url,
  'https://old-bucket.s3.ap-northeast-2.amazonaws.com',
  'https://dc70yyxvhpj8a.cloudfront.net'
)
WHERE group_img LIKE 'https://old-bucket.s3.ap-northeast-2.amazonaws.com%';

이렇게 CloudFront를 거치게 하면 S3 직접 URL을 사용하는 것보다 보안상 안전해지고, 만약 커스텀 도메인을 사용한다면 이후에 AWS 계정을 옮기더라도 DB에 저장된 URL을 변경할 필요 없이 그대로 사용할 수 있다고 한다!
S3와 CloudFront의 연동 과정은 이전 글에 정리해 두었다.

profile
알고리즘 블로그 아닙니다.

0개의 댓글