코드형 인프라스트럭처

1. 개요

코드형 인프라스트럭처(IaC)는 유틸리티 컴퓨팅과 2세대 웹 프레임워크의 문제에 대한 대응으로 등장하여, 인프라를 코드처럼 모델링하고 관리하는 방식이다. IaC는 애플리케이션 배포 속도를 높이고, 소프트웨어 개발자와 IT 관리자 모두에게 인프라 관리 방식을 혁신적으로 변화시켰다. IaC는 선언적, 명령형, 인텔리전트 접근 방식을 가지며, 푸시 및 풀 방식의 방법론을 사용한다. IaC 도구로는 Ansible, Terraform, Puppet, Chef 등이 있으며, 데브옵스 모범 사례를 실현하는 핵심 요소로 보안 검토 및 취약점 분석을 통해 보안을 강화해야 한다.

2. 역사

유틸리티 컴퓨팅과 2세대 웹 프레임워크가 제기한 어려움에 대한 대응으로 IaC(코드형 인프라스트럭처)가 성장했다. 2006년 아마존 웹 서비스(AWS)의 탄력적 컴퓨팅 클라우드(EC2) 출시와 루비 온 레일스 1.0 버전 출시는 대기업에서만 경험했던 광범위한 확장 문제를 기업 전반으로 확산시켰다. 이러한 변화는 IT 인프라 관리 방식을 혁신적으로 변화시킬 필요성을 제기했고, IaC는 이러한 요구에 대한 해결책으로 등장했다. 코드로 인프라를 모델링하고, 알려진 소프트웨어 모범 사례를 사용하여 애플리케이션 인프라를 설계, 구현, 배포할 수 있다는 아이디어는 소프트웨어 개발자와 IT 인프라 관리자 모두에게 어필했다. 인프라를 코드처럼 취급하고 다른 소프트웨어 프로젝트와 동일한 도구를 사용할 수 있게 되면서 개발자는 애플리케이션을 빠르게 배포할 수 있게 되었다.

2.1. 배경

유틸리티 컴퓨팅과 2세대 웹 프레임워크가 제기한 어려움에 대한 대응으로 IaC(코드형 인프라스트럭처)가 성장했다. 2006년 아마존 웹 서비스(AWS)의 탄력적 컴퓨팅 클라우드(EC2) 출시와 루비 온 레일스 1.0 버전 출시는 대기업에서만 경험했던 광범위한 확장 문제를 기업 전반으로 확산시켰다. 이러한 변화는 IT 인프라 관리 방식을 혁신적으로 변화시킬 필요성을 제기했고, IaC는 이러한 요구에 대한 해결책으로 등장했다. 코드로 인프라를 모델링하고, 알려진 소프트웨어 모범 사례를 사용하여 애플리케이션 인프라를 설계, 구현, 배포할 수 있다는 아이디어는 소프트웨어 개발자와 IT 인프라 관리자 모두에게 어필했다. 인프라를 코드처럼 취급하고 다른 소프트웨어 프로젝트와 동일한 도구를 사용할 수 있게 되면서 개발자는 애플리케이션을 빠르게 배포할 수 있게 되었다.

2.2. 개념의 발전

코드형 인프라스트럭처(IaC)는 유틸리티 컴퓨팅과 2세대 웹 프레임워크가 제기한 어려움에 대한 대응으로 성장했다. 2006년 아마존 웹 서비스(AWS)의 탄력적 컴퓨팅 클라우드(EC2) 출시와 루비 온 레일스 1.0 버전 출시는 대기업에서만 경험했던 광범위한 확장 문제를 기업 전반으로 확산시켰다. 코드로 인프라를 모델링하고, 소프트웨어 모범 사례를 사용하여 애플리케이션 인프라를 설계, 구현, 배포할 수 있다는 아이디어는 소프트웨어 개발자와 IT 인프라 관리자 모두에게 어필했다. 인프라를 코드처럼 취급하고 다른 소프트웨어 프로젝트와 동일한 도구를 사용할 수 있게 되면서 개발자는 애플리케이션을 빠르게 배포할 수 있게 되었다.

3. 접근 방식

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

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

3.1. 선언적 접근 방식 (Declarative)

선언적 접근 방식은 인프라의 최종 상태를 정의하고, 시스템이 이를 달성하기 위한 방법을 스스로 결정하도록 한다. 즉, "무엇(What)"을 원하는지에 초점을 맞춘다. 대표적인 도구로는 AWS CloudFormation, Terraform 등이 있다.

선언적 접근 방식과 명령형 접근 방식의 차이점은 본질적으로 무엇 대 어떻게이다. 선언적 접근 방식은 최종 대상 구성을 무엇으로 할지를 강조하는 반면, 명령형 접근 방식은 이러한 목표를 달성하기 위해 인프라를 어떻게 변경할 것인지에 초점을 맞춘다. 다시 말해, 선언적 접근 방식은 원하는 상태를 정의하고 시스템이 해당 원하는 상태를 달성하기 위해 필요한 작업을 실행한다.

3.2. 명령형 접근 방식 (Imperative)

명령형 접근 방식은 원하는 결과를 얻기 위해 적절한 순서로 실행해야 하는 특정 명령을 정의한다. 인프라를 어떻게 변경할 것인지에 초점을 맞추며, 최종 대상 구성을 어떻게 달성할지를 강조한다. 대표적인 도구로는 Chef, Ansible 등이 있다.

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

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

동일한 인프라스트럭처에서 실행되는 여러 애플리케이션의 모든 상호 관계와 종속성을 고려하여, 최종적인 목표 설정이 특정 방식의 이유에 초점을 맞춘다. 상호 의존(공의존) 애플리케이션에 영향을 주지 않도록 시스템은 발생해야 하는 무언가를 처리하기 전에, 목표 상태를 결정한다. 환경을 인식하는 상태가 IaC의 차세대이다.

4. 방법론

IaC(코드형 인프라스트럭처)는 서버 설정을 위해 '푸시' 방식과 '풀' 방식을 활용한다.

푸시 방식

코드형 인프라(IaC)를 사용하면 코드를 사용하여 서버와 해당 구성을 관리할 수 있다. 이러한 구성을 서버로 보내는 방법에는 '푸시 방식'과 '풀 방식'이 있다. 푸시 방식에서는 중앙 제어 시스템이 대상 서버에 직접 구성을 적용한다. Ansible, Terraform 등이 주로 사용하는 방식이다.

풀 방식

풀 방식에서는 대상 서버가 중앙 제어 시스템에서 구성을 가져와 적용한다. 셰프(Chef)나 퍼펫(Puppet)등이 주로 사용하는 방식이다.

모듈화

인프라스트럭처를 프로그래밍 언어의 모듈과 유사하게 여러 개의 묶음으로 분할하여 관리할 수 있다. 하나의 인프라스트럭처를 몇 개의 묶음으로 분할하고 각 묶음에 대한 설정 파일을 준비한다. 설정 파일 간의 읽기 시스템, 즉 모듈 import 메커니즘을 통해 모듈 단위로 인프라스트럭처를 관리하고 이를 조합하여 인프라스트럭처 전체를 구성할 수 있다. 예를 들어 AWS CloudFormation에서는 스택(stack)을 모듈 단위로 하여 모듈을 읽어 들이는 메커니즘(Nested Stacks)이 정비되어 있다.

자동 생성
코드형 인프라스트럭처 사상에 따라 프로그래밍에서 코드 자동 생성과 유사한 자동 생성을 인프라스트럭처에도 도입할 수 있다. IaC를 통해 인프라스트럭처 프로비저닝은 코드로 실행된다. 따라서 이 프로비저닝 코드 자체를 자동 생성할 수 있다면, 일종의 인프라 설계를 자동화할 수 있다.

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

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

4.1. 푸시 방식

코드형 인프라(IaC)를 사용하면 코드를 사용하여 서버와 해당 구성을 관리할 수 있다. 이러한 구성을 서버로 보내는 방법에는 '푸시 방식'과 '풀 방식'이 있다. 푸시 방식에서는 중앙 제어 시스템이 대상 서버에 직접 구성을 적용한다. Ansible, Terraform 등이 주로 사용하는 방식이다.

4.2. 풀 방식

풀 방식에서는 대상 서버가 중앙 제어 시스템에서 구성을 가져와 적용한다. 셰프(Chef)나 퍼펫(Puppet)등이 주로 사용하는 방식이다.

4.3. 모듈화

인프라스트럭처를 프로그래밍 언어의 모듈과 유사하게 여러 개의 묶음으로 분할하여 관리할 수 있다. 하나의 인프라스트럭처를 몇 개의 묶음으로 분할하고 각 묶음에 대한 설정 파일을 준비한다. 설정 파일 간의 읽기 시스템, 즉 모듈 import 메커니즘을 통해 모듈 단위로 인프라스트럭처를 관리하고 이를 조합하여 인프라스트럭처 전체를 구성할 수 있다. 예를 들어 AWS CloudFormation에서는 스택(stack)을 모듈 단위로 하여 모듈을 읽어 들이는 메커니즘(Nested Stacks)이 정비되어 있다.

4.4. 자동 생성

코드형 인프라스트럭처 사상에 따라 프로그래밍에서 코드 자동 생성과 유사한 자동 생성을 인프라스트럭처에도 도입할 수 있다. IaC를 통해 인프라스트럭처 프로비저닝은 코드로 실행된다. 따라서 이 프로비저닝 코드 자체를 자동 생성할 수 있다면, 일종의 인프라 설계를 자동화할 수 있다.

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

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

5. 도구

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

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

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

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

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

모든 CCA 도구는 기존 IaC 프레임워크의 확장 기능으로 간주될 수 있다. IaC를 활용하여 인프라를 변경, 구성, 자동화할 수 있을 뿐만 아니라, 인프라 관리의 가시성, 효율성, 유연성도 제공한다. 이러한 추가 기능은 기업 수준의 보안과 컴플라이언스를 제공하므로, 기업들은 이러한 도구에 관심을 보이는 것으로 보인다.

5.1.1. 커뮤니티 콘텐츠

커뮤니티 콘텐츠는 오픈 소스 CCA 도구의 품질을 결정하는 핵심 요소이다. 가트너(Gartner)는 CCA 도구의 가치가 "자동화 도구의 상업적 성숙도와 성능만큼이나 사용자 커뮤니티가 기여한 콘텐츠와 지원에 달려 있다"고 언급했다. 퍼펫(Puppet) 및 셰프(Chef)와 같은 기존 공급업체는 자체 커뮤니티를 만들었다. 셰프는 셰프 커뮤니티 저장소(Chef Community Repository)를 가지고 있으며 퍼펫은 퍼펫포지(PuppetForge)를 가지고 있다. 다른 공급업체는 인접한 커뮤니티에 의존하고 PowerShell DSC와 같은 다른 IaC 프레임워크를 활용한다.

5.1.2. 주요 CCA 도구

구성 관리 도구는 전통적으로 서버 (라이프사이클) 자동화 및 IaC를 수행하는 데 사용되었다. 현재 기업들은 마이크로소프트의 PowerShell DSC나 AWS CloudFormation과 같은 지속적인 구성 자동화 도구나 독립형 IaC 프레임워크를 사용하고 있다.

인프라 자동화 기능을 수행하고 IaC를 사용하는 도구는 많다. 일반적으로, 프로그래밍 방식을 기반으로 선언적 또는 명령적으로 인프라를 변경하거나 구성하는 모든 프레임워크나 도구는 IaC로 간주될 수 있다.

5.2. 기타 도구

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

6. 데브옵스와의 관계

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

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

7. 보안과의 관계

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