클라우드설계및구축 : 모범사례 최근업데이트 - 2011 년 1 월 Jinesh Varia jvaria@amazon.com 1/23 페이지
서론 소프트웨어설계자들은최근몇년동안확장성이뛰어난애플리케이션구축을위해여러가지기술개념및모범사례를개발하여구현해왔습니다. " 테라바이트급정보시대 " 를맞이하여, 데이터세트의지속적인증가와예측하기어려운트래픽패턴, 응답시간단축요구등으로인해이러한기술개념의필요성이더욱커지고있습니다. 본백서에서는이러한기존의기술개념가운데일부를재해석, 보완하여, 클라우드컴퓨팅측면에서발전시켜나갈수있는방안들을소개하며아울러, 클라우드가갖추고있는동적인특성으로인해새롭게부상하고있는탄력성과같은새로운개념에대해서도논의하고자합니다. 본백서는엔터프라이즈급애플리케이션을고정적인물리적환경에서가상클라우드환경으로마이그레이션하고자하는클라우드설계자들을대상으로작성되었습니다. 따라서새로운클라우드애플리케이션을개발하거나기존의애플리케이션을클라우드로마이그레이션하고자할때필요한기술개념, 원칙, 모범사례를집중적으로소개하고있습니다. 배경 클라우드설계자로서클라우드컴퓨팅의장점을이해하는것은매우중요합니다. 본절에서는클라우드컴퓨팅의몇가지경영및기술적측면의장점과아울러, 현재이용가능한 AWS 서비스에대해설명합니다. 클라우드컴퓨팅이기업경영에미치는장점 기업이클라우드에애플리케이션을구축할경우누릴수있는혜택은다음과같습니다. 초기인프라투자비용이거의없음 : 대규모시스템을구축해야하는경우부동산구입비, 물리적보안유지비용, 하드웨어 ( 랙, 서버, 라우터, 백업전원공급장치 ) 설치비에하드웨어관리 ( 전원관리, 냉각 ) 와, 운영직원의인건비에이르기까지막대한비용이소요될수있습니다. 높은초기투자비용때문에프로젝트를시작하려면여러차례경영진의승인을얻어야하는것이일반적이었습니다. 하지만이제는공공시설형태의클라우드컴퓨팅덕분에고정비용이나초기투자비가필요하지않습니다. 수요에따른인프라구축 : 과거에는고객기업의애플리케이션수요가증가하는데, 인프라와지원시스템이이수요에부응하지못하는경우, 성공을거둘수없었습니다. 반면, 인프라와시스템에막대한금액을투자하였으나기대만큼수요가발생하지못하는경우에도역시실패를피할수없었습니다. 필요에따라자체설정이가능하도록클라우드내에애플리케이션을구축할경우에는대규모시스템용량을미리구입하여구축할필요가없습니다. 이러한솔루션은성장속도에비례하는확장과사용량에준하는요금지불방식으로탄력성을높이며, 리스크완화및운용비용절감에도기여합니다. 보다효율적인리소스활용 : 일반적으로시스템관리자들은 ( 주어진용량이소진되었을때 ) 하드웨어의추가구매또는 ( 대기용량이과다한상태일때 ) 인프라의이용률향상방안에대해고민합니다. 하지만, 클라우드를적용할경우, 애플리케이션의필요에따라리소스를추가로요청하거나취소하는방법으로보다효과적이고효율적으로리소스를관리할수있습니다. 사용량에따른비용책정 : 공공요금형태의요금방식으로, 사용한인프라에대해서만요금이부과되며, 인프라를할당받았으나사용하지않은경우에는요금을지불하지않습니다. 이를통해새로운차원의비용절감효과를기대할수있습니다. 최적화패치를사용하여기존에보유하고있는클라우드애플리케이션을업데이트할경우즉시 ( 때로는익월결제시 ) 비용절감효과를확인할수있습니다. 예를들어, 캐싱계층에서사용자의데이터요구를 70% 까지줄일수있을경우, 절감효과가즉시발생하여익월결제시바로요금이줄어든것을확인할수있습니다. 더욱이, 플랫폼을클라우드에서구축하는경우이와같이유연하고가변적인사용량기준의요금체제를고객들에게도확대적용할수있습니다. 2/23 페이지
시장출시기간단축 : 병렬화방식으로처리속도를가장크게높일수있습니다. 병렬로실행될수있는컴퓨팅또는데이터중심의작업을컴퓨터한대에서처리할때 500 시간이걸린다면클라우드아키텍처 [6] 를사용할때에는 500 개인스턴스를생성하여작업을수행하므로같은양의작업을단 1 시간내에처리할수있습니다. 탄력적인인프라구축을통해경제적인방법으로병렬화를수행하여애플리케이션출시기간을단축시킬수있습니다. 클라우드컴퓨팅의기술적장점 클라우드컴퓨팅의기술적장점은다음과같습니다. 자동화 " 스크립터블인프라 ": (API 를이용하여 ) 프로그램가능한인프라를활용하여반복가능한구축및배포시스템을만들수있습니다. Auto-scaling: 운용자의개입없이예기치않은수요에맞게애플리케이션규모를늘리거나줄일수있습니다. Auto-scaling 기능을통해자동화를촉진하고효율성을더욱높입니다. 능동적확장및축소 : 고객의트래픽패턴을고려해적절한계획하에예상수요량에맞게애플리케이션규모를늘리거나줄임으로써이에따른비용을낮게유지시켜줍니다. 보다효율적인개발주기 : 생산시스템을개발및테스트환경에사용할수있도록쉽게복제할수있습니다. 단계별환경구성을통해쉽게생산을진행할수있습니다. 시험기능개선 : 테스트용하드웨어를항상충분히지원합니다. 개발과정중각단계별로자동으로시험을실시합니다. 시험이진행되는기간동안에만사전설정한환경으로 " 임시시험실 " 을구축할수있습니다. 재해복구및비즈니스연속성 : 클라우드는저렴한비용으로일정규모의 DR 서버와데이터스토리지를유지할수있는옵션을제공합니다. 클라우드를사용하여지리적분산효과와아울러수분이내에다른지점으로해당환경을복제할수있습니다. 과도한트래픽을클라우드로라우팅 : 단몇번의클릭과효과적인로드밸런싱기법을이용하여, 초과트래픽을클라우드로라우팅하는방법으로애플리케이션의폭주를완벽하게예방할수있습니다. Amazon Web Services 클라우드개요 Amazon Web Services (AWS) 클라우드는높은신뢰성과확장성을갖춘인프라를최소한의지원및관리비용으로웹규모의솔루션구축을위해제공하며, 개별건물또는데이터센터내에설치되어있는고객인프라에비해높은유연성을제공합니다. AWS 는현재다양한인프라서비스를제공합니다. 아래그림에서는 AWS 관련용어및고객애플리케이션과다양한 Amazon Web Services 연결방법및서비스간연계방법등을제시하고있습니다. Amazon Elastic Compute Cloud (Amazon EC2) 1 는클라우드에서컴퓨팅용량을자유자재로변경할수있는컴퓨팅파워를제공하는웹서비스입니다. 사용자가운영체제, 애플리케이션소프트웨어및관련구성설정값을 Amazon 머신이미지 (AMI) 에번들로함께구성할수있습니다. 이러한 AMI 를사용하여다수의가상인스턴스들을제공할수있을뿐아니라용량요구량이변경될때마다간단한웹서비스호출을통해인스턴스를해체하여신속하게용량규모를조정할수도있습니다. 시간단위로인스턴스요금을지불하는온디맨드인스턴스 (On-Demand Instances) 또는저렴한금액을일시불로지불하면온디맨드인스턴스보다도더저렴하게인스턴스를실행할수 1 Amazon EC2 에대한자세한사항은웹사이트 (http://aws.amazon.com/ec2) 를참조하십시오. 3/23 페이지
결제 : Amazon FPS/DevPay Amazon SimpleDB 도메인 Amazon SNS 주제 Amazon SQS 대기열 Amazon Web Services - 클라우드구축 : 모범사례 있는예약인스턴스 (Reserved Instances) 를구입하거나사용하지않는용량에입찰하여비용을더욱더줄일수있는스팟인스턴스 (Spot Instances) 를구입할수있습니다. 인스턴스를한개이상의지역에서시작할수있습니다. 각지역 (region) 에는여러개의가용영역 (Availability Zones) 이있습니다. 이러한가용영역은다른가용영역에장애가발생할경우이장애발생영역에서분리되도록설계된개별지점들이며, 동일지역내에있는다른가용영역들에저렴하고, 지연시간이짧은네트워크연결을제공합니다. 애플리케이션 Auto- Scaling Amazon RDS 유동 LB Amazon Virtual Private Cloud Amazon Elastic MapReduce JobFlows Cloud Watch Amazon EC2 인스턴스 ( 온디맨드, 예약, 스팟 ) EBS 볼륨 Amazon S3 객체및버킷 스냅샷 Amazon Cloud Front Amazon 글로벌물리인프라 ( 지역, 가용영역, 에지 ) 그림 1: Amazon Web Services 엘라스틱 IP 주소할당기능을이용하여고정 IP 주소를인스턴스마다프로그래밍방식으로할당할수있습니다. Amazon CloudWatch 2 를사용하여 Amazon EC2 인스턴스에대한모니터링기능을통해리소스이용률, 운용성능, 전반적인수요패턴 (CPU 사용률, 디스크읽기 / 쓰기, 네트워크트래픽등의메트릭포함 ) 을파악할수있습니다. Auto Scaling 기능 3 을사용하여 Auto Scaling 그룹을만들어 Amazon CloudWatch 가수집하는메트릭에따라특정조건에서용량을자동으로확장할수있습니다. Elastic Load Balancing 4 서비스를사용하여유연한로드밸런서를생성하여인입트래픽을분배할수있습니다. Amazon Elastic Block Storage (EBS) 5 볼륨은네트워크에연결된영구스토리지를 Amazon EC2 인스턴스에제공합니다. EBS 볼륨에대해일관성있는 PIT (Point in Time) 스냅샷을생성하여 Amazon Simple Storage Service (Amazon S3) 6 에저장할수있습니다. 2 Amazon CloudWatch 에대한자세한사항은웹사이트 (http://aws.amazon.com/cloudwatch/) 를참조하십시오. 3 Auto Scaling 기능에대한자세한사항은웹사이트 (http://aws.amazon.com/auto-scaling) 를참조하십시오. 4 Elastic Load Balancing 기능에대한자세한사항은웹사이트 (http://aws.amazon.com/elasticloadbalancing) 를참조하십시오. 5 Elastic Block Store 에대한자세한사항는웹사이트 (http://aws.amazon.com/ebs) 를참조하십시오. 6 Amazon S3 에대한자세한사항은웹사이트 (http://aws.amazon.com/s3) 를참조하십시오. 4/23 페이지
Amazon S3 는지속성이뛰어난분산형데이터저장장치입니다. 간편한웹서비스인터페이스를통해웹에서언제, 어디에서나대량의데이터를표준 HTTP 동사를사용하여버킷 ( 컨테이너 ) 내에객체로저장하거나이를검색할수있습니다. 객체의복사본은 ( 정적및스트리밍콘텐츠 ) 콘텐츠전송을위한웹서비스인 Amazon CloudFront 7 서비스를통해만들어진배포 (distribution) 기능을사용하여전세계 14 개의에지에서배포및캐싱할수있습니다. Amazon SimpleDB 8 는복잡한운용방식없이실시간데이터베이스쿼리기능및구조화된데이터를쉽게쿼리할수있는기능등데이터베이스의핵심기능을제공하는웹서비스입니다. 데이터세트를도메인에구성하여특정도메인에저장된모든데이터를조회할수있습니다. 도메인은속성 - 값쌍으로정의되는항목들의모음입니다. Amazon Relational Database Service 9 (Amazon RDS) 는관계형데이터베이스를클라우드에서설정, 운용, 확장할수있는간단한방법을제공합니다. DB 인스턴스를실행하여다기능 MySQL 데이터베이스에액세스할수있으며백업, 패치관리등의일반적인데이터베이스관리작업들도간단하게수행할수있습니다. Amazon Simple Queue Service (Amazon SQS) 10 는컴퓨터와애플리케이션구성요소간에전송되는메시지를저장하기위한안정적이고확장성이뛰어난호스팅된분산대기열을제공합니다. Amazon Simple Notifications Service (Amazon SNS) 는 11 주제를생성하고발행 - 구독프로토콜을사용하여클라우드에서애플리케이션또는사람에게해당주제에대해알릴수있는간편한방법을제공합니다. Amazon Elastic MapReduce 12 는 Amazon Elastic Compute Cloud (Amazon EC2) 및 Amazon Simple Storage Service(Amazon S3) 에서웹규모의인프라에서실행되는호스팅된 Hadoop 프레임워크를제공하며, 이를통해맞춤형 JobFlows 를생성할수있습니다. JobFlow 는일련의 MapReduce 단계를가리킵니다. Amazon Virtual Private Cloud (Amazon VPC) 13 를이용하면 AWS 에포함된사설클라우드로기업네트워크를확장할수있습니다. Amazon VPC 는 IPSec 터널모드를사용하여고객데이터센터내에있는게이트웨이와 AWS 의게이트웨이를안전하게연결합니다. Amazon Route53 는확장성이뛰어난 DNS 서비스로서, 고객이관리하고자하는모든도메인에 HostedZone 을생성하여 DNS 레코드를관리할수있습니다. AWS Identity and Access Management (IAM) 14 을이용하면하나의보안자격증명으로다수의사용자를생성하며, 고객의 AWS 계정내에서이들사용자각각에대한액세스허가여부를관리할수있습니다. IAM 은기본적으로 AWS 서비스에포함되어있습니다. 어떤서비스 API 도 IAM 을지원하기위해변경되지않았으며, AWS 서비스 API 를이용해구축된기존의애플리케이션및도구들은 IAM 을사용하는경우에도계속기능을유지합니다. AWS 는또한 Amazon 의결제인프라를활용하는다양한지불및요금청구서비스 15 를제공합니다. 7 Amazon CloudFront 에대한자세한사항은웹사이트 (http://aws.amazon.com/cloudfront) 를참조하십시오. 8 Amazon SimpleDB 에대한자세한사항은웹사이트 (http://aws.amazon.com/simpledb) 를참조하십시오. 9 Amazon RDS 에대한자세한사항은웹사이트 (http://aws.amazon.com/rds) 를참조하십시오. 10 Amazon SQS 에대한자세한사항은웹사이트 (http://aws.amazon.com/sqs) 를참조하십시오. 11 Amazon SNS 에대한자세한사항은다음주소에서확인할수있습니다 http://aws.amazon.com/sns 12 Amazon ElasticMapReduce 에대한자세한사항은웹사이트 (http://aws.amazon.com/elasticmapreduce) 를참조하십시오. 13 Amazon Virtual Private Cloud 에대한자세한사항은웹사이트 (http://aws.amazon.com/vpc) 를참조하십시오. 14 Amazon Identity and Access Management 에대한자세한사항은웹사이트 (http://aws.amazon.com/iam) 를참조하십시오. 15 Amazon Flexible Payments Service 에대한자세한사항은웹사이트 (http://aws.amazon.com/fps) 를참조하십시오. Amazon DevPay 에대한사항은웹사이트 (http://aws.amazon.com/devpay) 를참조하십시오. 5/23 페이지
모든 AWS 인프라서비스는장기약정이나계약이필요없는공공서비스요금형태의요금제를지원합니다. 예를들어, Amazon EC2 에서는인스턴스사용요금을시간단위로지불하며, Amazon S3 에서는기가바이트단위로스토리지및데이터전송요금을지불합니다. 이러한서비스및종량제요금에대한자세한사항은 AWS 웹사이트에서확인할수있습니다. AWS 클라우드를사용하는경우에도유연성과아울러다음과같이이미사용자에게익숙한컨트롤기능을그대로유지할수있습니다. 프로그래밍모델, 언어또는운영체제 (Windows, OpenSolaris 또는다양한 Linux 제품 ) 를원하는대로자유롭게사용할수있습니다. 고객의요구에부합하는 AWS 제품을자유롭게선택할수있으며, 어떤서비스든개별적으로또는통합하여사용할수있습니다. AWS 는규모조절이가능한리소스 ( 스토리지, 대역폭및컴퓨팅 ) 을제공하므로, 원하는만큼자유롭게소비할수있으며소비한만큼만지불하면됩니다. 과거에사용한시스템관리도구도자유롭게사용할수있으며, 데이터센터를클라우드로확장할수있습니다. 6/23 페이지
클라우드개념 클라우드는확장성이뛰어난인터넷아키텍처 [13] 를구축하고자하는기존개념을보완강화하는한편, 애플리케이션들의구축및배치방법을전혀새롭게바꾸고자하는새로운개념을도입합니다. 따라서, 개념을실행에옮기는과정에서마치 " 모든것이바뀌었지만, 달라진것이아무것도없다 " 는느낌을받게될것입니다. 클라우드는여러프로세스, 형식, 관행, 철학들을바꾸고, 이미알려진기존의서비스지향형아키텍처 (SOA) 의원칙들가운데일부분들은그어느때보다중요한부분이므로이를더욱더강화하였습니다. 이절에서는이와같이새로운클라우드개념과아울러다시주목을받게된 SOA 개념가운데몇가지를살펴보고자합니다. 기존의애플리케이션들은개발당시의도했던경제성과구조적인측면들을염두에두고구축되었습니다. 클라우드에는고객이반드시이해해야할몇가지새로운철학개념들이도입되었으며, 아래절에서그러한내용을설명하고자합니다. 확장가능한아키텍처구축 확장가능한인프라의혜택을누리기위해서는확장가능한아키텍처를구축하는것이중요합니다. 클라우드는이론상무한확장성이가능하도록설계되었습니다. 하지만, 고객이보유하고있는아키텍처의확장이불가능한경우에는인프라확장혜택을누릴수가없으므로, 이두가지요소가조화를이루어야합니다. 고객의아키텍처에서단일구조의구성요소와아키텍처의병목지점을파악하고, 이아키텍처에서온디맨드설정기능을활용할수없는분야를파악하며, 확장가능한인프라를이용하고클라우드의혜택을누리기위해고객의애플리케이션을리팩토링할수있어야합니다. 진정한의미의확장형애플리케이션이갖는특징은다음과같습니다. 리소스의양을증가시키면성능도이에비례하여증가합니다. 확장형서비스는이질성 (heterogeneity) 문제를해결할수있습니다. 확장형서비스는운용이효율적입니다. 확장형서비스는탄력적입니다. 확장형서비스는서비스가증가할때더비용효율적입니다 ( 단위비용이단위수증가에따라감소함 ). 이와같은특징이고객애플리케이션에내재되어야하며, 위의특성을염두에두고아키텍처를설계할경우아키텍처와인프라가조화를이루어고객이원하는확장성을달성할수있을것입니다. 7/23 페이지
탄력성의이해 아래의그래프에서는클라우드설계자가수요충족을위해애플리케이션의규모를조절하고자할때취할수있는몇가지방법을보여주고있습니다. 수직확장형접근법 : 확장형애플리케이션아키텍처를염두에두지않고수요충족을위해보다더크고, 강력한컴퓨터 ( 수직적확장 ) 에크게투자합니다. 이러한방법은일반적으로어느정도까지는효과가있으나엄청난비용이발생하거나 ( 아래그림의 " 막대한자본금 (huge capital expenditure)" 참조 ) 또는새로 " 거대한설비 " 를구축하기도전에수요가지원용량을초과할수있습니다 ( 아래그림의 " 고객상실부분 (You just lost your customers)" 참조 ). 기존의수평적확장방법 : 수평으로확장가능한아키텍처를만들고소량씩투자합니다. 대부분의기업및대규모웹애플리케이션은이러한방식에따라애플리케이션구성요소를배분하며데이터세트를연합하고서비스중심형디자인을채택합니다. 이러한방법이때로는수직적확장방법보다더효율적입니다. 하지만, 그럼에도불구하고, 정기적으로수요를예측하고이러한수요를충족하기위해소규모단위로인프라를구축해야합니다. 이로인해종종용량초과 (" 현금낭비 ") 나지속적인수동모니터링 (" 인력낭비 ") 이발생하기도합니다. 또한수평적확장방법은애플리케이션에일시적으로과부하 ( ' 슬래시닷효과 ' 라고도함 ) 가발생하는경우에는효과를발휘할수없습니다 16. 참고 : 두방법모두초기설치비용이있으며, 본질적으로반응적특성을가집니다. 인프라비용 USD 용량을너무많이초과했습니다.. 기회 비용 거대거대자본자본지출지출 방금고객을잃었습니다 예상수요 실제수요스케일업접근법기존스케일아웃접근법 자동탄력성 자동탄력성 + 확장성 시간 t 그림 2: 자동탄력성조절 16 http://en.wikipedia.org/wiki/slashdot_effect 8/23 페이지
기존의인프라는일반적으로고객의애플리케이션에서차후수년간사용할컴퓨팅리소스의양을예측해야합니다. 리소스의양을너무작게잡으면애플리케이션에예기치않은트래픽을처리할용량이없어잠재적으로고객불만을초래하게되며, 반대로너무높게잡으면과도한리소스로인해비용이낭비됩니다. 그러나탄력적인온디맨드클라우드 ( 자동탄력조절 ) 를사용하면인프라를실제수요량과거의일치하게조정 ( 확장및축소가능 ) 할수있으며, 이를통해전반적인사용률은높이고비용은줄일수있습니다. 탄력성은클라우드가제공하는기본적인속성중하나입니다. 탄력성은마찰은최소화하면서컴퓨팅리소스규모를쉽게확장하거나축소할수있는기능입니다. 이러한탄력성이야말로궁극적으로클라우드가제공하는장점들중가장중요한부분에해당함을이해하는것이중요합니다. 여러분은클라우드를설계할때, 이러한개념을충분히이해하고, 이를애플리케이션아키텍처내에구현하여클라우드의혜택을극대화해야합니다. 과거에는애플리케이션을고정적이고경직되어있으며, 설정이미리이루어진인프라에구축했습니다. 기업들은매일서버를설정하거나설치할필요가없었으며, 대부분의소프트웨어아키텍처는신속한배포또는하드웨어절감등의문제를고민할필요가없습니다. 새로운리소스를설치하거나새로투자하는데에는많은시간과비용이소모되므로, 소프트웨어설계자들은하드웨어이용률을극대화하기위해시간과리소스를투자하지않습니다. 애플리케이션을구동하는하드웨어의활용도가최대용량에못미치는경우에도이를불가피한것으로간주했습니다. 수분이내에새로운리소스를구한다는생각자체가불가능했으므로, 아키텍처내에서 " 탄력성 " 이라는개념이간과되었던것입니다. 클라우드에서는이러한사고방식을바꿔야합니다. 클라우드컴퓨팅에서는필요한리소스확보과정을합리화하여, 더이상사용하지않는하드웨어를미리주문하여보관할필요가없습니다. 대신클라우드설계자들은클라우드가제공하는광대한규모와빠른응답시간을활용하여필요한리소스를몇분내로주문하거나심지어구매과정을자동화할수있습니다. 사용하지않았거나또는사용하고남은리소스를반납하는데에도동일한효과가적용될수있습니다. 고객의애플리케이션아키텍처에서이러한변화를수용하지못하고탄력성을발휘하지못한다면클라우드의장점을충분히활용하지못할수도있습니다. 클라우드설계자라면창의적으로사고하며, 자신의애플리케이션내에탄력성을부여하는방법에대해서도연구해야합니다. 예를들어, 매일밤야간구축 (build) 작업을수행하고새벽 2 시부터 2 시간동안리그레션시험및단위시험을수행 ( 종종 "QA/ 빌드박스 " 라함 ) 하며나머지시간은유휴상태인인프라가있다고가정할때, 탄력적인인프라를이용하면, " 살아있는 (alive)" 박스에서심야구축작업을실시하고, 심야 2 시간작업분에대해서만비용을지불하면됩니다. 마찬가지로, 하루동안의수요량을충족하기위해항상최대용량 (5 개서버, 연중무휴상시작동 ) 으로실행되던내부장애티켓발행용웹애플리케이션을트래픽패턴에따라온디맨드로 ( 오전 9 시부터오후 5 시까지서버 5 개, 오후 5 시에서오전 9 시까지서버 2 개 ) 로운용하도록선택할수있습니다. 탄력적인지능형클라우드아키텍처를설계하여인프라를필요할때에만사용하는것자체가놀라운기술입니다. 탄력성이란구조적인설계요건또는시스템속성중하나여야합니다. 그렇다면, 내애플리케이션아키텍처의어떤구성요소또는계층에탄력성을부여할수있을까? 구성요소를탄력적적으로구성하는데시간은얼마나걸리나? 전체시스템아키텍처에탄력성을구현할경우어떠한효과를기대할수있을까? 와같은질문들을스스로에게던져볼수있을것입니다. 다음절에서는고객애플리케이션에탄력성을구현하는데필요한몇가지특별한기법을소개하고자합니다. 클라우드의장점을효과적으로발휘하려면이러한기법을반드시고려할필요가있습니다. 9/23 페이지
제약사항들에구애받지않음클라우드로애플리케이션을이동시켜클라우드에서이용가능한시스템에고객시스템사양을매핑할때클라우드가고객이보유하고있는리소스의규격과정확하게일치하지않을수있음을염두에두어야합니다. 예를들어, " 클라우드가서버에서원하는만큼의 RAM 용량을제공하지않는다 " 거나 " 내데이터베이스가인스턴스한개에서얻을수있는것보다더많은 IOPS 를필요로하는 " 경우가있을수있습니다. 클라우드가가상리소스를제공하며, 온디맨드설정모델과결합해야만이리소스가영향력을발휘한다는사실을이해해야합니다. 클라우드환경에서고객의하드웨어사양과동일한사양을구하지는못하더라도, 이보다더많은리소스를클라우드에서활용할수있으므로, 클라우드리소스를사용할때우려하거나제약을느낄필요가없습니다. 예를들어, 클라우드의서버에서원하는 RAM 용량이상을제공하지못할경우, 맴캐시드 (memcached) 와같은분산형캐시를사용하거나 17 여러대의서버로데이터를분할할수있습니다. 데이터베이스가더많은 IOPS 를필요로하거나, 클라우드에직접매핑하지않을경우, 고객의데이터유형과사용방법에따라몇가지방법을선택할수있습니다. 읽기중심의애플리케이션인경우, 동기화된슬레이브들에읽기부하를분산할수있습니다. 또는샤딩 (sharding) [10] 알고리즘을사용하여필요할때데이터를라우팅하거나다양한데이터베이스클러스터링솔루션을사용할수도있습니다. 요컨대, 유연성과온디맨드설정기능을결합시킬경우실질적으로제약조건이해소되어궁극적으로시스템의확장성및전체성능을개선할수있다는사실을깨닫게될것입니다. 가상관리클라우드의출현으로시스템관리자의역할이 " 가상시스템관리자 " 로바뀌었습니다. 이는가상시스템관리자가애플리케이션에대해보다상세하게이해하고, 업무차원에서최선의방법을선택할수있게됨에따라이들이수행하는일상적인작업이더욱큰의미를가지게되었음을의미합니다. 시스템관리자는더이상서버를설정하고, 소프트웨어를설치하며, 네트워크장치를연결할필요가없습니다. 이러한모든번거로운작업이이제는단몇번의클릭과명령실행으로해결되기때문입니다. 클라우드에서는이러한인프라를프로그래밍하여자동화할수있습니다. 시스템관리자는기술력을한단계높여, 스크립트를사용하여가상클라우드리소스를관리하는방법을익혀야합니다. 마찬가지로, 데이터베이스관리자의역할이 " 가상데이터베이스관리자 " 로바뀌었습니다. 이들은웹기반콘솔을통해리소스를관리하고, 데이터베이스하드웨어의용량이초과될경우스크립트를실행해새로운용량을프로그래밍방식으로추가하고일일프로세스를자동화합니다. 가상데이터베이스관리자 (DBA) 는이제새로운배포방법 ( 가상머신이미지 ) 을익히고, 새로운모델 ( 쿼리병렬화, 지리적중복성, 비동기복제 [11]) 를수용하고, 데이터에대한구조적접근법 ( 샤딩 [9], 수평적분할 [13], 페더레이션 [14]) 을수정하고, 다양한유형의데이터세트별로클라우드에서이용가능한여러가지스토리지옵션을활용할수있어야합니다. 기존의기업에서는애플리케이션개발자가네트워크관리자와긴밀하게협력하지않으며, 네트워크관리자는애플리케이션에대해전혀이해하지못하는경우가있었으며, 그로인해네트워크계층과애플리케이션아키텍처계층에가능한최적화기능이제대로이루어지지못하고있었습니다. 그러나클라우드를사용할경우위의두역할을어느정도하나로통합할수있습니다. 기업은미래의애플리케이션설계시, 두역할간에정보가활발히공유되도록하고두역할의통합을고려해야합니다. 17 http://www.danga.com/memcached/ 10/23 페이지
모범적인클라우드구현사례 본절에서는클라우드에서애플리케이션을구축할때도움이될수있는구현사례를소개하겠습니다. 장애복구형설계와장애에대비하지않는설계 경험법칙 : 클라우드에서아키텍처를설계할때는비관주의자가되어야합니다. 즉, 모든일에항상실패가따를것을전제로해야합니다. 따라서, 장애를자동으로복구할수있도록아키텍처를설계, 구축, 구현해야합니다. 특히언젠가는하드웨어에장애또는고장이발생할수있으며, 중단이발생한다고가정합니다. 애플리케이션에재해가발생할수도있고, 예상보다훨씬더많은초당요청수로인해피해를입을수도있음을전제해야합니다. 시간이지남에따라애플리케이션소프트웨어에도결국장애가발생한다고믿어야합니다. 비관론자가되어설계할때장애복구전략을수립하여전반적으로더나은시스템을설계할수있는것입니다. 시간이지날수록장애가발생한다는점을인식하고, 이러한사고를아키텍처에반영하여, 재해가발생하기전에이러한장애를처리할메커니즘을구축해인프라확장에대비함으로써, 클라우드에최적화된내결함성 (fault-tolerant) 아키텍처를만들수있습니다. 시스템노드하나에장애가발생하면어떤일이발생할것이며, 이러한장애를감지하는방법은무엇인지? 또, 이노드는어떻게교체하며, 이를위해어떠한시나리오를마련해야하는지? 장애발생시전체시스템을다운시킬수있는지점 (single point of failure) 은어디인지? 또, 애플리케이션서버열앞에로드밸런서가있는데, 이장치가고장나면어떻게해야하는지?, 아키텍처내에마스터와슬래이브노드가있는데, 이가운데마스터가장애를일으킨다면, 장애조치가어떻게이루어질수있는지? 슬래이브장치를어떻게새로투입하며, 마스터와어떤방식으로동기화를유지할것인지? 등등의질문을스스로에게던져보아야합니다. 하드웨어장애에대비해야하는것과마찬가지로설계시소프트웨어장애에도대비해야합니다. 관련서비스에서인터페이스가변경되면고객이보유하고있는애플리케이션에는어떤일이발생할것인지? 다운스트림서비스가타임아웃되어예외값을리턴할경우는어떻게해야하는지, 캐시키가인스턴스의메모리용량을초과하여계속증가하는경우는어떻게해야하는지? 등등의질문도스스로에게해보아야합니다. 이와같은장애를처리할수있는메커니즘을구축해야합니다. 예를들어, 다음과같은전략이도움을줄수있습니다. 1. 데이터에대해일관성있는백업및복구전략을수립하여이를자동화합니다. 2. 재부팅시복구할수있는프로세스스레드를구축합니다. 3. 대기열에서메시지를재로딩하여시스템상태를다시동기화합니다. 4. 사전구성및최적화를거친가상이미지를저장하여시작 / 부팅시 (2) 와 (3) 을지원하도록합니다. 5. 메모리내에세션또는상태저장 (stateful) 사용자컨텍스트를유지하지말고, 이들을데이터스토리지로이동합니다. 우수한클라우드아키텍처라면재부팅및재시작시손상되지않아야합니다. GrepTheWeb ( 클라우드아키텍처관련자료 [6] 참조 ) 에서는 Amazon SQS 와 Amazon SimpleDB 를함께사용함으로써전체컨트롤러아키텍처가본절에제시된장애유형에대해뛰어난회복력을보입니다. 예를들어, 컨트롤러스레드를실행중인인스턴스가종료되는경우, 다시불러와아무일도없었던것처럼이전상태로다시시작할수있습니다. 이를위해서는사전구성된 Amazon 머신이미지를생성해야합니다. Amazon 머신이미지가실행되면 Amazon SQS 대기열에있는모든메시지를제거합니다. 메시지상태는재부팅시 Amazon SimpleDB 도메인에서읽을수있습니다. 11/23 페이지
기본하드웨어에장애가발생할수있음을전제로한설계방식을통해실제로장애가발생할수있는미래의상황에대비할수있습니다. 이러한설계원칙은 Hamilton 의백서 [11] 에도중점적으로설명되어있는바와같이운용하기편리한애플리케이션들을설계하는데도움이됩니다. 이러한원칙을부하를능동적으로측정하여동적으로균형을맞추는데까지확대하여적용할경우, 한개의요소에서여러요구들을만족시켜야하는클라우드의특성 (multi-tenant nature) 으로인해발생하는네트워크및디스크성능변화를해결할수있을것입니다. 이상에서제시한모범적인방안들을적용하기위한 AWS 만의전략 : 1. 엘라스틱 IP 를사용한점진적인장애조치 : 엘라스틱 IP 는동적으로재매핑할수있는고정 IP 입니다. 신속하게재매핑하고다른서버집합으로장애조치하여트래픽을새서버로라우팅할수있습니다. 이방법은하드웨어를새버전으로업그레이드하거나하드웨어장애발생시효과적입니다. 2. 여러개의가용영역 (Availability Zones) 활용 : 가용영역의개념은논리데이터센터와유사합니다. 고객아키텍처를여러개의가용영역에구축하여가용도를높일수있습니다. Amazon RDS 다중 AZ[21] 배포기능을활용하여데이터베이스업데이트를자동으로여러가용구역에복제합니다. 3. Amazon 머신이미지를보유하여다른가용영역에매우손쉽게환경을저장하거나복제할수있습니다. 즉, 여러가용영역에여러개의데이터베이스슬레이브들을유지하며, 복제물을바로설정할수있습니다. 4. Amazon CloudWatch( 또는다양한실시간오픈소스모니터링도구 ) 를활용하여하드웨어고장또는성능저하발생시감시능력을높여적절한조치를취할수있습니다. Auto Scaling 그룹을설정하여인스턴스규모를일정하게유지함으로써이상이있는 Amazon EC2 인스턴스를새것으로교체합니다. 5. Amazon EBS 를활용하여 cron 작업을설정하면점진적으로더많은스냅샷이자동으로 Amazon S3 에업로드되고데이터는인스턴스와독립적으로유지됩니다. 6. Amazon RDS 를활용하여백업보존기간을설정하면 Amazon RDS 가자동백업을수행합니다. 고객구성요소들의해체 클라우드는시스템구성요소들을더느슨하게결합할수록, 이들요소의확장성이더향상된다는 SOA 설계원칙을재확인시켜줍니다. 이개념의핵심은상호연관성이높지않은구성요소들을구축하여만약구성요소중하나가다운되거나 ( 고장나거나 ), 수면상태이거나 ( 응답없음 ) 또는연결중 ( 응답느림 ) 일때, 시스템내다른요소들은장애가발생되지않은것처럼동작을유지할수있도록하는데있습니다. 본질적으로결합이느슨하면애플리케이션의다양한계층과구성요소들을상호격리하여각구성요소가서로비동기적으로동작하며, 상대요소들을 " 블랙박스 " 로취급합니다. 예를들어, 웹애플리케이션아키텍처에서는앱서버를웹서버및데이터베이스에서격리시킬수있습니다. 이앱서버와웹서버가서로에대해인식하지못하므로, 이들계층간결합이해체되며, 코드및기능면에서연관성이사라집니다. 일괄처리형 (batch-processing) 아키텍처에서는상호독립적인비동기구성요소들을만들수있습니다. 그렇다면, 기존의단면적인애플리케이션에서어떤비즈니스요소또는기능을격리하여단독으로실행할수있는지? 기존시스템을파괴하지않고이요소에인스턴스를추가하여더많은사용자들을지원할수있는방법은? 이요소를캡슐화하여다른요소들과비동기로상호작용할수있도록하는데는어떠한노력이필요한지? 와같은질문들을할필요가있습니다. 12/23 페이지
구성요소들의결합을해체하여비동기시스템을구축하고, 수평적으로확장하는것은클라우드의개념과관련하여매우중요합니다. 이를통해동일요소에인스턴스들을추가할수있을뿐아니라혁신적인하이브리드모델을설계하여일부요소들은사내에서실행하고다른요소들은클라우드규모를활용하여컴퓨팅능력과대역을추가로이용할수있게할수있습니다. 이러한방식으로, 별다른수고없이도스마트한로드밸런싱기술을구사하여과도한트래픽을클라우드로전환할수있습니다. 메시징대기열을사용하여결합이느슨한시스템을구축할수있습니다. 두개의구성요소를연결하는데대기열 / 버퍼를사용할경우동시성, 고가용성및부하스파이크를지원할수있습니다. 그결과구성요소중일부를일시적으로사용할수없게되더라도전체시스템은계속작동합니다. 하나의구성요소가다운되거나일시적으로사용할수없게되면시스템은메시지를버퍼링한뒤구성요소가복구되면처리하도록합니다. B 에게 Method 요청 C 에게 Method 요청 컨트롤러 A 컨트롤러 B 컨트롤러 C 단단한결합 ( 절차식프로그래밍 ) 대기열 A 대기열 B 대기열 C 컨트롤러 A 컨트롤러 B 컨트롤러 C 느슨한결합 ( 대기열을사용한독립형단계 ) 그림 3: 대기열을사용한구성요소결합해체 클라우드아키텍처백서 [6] 에는 GrepTheWeb 아키텍처에서대기열의활발한사용예를보여주고있습니다. GrepTheWeb 에서수많은요청들이갑자기서버에도달하거나 ( 인터넷으로인한과부하상황 ) 일상적인표현들의처리에평균 ( 구성요소의느린응답속도 ) 이상의시간이걸리면 Amazon SQS 대기열이요청을지속적으로버퍼링하여이러한지연이다른구성요소에영향을주지않도록합니다. 이와같은모범사례를구현하기위한 AWS 만의전략은다음과같습니다. 1. Amazon SQS 를사용하여구성요소들을격리합니다.[18] 2. Amazon SQS 를구성요소간버퍼로사용합니다.[18] 3. 모든구성요소에서서비스인터페이스를공개하고해당범위내에서자체확장을책임지며, 다른구성요소와비동기적으로상호작용하도록설계합니다. 4. 구성요소의논리구조를 Amazon 머신이미지와번들로결합시켜보다자주구현할수있도록합니다. 5. 애플리케이션을가능한한상태비저장 (stateless) 으로만듭니다. 세션상태를구성요소외부에저장합니다 ( 가능한경우 Amazon SimpleDB 에저장 ). 13/23 페이지
탄력성구현 클라우드는애플리케이션에탄력성이라는새로운개념을도입했는데, 이러한탄력성은다음의세가지방법으로구현할수있습니다. 1. 능동적주기적확장 : 일정한간격 ( 매일, 주간, 월간, 분기별 ) 으로이루어지는정기적인확장 2. 이벤트에따른능동적확장 : 예정된비즈니스이벤트 ( 신상품출시, 영업활동등 ) 로인한트래픽급증전망에따른확장 3. 필요에따른자동확장 : 모니터링시스템을사용하여적절한조치를취하는데필요한트리거를전송하여메트릭 ( 인스턴스의서버또는네트워크 I/O 사용량 ) 에따라규모를늘리거나줄일수있습니다. " 탄력성 " 을적용하기위해서는우선배포과정을자동화하고구성및구축과정을간소화해야합니다. 그럼으로써, 인력개입없이도시스템에서자동으로규모를늘리거나줄일수있습니다. 이용률이낮은유휴상태의서버보다는수요에맞추어리소스를할당함으로써전반적인이용률을높여즉각적인비용효율을높일수있습니다. 인프라자동화 클라우드환경을이용할때가장중요한장점은클라우드의 API 를사용하여리소스배포과정을자동화할수있다는것입니다. 마이그레이션과정이완료될때까지기다리기보다는초기에자동배포프로세스를마련하는것이바람직합니다. 자동화되고반복가능한배포과정을만들어오류를줄이고효율적이고확장가능한업데이트과정을촉진할수있습니다. 배포프로세스를자동화하려면 작고자주사용하는설치및구성용스크립트에대해 " 레시피 " 라이브러리를만듭니다. AMI 내에함께제공되는에이전트를사용하여구성및배포과정을관리합니다. 인스턴스를부트스트래핑합니다. 인스턴스를부트스트래핑하는방법 부팅시인스턴스가이름과역할에대해질문을하도록합니다. 모든인스턴스에주어진환경에서수행해야할역할을배분합니다 ( 웹애플리케이션의경우 "DB 서버 ", " 앱서버 ", " 슬레이브서버 " 등 ). 이역할은인스턴스시작시인수 (argument) 형태로전달되어, 부팅후취해야하는단계들을인스턴스화 (instantiate) 해야할때를 AMI 에게알립니다. 부팅시, 인스턴스는해당역할에따라필요한리소스 ( 코드, 스크립트, 구성 ) 를확보하여, 자신을클러스터에 " 연결 " 하여기능을수행합니다인스턴스부트스트래핑의장점은다음과같습니다. 1. 단몇번의클릭과최소한의노력만으로 ( 개발, 준비, 생산 ) 환경을다시만들수있습니다. 2. 가상클라우드기반리소스에대한통제력을높여줍니다. 3. 사람이실수로인한배포또는배치상의실수를줄일수있습니다. 4. 하드웨어고장시회복력이더뛰어난자기치유및자기검색가능환경을만들수있습니다. 14/23 페이지
고객의인프라를자동화하기위한 AWS 만의기법 1. Amazon EC2 의 Auto Scaling 기능을사용하여서로다른클러스터에대해 Auto Scaling 그룹을지정합니다. 2. 시스템메트릭 (CPU, 메모리, 디스크 I/O, 네트워크 I/O) 을 Amazon Cloudwatch 를사용하여모니터링하고, 적절한조치 (Auto Scaling 서비스를사용하여새로운 AMI 를동적으로시작 ) 를취하거나통지합니다. 3. 컴퓨터구성정보를동적으로저장및검색합니다. 즉, Amazon SimplDB 를사용하여인스턴스가부팅되는동안구성데이터를가져옵니다 ( 예 : 데이터베이스연결문자열 ). SimpleDB 는또한 IP 주소, 컴퓨터이름및역할등인스턴스에대한정보를저장하는데사용할수도있습니다. 4. 구축프로세스를설계하여 Amazon S3 의버킷에최신구축물 (builds) 을덤핑하고, 시스템시작중에애플리케이션의최신버전을다운로드합니다. 5. 리소스관리도구 ( 자동화스크립트, 사전구성된이미지 ) 를구축하는데투자하거나, Chef 18, Puppet 19, CFEngine 20 또는 Genome 21 과같은오픈소스구성관리도구를사용합니다. 6. Just Enough Operating System (JeOS 22 ) 과고객의소프트웨어종속요소를 Amazon 머신이미지에번들시키기때문에유지관리가용이합니다. 시작시구성파일또는매개변수 (parameter) 를전달하고시작후에는사용자데이터 23 와인스턴스메타데이터를검색합니다. 7. Amazon EBS 볼륨으로부팅하고 24 여러 Amazon EBS 볼륨들을인스턴스하나에연결함으로써번들처리및시작시간을줄입니다. 가능한경우언제든지공용볼륨의스냅샷을생성하고스냅샷 25 을공유합니다. 8. 애플리케이션구성요소는실행중인하드웨어의상태나위치에구애받지않아야합니다. 예를들어, 새노드의 IP 주소를클러스터에동적으로할당합니다. 장애시자동으로장애조치하여새로운복제노드를시작시킵니다. 병렬화에관하여클라우드를이용하면손쉽게병렬화를구현할수있습니다. 클라우드에서데이터를요청할때, 데이터를클라우드에저장할때, 클라우드에서데이터를처리 ( 또는작업실행 ) 할때등클라우드설계자는클라우드에아키텍처를설계할때병렬화의개념을이해해야합니다. 클라우드를이용하면반복가능한과정을매번쉽게처리할수있으므로, 가능한경우병렬화를구현하고자동화하는것이좋습니다. 클라우드는대량의데이터액세스 ( 검색및저장 ) 작업을병렬로처리할수있도록설계되었습니다. 최대성능및처리량을얻으려면요청병렬화 (request parallelization) 방법을사용해야합니다. 다수의동시스레드를사용하여요청을다중스레딩하면데이터를순차적으로요청할때보다더빠르게데이터를저장하거나가져올수있습니다. 따라서가능한경우클라우드애플리케이션의프로세스에서무공유원칙과다중스레드를통해스레드를안전하게관리할수있어야합니다. 18 Chef 에대한자세한사항은웹사이트 (http://wiki.opscode.com/display/chef/home) 를참조하십시오. 19 Puppet 에대한자세한사항은웹사이트 (http://reductivelabs.com/trac/puppet/) 를참조하십시오. 20 CFEngine 에대한자세한사항은웹사이트 (http://www.cfengine.org/) 를참조하십시오. 21 Genome 에대한자세한사항은웹사이트 (http://genome.et.redhat.com/) 를참조하십시오. 22 http://en.wikipedia.org/wiki/just_enough_operating_system 23 인스턴스메타데이터와사용자데이터사항은웹사이트 (http://docs.amazonwebservices.com/awsec2/latest/developerguide/index.html?aesdg-chapter-instancedata.html) 를참조하십시오. 24 Amazon EBS 로부팅기능에대한자세한사항은웹사이트 (http://developer.amazonwebservices.com/connect/entry.jspa?externalid=3121) 를참조하십시오. 25 스냅샷공유방법은웹사이트 (http://aws.amazon.com/ebs/) 를참조하십시오. 15/23 페이지
병렬화는클라우드에서요청을처리하거나실행할때훨씬더중요합니다. 웹애플리케이션에서가장좋은방법은로드밸런서를사용하여여러개의비동기웹서버로진입하는요청들을분산하는것입니다. 일괄처리애플리케이션에서는마스터노드를사용하여병렬로작업을처리하도록여러개의슬레이브작업노드를생성할수도있습니다 (Hadoop 과같은분산처리프레임워크와유사함 26 ). 탄력성과병렬화를조합하면클라우드의우수성이빛을발하게됩니다. 고객의클라우드애플리케이션은수분이내에단지몇개의 API 호출만으로설정된컴퓨팅인스턴스로클러스터를만들어병렬로작업을수행하고, 그결과를저장한다음모든인스턴스를종료합니다. [6] 에서설명한 GrepTheWeb 애플리케이션이이러한애플리케이션의한예입니다. AWS 만의병렬화전략 : 1. 모범사례백서 [2] 에자세하게설명한바와같이 Amazon S3 요청들을멀티스레딩합니다. 2. Amazon SimpleDB GET 및 BATCHPUT 요청 [3][4] [5] 을멀티스레딩합니다. 3. Amazon Elastic MapReduce Service 를사용하여각일일일괄처리프로세스 ( 인덱싱, 로그분석등 ) 에대한 JobFlow 를생성하면작업을병렬로처리하여시간이절약됩니다. 4. Elastic Load Balancing 서비스를사용하여부하를동적으로여러웹앱서버에분산합니다. 동적데이터는컴퓨팅에더가깝게, 정적데이터는최종사용자에더가깝게 일반적으로데이터를가능한한컴퓨팅또는처리요소에가깝게유지하여지연시간을줄이는것이바람직합니다. 클라우드에서는인터넷의지연처리문제를해결해야하기때문에이러한원칙이더욱의미가있고중요합니다. 더욱이클라우드에서는데이터전송량 (GB) 에따라클라우드안팎의대역폭사용료를지불해야하는데요금이매우빨리증가할수있습니다. 처리해야할대량의데이터가클라우드외부에존재할경우, 데이터를우선클라우드로 " 전송 " 한다음컴퓨팅을수행하는것이비용도저렴하고속도도빠릅니다. 예를들어, 데이터보관애플리케이션의경우데이터세트를클라우드로이동한다음데이터세트에대한병렬조회를수행하는것이좋습니다. 관계형데이터베이스로부터데이터를저장하고검색하는웹애플리케이션의경우, 앱서버와데이터베이스를한번에클라우드로이동하는것이좋습니다. 데이터가클라우드에서생성되는경우, 이데이터를소비하는애플리케이션역시클라우드내에구현되어클라우드내무료데이터전송및지연단축의장점을활용할수있습니다. 예를들어, 로그와클릭스트림데이터를생성하는전자상거래웹애플리케이션의경우, 클라우드에서로그분석기와보고엔진을실행하는것이좋습니다. 반대로, 데이터가정적이며자주변경하지않을경우 ( 예를들어, 이미지, 비디오, 오디오, PDF, JS, CSS 파일 ), 최종사용자 ( 요청자 ) 에더가까운에지에서정적데이터를캐싱하여액세스지연시간을줄일수있도록콘텐츠전송서비스를이용하는것이좋습니다. 콘텐츠전송서비스를이용하면캐싱덕분에자주요청되는객체에더빨리액세스할수있습니다. 26 http://hadoop.apache.org/ 16/23 페이지
이모범사례를구현하기위한 AWS 만의전략 : 1. 데이터드라이브를 Import/Export 서비스 27 를사용하여 Amazon 에장착합니다. 인터넷을통해업로드하는것보다 sneakernet 28 을통해대량의데이터를이동하는것이비용도저렴하고속도도빠릅니다. 2. 동일한가용영역에서여러장치들을시작합니다. 3. Amazon S3 버킷의배분을시작하여 Amazon CloudFront 이전세계 14 개에지에서해당버킷의콘텐츠를캐싱할수있도록합니다. 보안관련모범사례 멀티테넌트환경인경우클라우드설계자가보안에대해염려하는경우가있습니다. 보안은클라우드애플리케이션아키텍처의모든계층에구현되어야합니다. 물리적보안은일반적으로서비스공급자가제공하게되는데 ( 보안백서 [7]), 이러한특성이클라우드사용과관련하여부수적으로얻을수있는장점입니다. 네트워크및애플리케이션수준의보안은고객의책임사항이며, 고객의비즈니스에부합하는모범사례로구현해야합니다. 본절에서는 AWS 환경에서클라우드애플리케이션을안전하게보호하는데필요한몇가지구체적인도구, 기능및지침들에대해알아봅니다. 여기서언급하는이러한도구와기능을사용하여기본적인보안을구현하고난뒤적절하거나적합하다고생각되는표준방법을사용하여추가적인보안기법을구현하는것이좋습니다. 전송중데이터보호 브라우저와웹서버간에민감한기밀인정보를교환해야할때, 고객서버인스턴스에 SSL 을구성합니다. VeriSign 29 또는 Entrust 30 와같은외부인증기관이발행하는인증서도필요합니다. 인증서에포함된공개키가브라우저에대해서버를인증하고양방향에서데이터를암호화하는데사용되는공유세션키를만드는기반역할을합니다. 몇가지명령문호출 (Amazon VPC 사용 ) 을통해 Virtual Private Cloud 를하나생성할수있습니다. 이렇게하면 AWS 클라우드내에논리적으로격리된리소스를사용할수있으며, 이러한리소스를업계표준인암호화된 IPSec VPN 연결을통해데이터센터에직접연결할수있습니다. 또한 Amazon EC2 인스턴스에 [15] OpenVPN 서버를설정하고모든사용자 PC 에 OpenVPN 클라이언트를설치할수도있습니다. 보관중인데이터보호 민감한기밀데이터를클라우드에저장할때보안이염려된다면데이터 ( 개별파일 ) 를암호화한후에클라우드에업로드하면됩니다. 예를들어, Amazon S3 객체로저장하기전에오픈소스또는 31 상용 32 PGP 기반도구를사용하여데이터를암호화하고, 다운로드한후에복호화합니다. 이것은 PHI (Protected Health Information) 를저장해야하는 HIPPA 호환애플리케이션 [8] 을구축할때좋은방법입니다. 27 Amazon Import Export Services 에대한자세한사항은웹사이트 (http://aws.amazon.com/importexport) 를참조하십시오. 28 http://en.wikipedia.org/wiki/sneakernet 29 http://www.verisign.com/ssl/ 30 http://www.entrust.net/ssl-products.htm 31 http://www.gnupg.org 32 http://www.pgp.com/ 17/23 페이지
Amazon EC2 에서는파일암호화가운영체제에따라달라집니다. Windows 를구동하는 Amazon EC2 인스턴스는내장형 EFS (Encrypting File System) 기능을사용할수있습니다 [16]. 이기능은파일과폴더의암호화및복호화를자동으로처리하며, 사용자가처리과정을투명하게볼수있게합니다 [19]. 그러나그이름과달리 EFS 는전체파일시스템을암호화하지않고, 대신개별파일을암호화합니다. 전체암호화된볼륨이필요하면오픈소스 TrueCrypt 33 제품을사용하는것이좋습니다. 이제품은 NTFS 형식의 EBS 볼륨과잘호환됩니다. Linux 구동 Amazon EC2 인스턴스는다양한방법 (EncFS 34, Loop-AES 35, dm-crypt 36, TrueCrypt 37 ) 으로암호화된파일시스템을사용하여 EBS 볼륨을마운트할수있습니다. 마찬가지로 OpenSolaris 를구동하는 Amazon EC2 인스턴스는 ZFS 38 Encryption Support[20] 를사용합니다. 어떤방법을사용하든 Amazon EC2 에서파일및볼륨을암호화하면파일과로그데이터가보호되기때문에서버내에있는사용자와프로세스는데이터를분명한텍스트형태로볼수있지만, 서버밖에서는데이터가암호화된형태로보입니다. 어떤운영체제또는기술을선택하든지보관중인데이터를암호화하는경우에는데이터암호화에사용되는키를관리해야하는문제에직면하게됩니다. 키를잃어버리면데이터를영원히잃게되고, 키가손상되면데이터가위험에노출될수있습니다. 따라서사용하는제품의키관리기능을숙지하여키를잃어버릴위험성을최소화하도록필요한절차를마련해야합니다. 데이터를도청으로부터보호하는것뿐만아니라재해에서보호하는방법도고려해야합니다. 정기적으로 Amazon EBS 볼륨의스냅샷을만들어높은지속성과가용성을유지해야합니다. 스냅샷은특성상숫자가증가되어 Amazon S3( 별도의지리적위치 ) 에보관되며, 단몇번의클릭이나명령만으로다시복구가능합니다. 고객의 AWS 자격증명보호 AWS 는 AWS 액세스키와 X.509 인증서등 2 가지종류의자격증명을제공합니다. AWS 액세스키는액세스키 ID 와보안액세스키의두부분으로구성됩니다. REST 또는 Query API 를사용할때고객의비밀액세스키를사용하여인증요청에포함시킬서명값을계산해야합니다. ' 전송중도청 ' 을방지하려면모든요청을 HTTPS 를통해전송해야합니다. Amazon 머신이미지 (AMI) 가다른 AWS 웹서비스와통신하기위해 (Amazon SQS 대기열폴링또는 Amazon S3 에서객체읽기등 ) 프로세스를실행할경우, 범하기쉬운한가지설계상실수는 AWS 자격증명을 AMI 에포함시키는것입니다. 자격증명을 AMI 에포함시키는대신시작시인수형태 (arguments) 로전달하고유선으로 [17] 전송하기전에먼저암호화해야합니다. 보안액세스키가손상되면신규액세스키 ID 로교체 39 하여새키를받아야합니다. 가장권하고싶은방법은고객의애플리케이션아키텍처에키교체방식을통합하여정기적으로또는필요에따라 ( 불만을품은직원이퇴사하는경우 ) 이를사용함으로써손상된키를계속사용하지않도록하는것입니다. 또는특정 AWS 서비스에대한인증을위해 X.509 인증서를사용할수도있습니다. 이인증서파일에는 base64 로암호화된 DER 인증서본문에공개키가포함되어있습니다. 별도의파일에는상응하는 base64 로암호화된 PKCS#8 개인키가포함되어있습니다. 33 http://www.truecrypt.org/ 34 http://www.arg0.net/encfs 35 http://loop-aes.sourceforge.net/loop-aes.readme 36 http://www.saout.de/misc/dm-crypt/ 37 http://www.truecrypt.org/ 38 http://www.opensolaris.org/os/community/zfs/ 39 http://aws.amazon.com/about-aws/whats-new/2009/08/31/seamlessly-rotate-your-access-credentials/ 18/23 페이지
AWS 는다중요소인증을지원하는데, 40 이는 aws.amazon.com 및 AWS Management Console 에있는계정정보를이용하여작업할때추가적인보호기능역할을합니다 41. IAM 을이용한다수사용자및사용자권한관리 AWS Identity and Access Management (IAM) 42 를이용하면본인의 AWS 계정을이용하여여러사용자를생성하고, 각사용자의권한을관리할수있습니다. 사용자란 AWS 서비스액세스시사용되는고유한보안자격증명을포함하는일종의아이덴티티 ( 고객 AWS 계정에포함 ) 를의미합니다. IAM 을이용하면암호나액세스키를공유할필요가없어져적절한방법으로각사용자의액세스를손쉽게허용하거나거부할수있습니다. IAM 을사용하면모범적인보안사례를구현할수있습니다. 예를들어, 고객의 AWS 계정내에있는모든사용자에게고유의자격증명을부여하여사용자에게작업을수행하는데필요한 AWS 서비스와리소스액세스권한만주는것입니다. IAM 은기본값 (default) 으로보안이설정되어있습니다. 신규사용자에게구체적인권한이부여되기전까지는 AWS 에액세스할수없습니다. IAM 은기본적으로대부분의 AWS 서비스내에포함되어있습니다. 어떠한서비스 API 도 IAM 을지원하기위해변경할필요가없으며, AWS 서비스 API 를이용해구축된애플리케이션과도구들은 IAM 을사용하는경우에도계속동작을유지합니다. 따라서신규사용자를위해생성된액세스키를사용하여애플리케이션을시작하기만하면됩니다. AWS 서비스를사용할때는되도록고객 AWS 계정의자격증명사용을최소화하고, AWS 서비스와리소스에액세스할때 IAM 사용자자격증명을사용해야합니다. 고객애플리케이션보호 모든 Amazon EC2 인스턴스는하나이상의보안그룹 43 으로보호됩니다. 보안그룹이란고객인스턴스에전달할인그레스 ( 인입 ) 네트워크트래픽을지정하는규칙집합을의미합니다. TCP/UDP 포트, ICMP 유형과코드및소스주소를지정할수있습니다. 보안그룹은인스턴스를실행하기위해방화벽과같은기본적인보호방법을제공합니다. 예를들어, 웹애플리케이션에속한인스턴스는다음과같은보안그룹설정이가능합니다. 40 Multi-factor Authentication 에대한자세한사항은웹사이트 (http://aws.amazon.com/ko/mfa/) 를참조하십시오. 41 AWS Management Console(http://aws.amazon.com/console/) 42 자세한사항은웹사이트 (http://aws.amazon.com.com/iam) 를참조하십시오. 43 보안그룹에대한자세한사항은웹사이트 (http://docs.amazonwebservices.com/awsec2/2009-07- 15/UserGuide/index.html?using-network-security.html) 를참조하십시오. 19/23 페이지
그림 4: Amazon EC2 보안그룹을사용한웹애플리케이션보호 인입트래픽을제한하는또다른방법은고객인스턴스에방화벽소프트웨어를구성하는것입니다. Windows 인스턴스는내장된방화벽 44 을사용할수있으며, Linux 인스턴스는 netfilter 45 및 iptables 를사용할수있습니다. 시간이지남에따라소프트웨어의오류를발견하게되고, 수정을위해패치작업을해야합니다. 애플리케이션의보안을극대화하기위해서는다음의기본지침에따라야합니다. 공급업체의웹사이트에서정기적으로패치를다운로드하고 AMI 를업데이트합니다. 새 AMI 에서인스턴스를다시배포하고패치로인해손상된것이없는지확인하기위해고객의애플리케이션을시험합니다. 최신 AMI 가모든인스턴스에배포되었는지확인합니다. 테스트스크립트에투자하여정기적인보안점검을실행하고프로세스를자동화합니다. 타사소프트웨어를가장안전한설정으로구성되도록합니다. 반드시필요한경우가아니라면프로세스를루트또는관리자로그인으로실행하지않습니다. 좋은코딩방법을사용하거나, 중요한데이터를격리하는것과같은클라우드이전에적용되었던모든표준보안관행은여전히적용가능하며구현되어야합니다. 요컨대, 고객이필요로하는복잡한물리적보안기능을요약정리하여, 고객의애플리케이션을안전하게유지할수있도록도구및기능들을이용한컨트롤기능을제공합니다. 44 http://technet.microsoft.com/en-us/library/cc779199(ws.10).aspx, March 2003 45 http://www.netfilter.org/ 20/23 페이지
미래연구방향 애플리케이션이물리적하드웨어형태에구애받지않게될날이머지않았습니다. 전자레인지에전원을연결할때전기에대한지식까지필요하지않은것처럼애플리케이션을클라우드에플러그인하면전기를사용하듯이애플리케이션을실행하는데필요한동력을얻을수있게될것입니다. 설계자는물리적서버대신가상컴퓨팅, 스토리지및네트워크리소스를관리하게될것입니다. 기본물리적하드웨어에장애가발생하거나하드웨어를제거또는교체하더라도애플리케이션은동작상태를계속유지할것입니다. 변화하는수요패턴에맞춰애플리케이션이리소스를즉시자동으로배분하여사용률수준을언제나최상으로유지할수있게될것입니다. 애플리케이션아키텍처에서확장성, 보안, 고가용성, 내결함성, 테스트용이성, 탄력성등의속성을설정할수있게될것입니다. 또한, 플랫폼에서이러한속성을자동으로구성할수있게될것이며, 이러한속성이플랫폼의본질적인부분이될것입니다. 하지만아직은이러한단계까지이르지는못했습니다. 현재는본백서에서소개한모범사례를구현하는방법으로이러한특징가운데일부를갖춘클라우드내에애플리케이션을구축할수있습니다. 클라우드컴퓨팅아키텍처의모범사례는계속발전할것입니다. 연구원으로서우리는클라우드를개선할뿐아니라도구, 기술및프로세스를구축하는데주력하여개발자와설계자가클라우드에서애플리케이션을쉽게사용할수있도록할것입니다. 결론 본백서는효율적인클라우드애플리케이션설계를위해필요한규범적지침을클라우드설계자에게제공할목적으로작성했습니다. 기본개념과모범사례 ( 장애에대비하기위한설계, 애플리케이션구성요소들의해체, 탄력성의이해와구현, 병렬화, 애플리케이션아키텍처의모든측면에보안구현방법 ) 을중점적으로다루고있어클라우드설계자들이확장성뛰어난클라우드애플리케이션을구축하는데필요한사항을설계시고려할수있도록했습니다. AWS 클라우드는사용량만큼요금을부과하는매우안정적인인프라서비스를제공합니다. 본백서에서집중적으로설명한 AWS 중심전략들은고객여러분이이서비스를사용하여클라우드애플리케이션을설계하는데도움을드릴수있을것입니다. 본자료를작성한연구자로서본인은고객여러분들이 AWS 와같은상용서비스뿐아니라다른제품들도익히는가운데, 이를바탕으로더나은클라우드컴퓨팅기술을보완, 발전시켜나갈것을권해드립니다. 감사의말 본백서의초안작성시의견을제시해준 Jeff Barr, Steve Riley, Paul Horvath, Prashant Sridharan 및 Scot Marvin 에게진심으로감사를드립니다. 귀중한의견을제공해준 Matt Tavis 에게특별히감사를전합니다. 그분의도움이없었다면본백서작성은불가능했을것입니다. 본백서내용의일부는위저자가저술한 'Cloud Computing: Paradigms and Patterns' 에서인용한것입니다. Copyright 2010 John Wiley & Sons, Inc. 21/23 페이지
참고문헌 1. Amazon S3 Team, Best Practices for using Amazon S3, http://developer.amazonwebservices.com/connect/entry.jspa?externalid=1904, 2008-11-26 2. Amazon S3 Team, Amazon S3 Error Best Practices, http://docs.amazonwebservices.com/amazons3/latest/index.html?errorbestpractices.html, 2006-03-01 3. Amazon SimpleDB Team, Query 201: Tips and Tricks for Amazon SimpleDB Query, http://developer.amazonwebservices.com/connect/entry.jspa?externalid=1232&categoryid=176, 2008-02-07 4. Amazon SimpleDB Team, Building for Performance and Reliability with Amazon SimpleDB, http://developer.amazonwebservices.com/connect/entry.jspa?externalid=1394&categoryid=176, 2008-04-11 5. Amazon SimpleDB Team, Query 101: Building Amazon SimpleDB Queries, http://developer.amazonwebservices.com/connect/entry.jspa?externalid=1231&categoryid=176, 2008-02-07 6. J. Varia, Cloud Architectures, http://jineshvaria.s3.amazonaws.com/public/cloudarchitectures-varia.pdf, 2007-07-01 7. Amazon Security Team, Overview of Security Processes, http://awsmedia.s3.amazonaws.com/pdf/aws_security_whitepaper.pdf, 2009-06-01 8. Amazon Web Services Team, Creating HIPPA-Compliant Medical Data Applications With AWS, http://awsmedia.s3.amazonaws.com/aws_hipaa_whitepaper_final.pdf, 2009-04-01 9. D. Obasanjo, Building Scalable Databases: Pros and Cons of Various Database 샤딩 Schemes, http://www.25hoursaday.com/weblog/2009/01/16/buildingscalabledatabasesprosandconsofvariousdatabase 샤딩 Sche mes.aspx, 2009-01-16 10. D. Pritchett, Shard Lessons, http://www.addsimplicity.com/adding_simplicity_an_engi/2008/08/shard-lessons.html, 2008-08-24 11. J. Hamilton, On Designing and Deploying Internet-Scale Services, 2007, 21 st Large Installation System Administration conference (LISA O7), http://mvdirona.com/jrh/talksandpapers/jamesrh_lisa.pdf 12. J. Dean and S. Ghemawat, MapReduce: Simplified data processing on large clusters2004-12-01, In Proc. of the 6th OSDI, http://labs.google.com/papers/mapreduce-osdi04.pdf 13. T. Schlossnagle, Scalable Internet Architectures, Sams Publishing, 2006-07-31, 14. M. Lurie, The Federation: Database Interoperability, http://www.ibm.com/developerworks/data/library/techarticle/0304lurie/0304lurie.html, 2003-04-23 15. E. Hammond, Escaping Restrictive/Untrusted Networks with OpenVPN on EC2, http://alestic.com/2009/05/openvpn-ec2, 2009-05-02 16. R. Bragg, The Encrypting File System, http://technet.microsoft.com/en-us/library/cc700811.aspx, 2009 17. S. Swidler, How to keep your AWS credentials on an EC2 instance securely, http://clouddevelopertips.blogspot.com/2009/08/how-to-keep-your-aws-credentials-on-ec2.html, 2009-08-31 18. Amazon SQS Team, Building Scalable, Reliable Amazon EC2 Applications with Amazon SQS, http://sqs-publicimages.s3.amazonaws.com/building_scalabale_ec2_applications_with_sqs2.pdf, 2008 19. Microsoft Support Team, Best Practices For Encrypting File System (Windows), http://support.microsoft.com/kb/223316, 2009 20. Solaris Security Team, ZFS Encryption Project (OpenSolaris), http://www.opensolaris.org/os/project/zfs-crypto/, 2009-05-01 22/23 페이지
21. Amazon RDS Team, Amazon RDS Multi-AZ Deployments, http://docs.amazonwebservices.com/amazonrds/latest/developerguide/concepts.dbinstance.html#concepts.multiaz. 2010-05-15 22. Amazon SimpleDB Team, Amazon SimpleDB Consistency Enhancements http://developer.amazonwebservices.com/connect/entry.jspa?externalid=3572 2010-02-24 23/23 페이지