이 글은 24년 하반기 AWS Certified Solutions Architect - Associate(이하 AWS SAA-C03) 자격증 취득을 위해서 아래 유데미 강의를 보고, 공부한 내용을 정리하였습니다.
https://www.udemy.com/course/best-aws-certified-solutions-architect-associate
AWS Disaster Recovery
- 재해: 회사의 사업 지속이나 재정에 부정적 영향을 미치는 이벤트
재해 복구 유형
- 온프레미스 간 : 전통적인 DR로 매우 비쌈
- 온프레미스(기본) -> 클라우드 : 하이브리드 복구
- 모두 클라우드 : 리전 간 복구 수행
RPO, RTO
RPO(복구 시점 목표, Recovery Point Objective)
- 얼마나 자주 백업 수행할지... 시간상 어느 정도 과거로 되돌릴 수 있는지
- 데이터 손실을 얼마나 감수할지와 연결됨
RTO(복구 시간 목표, Recovery Time Objective)
- 애플리케이션 다운타임이 얼마나 되는지
재해복구 전략
* 밑으로 갈수록 빠른 RTO
백업 및 복구
- 높은 RPO, 적은 비용(저장 비용만 발생)
- DC라면 AWS Snowball이나 AWS 스토리지 GW로 S3에 백업
- AWS 클라우드(EBS, Redshift, RDS)라면 정기적 스냅샷 예약 후 백업
- 재해 상황에 데이터를 전부 복구해야함으로 RTO는 커짐
파일럿 라이트
- 애플리케이션의 축소버전(크리티컬 코어)이 클라우드에서 항상 실행 중
- 백업 및 복구와 유사
- 재해 상황에 코어 시스템 외에 여타 시스템만 더해주면 되니까 복구 속도는 좀 더 빠름
- 사례 : 온프레미스에서 서버와 DB가 있을 때, DB만 RDS에 계속 복제하는 방법.. 재해 상황에 서버만 복구
웜 대기
- 시스템 전체를 실행하되, 최소한의 규모로 가동해서 대기하는 방법
- 재해 발생 시 프로덕션 로드로 확장 가능
- 사례 : 온프레미스에 앱 서버, 마스터 DB를 두고, 클라우드에 RDS Slave로 데이터 복제.. 이때 EC2 ASG로 최소한의 서버를 유지하고, ELB도 유지... 재해 상황에 Route53에서 경로만 바꿔서 페일오버되게함
핫 사이트 / 다중 사이트 접근
- 몇 분/초 단위로 RTO는 낮지만 비용이 높음
- AWS와 온프레미스에서 두 완전 프로덕션 스케일을 얻게됨
- 클라우드와 온프레미스 모두 active-active 상태를 유지하고, 온프레미스 DB - AWS RDS 사이 Master/Slave 관계 유지
다중 리전
- 모두 AWS에서 실행하고, 다른 리전에 위치하게 함
- Aurora Global로 DB 유지.. 페일오버 시 완전 프로덕션 스케일이 다른 리전에서 가능
재해 복구 팁
백업 : AWS에서 EBS 스냅샷, RDS 자동 백업, S3 등에 푸시 / 수명 주기 정책 실행, Snowball
고가용성 : Route53으로 DNS를 다른 리전으로 옮기기, 다중 AZ 실행, VPN / DC 같이 사용
복제 : RDS 리전 간 복제, Aurora Global, 온프레미스에서 RDS로 복제
자동화 : CloudFormation, Elastic Beanstalk, CW, Lambda
카오스 테스트 : 사례) 넷플릭스는 프로덕션 EC2 인스턴스를 무작위로 종료
Database Migration Service
DMS 특징
- 온프레미스에서 AWS로 DB 마이그레이션 할 때, DMS 사용
- 빠르고 안전한 DB 서비스.. 복원력 있고 자가 치유 가능하다는 장점
- 마이그레이션해도 출발지 DB를 계속 쓸 수 있음
- 다양한 유형 엔진 지원 : Oracle 간, Postgre 간.. MS SQL Server에서 Aurora로 동종/이종 migration 가능
- CDC, Change Data Capture를 이용한 지속적 데이터 복제도 가능
- DMS 쓸려면 EC2 인스턴스를 만들고, EC2 인스턴스가 대신 복제 작업 수행
DMS 소스와 타겟
출발지(소스) : 온프레미스/EC2 인스턴스 기반 DB인 Oracle, MS Server, MySQL... 등등 대부분 가능, Azure DB, S3, DocumentDB 가능
도착지(타겟) : 온프레미스/AWS 대부분 DB, Redshift, DynamoDB, S3, OpenSearch, KDS, Apache Kafka, DocumentDB, Neptune, Redis, Babelfish 가능
(다 외울 필요 없음)
`Schema Conversion Tool
- SCT는 소스와 타겟 간, DB 엔진이 다를 때 사용
- 사례 : OLTP(SQL Server, Oracle)에서 MySQL, PostgreSQL, Aurora로 마이그레이션 시 사용
- SCT는 DMS와 같이 EC2 인스턴스에서 실행
- 동종 간 마이그레이션 시에는 사용할 필요 없음
지속적 복제 방법
1. 온프레미스에 Oracle DB, AWS에 MySQL RDS 위치
2. 먼저 온프레미스 서버에 AWS SCT 설치 후, RDS에 스키마 변환
3. 이후 EC2에 DMS 복제 인스턴스를 생성해서 Full load와 CDC하도록 함
4. 지속적으로 온프레미스 DB에서 EC2를 거쳐서 RDS로 마이그레이션 됨
멀티 AZ 배포
- 다른 AZ에 각각 DMS 인스턴스를 두고, 동기화 복제해두면 StandBy Replica로 동작
- 장점 : AZ 장애시 회복력을 가짐, 데이터 리던던시를 가짐, I/O 멈춤 현상 없어짐, 레이턴시 스파이크 최소화
RDS, Aurora Migrations
RDS MySQL을 Aurora MySQL로 마이그레이션 하는 방법
1. RDS 스냅샷을 생성하고, MySQL Aurora DB에서 복원하는 방법(다운타임 발생)
2. MySQL 읽기 복제본을 Aurora에서 생성하는 것.. 지연시간이 0일 때, 복제본을 DB 클러스터로 승격
- 다운타임은 없지만, 시간이 오래걸리고, 네트워크 비용 발생 가능성
MySQL DB가 외부에 있을 때
1. Percona XtraBackup 기능을 사용해서 백업 후 S3에 옮겼다가, S3에서 Aurora로 가져옴
2. mysqldump 기능으로 내보내고, Aurora에서 출력값을 불러옴(단 시간이 많이 듬)
공통적으로 DMS 써서 지속적 복제 가능
`AWS를 통한 온프레미스 전략
- Amazon Linux 2 AMI를 다운(.iso 파일) 받아서, 온프레미스에서 VM으로 로드 가능
- VM을 EC2 인스턴스로 마이그레이션 할수도 있음
- 온프레미스 VM으로, DR 리포지토리 전략을 만들 수도 있음
- AWS Application Discovery Service는 온프레미스 정보를 모아주고 마이그레이션을 계획할 수 있게 해주는 서비스.. 서버 사용량과 종속성 매핑 정보 제공... 온프레미스에서 클라우드로 대량 마이그레이션에 유용
- AWS Migration Hub로 마이그레이션 추적 가능
- DMS로 온프레미스, AWS 간 어떠한 조합이든 DB 마이그레이션 가능
- AWS Server Migration Service로 온프레미스 라이브 서버를 AWS로 복제 가능.. AWS로 볼륨을 직접 복제도 가능... 증분 복제
AWS Backup
- 완전 관리형, AWS 서비스 간의 백업을 중점적으로 관리하고 자동화 가능
- 중앙 시스템이 없고, 사용자 지정 스크립트나 메뉴얼 필요 없음
- 지원 서비스 : EC2, EBS, S3, RDS, Aurora, DynamoDDB, DocumentDB, Neptune, EFS, FSx, Storage GW
- 리전/계정 간 백업 지원
- PITR(지정 시간 복구) 지원
- 온디맨드와 함께 예약 백업 지원
- 태그 기반 백업 정책으로 프로덕션 태그 있는 서비스만 백업도 가능
- 백업 플랜을 만들어서 백업 빈도, 백업을 콜드 스토리지로 이전할지, 백업 보유 기간 등 설정
- AWS 백업은 플랜을 만들면 그에 따라 주요 리소스들을 자동으로 S3 내부 버킷에 백업
Vault 잠금
- WORM 정책 시행시, 백업 볼트에 저장한 백업 삭제 불가... 루트 사용자도 삭제 못함
Application Migration Service(MGN)
- 온프레미스 DC에서 클라우드로 마이그레이션 계획을 도와줌
- 서버를 스캔하고, 마이그레이션에 중요한 서버 설치 데이터 및 종속성 매핑에 대한 정보 수집
마이그레이션 방법
1. Agentless Discovery
- Connector를 사용... VM, 구성, CPU/RAM/DISK 사용량과 같은 성능 기록에 대한 정보 제공
2. Agent-based Discovery
- VM 내에서 더 많은 업데이트와 정보를 얻을 수 있음
- 시스템 구성, 성능, 프로세스, 시스템 사이 NW 연결 등 종속성 맵핑 정보 얻음
결과 데이터를 AWS Migration Hub 서비스에서 볼 수 있음
- MGN을 이용해서 쉽게 어플리케이션을 AWS로 마이그레이션하는 리호스팅(lift and shift) 가능
- MGN으로 적은 비용의 EC2와 EBS로 데이터를 지속적 복제하고, '컷오버'를 수행해서 프로덕션용 EC2, EBS로 높임... 다운 타임 적음
대규모 데이터 전송
상황: 200GB 데이터 옮기고 싶은데, 지금 인터넷 연결 100Mbps
1. 공용 인터넷 쓰기, Site-to-Site VPN 설치
- 즉시 설정할 수 있지만, 데이터 보내는데 반 년이 걸림
2. DC를 통해 1Gbps로 보내기
- 초기 설치에 시간이 오래 걸림, 연결 후에 18일 걸림
3. Snowball
- 2, 3개 스노우볼 필요하고 병렬 주문으로 동시에 도착하게 함
- 1주일 정도 종단간 전송 필요
- DB 있다면 DMS로 전송
- 1회성 전송
지속적 복제 : Site-to-Site VPN or DX with DMS or DataSync
VMware Cloud on AWS
상황 : 온프레미스에 DC있을 때 VMware Cloud로 DC 관리하는 경우, 고객은 DC 용량을 AWS로 늘리고, 클라우드와 AWS를 둘 다 쓰고 싶음, 하지만 VMware Cloud SW를 계속 쓰고 싶음
- VMware Cloud on AWS를 쓰면 VMware 하위서비스(vSphere, cSAN, NSX 등)에서 사용 가능
사례
1. 컴퓨팅 성능 확장해서 DC에서 클라우드뿐 아니라 스토리지까지 컴퓨팅 가능해져, VMware 기반 워크로드를 AWS로 마이그레이션하기
2. 프로덕션 워크로드를 여러 DC간 실행
3. 재해 복구 전략으로 사용
4. 다양한 AWS 서비스를 활용
