[Ansible] #1.2 IaC 도구 및 특징 비교

in Study on Ansible
[Ansible] #1.2 IaC 도구 및 특징 비교

IaC 도구 및 특징을 비교해보자.
구성 관리 vs 배포 / 가변 vs 불변 / 절차적 vs 선언적 / 마스터 , 에이전트 유무


1. 구성 관리 / 배포

  • 구성 관리 도구 : Ansible, Chef, Puppet, SaltStack 등
  • 배포 도구 : AWS CloudFormation, OpenStack Heat, Terraform 등

구성 관리(Configuration Management) 도구는 베어메탈 시스템, 가상 컴퓨터 및 클라우드 인스턴스 내에서 패키지 설치, 애플리케이션 구성, 운영체제 관련 구성 및 구성 변경을 관리하는 도구다.

배포(Provisioning) 도구는 새로운 인프라 리소스를 배포하고 이미 배포된 인프라 리소스의 생명주기를 관리하는 도구다.

보통 인프라 리소스를 만든다고는 말 안하고, 배포라고 한다.

VM(EC2) 을 만드는건 배포 도구가 하는 것이고, apache, html 코드 등을 구성하는 것은 구성 관리라고 한다.

최근에는 구성 관리 도구 및 배포 도구의 기능상 차이를 정확히 구별하는 것이 점점 어려워지고 있다.

구성 관리 도구에 배포 도구의 기능이 추가된다거나, 반대의 경우가 많이 생기고 있기 때문이다.

2. 가변 인프라 / 불변 인프라

기존에 있던 전통의 인프라는 대부분 가변 인프라다.
우리가 일반적으로 가지고 있는 컴퓨터 등이 그러하다.
시간축에 비례하여 컴퓨터의 상태가 변하기 때문이다.

이 때 컴퓨터의 상태란 컴퓨터에 설치되어 있는 소프트웨어 등의 여부를 말한다.
프로그램이 설치되면 컴퓨터의 상태가 바뀐 것이라고 말할 수 있다.
비단 설치 뿐만 아니라 업데이트, 삭제 등도 당연히 포함된다.

일반적으로 가장 대표적인 가변 인프라는 데이터베이스이다.
데이터베이스의 DBMS의 업데이트 또한 맞지만, 내부의 데이터, 스키마는 수시로 바뀌기 때문이다.

우리가 직접 SQL 을 통해서 변경할 수도 있지만, 일반적으로 그에 연결된 웹 어플리케이션에 의해 변경되며, 이를 가변적이라고 한다.

이를 Stateful, 즉 상태 가변적이라고 한다.

최근의 인프라는 대부분이 가변적이지만, 우리는 불변(Immutable) 인프라를 지향한다.

불변 인프라는 클라우드 인스턴스의 이미지나 컨테이너의 이미지와 같이 변하지 않는 이미지를 배포하는 것과 같이 인프라가 배포된 후 절대로 변하지 않는 인프라를 일컫는다.

이를 Stateless, 상태가 없다고 말한다.

그럼 업데이트는 어떻게 하느냐 ?

배포된 인프라를 업데이트 하지 않고, 그대로 두며 새로운 버전의 인프라를 배포하는 형식이다.

가상화, 컨테이너, 클라우드 컴퓨팅이 널리 퍼지고 난 이후, 가상 서버 및 컨테이너는 비용이 저렴하고 유연한 확장이 가능하고, 생성부터 폐기까지 생명 주기가 몇 분 밖에 걸리지 않는다. 또한 교체가 가능하다.

대부분의 구성 관리 도구(Ansible 등) 은 가변 인프라에 초점을 맞추고 있고,

배포 도구(Teraform 등)은 불변 인프라에 초점을 맞추고 있다.

“The History of Pets vs Cattle and How to Use the Analogy Properly, Cloudscaling”

위 링크는 가변 인프라와 불변 인프라를 애완동물과 가축으로 비유한 글이다.

애완동물 → 가변 인프라(교체가 쉽지 않음)

가축 → 불변 인프라(얼마든지 교체 가능)

가축은 당연히 대체할 수 있지만, 동일한 성격, 동일한 스펙의 애완동물로 기존의 애완동물을 교체하기란 불가능하다.

3. 절차적 언어 / 선언적 언어

절차적 언어는 원하는 최종 상태에 도달하기 위해 코드가 단계별로 정의되고 실행하는 형태를 일컫는다.

대표적으로 Ansible 및 Chef 도구가 절차적인 형태를 따른다.

선언적 언어는 최종적으로 원하는 형태를 정의만 하면 필요한 절차는 내부적으로 알아서 진행되는 형태를 일컫는다.

대표적으로 AWS CloudFormation, OpenStack Heat, Puppet, SaltStack, Terraform 도구가 선언적인 형태를 따른다.

절차적인 언어 → 학생들에게 일일히 교실 청소의 순서를 지정해야함.

선언적인 언어 → 교실 청소하자 라고 지휘. 학생들이 알아서함. 물론 선생님이 내부적인 절차를 알고는 있어야함.

아파치를 설치 → 설정 파일 변경 → 서비스 재시작과 같은 순서 등을 지정해주는게 절차적.

무슨 언어가 좋냐? 이러한 물음은 의미가 없다.
절대 이분법적으로 나누면 안되고, 각자의 역할과 장점이 있는 것이다.

4. 마스터 및 에이전트 유무

대표적으로 Chef, Puppet, SaltStack 도구는 인프라의 정보와 구성 관리 및 배포를 위한 정보를 가지고 있는 마스터 서버가 있다.

마스터 서버가 있음으로 중앙 집중화된 관리 및 모니터링이 가능한 장점이 있지만, 추가적인 리소스의 필요, 마스터의 관리, 장애 등 단점도 존재한다.

Chef, Puppet, SaltStack 도구는 서버가 관리할 인프라에 에이전트 소프트웨어의 설치 및 관리도 필요하다.

즉 관리(마스터) 에서 타겟으로 에이전트(소프트웨어)를 보내서 관리하는듯.

다만 위 도구들이 무조건 마스터 를 가지는 것은 아니고, 마스터 없이 대상 인프라에서 스케줄러에 의해 독립적으로도 작동 가능하다.

중요!
Ansible 은 마스터, 에이전트를 사용하지 않는다.

요즘은 마스터 라는 용어 대신 Controller 라는 용어를 쓰자는 경향이 있는 듯 하다.

© 2022. All rights reserved.