코드형 인프라스트럭처

3. 접근 방식

코드형 인프라(IaC)에는 일반적으로 선언적 (함수형) 대 명령형 (절차적) 두 가지 접근 방식이 있다. 선언적 접근 방식과 명령형 접근 방식의 차이점은 본질적으로 '''무엇''' 대 '''어떻게'''이다. 선언적 접근 방식은 최종 대상 구성을 '''무엇'''으로 할지를 강조하는 반면, 명령형 접근 방식은 이러한 목표를 달성하기 위해 인프라를 '''어떻게''' 변경할 것인지에 초점을 맞춘다. 선언적 접근 방식은 원하는 상태를 정의하고 시스템이 해당 원하는 상태를 달성하기 위해 필요한 작업을 실행한다. 명령형 접근 방식은 원하는 결과를 얻기 위해 적절한 순서로 실행해야 하는 특정 명령을 정의한다.^[18]

선언적 프로그래밍 (기능적), 명령형 프로그래밍 (절차적), 그리고 인텔리전트(환경 인식)의 3가지 IaC 접근 방식이 있다. 이들의 차이는 "무엇"을, "어떻게"와 "왜"의 차이와 같다.^[18]

3. 1. 선언적 접근 방식 (Declarative)

3. 2. 명령형 접근 방식 (Imperative)

3. 3. 인텔리전트 접근 방식 (Intelligent)

4. 방법론

IaC(코드형 인프라스트럭처)는 서버 설정을 위해 '푸시' 방식과 '풀' 방식을 활용한다.^[7]
푸시 방식코드형 인프라(IaC)를 사용하면 코드를 사용하여 서버와 해당 구성을 관리할 수 있다. 이러한 구성을 서버로 보내는 방법에는 '푸시 방식'과 '풀 방식'이 있다.^[7] 푸시 방식에서는 중앙 제어 시스템이 대상 서버에 직접 구성을 적용한다.^[7] Ansible, Terraform 등이 주로 사용하는 방식이다.
풀 방식풀 방식에서는 대상 서버가 중앙 제어 시스템에서 구성을 가져와 적용한다.^[7] 셰프(Chef)나 퍼펫(Puppet)등이 주로 사용하는 방식이다.
모듈화인프라스트럭처를 프로그래밍 언어의 모듈과 유사하게 여러 개의 묶음으로 분할하여 관리할 수 있다. 하나의 인프라스트럭처를 몇 개의 묶음으로 분할하고 각 묶음에 대한 설정 파일을 준비한다. 설정 파일 간의 읽기 시스템, 즉 모듈 import 메커니즘을 통해 모듈 단위로 인프라스트럭처를 관리하고 이를 조합하여 인프라스트럭처 전체를 구성할 수 있다. 예를 들어 AWS CloudFormation에서는 ''스택(stack)''을 모듈 단위로 하여 모듈을 읽어 들이는 메커니즘(''Nested Stacks'')이 정비되어 있다.^[19]
자동 생성코드형 인프라스트럭처 사상에 따라 프로그래밍에서 코드 자동 생성과 유사한 '''자동 생성'''을 인프라스트럭처에도 도입할 수 있다. IaC를 통해 인프라스트럭처 프로비저닝은 코드로 실행된다. 따라서 이 프로비저닝 코드 자체를 자동 생성할 수 있다면, 일종의 인프라 설계를 자동화할 수 있다.^[20]

API 개발에서는 스키마에서 프론트엔드 코드, 서버 스텁을 자동 생성하는 기술(cf. 스키마 주도 개발)이 존재한다. 일반적으로 서버 자체는 수동으로 시작되거나 IaC 기술을 사용하여 프로비저닝 코드로 자동 구성된다. 그러나 스키마를 기반으로 '''프로비저닝 코드를 자동 생성'''할 수 있다면, 생성된 코드를 통해 인프라 자동 프로비저닝까지 수행할 수 있다. 예를 들어 아마존 웹 서비스(Amazon Web Services) Amplify에서는 GraphQL 스키마를 정의함으로써 스키마에 맞는 GraphQL API 및 백엔드 데이터베이스의 프로비저닝 코드(AWS CloudFormation Templates)를 자동 생성하여 그대로 AWS에 배포할 수 있다.^[20]

이 자동 생성은 IaC 사상에 기반한 "프로비저닝 코드"가 존재하기 때문에 가능해진 기술이다. 이처럼 인프라스트럭처를 코드로 취급함으로써 다양한 소프트웨어 개발 기법을 인프라스트럭처 개발에 도입할 수 있다.^[20]

4. 1. 푸시 방식

4. 2. 풀 방식

4. 3. 모듈화

4. 4. 자동 생성

5. 도구

인프라 자동화 기능을 수행하고 IaC를 사용하는 도구는 많다. 일반적으로, 프로그래밍 방식을 기반으로 선언적 또는 명령적으로 인프라를 변경하거나 구성하는 모든 프레임워크나 도구는 IaC로 간주될 수 있다.^[8] 전통적으로, 서버 (라이프사이클) 자동화 및 구성 관리 도구는 IaC를 수행하는 데 사용되었다. 현재 기업들은 또한 마이크로소프트의 PowerShell DSC^영어[9]나 AWS CloudFormation과 같은 지속적인 구성 자동화 도구나 독립형 IaC 프레임워크를 사용하고 있다.^[10][21]

지속적 구성 자동화 (CCA) 도구는 기존의 IaC 프레임워크를 확장한 것으로 볼 수 있다. IaC를 활용하여 인프라를 변경, 구성 및 자동화하며, 인프라 관리 방식에 대한 가시성, 효율성 및 유연성을 제공한다. 이러한 추가 속성은 엔터프라이즈 수준의 보안 및 규정 준수를 지원한다.

가트너(Gartner)는 CCA 도구의 가치가 "자동화 도구의 상업적 성숙도와 성능만큼이나 사용자 커뮤니티가 기여한 콘텐츠와 지원에 달려 있다"고 언급했다.^[2] 퍼펫(Puppet) 및 셰프(Chef)와 같은 기존 공급업체는 자체 커뮤니티를 만들었다. 셰프는 셰프 커뮤니티 저장소(Chef Community Repository)를 가지고 있으며 퍼펫은 퍼펫포지(PuppetForge)를 가지고 있다.^[11]

5. 1. 지속적 구성 자동화(Continuous Configuration Automation, CCA) 도구

5. 1. 1. 커뮤니티 콘텐츠

5. 1. 2. 주요 CCA 도구

5. 2. 기타 도구

6. 데브옵스와의 관계

코드형 인프라(IaC)는 데브옵스(DevOps)의 모범 사례를 실현하는 핵심 요소 중 하나이다. 개발자는 구성 정의에 더 많이 관여하게 되고, 운영팀은 개발 프로세스에 더 일찍 참여하게 된다.^[12] IaC를 활용하는 도구는 서버의 상태와 구성을 가시화하고 궁극적으로 기업 내 사용자에게 가시성을 제공하여 팀 간의 협력을 통해 노력을 극대화하는 것을 목표로 한다.^[13]

일반적으로 자동화는 수동 프로세스의 혼란과 오류 발생 가능성을 제거하고 효율성과 생산성을 높이는 것을 목표로 한다. 유연성, 다운타임 감소, 전반적인 비용 효율성을 통해 더 나은 소프트웨어와 애플리케이션을 만들 수 있도록 한다. IaC는 수동 구성으로 인해 발생하는 비효율성을 줄이는 데 목적이 있다. 자동화와 협업은 데브옵스의 핵심 요소로 간주되며, 인프라 자동화 도구는 종종 데브옵스 툴체인의 구성 요소로 포함된다.^[14]

7. 보안과의 관계

팔로알토 네트웍스의 사이버 보안 제공업체 유닛 42의 위협 인텔리전스 부서에서 발표한 2020년 클라우드 위협 보고서에 따르면, 코드형 인프라스트럭처 템플릿에서 약 20만 개의 잠재적인 취약점이 발견되었다.^[15] IaC 도입 시 보안 검토 및 취약점 분석을 수행하고, 보안 모범 사례를 적용해야 한다.

참조

_[1] 학술지 Disruptive Technologies: Catching the Wave
_[2] 보고서 Innovation Insight for Continuous Configuration Automation Tools http://www.gartner.c[...] 2015-08-26
_[3] 학술지 Version Your Infrastructure https://devops.com/v[...] 2015-11-12
_[4] 웹사이트 Moving from Infrastructure Automation to True DevOps http://devops.com/20[...] 2015-05-14
_[5] 웹사이트 Declarative v. Imperative Models for Configuration Management: Which Is Really Better? https://www.scriptro[...] 2015-12-14
_[6] 간행물 Choosing between the leading open source configuration managers http://www.admin-mag[...] Linux New Media USA LLC 2014-11-14
_[7] 웹사이트 Puppet vs. Chef vs. Ansible vs. Salt http://www.networkwo[...] Network World 2015-12-14
_[8] 보고서 Garner Market Trends: DevOps – Not a Market, but Tool-Centric Philosophy That supports a Continuous Delivery Value Chain Gartner 2015-02-18
_[9] 간행물 DevOps, Infrastructure as Code, and PowerShell DSC: The Introduction http://www.powershel[...] PowerShell Magazine 2016-01-11
_[10] 웹사이트 Introducing AWS CloudFormation https://aws.amazon.c[...]
_[11] 웹사이트 Puppet or Chef? https://philsturgeon[...] 2016-01-29
_[12] 웹사이트 Continuous Integration: Infrastructure as Code in DevOps http://info.easydyna[...] 2016-01-29
_[13] 보고서 Infrastructure As Code: Fueling the Fire for Faster Application Delivery Forrester 2015-03
_[14] 보고서 Emerging Technology Analysis: DevOps a Culture Shift, Not a Technology Gartner
_[15] 웹사이트 Cloud Threat Report Shows Need for Consistent DevSecOps https://www.informat[...] 2020-02-24
_[16] 서적 Amazon Web Services in Action Manning Press
_[17] 웹사이트 Version Your Infrastructure http://devops.com/20[...] 2015-11-12
_[18] 간행물 Choosing between the leading open source configuration managers http://www.admin-mag[...] Linux New Media USA LLC 2014-11-14
_[19] 문서 AWS User Guide https://docs.aws.ama[...]
_[20] 문서 GraphQL Transform. Amplify JavaScript. https://aws-amplify.[...]
_[21] 간행물 DevOps, Infrastructure as Code, and PowerShell DSC: The Introduction http://www.powershel[...] PowerShell Magazine 2016-01-11
_[22] 보고서 Emerging Technology Analysis: DevOps a Culture Shift, Not a Technology Gartner
_[23] 서적 Amazon Web Services in Action https://archive.org/[...] Manning Press