초보자도 이해하는 AWS와 IaC 이야기

안녕하세요 클래스메소드의 수재입니다.

올해 7월에 2022 developersIO 2022가 개최됩니다.
올해도 비디오 세션을 하나 준비하게 되어서 AWS와 IaC에 대해 발표하려 합니다.
이 글에서는 해당 영상을 준비하기 위해 자료 수집한 내용을 정리하고자 합니다.

목차

• AWS와 IaC에 대하여
• IaC 툴의 특성
• 각 툴의 비교
• 나는 어떤 툴을 써야할까?

AWS와 IaC에 대하여

IaC

코드형 인프라(Infrastructure as Code, IaC)는 수동 프로세스가 아닌 코드를 통해 인프라를 관리하고 프로비저닝하는 것을 말합니다. - RedHat

인프라 스트럭쳐를 수동으로 작성하는 것이 아니라 코드로 작성하고 관리하는 것을 말합니다.
AWS로 예를 들자면 콘솔 화면에서 클릭하며 리소스를 생성하는 것이 아니라 IaC 도구를 이용하여 모든 리소스를 관리할 수 있게 됩니다.

좀 더 자세히 보자면 IaC는 데브 옵스 소프트웨어 개발부터 인프라 관리까지 모범 사례를 적용하는 것 것입니다.¹
그렇게 되면 신속한 인프라 구성이나 효율적인 관리가 가능해지며 마지막에는 자동화까지 이루어 지는 것입니다.
이러한 목적을 가진 IaC로 인프라를 구축하면 다음과 같은 메리트가 있습니다.

• 배포 속도 향상
• 유연성 확보
• 일관성 확보
• 지속적 관리
• 오류 감소

한번 코드를 작성한 후에는 같은 내용의 리소스를 몇 번이라도 재작성 할 수 있으며 필요에 따라 간단히 값만 바꾸는 식으로도 활용할 수 있습니다.
또한 CD/CD 툴과 함께 이용하는 경우 코드만 이해한다면 인프라의 지속적인 관리도 가능합니다.
그리고 리소스 간 의존성이나 설정 문제도 쉽게 파악할 수 있기 때문에 오류의 감소라는 효과도 있습니다.

정리하자면 환경을 IaC로 구축한다면 인프라 관리의 효율이 올라가고 빠르게 배포 할 수 있게 됩니다.

AWS와는 무슨 관계가 있는가?

AWS 리소스를 생성하기 위해선 웹 브라우저의 콘솔 화면에서 직접 생성하거나 AWS CLI의 스크립트를 이용하는 방법이 있습니다.
그리고 코드로 리소스를 작성하는 방법도 있습니다.

필요한 리소스를 손으로 배포하는 것은 해당 리소스에 대해서만 알면 되기 때문에 러닝 커브는 낮아집니다.
하지만 배포한 어플리케이션의 수정, 전체적인 리소스의 파악, 보안적인 측면 등 인프라의 관리에 대한 장기적인 관점으로는 불편한 점이 많습니다. 현재 사용되고 있는 IaC 제품들은 대부분 AWS에 대해 지원하고 있습니다. 그래서 인프라를 코드로 관리하여 IaC의 메리트들을 그대로 활용할 수 있습니다.

IaC 툴의 특성

여러가지 IaC 툴들의 주요한 차이점으로는 다음과 같습니다.
사용할 툴을 검토할 때 이러한 차이점을 잘 파악해두는 것이 좋습니다.

Language

여기서 말하는 Language는 파일의 작성 언어가 아닌 인프라를 정의하는 형태에 대해 말합니다.
IaC의 툴마다 선언형과 절차형으로 접근 방식이 다릅니다. 둘 다 지원하는 경우도 있고 하나만 지원하는 경우도 있습니다.
프로그래밍에 대해 잘 아시는 분은 이에 대해 잘 아시겠지만 간략히 설명하자면 다음과 같습니다.

• 선언형
  • 생성할 목표(생성할 리소스)에 대해 명시하면 툴이 알아서 처리
• 절차형
  • 목표를 생성하기 위한 모든 절차에 대한 스크립트(명령어)를 작성하면 툴이 해당 순서대로 처리

선언형은 목표하는 리소스만 기재하면 되기 때문에 관리가 쉬워집니다.
절차형의 경우 해당 과정까지 상세하게 알아야 할 필요가 있지만 그만큼 더 꼼꼼하게 체크할 수 있는 장점이 있습니다.

Infrastructure

리소스를 생성한 후 해당 리소스를 변경할 수 있는 툴(변경 가능, mutable)과 아닌 툴(변경 불가능,immutable)이 있습니다.

변경할 수 있는 경우엔 프로비저닝 된 리소스에 변경 사항이 있다면 다시 프로비저닝 할 필요 없이 변경 사항을 적용할 수 있어서 신속한 대응이 가능해집니다. 하지만 업데이트가 이어진다면 관리의 난이도가 올라가게 됩니다.
변경할 수 없는 경우엔 프로비저닝 된 리소스에 변경 사항이 있다면 새로운 리소스를 프로비저닝하게 됩니다. 하지만 인프라의 일관성이나 종속성을 확보하기 쉬워서 비교적 관리가 쉬워집니다.

Type

IaC 툴을 이용하면 인프라를 프로비저닝하고 관리할 수 있습니다. 각 툴들은 하나의 기능만을 하는 것이 아니라 툴에 따라서 그 이상의 기능을 모두 가지고 있을 수 있지만 [어느 영역에 더 적합한가]는 확인할 필요가 있습니다.

• 프로비저닝 툴(Orchestration)
  • 서버(VM), 네트워크, 데이터 베이스 등 인프라 리소스의 생성에 초점
• 구성 관리 툴(Configuration Management)
  • 컴퓨터 시스템, 서버 및 소프트웨어를 성능 상태로 설정하고 유지 관리하는 것에 초점

Architecture

일부 IaC툴은 명령을 실행하기 위해 인프라 상태를 관리하는 일종의 마스터 서버를 실행해야합니다.
마스터 서버에서 다른 관리 대상 서버에 작업을 실행시키거나 관리 대상 서버가 마스터 서버에서 최신 업데이트를 가져오거나 합니다.

이런 마스터 서버가 있는 툴을 이용하면 중앙 집중식으로 인프라를 관리할 수 있고 덕분에 진행 상황도 한눈에 파악할 수 있는 장점이 있습니다.
하지만 배포를 위한 서버가 필요하단 점이나 마스터 서버를 위한 로깅, 모니터링, 보안 등을 구려해야 하는 단점도 있습니다.

Agent-Agentless

일부 툴은 관리하는 모든 서버에 에이전트를 설치할 필요가 있습니다.
이러한 에이전트가 필요한 툴의 경우에는 마스터 서버의 경우와 마찬가지로 모니터링이나 보안 등을 고려할 필요가 있습니다.

각 툴의 비교

수 없이 많은 IaC 툴 중에서 AWS와 관련하여 많이 언급되고 사용되는 아래 5가지 툴에 대해 간략하게 소개하겠습니다.

• Terraform
• CloudFormation
• Ansible
• Chef
• Puppet

어디까지나 참고로서 각 툴의 최근 1년 관심도를 보면 다음과 같습니다.

Terraform

공식페이지

인프라를 프로비저닝하는 것이 목적인 프로비저닝 툴이며 이며 2022년 6월 기준 버전 4까지 공개되어 있습니다. 사용자는 HCL이라는 언어로 필요한 인프라를 구축할 수 있습니다. 선언형의 툴이기 때문에 인프라의 최종 결과물만 정의한다면 알아서 진행됩니다.
AWS, Azure, GCP, Kubernates 등 1700개 이상의 다양한 서비스²를 구성할 수 있으며 이러한 서비스의 API를 추상화한 provider를 정의하여 인프라를 구성할 수 있습니다.
출처 : terraform 공식 페이지

인프라의 작성은 코드 작성 - 계획(plan) - 적용(apply)의 순서를 따릅니다.
작성한 코드는 plan 명령어를 실행하여 예상 결과를 확인합니다. 문제가 없다면 apply 명령어를 실행하여 인프라를 생성할 수 있습니다.
이렇게 작성한 리소스의 상태는 상태 파일(state file)에 저장되어 실제 리소스를 추적할 수 있도록 구성됩니다.
Terraform은 불변(immutable)으로 리소스를 관리하기 때문에 작성했던 인프라의 코드를 변경하여 다시 프로비저닝하면 새롭게 인프라가 생성됩니다.

Terraform을 실행하기 위해 별도의 에이전트를 각 서버에 다운로드 할 필요는 없습니다. 또한 프로비저닝 된 리소스를 관리하는 마스터 서버도 없어도 됩니다.
로컬에서 조작하는 서버에 클라이언트만 인스톨하면 됩니다.

특징으로는 plan - apply - destroy의 사이클이나 모듈화나 상태 파일의 이용 등이 있습니다.
Terraform은 기본적으로 프로비저닝 툴이기 때문에 구성 관리가 필요하다면 부트스트랩 소프트웨어를 구성하여 첫 시스템을 부팅 할 때 구성 관리를 활성화 할 수 있습니다.

AWS에서 코드로 인프라를 관리할 때는 프로비저닝 툴로써 CloudFormation나 Terraform을 사용하는 경우가 많습니다.

즉, HCL이라는 언어로 인프라를 정의하며 다양한 서비스에 대해 대응할 수 있는 프로비저닝(오케스트레이션)툴 입니다.

CloudFormation

공식페이지

AWS에서 제공하고 있는 서비스이자 프로비저닝 툴입니다. yaml이나 json 형식으로 리소스를 정의하여 AWS 콘솔 및 CLI로 해당 파일을 읽으면 인프라가 프로비저닝됩니다.
선언형 툴이기 때문에 프로비저닝 하려는 리소스만 정의하면 됩니다.
서비스에 따라 재작성 없이 변경되거나 재작성되거나 합니다.

작성한 인프라는 CloudFormation 서비스에서 stack이란 단위로 관리됩니다.
만약 필요하다면 AWS에서 제공하고 있는 designer를 이용하여 콘솔에서 템플릿을 작성하거나 수정할 수 있습니다.
또한 만약 AWS에서 기존 서비스를 변경하더라도 CloudFormation으로 작성한 리소스와는 호환이 되도록 높은 수준의 보증을 제공합니다.
그리고 AWS의 서비스에 대해 가장 빠르게 지원하는 툴이기도 합니다.

정리하자면 yaml 및 json으로 파일을 작성하며 AWS만을 위한 툴이자 서비스이고 AWS 이외의 서비스는 지원하지 않지만 AWS에서 높은 수준의 보증을 제공하는 툴 입니다.
따라서 다른 서비스와 활용하는 경우에는 선택하기 까다로운 툴입니다.

Ansible

공식페이지

현재는 Redhat이 인수한 오픈 소스 프로젝트로 제공되고 있는 툴이며 2022년 6월기준 버전 5까지 공개되어 있습니다. 구성 관리를 중점으로 하고 있으며 플레이북(playbook)이라는 yaml 확장자의 파일에 태스크를 지정하여 인프라를 관리합니다.
절차형의 특성을 가진 툴³ 때문에 필요한 태스크의 내용 뿐만 아니라 순서도 정의하여야 됩니다.

Ansible이 설치된 컨트롤 노드(Control node)에서 에이전트 없이 SSH로 직접 관리할 관리 노드(managed nodes)⁴에 접속하여 조작합니다.
이러한 관리 노드의 목록은 인벤토리(inventory)로 관리합니다.
수행할 명령은 모듈(modules)이라고 불리며 이러한 모듈(즉, 실행할 작업들을)은 작업(task)으로 정의됩니다.
이러한 작업들은 플레이북(playbook)에 정의되어 결과적으로 이 플레이북을 참고하여 노드에 대한 관리가 이루어집니다.

정리하자면 플레이북에 YAML 방식으로 코드를 정의하며 중앙에서 인프라를 관리할 수 있는 설정 관리 툴 입니다.

AWS의 특정 리소스들을 관리하기 위해서 Ansible을 채택할 수 있습니다. EC2를 예로 들자면 컨트롤 노드에서 SSH로 직접 접속하여 관리할 수도 있지만 AWS System Manager를 이용하여 플레이북을 실행할 수 도 있습니다.⁵

Chef(progress chef)

공식페이지

Ruby 및 Erlang 으로 작성된 구성 관리 툴입니다. 사용자는 Ruby DSL(domain-specific language)라는 언어를 사용하여 쿡북(cookbook)에 구성 및 유지 관리 작업을 정의합니다.
절차형 툴⁶이며 적용 순서 등도 정의합니다. 따라서 최적의 배포 순서는 사용자에게 맡기게 됩니다.

chef infra의 요소 간 관계(출처: 공식페이지)

Chef에서는 레시피(recipe)에 구성 요소를 정의합니다. 그리고 구성 및 정책 배포 등의 관리 방법을 쿡북에 정의합니다.
이 쿡북에 레시피나 파일, 메타 데이터 등을 정의하여 노드를 관리하게 됩니다.
이러한 쿡북의 작성은 Chef 워크스테이션(workstation)에서 작업하게 됩니다. 워크스테이션에서 검증이 끝나면 Chef Server를 통하여 쿡북을 배포하게 됩니다.⁷
관리 대상의 노드에 Chef client라는 에이전트를 설치할 필요가 있습니다. 설치된 Chef client는 Chef server에서 cookbook을 가지고 와서 해당 구성을 실행합니다. 서버와 에이전트는 SSL 인증서를 가지고 HTTPS로 통신합니다.

AWS OpsWorks for Chef Automate를 이용하면 Chef 서버의 관리를 AWS에 맡길 수 있습니다.⁸

정리하자면 RubyDSL로 절차적으로 구성을 작성하고 관리 대상을 나누어 구성을 관리하는 툴 이겠네요.

Puppet

공식 페이지

Ruby로 작성된 구성 관리 툴입니다. 사용자는 Puppet의 DSL인 Puppet Langage로 구성을 정의합니다.
선언형 툴이기 때문에 필요한 인프라만 정의하면 됩니다.

Puppet의 실행 순서(출처: 공식페이지)

Puppet은 코드를 저장 및 관리, 실행하기 위해 Puppet Platform 이라는 패키지 그룹이 사용됩니다. 이러한 패키지에는 Puppet Server, Puppet DB 및 Puppet-agent(Facter 및 Hiera 포함)가 포함되어 있습니다.
Puppet은 관리하려는 대상 노드에 에이전트를 설치하여 중앙 서버에서 관리하는 서버-에이전트의 구성을 가집니다. 따라서 원하는 구성을 정의한 파일을 Puppet Server에 코드로써 저장하면 Puppet-agent가 코드를 명령으로 변환하여 작업을 수행하게 됩니다.
퍼펫 서버가 에이전트의 Facter로 호스트명, IP주소, OS 등 관리에 필요한 정보를 수집합니다. 수집이 끝났다면 원하는 상태를 정의한 카탈로그(Catalog)라는 JSON 파일을 에이전트 노드에서 읽고 구성을 변경하게 됩니다. 이후 에이전트 노드에서는 보고서(report)를 Puppet Server에 송신합니다.

AWS OpsWorks for Puppet Enterprise를 이용하면 AWS 인프라에서 Puppet Enterprise 를 구성하고 실행할 수 있습니다.⁹

정리하자면 Puppet Langage를 이용한 선언형 구성 관리 툴입니다.

특성 정리

툴의 특성을 정리하자면 다음과 같습니다

나는 어떤 툴을 써야할까?

AWS와 함께 쓰이는 툴을 간략하게 알아보았습니다.
찾아보면 오늘 소개한 툴 이외에도 수많은 툴이 공개되어 있습니다.

또한 각 툴의 상세정보까지 확인해보면 프로비저닝툴이 구성 관리까지 지원하는 경우도 있습니다.
이렇게 많은 툴 중에 무엇을 써야할까요?

개인적으로는 다음과 같은 항목들을 고려할 필요가 있다고 생각합니다.

• 결과물(=목표)
• 툴의 장단점 파악
• 요소 판단
• 비용

우선 목표를 확실히 할 필요가 있습니다.
단순히 리소스의 프로비저닝만을 목표로 하는지, 아니면 프로비저닝 후 어플리케이션의 확실한 관리도 필요한지 등을 고려한 후 툴을 선정할 필요가 있습니다.
이에 따라 한 가지 툴 혹은 여러 툴(Terraform과 Ansible을 함께 사용하는 등)을 복합적으로 사용할 수도 있습니다.
또한 작성 및 관리하려는 리소스-인프라에 대해 해당 툴의 지원 여부도 확인 할 필요가 있습니다.

목표에 맞춘 여러 툴을 선정했다면 장단점을 파악할 필요가 있습니다.
이 글에서는 툴에 대해 간략하게 소개했지만 각자 장단점이 있습니다.
구조적인 장단점 뿐만 아닌 사용 언어 등 여러 이유로 인한 러닝 커브 또한 고려해야합니다.

보안, 재해 복구, 가용성, 서포트 대응, 커뮤니티 등 필요 요소에 대해서도 고려해야합니다.
판단이 필요한 요소를 정의한 후 우선순위를 정하여 사용할 수 있는 툴을 선정합니다.

엔터프라이즈 대응이 필요하다면 비용도 고려할 필요가 있습니다.
엔터프라이즈급 규모에서 툴을 도입하는 경우에는 엔터프라이즈 서포트를 받는 것이 프로젝트에 소요되는 리소스를 줄일 수 있을 뿐더러 예상치 못한 이슈에 쉽게 대응할 수 있는 길로도 이어집니다.

최종 목표는 자동화

서두에 작성했듯이 IaC의 최종적인 목표는 공정의 자동화에 있습니다.¹⁰

각 단계에 따라 각기 다른 도구들이 사용되고 있습니다

각 스테이지에서 사용될 수 있는 툴은 수없이 많습니다.
개발자 및 관리자는 이 중에서 가장 적합한 툴을 적용하여 영향이 큰 선택 이외에는 필요한 부분의 코드만 수정하는 것으로 마지막 스테이지까지 자동화를 구축하는 것이 효율적인 경우가 많습니다.
이를 위해 단순히 인프라의 프로비저닝, 구성 관리뿐만 아니라 코드의 작성부터 어플리케이션 및 서버의 모니터링-리포트까지 필요한 부분을 점차 자동화해나가는 것을 추천합니다.

마무리

초보자를 위한 이라고 적었는데 많은 부분을 살짝씩만 소개하다보니 글이 많이 길어졌네요..
오늘 소개한 글은 IaC는 이런 느낌이구나~ 툴은 이런 곳에 쓰는구나~ 정도만을 소개하였습니다.
본인에게 필요한 툴의 상세 내용까지 조사해보는 것을 추천드립니다.

긴 글 읽어주셔서 감사합니다.
오탈자 및 내용 피드백은 언제나 환영합니다. must01940 지메일로 연락 주시면 감사합니다!

본 블로그 게시글을 보시고 문의 사항이 있으신 분들은
클래스메소드코리아 (info@classmethod.kr)로 연락 주시면 빠른 시일 내 담당자가 회신 드릴 수 있도록 하겠습니다 !