AWS 클라우드에서의웹애플리케이션호스팅모범사례 2010 년 5 월 Matt Tavis

AWS 클라우드에서의웹애플리케이션호스팅모범사례 2010 년 5 월 Matt Tavis

요약 가용성과확장성이뛰어난웹호스팅은복잡하고비용이많이들수있습니다. 기존의확장가능한웹아키텍처에서는높은수준의신뢰성을확보하기위해복잡한솔루션을구축하고, 고객서비스의질을보장하기위해트래픽도정확하게예측해야합니다. 트래픽최고치가일정기간에만밀집해있고트래픽패턴의변동폭이크면하드웨어의활용도가낮아지게되는데, 이렇게고가의운영비용이드는하드웨어를놀리게되면활용도가떨어지는하드웨어에집행한자본투자의효율도낮아지게됩니다. 이에반해, Amazon Web Services는트래픽사용량이급변하는웹애플리케이션에필요한신뢰성, 확장성, 보안, 고성능이라는장점을갖춘인프라는물론실시간고객트래픽패턴에맞게 IT 비용을최적화할수있는탄력적확장-축소형인프라모델도제공합니다. 대상 본백서는인프라의확장성을확보하고온-디맨드컴퓨팅수요를해결하는데필요한클라우드컴퓨팅서비스를찾고있는 IT 관리자및시스템아키텍트들을대상으로합니다.

기존웹호스팅의개요 휍호스팅의확장성은이미잘알려진주제이기때문에, 기존웹호스팅모델에익숙한사람들에게는이장에서다루는내용이그리놀랍지않을것입니다. 이섹션에서는클라우드에웹호스팅아키텍처를구현하는일에대해논할때주로비교대상으로등장하는표준웹호스팅아키텍처의예제를소개합니다. 기존웹애플리케이션호스팅아키텍처의사례 아래는기존웹호스팅모델을사용한확장가능한웹호스팅아키텍처의전형적인예입니다. 그림 1 - 기존웹애플리케이션아키텍처 기존웹호스팅아키텍처는구조를프레즌테이션, 애플리케이션, 퍼시스턴스 layer로구분하는일반적인 3 계층웹애플리케이션모델을중심으로설계됩니다. 이아키텍처는프리젠테이션, 퍼시스턴스또는애플리케이션 layer에호스트를더하는방식으로확장할수있도록설계되었으며필요성능, 장애조치, 가용성을갖추고있습니다. 다음섹션에서는이러한아키텍처를 Amazon Web Services 클라우드에이전할때의혜택과옮기는방법에대해살펴보겠습니다.

Amazon Web Services 를이용한클라우드에서의웹애플리케이션호스팅 기존웹호스팅아키텍처 ( 그림 1) 는몇가지적은수정만으로 AWS 제품에서제공하는클라우드서비스에이식될 수있습니다. 그보다먼저생각해보아야할것은과연이어플리케이션을클라우드환경에이전하는것이 적절한지에대한고려입니다. 기존애플리케이션호스팅솔루션을 AWS 클라우드로이전하는것에는어떤가치가있을까요? AWS 가일반적인웹애플리케이션호스팅문제를해결하는방법 여러분이웹애플리케이션의운영을담당한다면수많은인프라스트럭처및아키텍처관련문제들을겪게될 것입니다. AWS 는이에대해쉽고원활한솔루션들을효율적인비용으로제공합니다. 다음은기존호스팅모델 대신 AWS 를사용하는것의이점중일부입니다. 과도한서버대신효율적비용으로트래픽최고치를처리 기존호스팅모델에서는트래픽급증에대응하기위해서버를미리프로비저닝해둬야했으며트래픽이최고치까지 치솟지않는동안은그자원이낭비됩니다. 반면 AWS 로웹애플리케이션을호스팅하면서버를추가하는과정에서 온 - 디맨드프로비저닝이가능하므로트래픽에따라사용용량과비용이변화합니다. 예를들어다음의그래프는한웹애플리케이션이하루중오전 9 시부터오후 3 시사이에트래픽급증하며그외의 시간은낮은사용률을보여줍니다. 실제트래픽추이에기반한오토스케일링과필요시에만자원을사용하는 프로비저닝방식을택하면사용량과비용을 50% 이상절감할수있습니다. 그림 2 - 기존호스팅모델에서낭비된용량의사례

예측하지못한트래픽피크를처리하는확장성솔루션이보다더끔찍한일은기존호스팅모델의느린프로비저닝속도때문에예상하지못한트래픽요청급증에제때대응하지못하는것입니다. 어떤서비스가예상치못하게유명매체에서언급된후트래픽급증이일어나웹애플리케이션에장애가발생했다는식의이야기를많이들어보셨을겁니다. 예상치못한트래픽급증이발생한다고해도평소일반적인트래픽증감에맞춰웹애플리케이션을확장및축소하도록해주는온-디맨드사용구조는그대로단몇분만에새로운호스트를추가해충분히대응할수있습니다. 테스팅, 로드, 베타및사전생산환경을위한온-디맨드솔루션웹애플리케이션서비스를위한시스템자원을전통적호스팅환경에서구성할경우, 서비스를위한시스템구성에서만비용이발생하는것은아닙니다. 웹애플리케이션의품질을보장하기위해서는실제서비스를위한컴퓨팅환경을구성하기전에개발주기단계마다웹애플리케이션을최적화하기위한시험서비스, 베타및테스트환경을구성할필요가있습니다. 이테스팅하드웨어들의활용도를극대화하기위해여러가지최적화기술들을적용해본다고하더라도이자원들이정말로적절하게활용되는경우는매우드뭅니다. 따라서많은고가의하드웨어가오랜시간동안사용되지않은채로놓여있게됩니다. AWS 클라우드를사용할경우, 테스트시스템자원등을필요에따라프로비저닝할수있으므로정말필요할때만이런자원들을쓰는경제적활용이가능합니다. 또한최종버전의부하테스트를수행하기위해사용자트래픽을시뮬레이션할때도AWS 클라우드를활용할수있으며클라우드를새로운제품출시를위한준비환경으로사용해서비스중단을최소화한채애플리케이션버전을빠르게업데이트하는것도가능합니다.

AWS 클라우드아키텍처를통한웹호스팅 아래는기존웹애플리케이션아키텍처에서 AWS 클라우드컴퓨팅인프라를활용하는방법을나타낸것입니다. 그림 3 - AWS 에서웹호스팅아키텍처의사례

AWS 웹호스팅아키텍처의핵심구성요소 이섹션에서는 AWS 웹호스팅아키텍처의핵심적구성요소몇가지와기존웹호스팅아키텍처와의차이점을설명합니다. 콘텐츠전송 Amazon Web Service 클라우드컴퓨팅인프라에서도엣지캐싱은중요한요소입니다. 사용자의웹애플리케이션인프라에존재하는모든솔루션들이 AWS 클라우드에서잘작동하지만, AWS를사용하면고려할수있는선택지의수가하나늘어납니다. Amazon CloudFront 서비스 1 를활용해 Amazon Simple Storage Service 2 (Amazon S3) 에저장된애플리케이션을위한콘텐츠를엣지캐싱하는것입니다. Amazon EC2와엣지캐싱솔루션을함께사용할경우의주된이점은로컬엣지캐시 Point-of-Presence(POP) 를통해고객관점에서의애플리케이션성능을가속화할수있다는것입니다. 고객에게가장가까운지역에해당콘텐츠를캐싱함으로써스트리밍또는다운로드된정적콘텐츠 ( 예 : 플래시동영상또는이미지 ) 를훨씬빠르게로딩합니다. 또다른이점은 CloudFront 또한다른 AWS 서비스들과마찬가지로특별한조건이나최소의무사용량, 계약사항등이없는사용구조를갖고있으므로필요에따라원하는만큼의양과기간동안사용할수있다는것입니다. CNAME 및 Elastic IP를이용한공용 DNS의관리웹애플리케이션을 AWS 클라우드로이전하는데에는일부 DNS에대한변화가필수적입니다. AWS는공용 DNS 관리서비스를제공하지않으므로공용인터넷트래픽을 AWS 클라우드의애플리케이션에리다이렉트하기위해서는공용 DNS가 Elastic Load Balancing CNAM 또는엘라스틱 IP 주소를가리키도록변경해야합니다. 하지만 DNS는하위도메인에대한 CNAME의사용을제한하기때문에루트도메인 ( 예 : example.com) 이 Elastic Load Balancer CNAME을가리킬수없습니다. 시간이지남에따라 Elastic Load Balancer 뒤의 IP 주소가변경될수있으므로루트 DNS A-record를 Elastic Load Balancer CNAME 뒤의 IP에서가리키도록하는것은불가능하다는것을고려해야합니다. 이에대한간단한차선책은동적으로할당할수있는정적 IP 주소인 Elastic IP를애플리케이션에서두개이상의 EC2웹서버에지정하고, 이웹서버들이웹트래픽을올바른하위도메인으로리디렉트하게함으로써트래픽을 Elastic Load Balancer CNAME( 예 : www.example.com ) 으로라우팅하도록하는것입니다. 공개도메인이름을구매할때이용한도메인이름공급자는올바른하위도메인 ( 예 : www.example.com) 에대한 Elastic Load Balancer CNAME 신청을위해, 그리고루트도메인 A-records에대한엘라스틱 IP 주소목록을설정하기위해간단한체계를제공해야합니다. 1 Amazon CloudFront http://aws.amazon.com/cloudfront/ 2 Amazon S3 http://aws.amazon.com/s3

호스팅보안기존웹호스팅모델과는달리인바운드네트워크트래픽필터링은엣지에서제한되기보다는호스팅수준에서적용되어야합니다. Amazon EC2는인바운드네트워크방화벽과유사한보안그룹이라불리는기능을제공하여 EC2 인스턴스에접속할수있는프로토콜, 포트및소스 IP의범위를지정할수있도록해줍니다. 각각의 EC2 인스턴스는하나이상의보안그룹에할당될수있으며, 적합한트래픽을각인스턴스로라우팅합니다. 보안그룹은 EC2 인스턴스에대한액세스를가진특정서브넷또는 IP 주소만으로구성될수있습니다. 또는특정그룹에속한 EC2 인스턴스에대한액세스를제한하기위해다른보안그룹을참고할수있습니다. 예를들어 AWS 웹호스팅아키텍처사례 ( 위의그림 ) 에서클러스터웹서버의보안그룹은모든호스트에대해오직 TCP 80번, 443번 (HTTP, HTTPS) 포트를통한접근만허용하고, 직접호스트를관리하기위해어플리케이션서버보안그룹에속한인스턴스들에한해 22번 (SSH) 포트로의접근을허용하도록할수있습니다. 한편애플리케이션서버클러스터의보안그룹은웹서버보안그룹에접근을허용해웹요청을처리하도록하고사내서브넷에한정된 22번 (SSH) 포트의접속을허용해직접호스트를관리하도록할수있습니다. 이모델에서는지원엔지니어들이기업네트워크에서애플리케이션서버에직접로깅해애플리케이션서버박스에서다른클러스터에액세스할수있습니다. AWS의보안에대해더자세히알고싶으실경우 AWS 보안센터 3 에방문해주시기바랍니다. AWS 보안센터에서는 AWS의보안성능을설명하는보안게시판, 인증정보및보안백서를제공합니다. 그림 4: 웹애플리케이션에서의보안그룹 3 AWS 보안및준수센터 http://aws.amazon.com/ko/security

클러스터사이의로드밸런싱하드웨어로드밸런서는기존웹애플리케이션아키텍처에서사용되는일반적인네트워크어플라이언스입니다. AWS는호스팅상태점검, 다중가용영역에걸친 EC2 인스턴스에대한트래픽배포및로드밸런싱로테이션의 EC2 호스팅추가및제거를지원하는로드밸런싱솔루션인 Elastic Load Balancing 4 서비스를통해이와동일한성능을제공합니다. 사용자임의의설정이가능한 Elastic Load Balancing은영구 CNAME을통해예측가능한진입점을제공하는한편, 증감하는트래픽수요에대응하기위해로드밸런싱용량을동적으로확장및축소할수도있습니다. Elastic Load Balancing 서비스는어드밴스라우팅요구를처리할수있도록 sticky 세션도지원합니다. 애플리케이션이어드밴스로드밸런싱성능을필요로한다면그대안은 EC2 인스턴스 ( 예 : Zeus, HAProxy, nginx) 에소프트웨어로드밸런싱패키지를설치하여사용하며, 로드밸런싱이적용된이 EC2 인스턴스들에 Elastic IP를지정해 DNS 변화를최소화하는것입니다. 다른호스팅및서비스의검색기존웹호스팅아키텍처와의또다른차이점은대부분의호스트가동적 IP 주소를갖게될것이라는점입니다. 모든 EC2 인스턴스는공개및사설 DNS 항목을둘다가질수있으며인터넷상에서주소를부여할수있지만, DNS 항목및 IP 주소는인스턴스의시작에따라동적으로할당되며수동으로할당될수없습니다. 정적 IP (AWS 용어로는 Elastic IP) 는시작과동시에실행중인인스턴스에할당될수있지만, Elastic IP를갖춘 AWS 클라우드상의호스트들만이네트워크커뮤니케이션에대한일관된 endpoint를갖습니다. Elastic IP는마스터데이터베이스, 중앙파일서버및 EC2 호스팅로드밸런서등일관된 endpoint를필요로하는인스턴스및서비스용으로사용되어야합니다. 웹서버와같이쉽게확장-축소할수있는인스턴스유형은위에언급된영구적인서비스를통해자체동적 endpoint에서발견할수있도록만들어져야합니다. 이에대한간단한솔루션은인스턴스의구성및요구되는네트워크서비스 endpoint를중앙집중식으로유지하는것입니다. 그리고나서부트스트랩핑스크립트를통해인스턴스의시작동안사용할수있는일관된 Elastic IP 기반 endpoint로필요시에액세스할수있습니다. 대부분의웹애플리케이션아키텍처에는항상운영되는데이터베이스서버가있는데, 일반적으로이서버가이런유형의구성정보의저장소가됩니다. 염두에둬야할것중하나는 EC2로인프라를구성해지속적서비스를운영할경우비용절감을위해서예약인스턴스 5 를고려해볼필요가있다는것입니다. 예약인스턴스를사용하면새롭게추가된호스트가부트스트랩핑단계의통신을위해필요한 endpoint 목록을데이터베이스로부터요청할수있습니다. 인스턴스가시작될때이데이터베이스의위치를유저데이터 6 형태로각인스턴스에전달할수있습니다. 이외에도잘정의된 endpoint에서사용가능한고가용서비스인 SimpleDB 서비스를사용해구성정보를저장하고및유지할수있습니다. 4 Amazon Elastic Load Balancing http://aws.amazon.com/elasticloadbalancing 5 예약인스턴스 http://aws.amazon.com/ec2/reserved-instances/ 6 사용자데이터 http://docs.amazonwebservices.com/awsec2/latest/apireference/index.html?apireference-itemtype- RunInstancesType.html

웹애플리케이션내에서의캐싱기존웹애플리케이션아키텍처내에서사용되는소프트웨어기반캐싱솔루션은 AWS 클라우드에서도거의비슷하게사용됩니다. 캐싱소프트웨어솔루션을사용해 EC2 인스턴스를구축하기만해도충분히 AWS 클라우드에서캐싱을구현할수있습니다. 웹및애플리케이션 layer 캐싱을이러한방식으로처리할수있으며데이터베이스에서의중앙집중식구성으로웹및애플리케이션서버가적합한캐시서버를찾도록할수있습니다. 데이터베이스구성, 백업및 failover 많은웹애플리케이션들이특정형태의지속성을가지며, 대개데이터베이스형식입니다. AWS는클라우드에서데이터베이스를사용할수있도록해주는주요솔루션두가지를제공하는데, Amazon EC2 인스턴스에서관계형데이터베이스 (RDBMS) 를직접호스팅하거나, 호스팅된 RDBMS 솔루션인 Amazon Relational Database Service(RDS) 를사용하는것입니다. AWS는 EC 2에서 MySQL, Oracle, SQLServer, DB2 등다양한데이터베이스솔루션을쓸수있도록지원하고있습니다. RDS의사용은개발자에게친숙한연결방법 ( 예 : ODBC 또는 JDBC) 을제공하며, 또한웹서비스 API를통한간편한관리기능도제공합니다. 간단한 API 호출을통해스토리지추가나데이터백업, 더큰 EC2 인스턴스로의데이터이전등일반적인작업들을자동화할수있습니다. 기존의호스팅모델과마찬가지로클라우드의데이터베이스솔루션또한백업및 failover를지원할수있도록마스터인스턴스와슬레이브인스턴스모두를갖춰야합니다. EC2에서데이터베이스를호스팅하는 AWS 고객들은 EC2 인스턴스상에서읽기전용복제본의미러링및로그전달을통한항상준비된패시브슬레이브등다양한마스터 / 슬레이브및복제모델을사용하고있습니다. 웹애플리케이션은대개특정데이터베이스백업및실패모델을채택하고있는데, 대부분의경우 AWS 클라우드에서이러한모델을쉽게복제해구현할수있습니다. RDS를사용하는 AWS 고객에게는간단한 API 호출을통한기본백업및 failover 매커니즘을제공합니다. 데이터베이스의가용성을극대화하기위해 failover를위한멀티슬레이브를여러곳의가용영역에운영하는방식의 RDBMS 구성이권장됩니다. 각가용영역들은리전의가용성을최대한보장하기위해동일리전내다른가용영역과완전히분리되어있으므로, 가용영역을두개이상사용하는것은백업데이터센터를보유하는것과매우유사합니다. RDS를사용하는 AWS 고객은자동으로다른가용영역에바로사용될수있는예비슬레이브인스턴스를배포하는다중가용영역 (Multi-AZ) 기능의장점을누릴수있습니다. RDS를사용하지않고 EC2에서직접데이터베이스를실행할때더고려해봐야할사항은내결함지속스토리지의사용이가능한지생각해보는것입니다. 이조건을만족시킬수있도록 Amazon EC2에서데이터베이스를실행할때에는 Amazon Elastic Block Storage(Amazon EBS) 볼륨을활용하도록권장됩니다. EBS는데이터베이스가실행중인 EC2 인스턴스에대한 NAS(network attached storage) 와유사한역할을합니다. EC2 인스턴스에서데이터베이스를실행할때, 모든데이터베이스의데이터및로그는데이터베이스호스트가실패하더라도데이터와로그를사용가능하도록 Amazon EBS 볼륨에저장해야합니다. 이렇게하면호스트가실패하는경우에도새로운 EC2 인스턴스를생성하고여기에사용하던 Amazon EBS 볼륨을붙여데이터베이스가실패전의위치에서데이터를그대로액세스할수있습니다. 또한 Amazon EBS 볼륨은가용영역내에서자동으로이중화를제공해가용성을단순히디스크를사용하는것이상으로높입니다. 단일 Amazon EBS 볼륨의성능이필요한데이터베이스요건을만족시키지못한다면볼륨들을데이터베이스에맞게 IOPS 성능을향상시키도록스트라이프할수있습니다. RDS를사용할경우 RDS 서비스가직접 Amazon EBS 볼륨을관리합니다. RDS를사용할경우 Amazon EBS 볼륨의관리는 RDS 서비스로합니다.

AWS 는 EC2 상에서의관계형데이터베이스사용지원외에도, 고정된스키마없이도쿼리질의와데이터인덱싱이 가능한작은사이즈의고가용성및내결함성핵심비관계형데이터베이스서비스를제공하는 SimpleDB 서비스도 지원합니다. 인덱싱이많이되어있으며유연한대형단일스키마테이블의데이터액세스가필요한상황에서 SimpleDB 데이터베이스의좋은대안이될수있습니다. SimpleDB 사용의예로는구성관리데이터, 제품카탈로그 및세션데이터등이있습니다. 이외에도 EC2 는 Cassandra, CouchDB, MemcacheDB 등 NoSQL 진영의떠오르는신규 기술들을사용한호스팅이가능합니다. 데이터및자산에대한스토리지와백업 AWS 클라우드에는웹애플리케이션데이터및자산을저장, 액세스및백업하는다양한방법들이있습니다. Amazon Simple Storage Service(Amazon S3) 는고가용성이중화객체저장공간이며, 이미지나동영상, 혹은이외의 정적컨텐츠등정적이거나느리게변화하는객체를저장할수있는탁월한스토리지솔루션입니다. Amazon S3 를 CloudFront 서비스와연동해사용하면이러한데이터를엣지캐싱하거나스트리밍하는것도가능합니다. 스토리지와직접붙여쓸수있는파일시스템의경우 EC2 인스턴스에 Amazon Elastic Block Storage 볼륨을붙여 사용할수있으며, 이는 EC2 인스턴스가동을위한장착형디스크와같은역할을수행합니다. Amazon EBS 는 데이터베이스파티션이나애플리케이션로그등블록스토리지로액세스할필요가있거나실행중인인스턴스와 별개의지속성을요구하는데이터에적합합니다. EC2 인스턴스와별개로유지되는지속성에더해 Amazon EBS 볼륨의스냅샷을생성 Amazon S3 에저장하는것도가능하므로, 실행중인인스턴스데이터를백업하는데사용할 수있습니다. EBS 스냅샷은데이터증분백업이가능하며, 따라서자주스냅샷을생성할수록스냅샷에걸리는시간은 줄어듭니다. Amazon EBS 볼륨은 1TB 까지생성할수있으며, 다중 Amazon EBS 볼륨을스트라이핑해서더큰볼륨을 만들거나 I/O 성능을향상시키는것도가능합니다. Amazon EBS 스냅샷의또다른유용한특징은여러개의 Amazon EBS 볼륨으로복제하거나복제된볼륨을실행중인다른인스턴스에첨부하여사용이가능하다는점입니다. 플릿 Auto Scaling AWS 웹아키텍처와기존호스팅모델간의주요차이점중한가지는증감하는트래픽에대응할수있도록웹애플리케이션플릿을수요에맞게동적으로확장할수있는기능입니다. 일반적으로기존호스팅모델에서는예상되는트래픽의양에맞춰호스트의양을미리프로비저닝하는트래픽예측모델을사용합니다. AWS 클라우드아키텍처에서는플릿을확장및축소하는트리거세트에기초하여인스턴스를빠르게프로비저닝할수있습니다. Amazon Auto Scaling 은서버용량그룹을생성해실시간으로수요에맞춰늘리거나줄일수있도록해줍니다. Auto Scaling 은데이터지표를살피는 CloudWatch, 그리고부하를분산하기위해호스트를추가하거나제거해주는 Elastic Load Balancing 서비스와직접연동됩니다. 예를들어, 웹서버들이일정시간동안 80% 이상의 CPU 사용량을보고할경우신속하게웹서버를추가구축할수있으며, 이는자동으로 Elastic Load Balancer 에추가되어즉시부하분산에쓰입니다. AWS 웹호스팅아키텍쳐모델에나타나있듯이, 아키텍처의각레이어마다다른오토스케일링그룹을만들어레이어들이각기독립적으로확장및축소되도록할수있습니다. 예를들어, 웹서버 auto-scaling 그룹은네트워크 I/O 상에서확장 - 축소를트리거할수있으며, 애플리케이션서버 auto-scaling 그룹은 CPU 사용량을확장 - 축소할수있습니다. 최대값과최소값을지정해상시가용성을보장하고그룹내사용량을제한하는것도가능합니다. Auto Scaling 트리거를조정해해당레이어에맞게전체플릿을확장및축소하도록함으로써리소스사용량을실제트래픽수요에맞추도록할수도있습니다. Auto Scaling 서비스를사용하는방법외에도직접 EC2 API 를사용해 EC2 플릿을손쉽게확장할수있으므로인스턴스를시작혹은중단하거나검사하는것도가능합니다.

AWS를사용한 failover 기존웹호스팅대신 AWS를사용할때의또다른주요이점은가용영역이존재해웹애플리케이션개발자들이인스턴스를배포하기위해다양한위치에쉽게액세스할수있다는것입니다. 가용영역은다른가용영역에오류가발생할경우해당가용영역의오류로부터분리되도록설계된별개의위치로, 저렴하고지연시간도낮은네트워크를통해동일리전의다른가용영역에연결되어있습니다. AWS 웹호스팅아키텍처에서볼수있듯여러가용영역에 EC2 호스트를분산해웹애플리케이션에장애가발생하지않도록하는방법을권장합니다. 실패가발생할경우를대비해단일접속지점을여러가용영역에나눠이전할수있도록프로비저닝하는것이중요합니다. 예를들어, 예상치못한장애상황에서도데이터의지속성과접근성을보장할수있도록슬레이브데이터베이스를기존의가용영역외에다른가용영역에도설치해둘것을권장합니다. 기존의웹애플리케이션을 AWS 시스템으로이전하는과정에서종종구조적인변화가필요할수도있지만, AWS 클라우드를통해확장성과안정성, 그리고비용효율을제고할수있다는것을감안한다면충분한가치가있습니다. 웹호스팅에대한 AWS 사용시핵심고려사항 AWS 클라우드시스템에는기존호스팅모델과는다른몇가지주요차이점들이있습니다. 이전의섹션에서는클라우드에서웹애플리케이션을배포할때고려해야할다양한중점들을살펴봤습니다. 이번섹션에서는애플리케이션을클라우드로가져올때고려해야할설계상의주요변화를살펴보겠습니다. 물리적네트워크어플라이언스의제거 AWS 클라우드에서는물리적네트워크어플라이언스를사용할수없습니다. 예를들어여러분이 AWS에올리는애플리케이션에쓸방화벽이나라우터, 로드밸런서등은더이상물리적디바이스의형태를띠지않으며, 그보다는소프트웨어솔루션으로대체될필요가있습니다. 로드밸런싱 (Zeus, HAProxy, nginx, Pound 등 ) 이나 VPN 연결설정 (OpenVPN, OpenSwan, Vyatta 등 ) 등분야에따라다양한종류의엔터프라이즈급소프트웨어솔루션들이존재합니다. 이는 AWS 클라우드상에서실행할수있는것을제한하는것이아니라, 오늘날이런디바이스들을사용한다면애플리케이션설계에변화가있어야한다는것을의미합니다. 어디에나있는방화벽기존호스팅모델에서는간단한 DMZ를구축해호스트들간의오픈커뮤니케이션환경을마련했지만, AWS는모든호스트를차단할수있는보다안전한모델을지향합니다. AWS 상의애플리케이션배포를계획하는단계에서고려해봐야할것중하나는호스트간의트래픽을분석하는것으로, 이로써정확히어떤포트가열려있어야하는지에대한결정을내릴수있습니다. 아키텍처의각호스트별유형에따라 EC2 내보안그룹을생성할수있으며, 간단하게여러계층의보안모델을다양하게생성해아키텍처내의호스트사이에최소한의액세스만가능하도록설정할수도있습니다.

여러데이터센터사용하기 EC2를사용할때가용영역을여러개쓴다면이는데이터센터를여러곳사용하는것으로생각해야합니다. 이들은논리적으로, 그리고물리적으로구분되어있으며고가용성및안정성을확보하기위해위해여러데이터센터에애플리케이션을배포할수있도록해주는사용하기쉬운모델을제공합니다. 한시적인자동증감호스트애플리케이션을 AWS에올릴때고려해봐야할기존웹호스팅모델과 AWS의차이점들은여러가지가있겠지만그중가장중요한것은 EC2 호스트가자동으로증감될가능성이있기때문에그수명이한시적이라는사실입니다. AWS 클라우드에서작동하도록애플리케이션을설계할땐호스트가항상사용가능할것이라고생각하지말아야하며, 실패가발생할시엔 Amazon EBS 볼륨상에있는데이터외의모든로컬데이터가유실된다는것을유념해야합니다. 그리고새로운호스트를추가할때는해당호스트의 IP 주소나가용영역내에서의위치에대해임의로추측해서는안됩니다. 이때문에기존의방식보다유연한구성모델을짜고호스트를부트스트래핑할때도견고한접근방식을취할필요가있지만, 이러한방법들이야말로확장성이높고내결함성을갖춘애플리케이션을설계하고실행하는데반드시필요한요소라고할수있습니다. 결론 클라우드로의웹애플리케이션이전을검토할때고려해봐야할사항들은매우많습니다. 하지만효율적인비용으로여러분의비즈니스와함께성장할수있는높은확장성과내결함성을갖춘인프라를가질수있다는이점은 AWS 클라우드로이전하는과정에서의노고를보상하고도남을것입니다. 참고문헌 시작안내서 - 웹애플리케이션호스팅 : http://docs.amazonwebservices.com/gettingstarted/latest/wah/ 시작안내서 - 리눅스용웹애플리케이션호스팅 : http://docs.amazonwebservices.com/gettingstarted/latest/wah-linux