복원력과 비즈니스 연속성 보장을 위한 AWS 백업 및 복구 솔루션
ㅇ 재해 복구 계획
- 테스트: DR 계획 테스트해 구현을 검증
정기적으로 워크로드 재해 복구 리전으로 장애 조치 테스트해 복구 목표 충족 확인 - 리소스: 복구 경로를 프로덕션 환경에서 실행
리소스가 운영에 충분한지 확인
-계획: 유일한 복구 계획은 잦은 테스트
ㅇ 가용성 개녕
- 장애 발생시 가동 중단 시간 최소화하려면 고가용성
- 고가용성: 가동 중단 시간 및 비용을 최소화
- 내결함성: 서비스 중단이 발생하지 않도록 애플리케이션 구성 요소에 내장된 중복성
- 백업: 데이터 보호, 비즈니스 지속성 유지하는데 중요
- 재해 복구: 가용성 구성 요소중 하나로 데이터 손실 없이 신속하게 서비스 복원
ㅇ RPO
- 복구 시점 목표 (얼마나 자주 데이터를 백업?)
- 시간 단위로 측정한 허용 가능한데이터 손실량
ㅇ RTO
- 복구 시간 목표 (얼마나 오래 사용할 수 없나?)
- 서비스 수준으로 복원하는데 걸리는 시간
ㅇ 스토리지 복제
- Amazon S3 : 미션 크리티컬 및 기본 데이터 스토리지에 적합하게 설계, 내구성이 우수한 스토리지 제공
교차 리전 복제는 버킷 수준의 구성에 속하며, 서로 다른 AWS 리전에 있는 여러 버킷에서 객체를 복사 가능 - Amazon S3 Glacier:데이터 아카이빙 및 백업을 위한 스토리지를 저렴한 비용으로 제공, 아카이브는 자주 액세스 하지 않는 데이터에 최적화
- Amazon EBS: 데이터 볼륨의 특정 시점 스냅샷을 생성, 스냅샷이 completed한 경우 한 AWS 리전에서 다른 리전으로, 또는 동일 리전 내에서 스냅샷 복사 가능
- snowball: 스토리지 디바이스를 사용해 AWS 간에 테라바이트에서 페타바이트 규모의 데이터를 이동, 물리적 전송 시 보안을 유지하도록 설계
- SataSync: 온프레미스 또는 클라우드 내 파일 시스템의 파일을 Amazon EFS와 동기화
ㅇ 복구용 AMI 구성
- 별도의 가용 영역에서 인스턴스를 시작함으로써 단일 위치에서 장애 발생시 애플리케이션 보호 가능
- 해당 인스턴스 ID, IP 주소, 탄력적 IP 주소 EBS 볼륨연결 및 구성 세부 정보는 그대로 유지
- AMI는 운영 체제가 사전 구성
ㅇ 장애 조치 네트워크 설계
- 사용 중인 시스템이 다른 사이트로 장애 조치 될때 네트워크 설정을 수정할 가능성 큼
- Route 53에는 다수의 글로벌 로드 밸런싱 포함, 다수의 엔드포인트와 Amazon S3에 호스트되는 정적 웹 사이트간에 장애 조치를 실행하는 기능인 DNS 엔트포인트 상태 확인을 다룰 때 효과적일 수 있음
- ELB는 수신되는 애플리케이션 트래픽을 여러 Amazon EC2 인스턴스에 자동으로 분산, 로드 밸런싱 용량을 제공함으로써 내결함성을 높일 수 있음,로드 밸런서를 사전 구성해 DNS 이름을 식별하고 재해 복구 계획을 실행
ㅇ 데이터베이스 백업 및 복제본
- DynamoDB
-완전관리형 다중 리전, 다중 활성 데이터베이스- 선택한 AWS 리전에서 Dynamo DB 테이블의 복제본
- Amazon RDS
- 한 리전에서 데이터를 스냅샷하고 다른 리전에서 읽기 전용 복제본을 실행
- 수동 DB 스냅샷 또는 DB 클러스터 스냅샷을 공유
- 최대 20개의 AWS 계정과 수동 스냅샷을 공유
- 특정 시점 복구를 사용하여 최대 35일간 지속적으로 테이블을 백업
- 읽기 전용 복제본을 독립 실행형 데이터베이스 인스턴스로 승격
ㅇ AWS 백업
- 복잡성
- 규정 준수
- 비용
