03 Using AWS for Disaster Recovery www.wisen.co.kr Wisely Combine the Network platforms
Using AWS for Disaster Recovery Contents 개요 1 소개 2 복구 목표 시간 및 복구 목표 수준 / 전통적인 DR 투자 사례 3 AWS 장애 복구 시나리오 예제 백업과 복구 4 AWS로 빠르게 복구하기 위한 파일럿 라이트 AWS에서의 웜 스탠바이 솔루션 AWS와 온사이트에 배치된 멀티 사이트 솔루션 데이터의 복제 DR 계획 개선 소프트웨어 라이센싱 및 DR 10 11 13 개요 장애 발생시 비즈니스 연속성을 보장하기 위해 신속하게 아마존 웹 서비스(AWS)의 리소스들을 가동할 수 있습니다. 이 문서는 DR 프로세스에 대해서 연관된 AWS 특징 및 서비스들에 중점을 두고, 장애 복구 방법에 대하여 예제 시나리오를 보여 줍니다. 또한 어떻게 DR 계획을 보강하고, 장애 복구 프로세스에 대한 AWS의 강점을 활용하는 방법을 제공합니다.
2 소개 복구 목표 시간 및 복구 목표 수준 / 전통적인 DR 투자 사례 3 소개 장애 복구(DR)는 장애가 발생할 수 있는 요소에 대한 준비와 복구 에 대한 내용입니다. 비즈니스의 연속성이나 재정에 부정적인 영향을 줄 수 있는 상황을 장애라고 볼 수 있습니다. 그 상황으로는 하드웨어나 소프트웨어 오류, 네트워크 단절, 정전, 화재나 홍수, 사람의 실수, 기타 다른 유형이 될 수 있습니다. 복구 목표 시간 및 복구 목표 수준 이 문서에서는 장애 부문에 관련된 산업 공통 용어를 사용합니다. 복구 목표 시간(RTO) - 이것은 비즈니스의 연속성이 중단되었을 때 그 장애가 허용가능한 상태를 넘어서는 것을 피하기 위하여, 장애 발생 후 복구까지 걸리는 시간과 서비스 단계를 말합니다. 예를 들어, 장애가 오후 12시 정각에 발생하고 RTO가 8시간이라고 한다면, DR 프로세스는 허용 가능한 서비스 단계에 따라 8시간 이내에 복구가 되어야 합니다. 장애 복구(DR)는 장애가 발생할 수 있는 요소에 대한 준비와 복구에 대한 내용 입니다. 비즈니스의 연속성이나 재정에 부정적인 영향을 줄 수 있는 상황을 장애 라고 볼 수 있습니다. 그 상황으로는 하드웨어나 소프트웨어 오류, 네트워크 단절, 정전, 화재나 홍수, 사람의 실수, 기타 다른 유형이 될 수 있습니다. DR에 대한 적절한 대비는 필수적입니다. 그래서 이 문서는 DR 계획 및 프로세스를 보강하기 위하여 모범 사례들을 제시합니다. 장애 복구는 사업과 시스템이 발전하듯이, 문제점을 분석하고 개선시키는 일련의 프로세스라고 볼 수 있습니다. 각각의 비즈니스 서비스들에 대해 적절한 복구 요소와 시간을 수행해야 하고, 그 부분에 맞는 DR 솔루션을 구축할 필요가 있습니다. 복구 목표 수준(RPO) - 이것은 장애 시간 동안에 측정된 허용 가능한 데이터 손실량을 말합니다. 예를 들어, RPO가 1시간이고 장애가 오후 12시에 발생하고 복구되었다면, 오전 11시 이전의 모든 데이터는 존재하여야 합니다. 보통 비즈니스는 시스템이 이용할 수 없을 때 발생하는 재정적 영향에 기반하여 허용 가능한 RTO와 RPO를 결정합니다. 재정적 영향은 비즈니스 명성의 손상, 비즈니스 손실 및 시스템 가용성의 부족 등 여러가지 요인으로 고려됩니다. IT 조직은 RPO에 기반하여 비용 효율적으로 시스템 복구 솔루션을 계획하고, RTO에 기반하여 서비스 단계를 계획합니다. 전통적인 물리적 환경에서, 일반적인 방법은 여분의 가용성을 보장하기 위하여 인프라 이중화로 처리 하였습니다. 이 인프라는 예상되는 용량의 요구 사항을 처리하기 위해서 인프라를 도입, 구축, 관리를 하여야 했습니다. 보통의 운영 환경에서, 이 인프라는 실제 사용하는 양보다 많은 자원이 들어가게 됩니다. AWS는 필요에 따라 인프라를 확장할 수 있습니다. 웹 사이트를 전세계 네트워크를 통해 서비스 하려고 할 때, 아마존의 높은 확장성과 신뢰성, 보안, 빠르고 저렴한 인프라를 사용한 만큼만 비용 지불하면서 사용할 수 있습니다. 장애 복구(DR) 솔루션에 대해 이러한 점을 이용하여 비용을 절감할 수 있습니다. 또한 DR 시나리오를 변경하거나 최적화할 수 있도록 합니다. 사람의 실수는 시스템 장애 시간에 많은 원인이 됩니다. AWS는 설계상 최소한의 사용자 권한을 명시하고 분리할 수 있도록 제공합니다. 또한 예측 가능하고 반복적인 설정에 대해서는 모든 구성 요소 배포를 자동화 할 수 있습니다. 이것은 실제 중복되는 환경에서 변경된 설정을 동일한 완전한 테스트 인프라를 갖추지 않고도 테스트 할 수 있게 해줍니다. 전통적인 DR 투자 사례 DR에 대한 전통적인 접근 방식은 데이터와 인프라의 오프사이트 이중화에 여러 단계가 있습니다. 중요한 비즈니스 서비스들은 주기적으로 인프라를 구축, 유지보수, 테스트 합니다. 장애 복구 환경이 원본 사이트에 영향을 줄 수 있는 여러 가지 문제들로부터 독립시키기 위하여 장애 복구 환경의 위치와 원본 인프라는 물리적으로 분리되어 있어야 합니다. 이중화 환경을 지원하기 위해 필요한 인프라는 다음의 요소를 포함하여야 합니다. 전력 및 냉각 시스템을 포함하는 인프라 시설 물리적인 자산 보호를 위한 보안 적절한 시스템 규모를 지원하는 시설 인프라 수리, 교체, 유지하기 위한 지원 완전한 부하 처리를 위해 대역폭을 유지할 수 있는 인터넷 연결 제공 ISP 약정 계약 방화벽, 라우터, 스위치, 로드 밸런서와 같은 네트워크 인프라 사용자 인증, DNS, DHCP, 모니터링, 알람과 같은 백엔드 서비스를 제공해 주는 서버와 데이터를 보관하는 저장 장치를 모두 포함하는 모든 중요한 서비스들이 동작하기에 충분한 서버 용량 서비스의 중요도에 따라, 이중화 환경은 허용 방식(fault tolerant)으로 구성될 수 있습니다. 이 부분은 위에서 열거한 모든 인프라 이중화를 일반적으로 고려합니다.
4 AWS 장애 복구 시나리오 예제 AWS 장애 복구 시나리오 예제 5 AWS 장애 복구 시나리오 예제 이 섹션은 AWS 주요 기능을 사용한 DR 시나리오와 전통적인 DR 방법과의 다른 부분을 설명합니다. 백업과 복구 Corporate data center 10G Using AWS Direct Connect S3 Bucket AWS로의 간단한 복구를 위한 파일럿 라이트 웜 스탠바이 솔루션 Over the Internet 멀티 사이트 솔루션 Amazone Elastic Computer Cloud (EC3) 아마존 웹 서비스들은 각각 예제로 제시한 DR 전략을 비용 대비 효율적으로 운영할 수 있게 해줍니다. On-site infrastructure AWS Import / Export Or AWS Storage Gateway Availability Zone [ 온사이트 인프라나 AWS에서 S3로 데이터 백업이 이루어지는 구성 ] 백업과 복구 대부분의 전통적인 환경에서, 데이터는 정기적으로 테이프 장치로 백업 됩니다. 이 방법을 사용한 복구 시간은 아주 길어집니다. 아마존 S3는 데이터 백업의 목적으로, 매년 각 오브젝트에 대해 99.999999999%(11 9s) 내구성을 가지도록 설계되었습니다. 아마존 S3와 데이터 송수신은 네트워크를 통하여 수행되므로, 어떠한 곳에서도 접근이 가능합니다. 아마존 S3로의 백업을 수행하는 많은 상업용 혹은 오픈소스형 백업 솔루션들이 있습니다. AWS Import/Export는 AWS로 직접 스토리지 장치를 보냄으로써, 대단히 크고 많은 데이터를 전송할 수 있게 합니다. AWS Storage Gateway 서비스는 백업을 위해 온프레미스의 데이터 볼륨을 그대로 아마존 S3로 반영하여 동작할 수 있게 끔, 스냅샷을 가능하게 합니다. 이 스냅샷을 이용하여 로컬 볼륨이나 AWS EBS 볼륨을 생성할 수 있습니다. AWS에서 동작하는 시스템은 아마존 S3로 백업합니다. EBS 볼륨과 아마존 RDS 백업 스냅샷은 아마존 S3에 저장됩니다. 또한 아마존 S3로 직접 파일을 복사할 수 있고, 백업할 파일만 선택하여 아마존 S3로 복사할 수 있습니다. 아마존 S3에 백업 데이터를 저장하는 많은 백업 솔루션이 있고, 이 솔루션들은 아마존 EC2 시스템을 사용하여 동작할 수 있습니다. 데이터 백업은 전체 이야기에 반입니다. 나머지 반은 복구에 관련한 이야기 입니다. 장애 시나리오에서 데이터 복구는 테스트 되어져야 하고, 빠르고 신뢰성있게 수행되어야 합니다. 고객은 시스템이 적절한 데이터의 보존 및 보안, 데이터 복구 프로세스가 테스트 되었는지 확인해야 합니다. Instance Amazon EC2 Instance quickl provisioned from AMI Pre-bundled with OS and applications copled from objects in S3 S3 Bucket AMI Availability Zone [ S3 백업에서 AWS EC2로 복구가 이루어지는 구성 ] 백업과 복구의 중요한 순서는 다음과 같습니다 : 데이터를 AWS로 백업하기 위한 적절한 툴이나 방법을 선택 데이터에 대한 적절한 보존 정책이 있는지 확인 데이터에 대한 적절한 보안 조치와 암호화, 접근 정책이 설정되었는지 확인 정기적으로 데이터 복구 및 시스템 복원을 테스트
6 AWS 장애 복구 시나리오 예제 AWS 장애 복구 시나리오 예제 7 AWS로 빠르게 복구하기 위한 파일럿 라이트 파일럿 라이트의 아이디어는 가스 히터의 원리와 유사합니다. 가스 히터는 항상 조그마한 불꽃으로 집 전체를 따뜻하게 할 수 있습니다. 이 시나리오는 백업과 복구 시나리오와 유사합니다. 그러나, 가장 중요한 코어 요소들이 AWS에 설정되고 동작하고 있어야 합니다. 복구해야 할 때, 중요한 코어를 중심으로 전체 환경을 빠르게 복구할 수 있습니다. 파일럿 라이트 인프라 요소들은 보통 아마존 EC2로 데이터 복제하는 데이터 베이스 서버들을 포함합니다. 시스템에 따라, AWS로 복제되는 데이터베이스 외부에 다른 중요한 데이터가 있을 수 있습니다. 이것은 전체 시스템을 복구할 때, AWS에 있는 다른 모든 인프라 조각들이 신속하게 제공될 수 있게 만들어 주는 주변 시스템들 핵심입니다. 준비 단계 : 다음 그림은 변하는 데이터를 정기적으로 파일럿 라이트로 복제해야 하는 준비 단계를 보여 줍니다. 전체 시스템에서 작은 코어는 복구 단계가 시작될 것입니다. OS와 어플리 케이션 같은 가끔 업데이트 되는 데이터는 AMI로 주기적으로 업데이트하고 저장할 수 있습니다. 준비를 위한 핵심 포인트 : Nat Running 비즈니스에서 중요한 서비스들을 복구하기 위하여 인프라의 나머지 부분을 제공하기 위해, 보통 일부 미리 구성된 서버의 AMI 이미지를 번들시켜 놓습니다. 복구가 시작될 때, AMI를 통한 인스턴스들은 빠르게 가동되고, 파일럿 라이트 주변으로 배포 규칙을 찾습니다. 네트워크 관점에서 보자면, Elastic IP 주소를 사용하여 인스턴스들을 연동시킬 수 있거나, Elastic 로드 밸런싱을 사용하여 트래픽을 여러 개의 인스턴스들로 분산시킬 수 있습니다. 아마존 EC2 인스턴스 관점에서 DNS 레코드를 업데이트 하거나, 로드 밸런서 관점에서 CNAME을 사용할 수 있습니다. 덜 중요한 시스템에 대해, AWS에서 어떠한 설치 패키지와 설정 정보를 확인할 수 있습니다. 이것은 어플리케이션 서버 구성을 빠르게 합니다. 여러 AZ에 다양한 볼륨을 빠르게 생성하고, EC2 인스턴스에 연결할 수 있습니다. 그리고 설치와 구성을 진행할 수 있습니다. 데이터 복제나 미러링을 위한 EC2 인스턴스 설정 AWS에 지원하는 사용자 정의 소프트웨어 패키지가 있는지 모두 확인 빠른 복구를 위해 필요로 하는 AMI 생성 정기적으로 이러한 서버들을 가동하고, 테스트하고 소프트웨어 업데이트 및 구성 적용 AWS 자원들의 제공 방법을 자동화하는 것을 고려 Corporate Center Mirroring Replication Volume [ 파일럿 라이트 시나리오의 준비 단계 ] Pilot light system 파일럿 라이트 방법은 위에서의 백업과 복구 시나리오보다 복구 시간을 단축시켜 줍니다. 왜냐하면 시스템의 코어 조각들이 이미 동작중이고, 유지되기 때문입니다. 물론, 어플리케이션의 완전한 복구를 위해서는 여전히 설치와 구성 작업이 남아 있습니다. AWS는 사람의 실수에 대비하여 도움을 주고, 시간을 절약시킬 수 있는 인프라 리소스들의 제공과 구성을 자동화 합니다. 복구 단계 : 파일럿 라이트 주위 나머지 시스템을 복구 하기 위하여, 단시간 내에 AMI로부터 해당 인스턴스들을 가동해야 합니다. 변화하는 데이터 서버같은 경우는, 필요로 하는 볼륨 크기를 조절할 수 있고, 용량을 추가할 수 있습니다. 여러 대의 인스턴스들을 멀티로 수평적으로 연결하는 스케일 작업이 더 비용 면에서는 효율적입니다. 그러나, 수직적으로 더 큰 인스턴스 타입을 사용하는 것도 가능 합니다. 네트워크 관점에서 보자면, 필요로 하는 DNS 업데이트는 병렬적으로 수행될 수 있습니다. 일단 복구가 되면, 가능한한 빠르게 남은 부분이 없는지 확인해야 합니다. 제품이나 서비스 시스템에서 실패가 난 후에, DR 시스템 실패가 나지는 않겠지만, 위험성에 대해서는 알 필요가 있습니다. 시스템을 정기적으로 백업하고, 데이터 부분에서는 추가적으로 복제를 고려해야 합니다. Corporate Center Volume [ 파일럿 라이트 시나리오의 복원 단계 ] Start in Minutes Add additional capacity if needed 복구를 위한 핵심 포인트 : 사용자 정의 AMI로부터 어플리케이션 EC2 인스턴스 시작 필요한 곳에, 데이터베이스나 데이터 저장 인스턴스들의 사이즈 조절 EC2 서버로 가도록 DNS 변경 자동화 방식으로 비 AMI 기반 시스템 설치 및 구성
8 AWS 장애 복구 시나리오 예제 AWS 장애 복구 시나리오 예제 9 AWS에서의 웜 스탠바이 솔루션 웜 스탠바이 솔루션은 파일럿 라이트의 요소와 준비보다 더 확장합니다. 복구 시간을 더 단축시키기 위해서, 얼마의 서비스들을 항상 동작하고 있어야 합니다. 비즈니스의 중요한 시스템을 구분하기 위해, AWS에서 항상 이 시스템을 이중화해야 합니다. 이 서버들은 가능한 가장 작은 크기로 EC2 인스턴스를 최소화해서 동작할 수 있습니다. 이 솔루션은 전체 서비스 시스템 로드를 스케일링 못하지만, 기능은 완전히 동작합니다. 테스트, 품질 확인, 내부 사용과 같은 내부적인 부분에 사용될 수 있습니다. 장애시에 시스템은 빠르게 서비스 로드를 처리하기 위해 스케일이 커집니다. AWS에서 이러한 부분은 로드밸런서에 인스턴스를 추가하고, 각 인스턴스의 타입을 더 큰 타입으로 확장하는 방법으로 동작합니다. 앞에서 얘기했듯이, 가능하면 더 큰 타입의 인스턴스 확장보다는 여러 대의 인스턴스를 병렬적으로 추가하는 방법을 권장합니다. AWS와 온사이트에 배치된 멀티 사이트 솔루션 AWS에서 멀티사이트 솔루션은 액티브-액티브 구성의 온사이트 인프라와 동일하게 동작합니다. 데이터 복제 방법은 선택된 복구 포인트(RPO 참고) 에 의해 결정됩니다. 다양한 복제 방법이 존재합니다. (아래 참고) 아마존 Route 53과 같은 비중 조절이 가능한 DNS 서비스는 서비스 트래픽을 다른 사이트로 라우트하기 위해 사용됩니다. AWS에 있는 여러분의 인프라로 트래픽을 발생시키고, 나머지는 여러분의 온사이트 인프라로 트래픽을 발생 시킬 수 있습니다. 온사이트 장애 발생 시, DNS 비중 조절을 통하여 모든 트래픽을 AWS 서버로 보낼 수 있습니다. AWS 서비스 용량은 모든 서비스 로드를 처리하기 위하여 빠르게 증가될 수 있습니다. EC2 오토 스케일링은 이러한 프로세스를 자동화 하기 위하여 사용됩니다. 여러분은 메인 데이터베이스 장애를 감지해서 AWS 에 있는 병렬 데이터베이스 서비스로 넘기기 위한 어떤 어플리케이션 로직이 필요할 수 있습니다. 준비 단계 : 다음 그림은 온사이트와 AWS 솔루션이 나란히 실행되는 웜 스탠바이 솔루션에 대한 준비 단계를 보여줍니다. 준비를 위한 핵심 포인트 : 데이터 복제나 미러링을 위한 EC2 인스턴스 설정 AMI 생성 및 유지 EC2 인스턴스나 AWS 인프라에서 가장 작은 형태로 어플리케이션 실행 활성화된 시스템에 소프트웨어와 설정 파일을 패치하고 업데이트 복구 단계 : 서비스 시스템에 장애가 발생했을 경우, 스탠바이 시스템은 서비스 로드를 위하여 스케일이 확장되고 DNS 레코드는 AWS로 모든 트래픽을 라우트하기 위하여 변경 됩니다. 복원을 위한 핵심 포인트 : 필요한 만큼 더 큰 EC2 인스턴스 타입으로 어플리케이션 시작 로브밸런서에 연결된 EC2 수를 증가 모든 트래픽이 AWS 시스템으로 라우트되도록 DNS 레코드 변경 오토 스케일링 사용으로 증가하는 로드 수용 Corporate Center Amazon Route 53 Source Cut Over Mirroring / Replication Not for Production Traffic Scaled down Standby [ 웜 스탠바이 시나리오의 준비 단계 ] Corporate Center Amazon Route 53 Scaled up for Production Use [ 웜 스탠바이 시나리오의 복구 단계 ] Slave Elartic Load Balancer Slave Elartic Load Balancer 준비 단계 : 다음 그림에서, AWS 사이트로 트래픽을 라우트 하는 DNS를 볼 수 있습니다. AWS 어플리 케이션은 온사이트 서비스 시스템에 있는 데이터 소스를 접근할 수 있습니다. 데이터는 AWS 인프라로 복제되거나 미러링됩니다. 준비를 위한 핵심 포인트 : 서비스 시스템을 복제하기 위해 AWS 시스템을 구축 두 사이트로 들어오는 요청을 분산시키기 위해 DNS 비중 조절이나 비슷한 기술 사용 복구 단계 : 다음 그림은 온사이트에서 장애가 발생했을 때 무슨 일이 일어나는 지 보여줍니다. 트래픽은 DNS 업데이트를 통해 AWS 인프라로 넘어 갑니다. 복구를 위한 핵심 포인트 : 모든 요청이 AWS 사이트로 넘어가도록 DNS 비중 조절 변경 로컬 AWS 데이터베이스 서버를 사용하기 위한 장애처리 어플리케이션 로직 구성 자동적으로 AWS 그룹의 크기를 조절할 수 있는 오토 스케일링 사용 고려 멀티 AZ 구성을 설계함으로써, 멀티 사이트 솔루션의 가용성을 더 증가시킬 수 있습니다. 그것에 관련된 자세한 내용은 Designing Fault-Tolerant s in the AWS Cloud 백서를 참고하시기 바랍니다. 이 시나리오의 비용은 얼마나 많은 서비스 트래픽이 AWS에서 처리되는지에 따라 결정됩니다. 복구 단계에서, DR 시스템이 모든 것을 처리하기 위해 필요한 추가되는 부분과 시간에 따른 비용만 지불하면 됩니다. 항상 동작하는 인스턴스에 대해서는 RI 인스턴스를 적용하여 비용을 더 절감할 수 있습니다. Corporate Center [ 멀티 사이트 시나리오의 준비 단계 ] Corporate Center Amazon Route 53 Source Cut Over Amazon Route 53 Elartic Load Balancer [ 온사이트와 AWS 인프라를 포함하는 멀티 사이트 시나리오의 복구 단계 ] Mirroring / Replication Scaled up for Production Use Slave Slave Elartic Load Balancer
10 데이터의 복제 DR 계획 개선 11 데이터의 복제 원격 위치에 데이터를 복제 할 때 고려해야 할 몇 가지 요소가 있습니다. DR 계획 개선 견고한 DR 계획을 유지하기 위해서는 몇 가지 중요한 단계를 준수해야 할 필요가 있습니다. 이 섹션에서는 주요 단계 몇 가지에 대해 설명합니다. 위치간의 거리 : 보통 더 거리가 멀어질수록 더 많은 지연이나 불일치 발생 사용가능한 대역폭 : 상호 연결이 얼마나 광범위하고 변수가 많은지? 어플리케이션에 의해 요구되는 데이터 전송률 : 사용가능한 대역폭보다 데이터 전송률이 더 낮아야 함 복제 기술은 병렬적으로 이루어져야 함 (네트워크의 효율성을 위하여) 테스팅 동기식과 비동기식: 데이터 복제에는 두 가지의 접근 방식이 있습니다. 동기식 복제 데이터는 여러 위치에 원자적(Atomic)으로 업데이트 됩니다. 이것은 네트워크의 성능과 가용성에 달려 있습니다. DR 솔루션이 적용된 후에, 테스트 될 필요가 있습니다. 게임 데이 는 DR 시스템에 대해 시스템 대체 작동을 실행하는 때입니다. 충분한 문서를 확보하는 것은 실제 이벤트가 발생했을 때를 대비하여 프로세스를 가능한한 단순하게 만들어 줍니다. 게임 데이 시나리오를 테스트하기 위하여 이중화 시스템을 스핀업하는 것은 AWS에서 빠르고 비용 효율적입니다. 보통 여러분의 서비스 시스템을 건드릴 필요가 없습니다. AWS에서 전체 시스템을 배포하기 위하여 AWS CloudFormation을 사용할 수 있습니다. 이것은 전체 시스템을 생성하기 위해 필요한 AWS 리소스들과 연관된 의존성 부분들, 그리고 실행시 필요한 파라미터를 설명하는 템플릿을 사용합니다. 테스트를 구분하는 것은 여러 다른 유형의 장애가 있을 수 있는데, 그 장애 대비를 보장해 줍니다. 다음은 게임 데이 시나리오 예제입니다 : 비 동기식 복제 해당 지역 혹은 장비들의 정전 데이터는 여러 위치에 원자적(Atomic)으로 업데이트 되지 않습니다. 허용하는 네트워크 성능과 가용성에 맞추어 전송되고, 어플리케이션은 완전히 복제되지 않은 상태라도 데이터를 쓰게 됩니다. 많은 데이터베이스 시스템은 비동기식 데이터 복제를 지원합니다. 데이터 베이스 복제는 원격에 있을 수 있고, 이 복제는 메인 데이터베이스와 동기화가 완전하지 않습니다. 하나의 지역에 대한 ISP 연결 실패 여러 사이트에 영향을 주는 코어 비즈니스 서비스에 해를 끼치는 바이러스 복구 시점에 필요로 하는 데이터 손실을 야기하는 사용자 실수 고객이 그들의 소프트웨어 솔루션이 사용하는 복제 기술을 이해할 수 있도록 설명합니다. 자세한 복제 기술에 대한 분석은 이 문서에서 벗어납니다. AWS에서 Region내에 AZ는 서로 연결되어 있지만, 물리적으로는 분리되어 있습니다. 예를 들어, 멀티 AZ 모드로 배포할 경우에, 아마존 RDS는 두번째 AZ에 중복된 데이터를 복제하기 위해 동기식 복제를 사용합니다. 이러한 방법은 메인 AZ가 이용할 수 없을 경우 데이터가 손실되지 않도록 보장해 줍니다. 은 각각 완전히 분리되어 있습니다. 그러나, 여러분이 그것에 접근하거나 사용하는 방법에는 차이가 없습니다. 이것은 고객이 대륙간을 넘나드는 장애 복구 프로세스를 생성하기 위해서 어떠한 어려움이나 소요 비용을 가지지 않도록 해 줍니다. 고객은 아주 큰 규모의 장애에 복구를 지원하기 위하여 2개 이상의 에 데이터와 시스템을 백업할 수 있습니다. 고객은 그들의 최종 고객에게 낮은 복잡성과 동작 프로세스를 제공하기 위하여 들을 사용할 수 있습니다. 모니터링 및 알람 DR 시스템이 서버 장애, 연결 이슈, 그리고 어플리케이션 이슈로 인하여 영향을 받을 때, 여러분에게 알람을 줄 수 있도록 정기적으로 체크하고 충분한 모니터링이 있어야 합니다. 아마존 CloudWatch는 AWS 리소스들에 관하여 이러한 방법을 제공합니다. 어떠한 메트릭에 정의된 알람이 설정이 되면, 아마존 Simple Notification Service 메시지는 예기지 않은 문제가 생길 경우 알람 전송이 보내집니다. AWS에서는 다른 어떠한 모니터링 솔루션 역시 사용할 수 있습니다. 여러분은 게스트 OS나 어플리케이션의 상태를 체크하기 위하여 여러분 인스턴스 메트릭을 모니터링하기 위하여 회사에서 사용하던 기존의 모니터링과 알람 툴을 계속해서 사용할 수 있습니다.
12 DR 계획 개선 소프트웨어 라이센싱 및 DR 13 백업 일단 DR 시스템으로 전환이 되면, 정기적인 백업을 계속해야 합니다. 백업과 복구 테스팅을 정기적으로 하는 것은 대비 솔루션으로 유용합니다. AWS는 DR 인프라가 항상 활성화 되어 있어 있을 필요가 없도록 저렴한 DR 테스트를 수행할 수 있는 유연성을 제공합니다. 소프트웨어 라이센싱 및 DR 고객이 제대로 AWS 환경에 대한 라이센스가 있는지 보장하는 것은 다른 환경을 라이센싱 하는 것만큼이나 중요합니다. 아마존은 고객이 라이센싱을 더 쉽게 관리하기 위한 다양한 모델을 제공합니다. 예를 들어, 자신의 라이센스를 가져오는 것 은 여러 소프트웨어 구성 요소 또는 운영 체제에서 가능합니다. 대안 적으로, 큰 범위의 시간당 비용과 함께 라이선스의 비용이 포함되어있는 소프트웨어가 많이 있습니다. 이것은 라이센스 포함 으로 알려져 있습니다. 사용자 액세스 인증과 IAM을 사용하여 여러분의 DR 시스템에서 리소스 접근에 대한 보안을 설정할 수 있습니다. 여러분의 DR 시스템에서 작업하는 동안 분리된 사용자 권한/책임 정책으로 여러분들이 롤과 사용자들 기반 하의 보안 정책을 생성할 수 있습니다. 자신의 라이센스를 가져오는 것 은 재해시 기존 소프트웨어를 활용 할 수 있게 해줍니다. 라이센스 포함 은 예를 들어DR 테스트 중에, 일상적으로 사용되지 않는 DR 사이트에 대한 전면 라이센스 비용을 최소화 할 수 있습니다. 어떠한 단계에서라도 라이센스들이 AWS에 어떻게 적용되는지 그리고 라이센스에 대한 의심이 있는 경우 고객님들의 라이센스 대리점에 문의하면 됩니다. 자동화 여러분은 구성 관리 소프트웨어를 사용하여 AWS 기반 서버와 온프레미스 서버 위에 어플리케이션 배포를 자동화할 수 있습니다. 이것은 쉽게 두 시스템 모두 어플리케이션과 구성 변경 관리를 처리할 수 있게 합니다. 몇몇의 대중적인 소프트웨어와 제공업자는 Solution Provider 페이지에서 볼 수 있습니다. AWS CloudFormation은 자동화된 방법에서 인프라 서비스를 제공하기 위해 여러 툴들의 결합으로 동작합니다. 최초 부탕시에 사용자 데이터는 인스턴스로 전달되고, 구성 관리 툴은 인스턴스 타입이나 롤을 결정하기 위해 처리됩니다. 이것은 올바른 소프트웨어와 구성이 배포되도록 해 줍니다. 최종 목표는 가능한한 자동화로 여러분이 필요로 하는 인스턴스를 가져야 한다는 것입니다. 오토 스케일링은 여러분의 인스턴스 풀이 CloudWatch에 의해 측정되는 메트릭 기반하에 적절히 크기를 조절하기 위해 사용됩니다. DR 상황에서, 동적으로 요구되는 증가분만큼을 자연스럽게 스케일을 늘려 줌을 의미합니다. 이벤트가 종료된 후에 사용률이 감소하면, 최소한의 서버로 스케일을 줄여줍니다. 결론 많은 옵션과 변수가 DR을 위해 존재하고, 이 문서는 단순 백업에서 멀티 사이트 내구성이 있는 복구에 이르기까지 일부의 일반적인 패턴을 강조합니다. AWS 는 DR 목표(RTO와 RPO) 및 예산을 기반으로 적절한 DR 솔루션으로 구축하기 위한 세밀한 컨트롤과 블록을 제공합니다. AWS 서비스는 온디맨드로 제공되고, 고객은 사용하는 만큼 비용을 지불합니다. 이것은 장애가 발생한 경우 상당한 인프라가 필요한 시점에 빠르고 필요한 만큼의 양을 사용할 수 있다는 DR에 관련된 중요한 이점입니다. 이 문서는 어떻게 AWS가 더 효과적인 DR 계획을 할 수 있도록 유연하고 비용 효율적인 인프라 솔루션을 제공하는 방법을 보여 주었습니다.
www.wisen.co.kr Wisely Combine the Network platforms Using AWS for Disaster Recovery 서울특별시 구로구 경인로 576 (구로동) [TEL] 02-2630-5795 [FAX] 02-2630-5255