Amazon Web Services 를사용한재해복구 2011 년 10 월 업데이트 : 2012 년 1 월 Glen Robinson, Ianni Vamvadelis, Attila Narin

Amazon Web Services 를사용한재해복구 2011 년 10 월 업데이트 : 2012 년 1 월 Glen Robinson, Ianni Vamvadelis, Attila Narin

목차 요약... 3 서론... 3 복구시간목표및복구시점목표... 5 기존의재해복구투자관행... 5 재해복구에필수적인 AWS 서비스및기능... 6 지역... 6 스토리지... 6 컴퓨팅... 7 네트워킹... 8 데이터베이스... 8 배포오케스트레이션... 9 보안... 9 AWS를사용한재해복구시나리오의예... 10 백업및복구... 10 AWS 로의신속한복구를위한파일럿라이트... 12 AWS 의웜대기솔루션... 14 AWS 및현장에배포된다중사이트솔루션... 17 다중사이트... 17 데이터복제... 20 동기복제... 20 비동기복제... 20

재해복구계획의개선... 22 테스트... 22 모니터링및경보... 22 백업... 22 사용자액세스... 23 자동화... 23 소프트웨어라이선스와재해복구... 23 결론... 24 참고문헌... 25 요약 재해발생시, Amazon Web Services(AWS) 에서신속하게리소스를시작하여사업을지속할수있습니다. 본백서는재해복구절차에활용할수있는관련 AWS 기능과서비스를중심으로설명하며재해복구방법에대한모범시나리오를제시합니다. 또한재해복구계획을개선하고재해복구절차에대한 AWS의잠재력을최대한활용할수있는방법을권고합니다. 서론 재해복구 (DR) 는재해대비및복구에대해다룹니다. 비즈니스연속성또는재무상태에부정적인영향을미치는모든이벤트를재해라고할수있습니다. 여기에는하드웨어 / 소프트웨어장애, 네트워크중단, 정전, 화재나수해등건물의물리적인손상, 인간의실수, 기타일부심각한재해가포함됩니다. 재해가사업에미치는영향을최소화하기위해기업은시간과자원을들여이벤트처리절차를계획, 준비, 연습, 문서화, 교육및갱신합니다. 특정시스템의재해복구계획에대한투자규모는잠재적인중단으로인한손실에따라현저하게달라질수있습니다. 본백서는최소투자에서최대가용성및내결함성에이르기까지몇가지일반적인방법에대해설명합니다. DR을적절히준비하는것은반드시필요하기때문에본백서는 DR 계획및절차를개선하기위한몇가지베스트프랙티스를간략하게다룹니다.

재해복구는사업및시스템이발전함에따라지속적으로수행해야할분석및개선과정입니다. 고객은각사업서비스에대해수용가능한복구시점과시간을결정하고적합한 DR 솔루션을구축해야합니다. 기존의물리적인환경에서일반적인방법은재해시, 여분의용량을확보하기위해인프라를복제하는것이었습니다. 이러한인프라는용량을확보, 설치및유지관리하여예상되는용량요구사항을처리할준비를갖추어야합니다. 정상적인운영환경에서이러한인프라는보통활용률이낮거나과다하게프로비저닝되는경우가많았습니다. AWS를이용하면필요에따라인프라를확장할수있습니다. Amazon이자체글로벌웹사이트네트워크를실행하기위해사용하는것과동일한탁월한확장성, 신뢰성, 보안성, 속도를유지하면서도비용이저렴한인프라에액세스할수있고사용량에대해서만비용을지불하면됩니다. 재해복구 (DR) 솔루션측면에서이러한장점은비용을상당히절감해줍니다. 또한재해복구시, 더욱민첩하게리소스를변경하여최적화할수있습니다. 인간의실수는시스템다운타임의가장큰원인입니다. AWS는최소권한 1 설계가가능하도록역할분리가가능한도구를제공합니다. 또한전체환경배포를자동화하여예측가능하고반복가능한구성설계가가능합니다. 매우신속하게구축할수있는재해복구테스트환경을일회용자원처럼사용할수있습니다. 조직은보통활용성이떨어지는완벽한전용테스트환경을구축할필요없이설정변경을생산단계에서둘러적용하기전에복제환경에서설정변경사항을미리테스트해볼수가있습니다. 1 http://en.wikipedia.org/wiki/principle_of_least_privilege

복구시간목표및복구시점목표 본백서에서는재해계획에두가지일반적인업계용어를사용합니다. 복구시간목표 (RTO) 2 비즈니스프로세스가재해 ( 또는중단 ) 후복구되어야하는시간및서비스수준을말하는것으로, 비즈니스연속성이중단되어발생하는수용불가능한결과를예방하기위해필요합니다. 예를들어, 오후 12시 ( 정오 ) 에재해가발생했고 RTO가 8시간이면, DR 절차는수용가능한서비스수준으로의복구가오후 8시까지는가능하도록조처해야하는것입니다. 복구시점목표 (RPO) 3 시간적으로측정한, 수용가능한데이터손실량을말합니다. 예를들어, RPO가 1시간이라면재해가정오에발생했으므로복구된시스템에는최소오전 11시까지의모든데이터가포함되어야한다는것입니다. 기업은일반적으로시스템을가동할수없을때기업에미칠재정적영향에근거하여수용가능한 RTO 및 RPO를결정합니다. 재정적영향은일반적으로시스템다운타임및가용성부족으로인한사업손실및기업이미지손상등여러요인을고려하여평가됩니다. IT 조직은 RTO에서수립한시간및서비스수준범위내에서 RPO에따라비용효율적으로시스템복구를제공할수있는솔루션을계획합니다. 기존의재해복구투자관행 재해복구에대한기존접근방식은데이터및인프라를다양한수준의오프사이트에복제하는것입니다. 중요한비즈니스서비스는이러한인프라에서설정및유지관리되며정기적으로테스트됩니다. 재해복구환경과소스인프라는물리적으로멀리떨어지게배치하여재해복구환경을원본사이트에영향을줄수있는장애로부터격리해야합니다. 복제환경을지원하는데필요한인프라에는다음각항목이포함됩니다. 전력공급및냉각을포함한인프라수용시설. 자산의물리적보호를위한보안인프라. 환경확장을위한적합한수용능력. 인프라를수리, 교체및재생하기위한지원. 2 출처 : http://en.wikipedia.org/wiki/recovery_time_objective 3 출처 : http://en.wikipedia.org/wiki/recovery_point_objective

최대부하환경에서의대역폭사용률을견딜수있는인터넷연결을제공하기위한인터넷서비스 공급자 (ISP) 와의계약. 방화벽, 라우터, 스위치및로드밸런서같은네트워크인프라. 사용자인증, DNS( 도메인이름시스템 ), DHCP( 동적호스트구성프로토콜 ), 모니터링및경고등의 애플리케이션및백엔드서비스를실행하는서버및지원데이터를위한스토리지장치를포함하는 모든미션크리티컬서비스를실행할충분한서버용량. 서비스의중요도에따라복제환경을장애내결함성방식으로구성할수있습니다. 이경우일반적으로위에 나열된전체인프라를복제하는작업이수반됩니다. 재해복구에필수적인 AWS 서비스및기능 재해복구에대한다양한접근법을논의하기전에, 재해복구와가장관련이있는 AWS 서비스및기능을검토하는것이중요합니다. 이섹션은이러한내용을요약하고있습니다. 재해복구준비단계에서는데이터마이그레이션과영구스토리지를지원하는서비스및기능의사용을고려하는것이필수적인데, 이로써재해가닥쳤을때 AWS에백업한데이터를복구할수있기때문입니다. AWS에서시스템의규모축소또는최대확장이수반되는일부시나리오의경우, 컴퓨팅리소스가필요한경우도있습니다. 재해에대처할때, AWS에서시스템을실행할수있도록신속하게컴퓨팅리소스를공급하거나 AWS에서이미실행중인리소스에장애조치를취하는것이관건입니다. 필수적인인프라요소에는 DNS, 네트워킹기능및아래에서설명하는다양한 Amazon Elastic Compute Cloud(Amazon EC2) 기능이포함됩니다. 지역 Amazon Web Services는여러지역에서사용이가능하므로, 시스템을완전히배포할장소뿐만아니라재해복구를위해가장적합한위치도선택할수있습니다. 본백서의작성시점을기준으로 AWS는미국동부 ( 버지니아북부 ), 미국서부 ( 캘리포니아북부 ), EU( 아일랜드 ), 아시아태평양 ( 싱가포르 ), 아시아태평양 ( 도쿄 ) 의다섯개지역에서사용가능합니다. 스토리지 Amazon Simple Storage Service(Amazon S3) 는미션크리티컬한데이터및기본데이터저장을위한내구성이뛰어난스토리지인프라를제공합니다. 객체는지역내에서여러시설의여러장치에중복저장됩니다. AWS는 Amazon S3 버전관리, AWS Multi-Factor Authentication, 버킷정책및Identity and Access Management(IAM) 을통해데이터보존및보관을위한추가보호수단을제공합니다.

Amazon Elastic Block Store(Amazon EBS) 는데이터볼륨의 PIT(Point in Time) 스냅샷을생성하는기능을제공합니다. 스냅샷은새로운 Amazon EBS 볼륨을시작하는기점이될수있으며데이터를장기간보호할수있습니다. 일단볼륨을생성하면실행중인 Amazon EC2 인스턴스에연결할수있습니다. Amazon EBS 볼륨은인스턴스수명과관계없이지속되는오프인스턴스스토리지를제공합니다. AWS Import/Export는데이터전송시이동식스토리지디바이스를사용하여 AWS에서많은양의데이터를빠르게송수신할수있습니다. AWS는 Amazon의고속내부네트워크를사용해인터넷을거치지않고스토리지디바이스에서직접데이터를송수신합니다. 용량이큰데이터세트의경우 AWS Import/Export가대개인터넷전송보다빠르며연결을업그레이드하는것보다비용효율성이높습니다. AWS Import/Export를사용하여 Amazon S3 버킷안팎으로또는 EBS 스냅샷으로데이터를마이그레이션할수있습니다. AWS Storage Gateway를사용하면 AWS 클라우드스토리지와온프레미스애플리케이션사이에데이터를원활하게마이그레이션할수있습니다. AWS Storage Gateway는볼륨데이터를사용자인프라및 AWS에로컬로저장합니다. 이를통해기존온프레미스애플리케이션에서데이터를비용효율적이고안전하고견고한 AWS 스토리지인프라에원활하게저장하고이데이터에액세스할때의지연시간을줄입니다. 컴퓨팅 Amazon Elastic Compute Cloud(Amazon EC2) 는클라우드에서규모를자유자재로변경할수있는컴퓨팅파워를제공합니다. 몇분이내에 EC2 인스턴스를생성할수있는데, 이는온전한제어권한이귀하에게있는가상머신입니다. 재해복구측면에서는이처럼귀하가제어할수있는가상머신을신속하게생성할수있는기능이필수적입니다. Amazon EC2의모든기능을설명하는것은이문서의범위를벗어납니다. 여기서는재해복구와가장밀접한관련이있는 Amazon EC2의측면을중점적으로다룹니다. Amazon 머신이미지 (AMI) 는운영체제에맞춰사전구성되며, 일부사전구성된 AMI에는애플리케이션스택이포함될수도있습니다. 또한귀하만의 AMI를구성할수도있습니다. 재해복구측면에서는귀하만의 AMI를구성하여구별해둔후복구절차의일부로실행하는것이좋습니다. 이러한 AMI는귀하가선택한운영체제및적절한애플리케이션스택과사전구성해야합니다. Amazon EC2 예약인스턴스는 EC2 인스턴스의운영비용절감을위해종종사용되는데, 재해복구와특히관련된다른장점이있습니다. 예약인스턴스는필요한용량을실제로필요할때사용할수있도록해줍니다. 가용영역은다른가용영역에장애가발생할경우분리되도록설계된별개의위치로, 동일지역의다른가용영역에저렴하고, 지연시간이짧은네트워크연결을제공합니다. 별도의가용영역에서인스턴스를시작함으로써단일위치에서장애가발생할경우애플리케이션을보호할수있습니다. 지역은하나이상의가용영역으로구성됩니다.

Amazon EC2 VM Import 기능을사용하면가상머신이미지를기존환경에서 Amazon EC2 인스턴스로손쉽게 가져올수있습니다. 네트워킹 재해처리시, 다른장소에서장애조치할때네트워크설정을수정해야할가능성이큽니다. Amazon Route 53는가용성과확장성이높은 DNS( 도메인이름시스템 ) 웹서비스입니다. 이서비스는개발자와기업이매우신뢰할수있고비용효율적인방식으로최종사용자를인터넷애플리케이션에라우팅할수있도록설계되었습니다. 엘라스틱 IP 주소는동적클라우드컴퓨팅에적합하게설계된고정 IP 주소입니다. 그러나기존의고정 IP 주소와달리엘라스틱 IP 주소를사용해공인 IP 주소를특정지역내에있는계정의인스턴스에프로그래밍방식으로다시매핑하여인스턴스또는가용영역장애를마스킹할수있습니다. 재해복구를위해대부분의필수시스템에대한 IP 주소를사전할당하여재해가발생하기전에 IP 주소를미리알수있습니다. 이로써재해복구계획을간단히실행할수있습니다. Elastic Load Balancing은수신되는애플리케이션트래픽을여러 Amazon EC2 인스턴스에자동으로분산합니다. 따라서애플리케이션의내결함성을크게높이고, 수신되는애플리케이션트래픽에응답하는데필요한로드밸런싱용량을원활하게제공할수있습니다. 엘라스틱 IP 주소를사전할당하는것과마찬가지로, Elastic Load Balancer를사전할당하여 DNS 이름을미리알수있어재해복구계획을간단히실행할수있습니다. Amazon Virtual Private Cloud(Amazon VPC) 를사용해 Amazon Web Services 클라우드에서개인적이고격리된공간을프로비저닝하고, 가상네트워크를정의해 AWS 리소스를시작할수있습니다. 또한, IP 주소범위, 서브넷생성, 라우팅테이블과네트워크게이트웨이의구성을선택하는등가상네트워킹환경을완벽히제어할수있습니다. 이렇게하면기업데이터센터와 VPC를 VPN으로연결하여 AWS 클라우드를기업데이터센터의연장선으로활용할수있습니다. 재해복구측면에서는 Amazon VPC를사용하여기존네트워크토폴로지를클라우드까지확장할수있습니다. 이는특히일반적으로내부네트워크에있는기업애플리케이션을복구할때에적합합니다. Amazon Direct Connect를사용해귀하의프레미스에서 AWS로전용네트워크를간편하게연결할수있습니다. 많은경우, 이서비스는네트워크비용을줄이고, 대역폭처리량을높이며, 인터넷기반연결보다더일관된네트워크환경을제공합니다. 데이터베이스 데이터베이스요구사항에대해서는다음 AWS 서비스를사용하는것을고려해보십시오.

Amazon Relational Database Service(Amazon RDS) 를사용해클라우드에서관계형데이터베이스를더욱간편하게설정, 관리및확장할수있습니다. Amazon RDS를재해복구준비단계에서사용하여이미실행중인데이터베이스에있는중요데이터를보존하거나복구단계에서사용하여생산데이터베이스를실행할수도있습니다. Amazon SimpleDB는데이터베이스관리작업부담을덜어주는고가용성의유연한비관계형데이터스토리지입니다. 이스토리지는재해복구준비및복구단계에서도사용할수있습니다. Amazon EC2에서원하는데이터베이스소프트웨어를설치하여실행할수도있으며, 인기있는다양한데이터베이스시스템중에서선택할수있습니다. AWS의데이터베이스옵션에대한자세한정보는 'AWS에서데이터베이스실행 ' 을참조하십시오. 배포오케스트레이션 Amazon EC2에서배포자동화및시동후소프트웨어설치 / 구성프로세스와도구를사용할수있습니다. 이영역에투자하는것은매우중요합니다. 이는자동화방식으로필요한리소스를생성할수있으므로복구단계에서매우유용합니다. AWS CloudFormation은개발자와시스템관리자가관련 AWS 리소스집합을쉽게생성하고, 예측가능하게순서대로프로비저닝하도록지원합니다. 귀하의환경에맞는템플릿을생성하고필요한만큼관련리소스 ( 스택이라칭함 ) 집합을배포할수있습니다. 보안 AWS 서비스에서는다양한보안관련기능을사용할수있습니다. 보안베스트프랙티스백서를검토해 보십시오. AWS 는또한 AWS 보안센터에서위험성및준수관련추가정보를제공합니다. 보안에대해자세히 다루는것은본백서의범위를벗어납니다.

AWS 를사용한재해복구시나리오의예 이섹션은기존의재해복구방법과 AWS 를비교하고, AWS 의사용법을중점적으로보여주는네가지재해복구 시나리오에대해소개합니다. 백업및복구 AWS로의간단한복구를위한파일럿라이트웜대기솔루션다중사이트솔루션 Amazon Web Services 는위에예로든각재해복구전략을고객이비용효율적으로수행할수있게해줍니다. 위의예는단편적인예일뿐이며, 이러한예를변형하거나서로조합하여사용하는것도가능합니다. 백업및복구 대부분의기존환경에서는데이터를테이프에백업하여정기적으로오프사이트로전송합니다. 이방법은복구하는데시간이오래걸립니다. Amazon S3가백업데이터에이상적인솔루션인이유는지정된한해동안 99.999999999% 의객체내구성을제공하도록설계되었기때문입니다. Amazon S3와데이터를주고받는과정은주로네트워크를통해이루어지므로, 어떤위치에서든액세스가가능합니다. Amazon S3에백업할수있는다양한상용및오픈소스백업솔루션이있습니다. AWS Import/Export 서비스는스토리지장치를직접 AWS에연결함으로써대규모의데이터세트전송이가능합니다. AWS Storage Gateway 서비스를사용하면온프레미스데이터볼륨의스냅샷이백업을위해 Amazon S3에자동으로복사되므로나중에이스냅샷에서로컬볼륨이나 AWS EBS 볼륨을생성할수있습니다. AWS에서실행되는시스템의경우, 고객은 Amazon S3에도백업할수있습니다. Amazon RDS의 Elastic Block Store(EBS) 볼륨및백업의스냅샷은 Amazon S3에저장됩니다. 또는 Amazon S3로파일을직접복사하거나백업파일을생성하여 Amazon S3에복사할수도있습니다. Amazon S3에백업데이터를저장하는다양한백업솔루션이있으며, Amazon EC2 시스템에서도이러한솔루션을사용할수있습니다.

그림 1: 현장인프라또는 AWS 로부터 S3 에데이터를백업하는옵션 데이터백업은시작에불과합니다. 재해시나리오에서는데이터복구를테스트할수있어야하고, 데이터복구가 신속하고신뢰할만한방식으로이루어져야합니다. 고객은자신의시스템이데이터를적절히보존하고, 데이터 보안을유지하도록구성되었는지, 데이터복구절차를이미테스트했는지확인해야합니다. 그림 2: S3 백업에서 AWS EC2 로시스템복구

백업및복구를위한핵심단계 : 귀하의데이터를 AWS에백업할적절한도구또는방법을선택합니다. 이데이터에대한적절한보존정책이있는지확인합니다. 이데이터에대한적절한보안방법 ( 암호화및액세스정책등 ) 이마련되어있는지확인합니다. 이데이터의복구및시스템복구를정기적으로테스트합니다. AWS 로의신속한복구를위한파일럿라이트 파일럿라이트의개념은가스히터에서비롯되었습니다. 가스히터는항시켜지는작은불꽃으로전체난로를점화하여필요할때집을따뜻하게할수있습니다. 이시나리오는백업및복구시나리오와비슷하지만시스템의가장중요한핵심요소가이미구성되어 AWS( 파일럿라이트 ) 에서실행되고있는지를확인해야합니다. 복구시점이되면중요한코어주변으로전체생산환경을신속하게프로비저닝해야합니다. 파일럿라이트를위한인프라요소에는기본적으로데이터베이스서버가포함되는데, 이서버의데이터는 Amazon EC2에복제됩니다. 시스템에따라 AWS에복제해야하는중요데이터가데이터베이스외부에있을수도있습니다. 이것이시스템의중요한코어 ( 파일럿라이트 ) 입니다. 코어주변으로 AWS의모든다른인프라요소 ( 난로의나머지부분처럼 ) 가신속하게프로비저닝되어전체시스템을복구하는것입니다. 비즈니스크리티컬한서비스를복구하기위해인프라의나머지부분을프로비저닝하려면일반적으로 Amazon 머신이미지 (AMI) 로번들링된사전구성된서버가있어야합니다. 이서버는복구시점통지를받는즉시시작됩니다. 복구를시작할때, 이 AMI의인스턴스가신속하게준비되어파일럿라이트주변의배포범위에서각자의역할을찾습니다. 네트워킹관점에서보면엘라스틱 IP 주소 ( 재해복구준비단계에서미리할당할수있음 ) 를사용하여인스턴스와연결하거나 Elastic Load Balancing을사용하여트래픽을여러인스턴스에분배할수도있습니다. 다음으로 CNAME을사용하여 Amazon EC2 인스턴스시점이나 Elastic Load Balancing 시점으로 DNS 레코드를업데이트합니다. 덜중요한시스템의경우에는 EBS 스냅샷의형태와같이 AWS에서이용가능한설치패키지및구성정보가있는지확인할수있습니다. 이는애플리케이션서버설정속도를높여주는데, 여러가용영역에서다수의볼륨을신속하게생성하여 EC2 인스턴스에연결할수있기때문입니다. 그런다음적당하게설치및구성할수있습니다. 파일럿라이트방법은상기 " 백업및복구 " 시나리오보다복구시간을더단축할수있는데, 시스템의핵심요소가이미실행되고있고지속적으로업데이트되기때문입니다. 애플리케이션을완전히복구하기위한설치

및구성작업이아직남아있습니다. AWS 를사용해인프라자원의프로비저닝및구성을자동화해상당한 시간을절약하고인간의실수로부터보호할수있습니다. 준비단계 : 다음그림은준비단계를보여줍니다. 이단계에서는복구단계시, 전체환경이시작되는작은코어인파일럿 라이트에정기적으로변경되는데이터를복제해야합니다. 운영체제및애플리케이션과같이업데이트빈도가 비교적적은데이터는 Amazon 머신이미지 (AMI) 로정기적으로업데이트및저장할수있습니다. 그림 3: 파일럿라이트시나리오의준비단계 준비핵심사항 : 데이터를복제또는미러링하도록 EC2 인스턴스를설정합니다. AWS에모든사용자정의지원소프트웨어패키지가있는지확인합니다. 빠른복구가필요한핵심서버의 Amazon 머신이미지 (AMI) 를생성및관리합니다. 이서버를정기적으로실행하고, 테스트하고, 소프트웨어업데이트및구성변경사항을적용합니다. AWS 리소스의프로비저닝을자동화할것인지고려합니다. 복구단계 :

파일럿라이트주변환경의나머지부분을복구하기위해, 적절한인스턴스형태로몇분내에 Amazon 머신이미지 (AMI) 에서시스템을시작할수있습니다. 동적데이터서버의경우, 크기를조정하여필요에따라생산볼륨을처리하거나적당히용량을추가합니다. 대개의경우수평적확장 ( 가능한경우 ) 은가장비용효율적인방법이며, 시스템에용량을추가하는확장성있는방법입니다. 그러나더큰 EC2 인스턴스유형을선택하여수직으로확장하는것도가능합니다. 네트워킹관점에서보면필요한 DNS 업데이트는무엇이든병렬로처리할수있습니다. 일단복구한후에는중복을최대한빨리복구해야합니다. 생산환경에장애가발생한직후에재해복구환경에장애가발생할확률은적지만, 이위험성역시염두에두어야합니다. 시스템을정기적으로백업하고데이터계층에추가중복을고려해볼수있습니다. 그림 4: 파일럿라이트시나리오의복구단계 복구핵심사항 : 사용자정의 AMI에서애플리케이션 EC2 인스턴스를시작합니다. 필요시, 데이터베이스 / 데이터저장인스턴스의크기를조정및 / 또는확장합니다. EC2 서버지점으로 DNS를변경합니다. AMI에기반하지않는시스템을설치및구성합니다. 이때, 자동화방식으로수행하는것이이상적입니다. AWS 의웜대기솔루션 웜대기솔루션은파일럿라이트요소와준비과정을제공합니다. 이솔루션을사용할경우일부서비스는항상 실행되므로복구시간을더욱단축할수있습니다. 비즈니스크리티컬한시스템을확인한후 AWS 에완전히 복제하여항상실행할수있습니다.

이러한서버는규모가제일작은 EC2 인스턴스에서실행할수있습니다. 이솔루션은최대생산부하를처리할정도로규모가확장되지는않지만기능은온전하게작동합니다. 이솔루션은테스트, 품질보증및내부사용목적등비생산작업에사용할수있습니다. 재해시, 이시스템은생산부하를처리할수있도록신속하게규모를확장합니다. AWS에서는로드밸런서에더많은인스턴스를추가하거나작은용량의서버가더큰 EC2 인스턴스유형에서실행되도록크기를조정함으로써규모를확장할수있습니다. 위에서설명한바와같이대개의경우수평적확장 ( 가능한경우 ) 이수직적확장보다더많이이용됩니다. 준비단계 : 다음다이어그램은웜대기솔루션의준비단계를보여주며, 이때현장및 AWS 솔루션이나란히실행됩니다. 그림 5: " 웜대기 " 시나리오의준비단계 준비핵심사항 :

데이터를복제또는미러링하도록 EC2 인스턴스를설정합니다. Amazon 머신이미지 (AMI) 를생성및관리합니다. EC2 인스턴스또는 AWS 인프라의최소풋프린트를사용하여애플리케이션을실행합니다. 실제환경에맞게소프트웨어및구성파일을패치하거나업데이트합니다. 복구단계 : 생산시스템에장애가발생할경우, 대기환경은생산부하를처리하도록확장되며, DNS 레코드는모든 트래픽을 AWS 로라우팅하도록변경됩니다. 그림 6: " 웜대기 " 시나리오의복구단계. 복구핵심사항 : 필요하다면더큰 EC2 인스턴스유형에서애플리케이션을시작합니다 ( 수직적확장 ). Load Balancer로서비스내에서 EC2의크기를증가시킵니다 ( 수평적확장 ). DNS 레코드를변경하여모든트래픽이 AWS 환경으로라우팅되게합니다. AWS의규모를적정하게조정하거나증가된부하를수용할수있도록 Auto Scaling 사용을고려합니다.

AWS 및현장에배포된다중사이트솔루션 다중사이트솔루션은액티브-액티브구성으로기존의현장인프라뿐아니라 AWS에서도실행됩니다. 사용하는데이터복제방법은선택한복구시점에의해 ( 위 RPO 참조 ) 결정됩니다. 다양한복제방법이있습니다 ( 아래참조 ). Amazon Route 53와같은가중 DNS 서비스는서로다른사이트로생산트래픽을라우팅하는데사용됩니다. 일정량의트래픽은 AWS의인프라로전송되며, 나머지는현장인프라로전송됩니다. 현장재해시, DNS 가중치를조정하여모든트래픽을 AWS 서버로보낼수도있습니다. 최대생산부하량을처리할수있도록 AWS 서비스용량을신속하게증가시킬수있습니다. EC2 Auto Scaling을이용해이과정을자동화할수있습니다. 기본데이터베이스서비스의장애를감지하고 AWS에서실행되는병렬데이터베이스서비스로이관되기위해몇가지애플리케이션로직이필요할수있습니다. 이시나리오의비용은정상운영중 AWS가처리하는생산트래픽의양에따라결정됩니다. 복구단계에서는트래픽을사용한만큼, 그리고전체재해복구환경을사용한기간에대해서만비용을지불하면됩니다. " 항시작동하는 " AWS 서버에대해예약인스턴스를구입하여비용을더욱줄일수있습니다. 준비단계 : 아래그림에서 DNS 를사용하여트래픽의일부를 AWS 사이트로라우팅하는것을볼수있습니다. AWS 의 애플리케이션은현장생산시스템의데이터원본에액세스할수있습니다. 데이터는 AWS 인프라에복제되거나 미러링됩니다.

그림 7: " 다중사이트 " 시나리오의준비단계. 준비핵심사항 : 생산환경을복제하도록 AWS 환경을설정합니다. DNS 가중치또는이와유사한기술을설정하여두사이트에전송되는요청량을분배합니다. 복구단계 : 아래그림은재해가현장에발생했을때의상황을보여줍니다. 트래픽은 DNS 업데이트를통해 AWS 인프라로 이관됩니다.

그림 8: 현장및 AWS 인프라를이용한 " 다중사이트 " 시나리오의복구단계. 복구핵심사항 : DNS 가중치를변경하여모든요청이 AWS 사이트로전송되도록합니다. 로컬 AWS 데이터베이스서버를사용하도록장애조치에대한애플리케이션로직을구성합니다. AWS의규모를적정하게자동으로조정하도록 Auto Scaling 사용을고려합니다. 다중 AZ 아키텍처를설계하여다중사이트솔루션의가용성을더증가시킬수있습니다. 여러가용영역에있는 애플리케이션을설계하는방법에대한자세한정보는 Designing Fault-Tolerant Applications in the AWS Cloud 백서를참조하십시오.

데이터복제 원격지에데이터를복제할때, 고려해야할몇가지요인이있습니다. 사이트간의거리 : 거리가멀수록일반적으로지연시간및 / 또는지터가더발생하기쉽습니다. 이용가능한대역폭 : 연결범위와다양성 애플리케이션에필요한데이터전송속도 : 데이터전송속도는이용가능한대역폭보다낮아야합니다. 복제기술은네트워크를효과적으로사용할수있도록병행해서사용가능해야합니다. 데이터복제시두가지주요방법이있습니다 : 동기화및비동기화. 동기복제 데이터가여러위치에서개별적으로업데이트됩니다. 이작업은네트워크성능과가용성에의존합니다. 비동기복제 데이터가여러위치에서개별적으로업데이트되지않습니다. 데이터는네트워크성능과가용성이허용하는범위에서전송되며, 애플리케이션은데이터를계속작성합니다. 이러한데이터는아직완전히복제되지않았을수있습니다. 많은데이터베이스시스템이비동기데이터복제를지원합니다. 데이터베이스복제본은원격에배치가능하며, 복제본은기본데이터베이스서버와완전히동기화될필요는없습니다. 이점은많은시나리오에서허용되는데, 이를테면백업소스또는보고 / 읽기전용사용사례가이에해당합니다. 사용중인소프트웨어솔루션에사용되는복제기술을알아보십시오. 복제기술에대한세부적인분석은본 백서의범위를벗어납니다. AWS에서는지역내가용영역이잘연결되어있으나, 물리적으로는분리되어있습니다. 예를들어, " 다중 AZ" 모드를사용하는경우 Amazon Relational Database Service는동기복제를통해 2차가용영역에데이터를복제합니다. 이렇게함으로써기본가용영역을사용할수없게될경우에도데이터손실을방지할수있습니다. AWS 지역은서로완전히독립되어있으나, 액세스하고사용하는방식은모두같습니다. 고객은서로다른대륙간처럼멀리떨어진위치의재해를해결하는복구프로세스를만들수있습니다. 장거리재해복구시흔한문제나비용이발생하지않습니다. 고객은데이터와시스템을두곳이상의 AWS 지역에백업하여대규모재해가발생하더라도서비스를복구할수있습니다. 고객은 AWS 지역을사용하여작업프로세스의복잡성을상대적으로줄이고전세계최종사용자에게서비스를제공할수있습니다.

재해복구계획의개선 탄탄한재해복구계획을수립하기위해서는몇가지중요한단계를따라야합니다. 이섹션은주요단계중 일부를설명합니다. 테스트 재해복구솔루션을배치한다음에는테스트를해야합니다. " 게임데이 " 는재해복구환경에장애조치를수행하는날입니다. 충분한설명서를준비하여실제상황이발생했을때프로세스를최대한간소화하도록합니다. AWS에서는게임데이시나리오를테스트하기위한복제환경을신속하고비용효율적으로구성할수있으며, 일반적으로기존의생산환경을변경할필요가없습니다. AWS CloudFormation을사용하여 AWS에완벽한환경을배포할수있습니다. 이서비스는템플릿을사용하여 AWS 리소스에대해설명하며, 전체환경을생성하기위해필요한관련종속성또는런타임매개변수에대해서도설명합니다. 차별화된테스트는다양한종류의재해를대비하고있는지확인하기위한중요한요소입니다. 다음은 " 게임데이 " 시나리오의예입니다. 특정사이트와컴퓨터세트에전력손실발생단일사이트의 ISP 연결손실핵심비즈니스서비스에영향을미치는바이러스가다중사이트에작용함사용자의실수가데이터손실을야기하여 PIT(Point in Time) 복구가필요함 모니터링및경보 정기적인점검과충분한모니터링을실시하여재해복구환경이서버장애나연결문제, 애플리케이션문제등으로영향을받았을때경고해주어야합니다. Amazon CloudWatch를통해 AWS 리소스의메트릭에액세스할수있습니다. 경보는어떤메트릭에서든정의된임계값에따라설정할수있으며, 필요한 Amazon Simple Notification Service 메시지를전송하여예기치않은동작발생에대해경고할수있습니다. AWS에서어떠한모니터링솔루션이든사용할수있습니다. 귀하의회사가인스턴스메트릭뿐만아니라게스트 OS 통계및애플리케이션상태를모니터링하기위해사용하는기존의모니터링및경고도구를계속사용할수도있습니다. 백업 재해복구환경으로전환한경우, 지속적으로정기적인백업을해야합니다. 백업및복구를정기적으로 테스트하는것은폴백솔루션에필수적입니다.

AWS 를사용하면재해복구인프라를 " 항시작동 " 할필요없이저렴한비용으로자주재해복구테스트를수행할 수있습니다. 사용자액세스 AWS Identity and Access Management(IAM) 을사용하여재해복구환경의리소스에안전하게액세스할수있습니다. 이방식으로재해복구환경에서작업하는동안사용자의책임을분리하는역할 / 사용자기반보안정책을만들수있습니다. 자동화 구성관리또는오케스트레이션소프트웨어를사용하여 AWS 기반서버와온프레미스서버에애플리케이션배포를자동화할수있습니다. 자동화를통해두환경모두에서애플리케이션및구성변경관리를손쉽게처리할수있습니다. 몇가지인기있는오케스트레이션소프트웨어옵션이제공되며, 이용가능한솔루션공급자를당사의솔루션공급자페이지 4 에서확인할수있습니다. AWS CloudFormation은몇가지도구와함께작동하여인프라서비스를자동으로프로비저닝합니다. 처음부팅시사용자데이터를인스턴스로전달하고, 인스턴스유형또는역할을결정하기위해구성관리도구로이동시킬수있습니다. 이를통해정확한소프트웨어및구성이배포되었는지확인합니다. 자동화의전반적인목표는인스턴스상태가변경되지않도록자동으로유지하는것입니다. Auto Scaling을사용하여인스턴스풀의규모가 CloudWatch에서지정한메트릭에따른수요량을충족하기에적합한지확인할수있습니다. 재해복구측면에서다시말하면사용자가환경을더많이사용하면이러한증가된수요를충족하도록솔루션을자동으로확장할수있다는것입니다. 이벤트가종료되고사용량이잠재적으로감소하면솔루션을최소수준의서버로다시축소할수있습니다. 소프트웨어라이선스와재해복구 AWS 환경에대한라이선스를제대로받았는지확인하는것은다른어떤환경에대한라이선스를받는것못지않게중요합니다. Amazon은라이선스관리를용이하게해주는다양한모델을제공합니다. 예를들어, "Bring Your Own License" 를몇몇소프트웨어구성요소또는운영체제에서사용할수있습니다. 또는라이선스비용이시간당요금에포함되어있는소프트웨어군도있습니다. 이를 "License included" 라고합니다. Bring your Own License 는재해시, 기존의소프트웨어투자요소를활용할수있습니다. License included 는재해복구테스트기간과같이매일사용하지않는재해복구사이트에대한사전라이선스비용을최소화합니다. 4 솔루션공급자는다음주소에서참조할수있습니다. http://aws.amazon.com/solutions/solution-providers/

어느때든지귀하의라이선스및 AWS 에서의적용방식에대해의문사항이있는경우라이선스재판매자에게 연락하시기바랍니다. 결론 재해복구에대한다양한옵션과변형이있지만본백서는간편한백업및복구에서부터장애내결함성다중사이트솔루션에이르기까지일부일반적인패턴을중점적으로다룹니다. AWS는귀하의재해복구목표 (RTO와 RPO) 와예산을고려하여적절한재해복구솔루션을구성할수있는다양한구성블록과세부적인제어기능을제공합니다. AWS 서비스는온디맨드서비스이며사용량에대해서만비용을지불하면됩니다. 이것이바로상당한인프라를재해시에만신속하게사용해야하는재해복구에적합한핵심장점입니다. 본백서는보다효과적인재해복구계획을수립할수있도록 AWS가유연하고비용효율적인인프라솔루션을제공하는방법에대해기술합니다.

참고문헌 S3 시작안내서 : http://docs.amazonwebservices.com/amazons3/latest/gsg/ EC2 시작안내서 : http://docs.amazonwebservices.com/awsec2/latest/gettingstartedguide/ AWS 솔루션공급자정보 : http://aws.amazon.com/solutions/solution-providers/ Designing Fault-Tolerant Applications in the AWS Cloud 백서 : http://aws.amazon.com/whitepapers/ AWS 보안및준수센터 : http://aws.amazon.com/ko/security/ AWS 아키텍처센터 : http://aws.amazon.com/architecture AWS 기술백서 : http://aws.amazon.com/whitepapers