[AWS] AWS 프리티어 마이그레이션-1 (예약 인스턴스, RDS, Elasticache)

개인 공부 목적으로 작성된 글입니다. 왜곡된 내용이 포함되어 있습니다.

 

진행중인 프로젝트 "아워메뉴"에 대한 AWS 클라우드 서비스를 통한 서버 환경 구축을 진행하였다. 기존에 API 서버는 프리티어 EC2위에서 동작하고 있었고, 프리티어 기간 1년이 경과 됨과 이메일 기능과 같은 기능 확장으로 프로젝트에 대한 계정을 새로 생성하여 관리하기로 결정했다. 일부 환경은 마이그레이션을 진행해야한다. AWS 자격증을 취득한 만큼 제대로 AWS 이해하고 사용하는 것을 목표로 잡았다.

1. 예약형 인스턴스

사용해야하는 EC2는 API 서버 + 모니터링 서버 총 2개로 프리티어 인스턴스로는 운영하기에 한계가 있다. 따라서 프리티어 기간에 맞추어 예약형 인스턴스를 구매하여 사용하고자 하였다.

https://aws.amazon.com/ko/ec2/pricing/reserved-instances/

Amazon EC2 - 크기 조정이 가능한 안전한 컴퓨팅 용량 - Amazon Web Services

예약형 인스턴스는 기존 온디맨드 요금과 비교하여 할인된 가격으로 인스턴스를 구매할 수 있는 옵션이다. 1년 이상 장기적으로 인스턴스를 운영해야하는 경우 합리적인 방법이 될 수 있다.

AWS 콘솔에서 인스턴스 하위에 예약 인스턴스를 통해 구매할 수 있다.

구매 옵션 검색

예약 인스턴스 콘솔에서 원하는 인스턴스 옵션을 검색하여 구매할 수 있다.

1-1 구매 실수

계획한대로 예약 인스턴스를 구매하였다. 사전에 조사한 것과 달리 가격이 다르게 책정되어 있어서, "그새 가격이 올랐나" 생각하면서 결제했다. 결제하고 보니 잘못된 리전(시드니)의 예약 인스턴스를 구매했다.

자세히 보면 리전이 시드니..

예약 인스턴스의 경우, 환불이 불가하다고 공식 문서에 나와 있어서 몹시 당황했다. AWS에서 일부 결제 내역이나 실수에 대해서 처리를 해준다는 것을 알고 있어서 일단 메일을 보냈다.

AWS 감사합니다

환불이 원래 불가한 내역이라 AWS 담당 서비스팀에서 회의가 필요하다는 회신이 왔다. 해외 AWS 상품을 구매했기 때문에 시드니 리전 AWS 와의 시차로 인한 지연으로 시간이 2주 정도 걸렸지만 환불 받았다.

1-2 T3

다시 서울 리전 대상으로 예약형 인스턴스를 구매하였다. 다만 이때, EC2 인스턴스 유형을 T2 대신 T3으로 구매하였다. 프리티어 인스턴스 유형인 T2를 구매하려다 T3의 가격이 비교적 저렴하고, T3는 무제한 모드를 지원하는 것으로 알고 있어서 T3으로 변경하였다.

관련된 동영상을 첨부한다.

https://www.youtube.com/watch?v=lmJBrtpJkNU

 

같은 실수를 반복할 수 있어서 구매 옵션을 여러번 읽고 구매했다.

제대로 구입한 예약 인스턴스

 

2. 네트워킹

인스턴스를 구매했으니, 본격적으로 환경 구축을 해보자

기존에는 EC2와 RDS, CloudWatch를 제외한 다른 것들을 설정하지 않고 기본 VPC에 모든 것을 추가했지만, 이번에는 별도의 VPC 구축하였다.

직접 VPC 및 네트워킹을 구축하기 위해서는 다음을 직접 추가해야한다.

• VPC
• Subnet
• Routing Table
• Internet Gateway

초기 VPC

서울 리전의 경우 4개의 가용영역이 존재하지만, 하나의 가용영역만 생성해서 사용하고자 한다(아직 여러 가용영역을 사용할 이유가 없다)

+) RDS를 사용하는 경우 장애 조치를 위해 최소 서로 다른 가용영역 2개의 서브넷을 구성해야 한다.

수정된 VPC

3. EC2 생성

이제 EC2를 생성하여 생성한 VPC Subnet에 추가하면 된다.

예약 인스턴스의 경우, 별도의 설정 없이 구매한 인스턴스 옵션과 동일한 인스턴스를 생성하면 해당 인스턴스의 요금이 면제된다.

 

이때 스토리지의 경우, 프리티어는 기본적으로 30GB를 제공한다. 운영 서버 및 모니터링 서버의 리소스를 효율적으로 관리하는 연습을 하고, 만약 스토리지가 부족하면 스토리지를 추가해도 문제없기 때문에 적은 양의 스토리지를 할당하여 생성하였다.

 

4. RDS 마이그레이션 (실패)

새로 생성한 RDS

기존에 배포했던 서버가 운영중인 서버는 아니였기 때문에 서버의 경우 별도의 마이그레이션 작업 없이 진행하였지만, RDS의 경우 기존 RDS 데이터를 마이그레이션 하고자 였다

RDS에서 수동 스냅샷을 생성한다

수동 스냅샷 생성

RDS 스냅샷을 다른 AWS 계정으로 공유할 수 있다.

스냅샷 공유

 

마이그레이션 대상 계정 콘솔로 돌아서 스냅샷에 "나와 공유됨" 탭에 공유된 스냅샷을 확인 할 수 있다.

공유된 스냅샷

스냅샷 복원을 통해 RDS 인스턴스를 새로 생성할 수 있다

공유된 스냅샷이 암호화되어 있어서 실패했다. 설상 가상으로 기존 RDS를 AWS 자체 관리형 KMS 키로 암호화를 진행한 터라 KMS키를 공유할 수 없어 데이터베이스 마이그레이션을 할 수 없었다.

https://docs.aws.amazon.com/ko_kr/ko_kr/AmazonRDS/latest/UserGuide/share-encrypted-snapshot.html

Amazon RDS의 암호화된 스냅샷 공유 - Amazon Relational Database Service

따라서 mysqldump를 통해 RDS 마이그레이션을 진행하였다.

 

5. ElastiCache 추가

기존 API 서버에서는 동일한 EC2에 Redis를 설치하여 사용하였지만, API 서버 노드에 대한 부하를 최대한 줄이고, 기존 Redis에서 AWS 에서 제공하는 Elsatic Cache로 전환하였다. 프리티어의 경우 Elastic Cache Redis OSS 에 대해 특정 컴퓨팅 버전에 대해 다중 AZ, 클러스터 모드를 비활성화 하는 조건으로 무료로 제공한다. 다중 AZ를 지원하지 않기 때문에 기존 API 서버 EC2와 동일한 가용영역 프라이빗 서브넷에 배치하였다