참고
AWS의 재해복구
NOTE
재해 복구(Disaster recovery, DR)은 재해에 대비하고 발생 시 복구하는 작업을 의미한다!
•
재해 복구 유형
◦
온프레미스 > 온프레미스
▪
전형적인 재해 복구 유형
▪
비용이 많이 듦
◦
온프레미스 > 클라우드
▪
하이브리드 복구
◦
AWS Cloud 리전 A > AWS Cloud 리전 B
•
복구 시점 목표를 의미하는 RPO
•
복구 시간 목표를 의미하는 RTO
RPO & RTO
NOTE
RPO와 RTO는 최적화 솔루션 아키텍쳐를 결정하는 요인이되고 시간 간격이 짧을수록 비용이 높아짐
•
복구 시점 목표 RPO
◦
얼마나 자주 백업을 하고, 시간상 어느 정도 과거로 되돌릴 수 있는지 결정
◦
RPO가 1시간 ⇒ 오후12시에 재해가 발생한다 ⇒ 오전 11시 이전내에 있던 데이터를 복구해야함!
◦
RPO는 1시간, 1분 등 원하는 대로 설정 가능
◦
재해 발생 시 데이터 손실을 얼마나 감수할지 설정
•
복구 시간 목표 RTO
◦
재해 발생 후 복구할 때 사용됨
◦
RTO 1시간 ⇒ 오후 12시에 재해가 발생한다 ⇒ 시스템을 1시간 이내에 복구!
◦
재해 발생 시점과 RTO의 시간 차는 애플리케이션의 다운 타임
재해 복구 전략
NOTE
⇒ 방향으로 갈수록 비싸다
•
Backup & Restore
◦
아주 쉽고 비용이 저렴하지만 RPO/RTO가 높다
◦
S3, 스토리지 게이트웨이 등을 사용할 수 있다.
•
Pilot Light
◦
애플리케이션 축소 버전이 클라우드에서 항상 실행되고 보통 크리티컬 코어가 되는데 이를 Pilot Light라고 한다
◦
크리티컬 코어 보조에 사용한다.
◦
작은 버전의 앱이 항상 클라우드에서 실행됨!
◦
EC2 인스턴스를 사용해서 호스팅 환경을 다시 생성하고 EC2인스턴스를 중지한다 이후 장애가 발생하면 중지된 인스턴스를 전달함
◦
준비단계
▪
중요 데이터를 복제 또는 미러링하기 위해 EC2, RDS 생성
▪
빠른 복구가 필요한 경우 AMI도 생성
◦
복구 단계
▪
사용자 지정 AMI에서 EC2 시작
•
Warm Standby
◦
비즈니스 중요 시스템과 동일한 기능을 갖춘 축소버전을 항상 클라우드에서 실행!
◦
EC2 인스턴스를 사용해 호스팅 환경을 다시 생성, 10%를 실행중인 인스턴스로 전달하는 방법
◦
RTO 5분의 요구사항을 충족하며, 인스턴스는 낮은 용량으로 실행되며 몇분안에 확장가능!
•
Mulit Site
◦
동일한 솔루션이 온사이트 인프라와 동일한 AWS에서 실행되고 있다!
◦
몇 분, 몇 초 정도로 RTO가 낮지만 비용이 굉장히 비쌈
◦
요구사항을 즉시 해결한다.
◦
AWS와 온프레미스에서 완전 프로덕션 스케일을 얻을 수 있다.
재해 복구 Tip
NOTE
•
백업
◦
EBS 스냅샷, RDS로 자동화된 스냅샷과 백업등을 사용한다
◦
S3, S3 IA, Glacier 등에 스냅샷을 수명 주기 정책을 통해 규칙적으로 푸시할 수 있고 리전간 복제 가능
•
고가용성
◦
Route 53을 사용해 DNS를 다른 리전으로 옮겨서 고가용성 확보
◦
RDS 다중 AZ, ElasticCache 다중 Az.. 등
◦
기업 데이터센터에서 AWS로 연결할 때 DX와 Site-to-Site VPN으로 네트워크 가용성 확보
•
복제
◦
RDS 리전 간 복제, Aurora + 글로벌 데이터베이스로 복제 가능
◦
Storage Gateway
•
자동화
◦
CloudWatch를 통해 CloudWatch의 Alarm이 실패했을 때 EC2 인스턴스 복구, 재시작
•
카오스
◦
재해를 만들어서 대처해 보는 방법
◦
ex) 넷플릭스 ⇒ 모든걸 AWS에서 실행하고 Simian Army를 만들어 EC2 인스턴스를 무작위 종료해 장애가 발생해도 멀쩡한지 테스트 (카오스 몽키)
AWS DataSync
NOTE
온프레미스와 AWS 스토리지 서비스 사이에서 데이터 이동을 자동화 및 가속화하는 서비스!
•
대용량 데이터 이동
◦
온프레미스/다른 클라우드에서 AWS로 - 에이전트 필요
◦
AWS에서 AWS로 - 에이전트 필요 없음
•
동기화
◦
S3, EFS, FSx
•
매시간, 매일, 매주 복제 작업 예약 가능
AWS DMS - Database Migration Service
NOTE
온프레미스 ⇒ AWS 클라우드 DB 이주하고 싶을 때 사용한다!
•
빠르고 안전한 DB 서비스로 복원성이 좋고 자가 복구가 된다는 장점이 있다.
•
DMS를 사용하려면 EC2 인스턴스를 생성해서 복제를 처리하도록 해야 한다.
•
새코드를 작성하지 않고도 S3에서 KinesisData로 스트리밍하도록 확장가능!
•
마이그레이션을 하는 과정에서 소스 DB도 여전히 사용가능하다.
DMS 소스와 대상
NOTE
•
온프레미스에서 대상으로 하는 소스를 변환할 수 있고 이 대상은 보통 AWS에 해당되는데 주로 DB
AWS Schema Conversion Tool
NOTE
•
핵심은 소스 데이터베이스가 대상 데이터베이스와 다른 엔진을 쓴다는 것
•
같은 엔진을 쓰는 DB의 마이그레이션에서는 SCT가 필요없다
•
데이터베이스의 스키마를 다른 엔진으로 변환
AWS Backup
NOTE
AWS 서비스 간의 백업을 중점적으로 관리하고 자동화할 수 있게 지원한다!
•
계정간 백업 지원, Aurora와 같은 지정 시간 복구(PITR)지원
•
태그 기반 정책이 있어서 특정 태그가 지정된 리로스만 백업 가능
•
백업 정책에서 백업 플랜 생성 가능
◦
백업의 빈도(12시간, 매일 ..)
◦
백업을 콜드 스토리지로 이전할지 결정
◦
백업 보유기간 설정