Introduction to DevOps on AWS David Chapman
목차 목차 2 개요 3 소개 3 Agile 에서 DevOps 로의진화 4 인프라를나타내는코드 5 AWS CloudFormation 6 AWS AMI 9 지속적인개발 9 AWS CodeDeploy 10 AWS CodePipeline 11 AWS CodeCommit 11 AWS Elastic Beanstalk 및 AWS OpsWorks 12 블루-그린 (Blue-Green) 배포 12 자동화 14 AWS Elastic Beanstalk 15 AWS OpsWorks 16 모니터링 17 Amazon CloudWatch 17 AWS CloudTrail 18 보안 18 Identity and Access Management(IAM) 19 결론 19 2 / 19
개요 혁신이가속화되고고객이급속한발전을요구함에따라기업의대응능력도그만큼민첩해야합니다. 따라서시장진입시간은매우중요하며, 전반적인비즈니스목표를실현하기위해서는 IT 부서의민첩한대응능력이필수적으로요구됩니다. 소프트웨어개발수명주기는수년간에걸쳐폭포형 (Waterfall) 개발모델에서 Agile 개발모델로바뀌었습니다. 이러한개선이 DevOps 발전과더불어 IT 운영으로확산되고있습니다. Agile 비즈니스의요구를충족하기위해서는 IT 운영팀에서일관되고반복가능하며신뢰할수있는방식으로애플리케이션을배포해야합니다. 이는자동화를통해서만완전하게실현할수있습니다. Amazon Web Services(AWS) 는 IT 부서에서비즈니스의민첩한대응능력을향상시키기위해활용할수있는다양한 DevOps 원칙과사례를지원합니다. 이백서는 DevOps 원칙과 AWS 플랫폼에서지원되는사례에대해집중적으로다룹니다. DevOps 의유래에대한간단한소개를통해현재의상황을정의하고, DevOps 가어떻게발전해왔는지그리고왜발전해야하는지에대해설명합니다. 소개 DevOps 란기본적으로소프트웨어개발자와 IT 운영팀간의향상된협업, 커뮤니케이션및통합에초점을맞춘새로운용어입니다. 이용어는철학, 문화변화및패러다임전환으로설명되는포괄적인용어입니다. 코드 개발자 운영자 그림 1: " 벽너머로 " 코드를던지는개발자 많은조직은개발, 인프라, 보안및지원팀간의통합이제대로이루어지지않는수직적인구조형태를보여왔습니다. 흔히그룹은회사목표와철학이서로다른다양한조직구조로볼수있습니다. 3 / 19
소프트웨어배포는대체로 IT 운영그룹의역할이었습니다. 기본적으로개발자는신속하게소프트웨어를개발하고변경하기를좋아하는반면, IT 운영팀에서는안정성과신뢰성에중점을둡니다. 이러한목표의불일치는충돌로이어지며, 결국회사에문제가될수있습니다. 오늘날에는 IT 와개발자역할이일련의조직적원칙에따라통합되면서이러한과거이분할개념이무너지고있습니다. 코드형인프라 연속배포 자동화 모니터링 보안 이러한각각의원칙을살펴보면 Amazon Web Services 에서제공하는상품과의밀접한관계가드러납니다. Agile 에서 DevOps 로의진화 DevOps 원칙을제대로인식하기위해서는 DevOps 가발전해온정황을이해하는것이도움이됩니다. 이이야기는 10 년전에우수한소프트웨어빌드방법으로여겨져큰인기를누렸던 Agile 소프트웨어개발에서시작됩니다. Agile 이전에지배적이었던폭포형 (Waterfall) 개발방법은개발할시스템을 100% 미리정의해놓고, 요구사항분석단계에서시작하는순차적인개발프로세스입니다. 이방법은유연하지못하고획일적임이자체적으로입증되었습니다. Agile 모델은비즈니스사용자와개발자간의새롭고향상된협업의개념을가져왔습니다. 이모델은프로젝트기간동안발전하면서가치를제공하는, 작동소프트웨어의반복적인개발에중점을두기시작했습니다. Agile 은경험적으로제어되는엔지니어링프로세스로, 현재다양한도구가이모델을지원합니다. 개발자를위한이러한도구에는 IDE, 단위테스트프레임워크및코드최적화도구등이있습니다. 개발자의생산성이향상될수록비즈니스의대응능력이민첩해져서고객요청에더빠르고효율적으로대응할수있습니다. 4 / 19
비즈니스사례요구사항사용사례기능계획시장진입 비즈니스 개발자 ( 애플리케이션 ) IT 운영 ( 인프라 ) Agile 소프트웨어개발 - 반복적개발 - 스프린트, 스톤, 피드백 - 속도 설계코드리팩터단위테스트버그수정배포 - IT 자동화 - 지속적통합 - 지속적배포 프로비저닝구성조직화배포보고모니터링 그림 2: Agile 소프트웨어개발과 DevOps 의공진화 비즈니스대응능력 (Agility) IT 대응능력 지난몇년동안 Agile 소프트웨어개발의발전이 DevOps 라는이름아래인프라전체로확산되었습니다. Agile 소프트웨어개발은기본적으로회사와개발자간의협업에중점을두는반면, DevOps 는개발, IT 운영및보안팀간의협업에중점을둡니다. IT 운영팀에는시스템관리자, 데이터베이스관리자, 네트워크엔지니어, 인프라아키텍트및지원담당자가포함됩니다. Agile 소프트웨어개발이비즈니스대응능력을제공하는반면, DevOps 는 IT 대응능력을제공하여보다안정되고예측가능하며효율적인애플리케이션을개발할수있게해줍니다. DevOps 사례는작업마다다릅니다. 애플리케이션개발의경우, DevOps 는코드빌드, 코드범위, 단위테스트, 패키지화및개발에중점을둡니다. 한편, 인프라의경우에는 DevOps 는프로비저닝, 구성, 조직화및개발에중점을둡니다. 하지만각영역에서버전관리, 배포, 롤백, 롤포워드및테스트의기본원리는모두동일합니다. 인프라를나타내는코드 DevOps 의기본원리는개발자가코드를다루는방식과동일한방식으로인프라를다루는것입니다. 애플리케이션코드에는형식과구문이정의되어있습니다. 코드가프로그래밍언어의규칙에따라작성되지않으면애플리케이션을만들수없습니다. 코드는코드개발, 변경내용및버그수정사항내역이기록되는버전관리시스템에저장됩니다. 코드가애플리케이션으로컴파일 ( 빌드 ) 될때일관된애플리케이션이생성됩니다. 즉, 빌드가반복적이고안정적입니다. 코드형인프라 를실현한다는것은애플리케이션코드개발과똑같은엄격성을인프라프로비저닝에적용한다는뜻입니다. 모든구성을선언방식으로정의하고애플리케이션코드와똑같이버전관리시스템에저장해야합니다. 인프라프로비저닝, 조직화및개발에서 " 인프라코드 " 사용을지원해야합니다. 5 / 19
최근까지는애플리케이션코드개발에적용되는엄격성이인프라에반드시적용될필요가없었습니다. 대체로인프라는수동프로세스를사용하여프로비저닝됩니다. 프로비저닝중에개발된스크립트는버전관리시스템에저장하지못할수도있으며환경구축의반복성, 안정성또는일관성이반드시유지되지는않습니다. 이와대조적으로, AWS 는인프라구축및유지관리를위한 DevOps 중심의방법을제공합니다. 소프트웨어개발자가애플리케이션코드를작성할때처럼, AWS 는프로그래밍, 설명및선언적인방식으로인프라의구축, 배포및유지관리를지원하는서비스를제공합니다. 이러한서비스는엄격성, 명확성및안정성을제공합니다. 이문서에서설명한 AWS 서비스는 DevOps 전략의핵심요소로, 다양한상위수준의 AWS DevOps 원칙및사례의토대를형성합니다. AWS CloudFormation AWS CloudFormation 은 DevOps 원칙이실제로어떻게사용되지를보여주는좋은예입니다. 1 AWS CloudFormation 템플릿을사용하면생성및업데이트할수있는 AWS 리소스를정의하고모델링할수있습니다. 이러한템플릿은 JavaScript Object Notation(JSON) 이라고하는형식으로작성됩니다. 템플릿에는생성및관리되는리소스유형에따라달라지는특정구문및구조가필요합니다. 템플릿을사용하면반복가능하고안정적인방식으로인프라를프로비저닝할수있습니다. 사용자지정 AWS CloudFormation 템플릿을만들거나공개적으로사용가능한샘플템플릿을사용할수있습니다. 템플릿을 AWS 환경으로배포또는업데이트한후, 관리되는리소스모음을 스택 이라고합니다. AWS Management Console, AWS 명령줄인터페이스또는 AWS CloudFormation API 를통해스택을관리할수있습니다. 일반적인작업으로는스택생성, 스택설명, 스택나열및스택업데이트가있습니다. 콘솔에서스택을생성하거나업데이트할때구성상태를보여주는이벤트가표시됩니다. 오류가발생하면스택이이전상태로롤백됩니다. Amazon Simple Notification Service(Amazon SNS) 는이러한이벤트를관리하는데도움이됩니다. 예를들어 Amazon SNS 를사용하여이메일을통해스택생성및삭제진행상황을추적하고다른프로세스와프로그래밍방식으로통합할수있습니다. Amazon Simple Storage Service(Amazon S3), Auto Scaling, Amazon CloudFront, Amazon DynamoDB, Amazon Elastic Compute Cloud(EC2), Amazon ElastiCache, AWS Elastic Beanstalk, Elastic Load Balancing, AWS Identity and Access Management, AWS OpsWorks, Amazon Virtual Private Cloud 등을비롯한광범위한 AWS 상품에서템플릿을사용하여작업할수있습니다. 1 http://aws.amazon.com/cloudformation 6 / 19
스택 템플릿 그림 3: AWS CloudFormation 예 1 템플릿하나에서전체환경 ( 스택 ) 구축 단일템플릿을사용하여전체환경을구축및업데이트하거나여러개별템플릿을사용하여환경내계층을관리할수있습니다. 따라서템플릿을모듈화할수있으며여러조직에중요한거버넌스계층도제공되는셈입니다. 스택 1 스택 2 스택 3 스택 4 템플릿 1 템플릿 2 템플릿 3 템플릿 4 그림 4: AWS CloudFormation 의예 2 - 계층화된방식으로여러템플릿에서전체환경 ( 스택 ) 구축 7 / 19
AWS CloudFormation 을사용하면 AWS 리소스모음을쉽게구성및배포할수있으며스택이구성될때특수파라미터를전달하거나종속성을설명할수있습니다. AWS CloudFormation 의 코드형정보 (information as code) 능력을실현하려면 AWS 에서템플릿을배포하거나업데이트하기전에소스코드관리시스템의버전관리부분에템플릿을저장해야합니다. Amazon S3 은템플릿을저장하고버전을관리하기에적합한위치를제공합니다. AWS CloudFormation 을원하는배포및관리도구와통합할수있습니다. AWS CloudFormation 서비스에서 코드형인프라 (infrastructure as code) 정의에는별도의요금이청구되지않습니다. AWS CloudFormation 에서생성되어애플리케이션에서사용된 AWS 리소스에대한일반요금만청구됩니다. 그림 5: EC2 인스턴스를시작하기위한 AWS CloudFormation 템플릿예 위의예에서 AWS CloudFormation 템플릿은 Amazon EC2 인스턴스를생성하기위해 JSON 형식으로정의되었습니다. 이사례에서는 m1.medium 유형의 EC2 인스턴스를프로비저닝합니다. Ref 라는용어는스택이생성될때액세스되는파라미터를의미합니다. KeyPair 라고하는파라미터는스택을생성할때제공할수있습니다. 이이름은 SSH 를사용하여인스턴스에액세스할때사용되는키페어의이름입니다. 8 / 19
AWS AMI Amazon 머신이미지 (AMI) 는 코드형인프라 를보여주는또하나의예입니다. AWS 컴퓨팅의이핵심구성요소는클라우드에서기본 AWS 컴퓨팅환경인 Amazon EC2 인스턴스를시작 ( 프로비저닝 ) 할수있는일종의디지털템플릿입니다. 이이미지에는웹서버, 애플리케이션서버및데이터베이스등소프트웨어구성에포함되어있습니다. 세가지 AMI 유형중에서선택할수있습니다. AWS 에서발행한 AMI 타사 AMI 사용자지정하여만든 AMI AWS 는 Linux 나 Microsoft Windows 같은인기운영체제에기초한일반적인소프트웨어구성을포함하는 AMI 를게시합니다. AMI 는타사공급업체에서구할수도있으며, 일부 AMI 는 AWS Marketplace 에서구입할수있습니다. 2 조직에서고유의사용자지정 AMI 를생성하여게시할수도있습니다. 사용자지정조직 AMI 에는일반적으로강화된운영체제, 안티바이러스소프트웨어및 Office 생산성제품군등회사차원에서배포된소프트웨어가포함됩니다. 또한 AMI 에는 AMI 와함께번들화된애플리케이션소프트웨어가포함되거나, 인스턴스에서시작시애플리케이션소프트웨어를설치할수있도록하는 부팅 스크립트및소프트웨어가포함될수있습니다. AMI 로애플리케이션수준의소프트웨어를미리로드하는것에는장단점이있습니다. 장점으로는, 부팅시추가소프트웨어를설치할필요가없으므로인스턴스를매우빨리시작할수있습니다. 하지만애플리케이션수준의소프트웨어가변경될때마다새 AMI 를생성해야할수도있습니다. 지속적인개발 연속배포는 DevOps 전략의또한가지핵심개념입니다. 기본목표는프로덕션가능한애플리케이션코드의자동화된개발을실현하는것입니다. 경우에따라서는연속배포가연속전송을의미하기도합니다. 단지연속배포가일반적으로프로덕션배포를의미한다는점만다릅니다. 연속전송사례및도구를사용하면소프트웨어를반복적및안정적으로빠르게배포할수있습니다. 배포에실패할경우이전버전으로자동롤백할수있습니다. 2 https://aws.amazon.com/marketplace 9 / 19
AWS CodeDeploy AWS 에서이원리를보여주는가장좋은예는코드배포서비스인 AWS CodeDeploy 입니다. 3 이서비스의핵심기능은관리를중앙화하며기존소프트웨어또는연속전송프로세스와통합하여최소중단시간으로 Amazon E2C 집합전체에애플리케이션을배포할수있는기능을제공합니다. 운영방식은다음과같습니다. 그림 6: AWS CodeDeploy 프로세스 1. 애플리케이션콘텐츠는패키지로압축되어 AWS CodeDeploy 에서실행해야하는일련의배포단계를정의한 AppSpec(Application Specific) 파일과함께 Amazon S3 로배포됩니다. 이패키지를 CodeDeploy 개정 이라고합니다. 2. AWS CodeDeploy 에서애플리케이션을생성하고애플리케이션을배포해야할인스턴스를정의할수있습니다 (DeploymentGroup). 또한애플리케이션은배포패키지가상주하는 Amazon S3 버킷을정의합니다. 3. AWS CodeDeploy 에이전트는각각의참여 Amazon EC2 에배포됩니다. 에이전트는 AWS CodeDeploy 를폴링하여지정된 Amazon S3 버킷에서개정을가져와야하는시기와가져올개정을결정합니다. 4. AWS CodeDeploy 에이전트는패키지화된애플리케이션코드를가져와서인스턴스에배포합니다. 배포지침이들어있는 AppSec 파일도다운로드됩니다. 3 http://aws.amazon.com/codedeploy 10 / 19
이와같이, AWS CodeDeploy 는 DevOps 의중심이되는연속자동화배포를보여주는전형적인예입니다. AWS CodePipeline AWS CodeDeploy 와마찬가지로, AWS CodePipeline(2015 년에사용가능 ) 은원활한배포를돕는연속전송및방출자동화서비스입니다. 4 코드를체크인하여구축하고애플리케이션을준비단계로배포하고테스트하며출시하는개발워크플로우를설계할수있습니다. 출시프로세스의어느단계에서든타사도구를통합할수있으며 AWS CodePipeline 을엔드투엔드솔루션으로도사용할수있습니다. AWS CodePipeline 을사용하면구축, 테스트, 출시프로세스를자동화하여높은품질의기능및업데이트를신속하게전송할수있습니다. AWS CodePipeline 는 DevOps 연속배포원리에맞는여러이점을제공합니다. 빠른전송 품질향상 구성가능한워크플로우 손쉬운통합 AWS CodeCommit 또한 2015 년에는프라이빗 Git 저장소를호스팅하는안전하고확장가능한소스관리형서비스인 AWS CodeCommit 서비스도실시될예정입니다. 5 CodeCommit 를사용하면자체소스제어시스템을운영하거나인프라조정을염려할필요가없습니다. 코드부터바이너리까지모든것을저장할수있으며, Git 의표준기능을지원하여기존 Git 기반도구와도원활하게연동됩니다. 또한, 팀에서 CodeCommit 의온라인코드도구를사용하여프로젝트를찾아보고수정및공동작업할수있습니다. AWS CodeCommit 은여러이점을제공합니다. 종합관리형 무엇이든저장가능 고가용성 보다빠른개발수명주기제공 기존도구와작동 보안 4 http://aws.amazon.com/codepipeline 5 http://aws.amazon.com/codecommit 11 / 19
AWS Elastic Beanstalk 및 AWS OpsWorks AWS Elastic Beanstalk 6 와 AWS OpsWorks 7 모두애플리케이션코드변경사항및인프라수정사항의연속배포를지원합니다. AWS Elastic Beanstalk 에서코드변경배포는 애플리케이션버전 으로저장되며인프라변경은 저장된구성 으로배포됩니다. AWS OpsWorks 에는고유한애플리케이션배포프로세스가있으며추가런타임시작명령과 Chef 레시피를정의할수있습니다. 애플리케이션버전예는.zip 또는.war 파일로업로드하는새 Java 애플리케이션입니다. 저장된구성의예는단일인스턴스가아닌 Elastic Load Balancing 및 Auto Scaling 을사용하는 AWS Elastic Beanstalk 구성입니다. 변경이완료되면새구성을저장할수있습니다. AWS Elastic Beanstalk 눈 배포롤링 이라고하는 DevOps 사례를지원합니다. 이방법이활성화된경우구성배포가 Auto Scaling 과함께작동하므로구성이변경될때정의된사용가능인스턴스수가항상유지됩니다. 따라서 Amazon EC2 인스턴스가업데이트될때사용자에게제어기능이제공됩니다. 예를들어 EC2 인스턴스유형을변경되는경우 AWS Elastic Beanstalk 에서모든인스턴스를동시에업데이트할지아니면다른인스턴스가업데이트될때요청을이행하기위해일부인스턴스의실행상태를유지할지여부를결정할수있습니다. 이와마찬가지로, AWS OpsWorks 는배포될때업데이트해야할계층과인스턴스를정의할수있는옵션도제공합니다. AWS Elastic Beanstalk 및 AWS OpsWorks 의추가기능은자동화섹션에설명되어있습니다. 블루 - 그린 (Blue-Green) 배포 Blue green 배포는도메인이름서비스 (DNS) 를사용하여애플리케이션을배포하는 DevOps 배포사례입니다. 이전략에서는기존 ( 블루 ) 환경으로시작하면서동시에새 ( 그린 ) 환경을테스트해야합니다. 새환경이모든필수테스트를통과했으며가동준비가완료된경우, 간단히 DNS 를통해이전환경에서새환경으로트래픽을리디렉션하기만하면됩니다. AWS 는블루 - 그린개발전략을구현하는데필요한도구를모두제공합니다. AWS CloudFormation 또는 AWS Elastic Beanstalk 같은서비스를사용하여이상적인새인프라환경을구성할수있습니다. AWS CloudFormation 템플릿을사용하면기존프로덕션환경과동일한새환경을쉽게구축할수있습니다. 6 http://aws.amazon.com/elasticbeanstalk 7 http://aws.amazon.com/opsworks 12 / 19
AWS DNS 서비스인 Amazon Route 53 을사용할경우가중치를할당한리소스레코드세트를사용하여트래픽흐름을라우팅할수있습니다. 이러한레코드세트를사용하면 DNS 확인을통해여러서비스나로드밸런서를정의할수있습니다. 그림 7: Amazon Route 53 가중치기반의리소스레코드세트를사용한블루 - 그린배포 DNS 서비스리졸루션 ( 도메인이름을 IP 주소로변환 ) 은가중치기반으로, 새로배포한프로덕션환경으로라우팅되는트래픽의양을정의할수있습니다. 이기능을사용하면환경을테스트한후, 배포가적절하다고확신될경우가중치를높일수있습니다. 이전프로덕션환경의트래픽수신율이 0% 인경우이환경을백업목적으로유지하거나폐기할수있습니다. 새환경의트래픽양이증가하면 Auto Scaling 을사용하여추가 Amazon EC2 인스턴스를확장할수있습니다. AWS 클라우드에서동일한환경을쉽게구축및폐기할수있는이기능을통해블루 - 그린배포같은 DevOps 사례가실현가능합니다. 또한데이터베이스배포및장애조치같은백엔드서비스에도블루 - 그린배포를사용할수있습니다. 13 / 19
자동화 DevOps 의또한가지핵심원칙과사례는자동화입니다. 자동화는인프라와인프라에서실행되는애플리케이션의설정, 구성, 배포및지원에중점을둡니다. 자동화를사용하여표준화되고반복가능한방식으로환경을매우신속하게설정할수있습니다. 성공적인 DevOps 전략의핵심은수동프로세스를제거하는것입니다. 지금까지서버구성및애플리케이션배포는주로수동프로세스로이루어져왔습니다. 환경이표준화되지않으면문제발생시환경을재현하기가어렵습니다. 자동화의사용은클라우드의모든이점을실현하는데있어서매우중요합니다. AWS 는내부적으로자동화에의존하여탄력성과확장성의핵심기능을제공합니다. 수동프로세스는오류가발생하기쉽고, 신뢰성이떨어지며, 민첩한대응능력을필요로하는비즈니스를지원하기에적합하지않습니다. 흔히조직의고급기술인력이수동구성을제공하는업무에얽매여있기도합니다. 이러한시간을회사에서보다중요하고더높은가치를창출하는다른활동을지원하는데쓰면더좋을것입니다. 현대의운영환경은일반적으로전체자동화에의존하여수동개입을제거하거나프로덕션환경에액세스합니다. 여기에는모든소프트웨어릴리스, 머신구성, 운영체제패치, 문제해결또는버그수정이포함됩니다. 자동화사례의다양한수준을함께사용하면보다높은수준의완전자동화프로세스를제공할수있습니다. 자동화는많은이점을제공합니다. 신속한변경 생산성향상 반복가능한구성 재현가능한환경 탄력성활용 자동조정활용 테스트자동화 자동화는 AWS 서비스의기초로, 모든서비스, 기능및상품에서내부적으로지원됩니다. 14 / 19
AWS Elastic Beanstalk AWS 의자동화예로, AWS Elastic Beanstalk 하나면충분합니다. AWS Elastic Beanstalk 는개발자가일반적으로사용되는기술스택에애플리케이션을쉽고생산적으로배포할수있게해주는서비스입니다. 인터페이스가간단하고쉬워서다계층애플리케이션을빠르고쉽게배포할수있습니다. AWS Elastic Beanstalk 는자동화는물론, 자동화된애플리케이션배포, 모니터링, 인프라구성및버전관리등다양한다른 DevOps 모범사례를지원합니다. 애플리케이션과인프라의변경을쉽게롤백하고전달할수있습니다. 환경구축은 AWS Elastic Beanstalk 자동화를보여주는좋은예입니다. 환경에대한세부정보만지정하면 AWS Beanstalk 에서자체적으로모든구성과프로비저닝작업을수행합니다. 예를들어다음은애플리케이션생성마법사에서지정할수있는몇가지옵션입니다. 웹서비스계층 ( 웹서버와애플리케이션서버포함 ) 을사용할지아니면작업자계층 (Amazon Simple Queue Service 사용 ) 을사용할지여부 애플리케이션에사용할플랫폼. IIS, Node.js, PHP, Python, Ruby, Tomcat 또는 Docker 중에서선택할수있습니다. 단일인스턴스를시작할지아니면로드밸런싱자동조정환경을구축할지여부 환경에자동으로배정할 URL 환경에 Amazon Relational Database 인스턴스를포함할지여부 Amazon Virtual Private Cloud 내부에서환경을구축할지여부 애플리케이션에대한자동상태확인에사용할 URL( 있는경우 ) 환경을식별하기위해적용할태그 ( 있는경우 ) 또한 AWS Elastic Beanstalk 는자동화를사용하여애플리케이션을배포합니다. 플랫폼에따라,.war 또는.zip 파일형태의패키지를컴퓨터나 Amazon S3 에서직접업로드하는것만으로도애플리케이션을배포할수있습니다. AWS Elastic Beanstalk 는환경이구축되는동안진행상황에대한피드백과시작상태를알려주는이벤트를관리콘솔에자동으로기록합니다. 완료되고나면정의된 URL 을사용하여애플리케이션에액세스할수있습니다. 애플리케이션및기술스택의특정측면을제어하려는경우 AWS Elastic Beanstalk 를그에맞게사용자지정할수있습니다. 15 / 19
AWS OpsWorks AWS OpsWorks 는 AWS Elastic Beanstalk 보다더세부적으로 DevOps 의원칙을적용합니다. AWS OpsWorks 는구성관리소프트웨어 (Chef) 및애플리케이션수명주기관리와의통합같은추가기능과함께훨씬더다양한자동화수준을제공합니다. 애플리케이션수명주기관리를사용하여리소스가설정, 구성, 배포, 배포해제또는종료되는시점을정의할수있습니다. AWS OpsWorks 는구성가능한스택에서애플리케이션을정의할수있는추가유연성도제공합니다. 또한미리정의된애플리케이션스택을선택할수도있습니다. 애플리케이션스택에는애플리케이션서버, 웹서버, 데이터베이스및로드밸런서등애플리케이션에필요한 AWS 리소스에대한모든프로비저닝이포함되어있습니다. 그림 8: DevOps 기능및아키텍처를보여주는 AWS OpsWorks 애플리케이션스택은스택을독립적으로유지관리할수있도록아키텍처계층으로구성됩니다. 계층의예로는웹계층, 애플리케이션계층및데이터베이스계층등을들수있습니다. 즉시사용가능한 AWS OpsWorks 는 Auto Scaling 그룹과 Elastic Load Balancing 로드밸런서설정을간소화함으로써 DevOps 자동화원칙을확실하게보여줍니다. AWS Elastic Beanstalk 와마찬가지로, AWS OpsWorks 도애플리케이션버전관리, 연속배포및인프라구성관리를지원합니다. AWS OpsWorks 는다음섹션에서설명하는 DevOps 모니터링및로깅사례도지원합니다. 모니터링지원은 Amazon CloudWatch 에서제공됩니다. 모든수명주기이벤트가기록되며, 실행되는모든 Chef 레시피가예외사항과함께개별 Chef 로그문서에문서화됩니다. 8 8 Chef 레시피는패키지및패치설치등시스템을구성하기위해수행해야하는모든작업을정의하는 Ruby 애플리케이션입니다. 16 / 19
모니터링 커뮤니케이션과협업은 DevOps 전략의기본요소입니다. 이를지원하기위해서는피드백이중요합니다. AWS 에서는피드백이 Amazon CloudWatch 와 AWS CloudTrail 이라는두가지핵심서비스를통해제공됩니다. 이들두서비스가함께작동하여인프라에대한강력한모니터링, 경고및감사기능을제공하므로개발자와운영팀이서로긴밀하고분명하게협력할수있습니다. Amazon CloudWatch Amazon CloudWatch 는모든 AWS 리소스와이러한리소스에서실행되는애플리케이션을실시간으로모니터링합니다. 9 리소스와애플리케이션은 Amazon CloudWatch 에서수집하고추적하는매트릭스를생성할수있습니다. 이벤트가발생할때마다알림을보내도록경보를구성할수있습니다. 이메일, Amazon SNS 및 Amazon Simple Queue Service 등다양한형식으로알림을구성할수있습니다. 알림을개인, 팀또는다른 AWS 리소스로전송할수있습니다. Amazon CloudWatch 는피드백을제공할뿐만아니라, DevOps 자동화개념도지원합니다. Auto Scaling 같은 AWS 서비스는 Amazon EC2 인스턴스의확장 / 축소와로드증가 / 감소등과같이해당자동작업을트리거하는알림을위해 CloudWatch 를사용합니다. 그림 9: Amazon CloudWatch 및 Auto Scaling 을사용한 DevOps 자동화의예 9 http://aws.amazon.com/cloudwatch 17 / 19
위의예에서 Amazon CloudWatch 는 Elastic Load Balancing 에서지연시간측정치를모니터링하고, 실행중인 Amazon EC2 인스턴스에서평균 CPU 측정치를모니터링합니다. 지연시간측정치는 Amazon EC2 인스턴스에대한요청이발생한후응답이전송되는데걸리는시간을측정합니다. 정의된임계값을벗어나서트리거되는경보에대해조치를취하는조정정책을만들수있습니다. 이러한정책을통해상황에따라 Amazon EC2 인스턴스수가증가하거나감소할수있습니다. 추가알림을정의하여 Amazon SNS 를통해메시지를전송할수도있습니다. 이기능은지원팀과같은관계자에게이벤트가발생했음을알릴때유용합니다. Auto Scaling 의예는 DevOps 전략을수용하는데있어핵심이되는, 투명하고자동화된서비스를제공하기위해 AWS 서비스가어떻게함께작동하는지를보여줍니다. 시스템관리자와지원팀은다른부가가치비즈니스요구에초점을맞출수있으며 AWS 인프라에서애플리케이션조정요구사항이잘처리되고있음을확신할수있습니다. 이시나리오에서는해당애플리케이션이클라우드에최적화되었으며수평확장가능한방식으로디자인되어 Auto Scaling 의이점을활용할수있다고가정합니다. AWS CloudTrail 협력, 커뮤니케이션및투명성에대한 DevOps 원칙을적용하기위해서는누가인프라를변경하는지알아야합니다. AWS 에서는이러한투명성이 AWS CloudTrail 서비스를통해제공됩니다. 10 모든 AWS 상호작용은 AWS CloudTrail 에서모니터링하고기록하는 AWS API 호출을통해처리됩니다. 생성된모든로그파일은사용자가정의한 Amazon S3 버킷에저장됩니다. 로그파일은 Amazon S3 서버쪽암호화 (SSE) 를사용하여암호화됩니다. 사용자로부터직접수신되든사용자를대신하여 AWS 서비스에의해수신되든모든 API 호출이기록됩니다. 지원관련운영팀, 거버넌스관련보안팀및결제관련회계팀등과같은다양한팀에서 CloudTrail 로그를활용할수있습니다. 보안 DevOps 지원환경에서도여전히보안을최우선으로생각해야합니다. 인프라와회사자산을보호해야하며문제발생시반복적이고효과적으로문제를해결해야합니다. 10 http://aws.amazon.com/cloudtrail 18 / 19
Identity and Access Management(IAM) AWS Identity and Access Management(IAM) 서비스는 AWS 보안인프라의구성요소중하나입니다. IAM 을사용하면사용자가어떤 AWS 서비스와리소스에액세스할수있는지를제어하는암호, 액세스키및사용권한정책과같은보안자격증명과사용자를중앙에서관리할수있습니다. IAM 을사용하여 DevOps 전략내에서광범위하게사용되는역할을만들수도있습니다. IAM 역할을사용하면사용자나서비스에서필요로하는리소스에액세스할수있는권한세트를정의할수있습니다. 하지만특정사용자나그룹에권한을연결하는대신에, 이들사용자나그룹을명명된역할에연결합니다. 그런다음에리소스를역할과연결하고서비스를프로그래밍방식으로정의하여역할을부여할수있습니다. 모든자동화프로세스중에는보안요구사항과규제를준수해야하며암호및키를사용하여작업할때는각별히주의해야합니다. 항상보안모범사례를따라야합니다. AWS 에서의보안중요성에대한자세한내용은 AWS 보안센터를참조하십시오. 11 결론 기술업체에서는 DevOps 원칙과사례를수용하여클라우드로원활하고효율적이며효과적인방법으로전환할수있습니다. 이러한원칙은 AWS 플랫폼에포함되어있습니다. 실제로이러한원칙은다양한 AWS 서비스의토대가되며, 특히배포및모니터링상품에서는더욱그렇습니다. AWS CloudFormation 서비스를사용하여코드형인프라를정의하는것부터시작하십시오. 그런다음, 애플리케이션에서 AWS CodeDeploy, AWS CodePipeline 및 AWS CodeCommit 같은서비스의도움을받아연속배포를어떤방식으로사용할지정의하십시오. 애플리케이션수준에서는 AWS Elastic Beanstalk 및 AWS OpsWorks 같은서비스를사용하여일반아키텍처의구성을간소화하십시오. 이러한서비스를사용하면 Auto Scaling 및 Elastic Load Balancing 같은다른중요서비스도쉽게포함할수있습니다. 마지막으로 DevOps 모니터링전략 (AWS CloudWatch) 과강력한보안사례 (AWS IAM) 를사용하십시오. AWS 를파트너로삼음으로써, 귀사의 DevOps 원칙이비즈니스와 IT 조직에민첩성을제공하고클라우드로의전환을가속화할것입니다. 2014, Amazon Web Services, Inc. 또는자회사. All rights reserved. 11 http://aws.amazon.com/security/ 19 / 19