[ 고지 사항 (Disclaimer) ]
본 컨텐츠는 고객의 편의를 위하여 AWS 서비스 설명을 위해 제작, 제공된 것입니다. 만약 AWS 사이트와 컨텐츠 상에서 차이나 불일치가 있을 경우 AWS 사이트 (AWS.amazon.com)가 우선합니다. 또한 AWS 사이트 상에서 한글 번역문과 영어 원문에 차이나 불일치가 있을 경우(번역의 지체로 인한 경우 등 포함), 영어 원문이 우선합니다.
본 문서는 Infrastructure as Code(2017, 영문) 내용에 기반하여 작성 되었습니다.
이 문서는 정보 제공의 목적으로만 제공됩니다. 본 문서의 발행일 당시 AWS의 현재 제품 오퍼링 및 실행방법 등을 설명하며, 예고 없이 변경될 수 있습니다. 고객은 본 문서에 포함된 정보나 AWS 제품 또는 서비스의 사용을 독립적으로 평가할 책임이 있으며, 각 정보 및 제품은 명시적이든 묵시적이든 어떠한 종류의 보증 없이 “있는 그대로” 제공됩니다. 본 문서는 AWS, 그 자회사, 공급업체 또는 라이선스 제공자로부터 어떠한 보증, 표현, 계약 약속, 조건 또는 보장을 구성하지 않습니다. 고객에 대한 AWS의 책임 및 의무는 AWS 계약에 의해 관리되며 본 문서는 AWS와 고객 사이의 어떠한 계약에도 속하지 않으며 계약을 변경하지도 않습니다.
© 2020, Amazon Web Services, Inc. or its affiliates. All rights reserved.
요약
코드로서의 인프라(Infrastructure as Code)는 인프라 서비스 프로비저닝을 자동화하는 모범 사례로 부상했습니다. 이 백서에서는 인프라가 코드로서 갖는 이점과 이 영역에서 Amazon Web Services의 기능을 활용하여 DevOps 이니셔티브를 지원하는 방법에 대해 설명합니다.
DevOps는 문화 철학, 관행 및 툴의 조합으로, 빠른 속도로 애플리케이션과 서비스를 제공할 수 있는 능력을 향상시킵니다. 이를 통해 조직은 고객의 요구에 보다 효과적으로 대응할 수 있습니다. 코드로서의 인프라 실행은 그러한 속도를 달성하는 촉매제가 될 수 있습니다.
코드 형태의 인프라 소개
인프라 관리는 소프트웨어 엔지니어링과 관련된 프로세스입니다. 조직에서는 전통적으로 하드웨어를 “ racked and stacked”한 다음, 기술 요구사항을 지원하기 위해 운영 체제와 애플리케이션을 설치 및 구성했습니다. 클라우드 컴퓨팅은 가상화를 활용하여 기술 인프라를 구성하는 컴퓨팅, 네트워크 및 스토리지 리소스의 온디맨드 프로비저닝을 지원합니다.
인프라 관리자는 이러한 프로비저닝을 수동으로 수행하는 경우가 많습니다. 수동 프로세스에는 다음과 같은 몇 가지 단점이 있습니다.
· 더 높은 비용은 그렇지 않을 경우 더 중요한 비즈니스 요구로 전환할 수 있는 인적 자본이 필요하기 때문입니다.
· 인적 오류로 인한 불일치로 인해 구성 표준과의 편차가 발생합니다.
· 고객의 요구와 시장 동인에 대응하여 새로운 버전의 서비스를 제공할 수 있는 속도를 제한하여 민첩성이 부족합니다.
· 반복 가능한 프로세스가 없기 때문에 기업 또는 업계 표준을 준수하고 유지하기 어렵습니다.
코드로서의 인프라(Infrastructure as Code)는 프로비저닝 프로세스의 자동화를 통해 이러한 결함을 해결합니다. 관리자와 개발자 모두 수동으로 수행하는 단계에 의존하지 않고 구성 파일을 사용하여 인프라를 인스턴스화할 수 있습니다. Infrastructure as Code는 이러한 구성 파일을 소프트웨어 코드로 처리합니다. 이러한 파일은 운영 환경을 구성하는 컴퓨팅, 스토리지, 네트워크 및 애플리케이션 서비스 등 일련의 아티팩트를 생성하는 데 사용할 수 있습니다. Infrastructure as Code는 자동화를 통한 구성 지연을 제거하여 인프라 구현의 속도와 민첩성을 향상시킵니다.
인프라 리소스 수명주기
이전 섹션에서는 반복 가능하고 일관된 방식으로 리소스를 프로비저닝하는 방법으로 인프라(Infrastructure as Code)를 제시했습니다. 기본 개념은 인프라 기술 운영의 광범위한 역할과도 관련이 있습니다. 다음 도표를 고려합니다.
그림 1은 조직 내 인프라 리소스의 라이프사이클에 대한 일반적인 보기를 보여 줍니다. 라이프사이클의 단계는 다음과 같습니다.
1. 리소스 프로비저닝. 관리자는 원하는 사양에 따라 리소스를 프로비저닝합니다.
2. 구성 관리. 리소스는 조정 및 패치 등의 작업을 지원하는 구성 관리 시스템의 구성 요소가 됩니다.
3. 모니터링 및 성능. 모니터링 및 성능 도구는 메트릭, 통합 트랜잭션 및 로그 파일과 같은 항목을 검사하여 리소스의 작동 상태를 확인합니다.
4. 준수 및 거버넌스. 컴플라이언스 및 거버넌스 프레임워크는 기업 및 업계 표준과 규정 요구 사항과의 조정을 보장하기 위해 추가적인 검증을 유도합니다.
5. 자원 최적화. 관리자는 성능 데이터를 검토하고 성능 및 비용 관리와 같은 기준에 따라 환경을 최적화하는 데 필요한 변경 사항을 파악합니다.
각 단계에는 코드를 활용할 수 있는 절차가 포함됩니다. 이를 통해 Code로서의 인프라(Infrastructure as Code)의 이점을 프로비저닝에서 기존 역할에서 전체 리소스 라이프사이클까지 확장할 수 있습니다. 그러면 모든 라이프사이클이 코드로서의 인프라가 제공하는 일관성과 반복성의 이점을 누릴 수 있습니다. 이렇게 확장된 인프라는 코드로 인해 IT 조직 전체의 성숙도가 높아집니다.
다음 섹션에서는 프로비저닝, 구성 관리, 모니터링 및 성능, 거버넌스 및 컴플라이언스, 최적화 등 라이프사이클의 각 단계에 대해 살펴봅니다. 각 단계와 관련된 다양한 작업을 고려하고 AWS(Amazon Web Services) 기능을 사용하여 이러한 작업을 수행하는 방법에 대해 논의하겠습니다.
리소스 프로비저닝
정보 리소스 라이프사이클은 리소스 프로비저닝부터 시작됩니다. 관리자는 Code로서의 인프라 원칙을 사용하여 프로비저닝 프로세스를 간소화할 수 있습니다. 다음 상황을 고려합니다.
· 릴리즈 관리자는 재해 복구를 위해 클라우드 기반 프로덕션 환경의 복제본을 구축해야 합니다. 관리자는 운영 환경을 모델링하고 재해 복구 위치에서 동일한 인프라를 프로비저닝하는 템플릿을 설계합니다.
· 한 대학교수는 매 학기마다 수업에 필요한 자원을 공급하고 싶어합니다. 반 학생들은 공부에 적합한 도구를 포함하는 환경이 필요합니다. 교수는 적절한 인프라 구성 요소가 포함된 템플릿을 생성한 다음 필요에 따라 각 학생의 템플릿 리소스를 인스턴스화합니다.
· 특정 업계 보호 표준을 충족해야 하는 서비스에는 서비스를 설치할 때마다 일련의 보안 제어가 포함된 인프라가 필요합니다. 보안 관리자는 보안 제어를 구성 템플릿에 통합하여 보안 제어가 인프라와 인스턴스화되도록 합니다.
· 소프트웨어 프로젝트 팀의 관리자는 필요한 도구와 지속적인 통합 플랫폼과의 인터페이스 기능이 포함된 개발 환경을 프로그래머에게 제공해야 합니다. 관리자는 리소스의 템플릿을 생성하고 해당 템플릿을 리소스 카탈로그에 게시합니다. 이를 통해 팀 구성원은 필요에 따라 자체 환경을 프로비저닝할 수 있습니다.
이러한 상황에는 리소스를 일관되게 인스턴스화하기 위한 반복 가능한 프로세스가 필요합니다. 코드로서의 인프라(Infrastructure as Code)는 이러한 프로세스의 프레임워크를 제공합니다. 이러한 요구를 해결하기 위해 AWS는 AWS CloudFormation을 제공합니다.
AWS CloudFormation
AWS CloudFormation은 개발자 및 시스템 관리자에게 관련 AWS 리소스 컬렉션을 순서 있고 예측 가능한 방식으로 쉽게 생성, 관리, 프로비저닝 및 업데이트할 수 있는 방법을 제공합니다. AWS CloudFormation은 JSON 또는 YAML 형식으로 작성된 템플릿을 사용하여 AWS 리소스(스택을 스택이라고 함), 관련 종속성 및 필요한 런타임 매개 변수를 설명합니다. 템플릿을 반복적으로 사용하여 동일한 스택의 동일한 복사본을 AWS 영역 간에 일관되게 생성할 수 있습니다. 리소스를 배포한 후 제어되고 예측 가능한 방식으로 리소스를 수정하고 업데이트할 수 있습니다. 실제로 애플리케이션 코드와 동일한 방식으로 AWS 인프라에 버전 제어를 적용하고 있습니다.
템플릿 분석
그림 2는 기본 AWS CloudFormation YAML 형식 템플릿 조각을 보여줍니다. 템플릿에는 매개 변수, 리소스 선언 및 출력이 포함됩니다. 템플릿은 모듈화를 지원하는 다른 템플릿의 출력을 참조할 수 있습니다.
그림 3은 AWS CloudFormation 템플릿의 예입니다. 템플릿은 매개 변수 섹션의 사용자로부터 Amazon Elastic Compute Cloud(EC2) 키 쌍의 이름을 요청합니다. 그런 다음 템플릿의 리소스 섹션에서 해당 키 쌍을 사용하여 HTTP(TCP 포트 80) 액세스를 실행하는 EC2 Security Group을 사용하여 EC2 인스턴스를 생성합니다.
변경 세트
AWS CloudFormation 템플릿을 애플리케이션 소스 코드로 업데이트하여 스택 리소스를 추가, 수정 또는 삭제할 수 있습니다. 변경 세트 기능을 사용하면 관련 업데이트를 수행하지 않고도 스택에 대해 제안된 변경 사항을 미리 볼 수 있습니다. AWS IAM(Identity and Access Management)을 사용하여 변경 세트를 만들고 보는 기능을 제어할 수 있습니다. 일부 개발자가 변경 세트를 만들고 미리 볼 수 있도록 허용하면서 스택 업데이트 또는 변경 세트 실행 기능을 선택한 몇 개로 예약할 수 있습니다. 예를 들어 개발자가 템플릿 변경의 영향을 확인한 후 테스트 단계로 변경할 수 있습니다.
변경 세트 사용과 관련된 세 가지 기본 단계가 있습니다.
스택에 대한 변경 세트를 작성하려면 템플릿 또는 매개 변수에 변경 사항을 AWS CloudFormation에 제출합니다. AWS CloudFormation은 현재 스택과 변경 내용을 비교하여 변경 세트를 생성합니다.
AWS CloudFormation 콘솔, AWS CLI 또는 AWS CloudFormation API를 사용하여 변경 세트를 볼 수 있습니다. AWS CloudFormation 콘솔은 변경 사항에 대한 요약과 JSON 형식의 변경 사항에 대한 자세한 목록을 제공합니다. AWS CLI 및 AWS CloudFormation API는 JSON 형식의 변경 사항 목록을 반환합니다.
AWS CloudFormation 콘솔에서 변경 세트를 선택하여 실행하거나, AWS CLI에서 aws Cloudformation runch-set 명령을 사용하거나, ExecuteChangeSet API를 사용할 수 있습니다.
변경 세트 기능을 사용하면 AWS CloudFormation에서 버전 제어를 넘어 한 버전에서 다음 버전으로 실제로 변경되는 내용을 추적할 수 있습니다. 개발자와 관리자는 변경 사항을 홍보하기 전에 변경사항이 미치는 영향을 더 잘 파악하고 오류 발생 위험을 최소화할 수 있습니다.
재사용 가능한 템플릿
많은 프로그래밍 언어는 함수 및 서브 루틴과 같은 구문으로 코드를 모듈화하는 방법을 제공합니다. 마찬가지로 AWS CloudFormation은 스택을 관리하고 구성하는 여러 가지 방법을 제공합니다. 모든 리소스를 단일 스택 내에서 유지 관리 할 수 있지만 큰 단일 스택 템플릿을 관리하기가 어려워 질 수 있습니다. 또한 여러 AWS CloudFormation 제한이 발생할 가능성이 더 큽니다.
AWS CloudFormation 스택의 아키텍처를 설계 할 때 기능별로 스택을 논리적으로 그룹화 할 수 있습니다. 가상 사설 클라우드 (VPC), 서브넷 및 보안 그룹과 같이 필요한 모든 리소스가 포함 된 단일 템플릿을 생성하는 대신 중첩 스택 또는 교차 스택 참조를 사용할 수 있습니다.
중첩된 스택 기능을 사용하면 AWS CloudFormation 템플릿 내에 새 AWS CloudFormation 스택 리소스를 생성하고 두 스택 간에 상위-하위 관계를 설정할 수 있습니다. 상위 템플릿에서 AWS CloudFormation 스택을 생성할 때마다 AWS CloudFormation은 새 하위 스택도 생성합니다. 이 접근 방식을 사용하면 프로젝트 간에 인프라 코드를 공유하면서 각 프로젝트에 대해 완전히 별도의 스택을 유지할 수 있습니다.
교차 스택 참조를 사용하면 AWS CloudFormation 스택이 다른 AWS CloudFormation 스택에서 가져올 수 있는 값을 내보낼 수 있습니다. 크로스 스택 참조는 단일 리소스 세트를 여러 프로젝트에서 공유할 수 있는 느슨한 커플링을 통해 서비스 지향 모델을 촉진합니다.
템플릿 Linting
애플리케이션 코드와 마찬가지로 AWS CloudFormation 템플릿은 Linting이라고도 하는 정적 분석을 수행해야 합니다. Linting의 목표는 코드가 구문적으로 올바른지 여부를 결정하고, 잠재적인 오류를 식별하며, 특정 스타일 지침을 준수하는지 평가하는 것입니다. AWS CloudFormation에서 Linting은 템플릿이 JSON 또는 YAML에 올바르게 기록되었는지 확인합니다.
AWS CloudFormation은 검증을 제공합니다. JSON 또는 YAML 구문이 올바른지 확인하는 템플릿 API입니다. 확인이 실패하면 AWS CloudFormation은 템플릿 유효성 검사 오류를 반환합니다. 예를 들어 다음 명령을 실행하여 Amazon Simple Storage Service(Amazon S3)에 저장된 템플릿을 검증할 수 있습니다.
aws cloudformation validate-template — template-url \ s3://examplebucket/example_template.template
타사 검증 도구를 사용할 수도 있습니다. 예를 들어 cfn-nag는 잠재적인 보안 문제를 찾기 위해 템플릿에 대한 추가 평가를 수행합니다.
또 다른 도구인 cfn-check는 리소스 사양을 자세히 검사하여 스택 생성 중에 잠재적인 오류를 식별합니다.
모범 사례
AWS CloudFormation 사용자 설명서는 AWS CloudFormation 템플릿을 설계 및 구현하기 위한 모범 사례 목록을 제공합니다. 아래에서는 이러한 사례에 대한 링크를 제공합니다.
계획 및 구성
· Organize Your Stacks By Lifecycle and Ownership
· Reuse Templates to Replicate Stacks in Multiple Environments
· Use Nested Stacks to Reuse Common Template Patterns
· Use Cross-Stack References to Export Shared Resources
템플릿 만들기
· Do Not Embed Credentials in Your Templates
· Use AWS-Specific Parameter Types
· Use AWS::CloudFormation::Init to Deploy Software Applications on Amazon EC2 Instances
· Use the Latest Helper Scripts
· Validate Templates Before Using Them
· Use Parameter Store to Centrally Manage Parameters in Your Templates
스택 관리
· Manage All Stack Resources Through AWS CloudFormation
· Create Change Sets Before Updating Your Stacks
· Use AWS CloudTrail to Log AWS CloudFormation Calls
· Use Code Reviews and Revision Controls to Manage Your Templates
· Update Your Amazon EC2 Linux Instances Regularly
정리
정보 리소스 라이프사이클은 리소스의 프로비저닝에서 시작됩니다. AWS CloudFormation은 생성 프로세스 중에 인프라를 생성하고 리소스 간의 종속성을 관리하는 템플릿 기반 방법을 제공합니다. AWS CloudFormation을 사용하면 애플리케이션 소스 코드와 마찬가지로 인프라를 유지할 수 있습니다.
AWS는 IT 인프라 비용을 절감하고 기업의 핵심가치에 더욱 집중할 수 있도록 합니다.
AWS에 대한 자세한 문의사항은 여기를 눌러 주세요.
빌드업웍스는 AWS 컨설팅 파트너로 고객 비즈니스를 최우선으로 하며 고객의 클라우드의 성공적인 시작과 운영을 지원합니다.
