[Terraform] 1장 Why Terraform? (terraform up&running 책 정리)
본 글은 Terraform Up& Running 책에 대하여 1장에 대한 내용 정리 글이다.
DevOps란
DevOps 정의
장애를 예측하기 위해 수없는 모의 시뮬레이션을 수행하는 조직이다. 규모가 작다면 개발팀에서 스스로 할 수 있겠지만 규모가 커질수록 ci/cd 변경 요구사항이나 인프라 관련 요구사항들을 다 커버할 수 없기에 시스템 복잡도도 늘어나고 컴플라이언스 요구사항도 까다로워지게 된다.
DevOps는 개발자가 프로덕션 환경에서 24시간 365일 서비스가 운영되도록 책임지게 하는 방법론이다. 개발과 운영을 병행 가능하게끔 높은 품질로 소프트웨어를 빠르게 개발하도록 지원하는 빌드, 테스트, 배포를 위한 자동화 환경을 말한다.
등장배경
(1) 과거에는 소프트웨어 개발팀(Dev)과 운영팀(Ops)이 분리되어 운영되어졌다. 개발팀은 애플리케이션을 개발하고, 운영팀은 이를 배포하고 하드웨어를 관리하는 이원화 체계가 일반적이였다.
(2) 그러나 시간이 지나게 되면서 수작업으로 이루어지는 배포와 운영방식은 수동 설정으로 인한 서버별 구성이 일치하지 않는 경우가 증가하였으며 운영 효율성 저하로 이어지게 되었다.
(3) DevOps는 이러한 문제를 해결하기 위해 개발과 운영 간의 경계를 허물고, Software delivery 프로세스를 효율적으로 만들기 위한 방법론이다. (정의에 대한 부분은 제각각 다르며 이 책에 한정하여 정의한 내용)
- 코드를 지속적으로 통합(CI)하여 항상 배포 가능한 상태 유지.
- 배포 속도를 높여 하루에도 여러 번, 또는 매 커밋마다 배포 가능하도록 설계
- self-healing 시스템과 모니터링 시스템 구축을 통한 문제를 사전에 방지
(4) DevOps는 CAMS(문화, 자동화, 측정, 공유)라는 핵심 가치를 지향한다. 이 책에서는 특히 자동화에 초점을 두며 코드방식으로 인프라를 관리함으로써 수동 작업을 줄이고, 안정적인 배포를 구현하는 방법에 대하여 초점을 둔다.
Infrastructure as Code(IaC)란?
IaC의 개념
- IaC는 인프라를 코드로 (1)정의 (2)배포 (3)업데이트 (4)삭제 와 같은 작업을 자동화하는 방법론이다.
- 이는 모든 운영 요소(서버, 데이터베이스, 네트워크 설정, 로그파일, 어플리케이션 설정 등)를 마치 소프트웨어처럼 코드 기반으로 운영하는 것을 의미한다.
IaC 도구는 넓게 아래와 같이 5가지 카테고리로 나뉘어지며, 이에 대하여 각 항목별로 살펴보자.
- Ad hoc scripts
- Configuration management tools
- Server templating tools
- Orchestration tools
- Provisioning tools
1. Ad Hoc Script
Ad Hoc Script는 특정 문제를 해결하거나 특정 작업을 수행하기 위해 빠르게 작성된 즉석 스크립트를 의미한다.
- 라틴어로 “for this particular purpose”에서 유래되었다. (Ad: “~를 위해(for)”, Hoc: “이것(this)”)
- 주로 개발 기간이 촉박하여 급하게 요구사항을 맞추기 위해 사용되어지며, 흔히 ‘하드코딩’이라 불리는 방법으로 만든 솔루션이다.
- 간단하지만 확장성과 유지보수가 어려운 특징을 지닌다.
2. 구성 관리 도구(Configuration management tools)
- 대표적으로 Chef, Puppet, Ansible이며 기존 서버에 툴을 설치하여 관리하는 특성을 지닌다.
- 이를 바탕으로 (1) 스크립트의 일관된 구조화, (2) 멱등성(Idempotent)의 성질을 지닌다. 여기서 멱등성이란, 연산을 여러 번 적용하더라도 결과가 달라지지 않는 성질, 즉, 연산을 여러 번 반복하여도 한 번만 수행된 것과 같은 성질을 의미한다.
- 아래는 Ansible 코드 예시이다.
- name: Update the apt-get cache
apt:
updateflcache: yes
- name: Install PHP
apt:
name: php
- name: Install Apache
apt:
name: apache2
- name: Copy the code from the repository
git: repo=https://github.com/brikis98/php-app.git
dest=/var/www/html/app
- name: Start Apache
service: name=apache2 state=started enabled=yes
3. 서버 템플릿 도구(Server Templating)
대표적으로 대중적으로 많이 사용되는 도구는 Docker, Packer, Vagrant 같은 도구이며 이를 통해 서버의 전체 상태(OS, 소프트웨어 등)를 이미지화한다.
- 인프라 불변(Immutable Infrastructure) 접근 방식이다. 이를 풀어서 기술하면 서버는 배포 후 변경되지 않으며, 업데이트가 필요하면 새로운 이미지를 생성하고 새 서버에 배포하는 방식이다.
- 서버 정보를 명확히 정의함으로써 신규서버를 보다 빠르고 쉽게 프로비저닝을 가능하게 한다.
- 서버 템플릿 도구는 크게 가상머신(VM)과 컨테이너(Container) 두 분야로 나뉘어 진다. (이 두 개념에 대한 차이에 대한 설명은 내용이 길어지기에 다른 포스팅에서 기술할 수 있도록 하겠다.)
4. Orchestration tools
- 대표적으로 Kubernetes, Amazon ECS, Docker Swarm과 같은 도구이며 Rolling Update, Blue-Green 배포방식과 같이 자동화된 배포 전략을 지원한다.
- 아래 예시는 Kubernetes Orchestration 예시이며, YAML 파일 하나로 replica 관리, 업데이트, 복구, 로드 밸런싱 같은 복잡한 작업을 자동화하여 효율성과 일관성을 높일 수 있는 시사점을 제공한다.
apiVersion: apps/v1
kind: Deployment
metadata:
name: example-app
spec:
selector:
matchLabels:
app: example-app
replicas: 3
strategy:
rollingUpdate:
maxSurge: 3
maxUnavailable: 0
type: RollingUpdate
template:
metadata:
labels:
app: example-app
spec:
containers:
- name: example-app
image: httpd:2.4.39
ports:
- containerPort: 80
5. Provisioning tools
- 대표적으로 Terraform, CloudFormation, Pulumi 같은 도구이며 이를 통해 서버, 데이터베이스, 로드 밸런서 등과 같은 인프라 자체를 생성할 수 있다.
- IaC 코드로 네트워크 설정, 보안 규칙과 같은 설정내용들도 정의 및 관리가 가능하다.
테라폼 작동방식
(1) Terraform은 HashiCorp에서 개발한 오픈 소스 도구로, Go 프로그래밍 언어로 작성되어졌다.
(2) 여기서, Go 코드로 컴파일된 단일 바이너리(terraform)를 사용하며, 추가적인 인프라를 실행하지 않아도 로컬 PC나 빌드 서버 등에서 바로 실행 가능한 특징을 지닌다.
(3) Terraform 바이너리는 API 호출을 통해 AWS, Azure, Google Cloud, DigitalOcean, OpenStack 등 다양한 클라우드 프로바이더와 상호작용한다.
(4) Terraform 실행 파일은 사용자가 작성한 구성 파일을 파싱한 뒤 해당 내용에 따라 지정된 클라우드 공급자(AWS, Azure, GCP, DigitalOcean, OpenStack 등)의 API 서버로 요청을 보내어 리소스를 생성, 수정, 삭제한다.
(5) 이는 Terraform 스스로 인프라를 ‘직접’ 운영하는 것이 아니라, 이미 해당 클라우드 공급자들이 제공하는 API와 인증 시스템을 활용함으로써 별도의 관리 서버나 중간 계층 없이도 인프라 프로비저닝을 자동화할 수 있음을 의미한다.
(6) Terraform를 이용해 한 클라우드의 인프라를 그대로 다른 클라우드로 '투명하게' 이전은 불가능하다.
여러 클라우드 공급자를 지원한다는 점에서 Terraform는 멀티 클라우드 전략에 유용할 수 있지만, 이를 통해 "동일한 인프라를 투명하게 다른 클라우드로 옮기는" 것은 현실적으로 불가능하다. 각 클라우드 공급자는 고유한 서비스와 기능을 제공하기 때문에 인프라 설정과 구성이 상이하며, Terraform는 그러한 차이를 일괄적으로 추상화하기보다 각 공급자 고유 기능을 활용할 수 있도록 하는 공통 언어와 도구 세트를 제공하는 데 집중한다.
다시 말해, 다중 클라우드 환경에서 공통된 워크플로우(코드 작성→검토→적용)를 제공하나, 클라우드 간 완전한 ‘transparent portability’을 보장하지는 않는 도구라고 할 수 있다.
테라폼과 다른 도구 비교
절차적(Procedural) vs 선언적(Declarative) 언어 접근 방식 비교
- Procedural 방식: Chef, Ansible
원하는 최종 상태에 도달하기 위한 단계별 절차를 정의한다. 이는 인프라의 현재 상태를 직접 고려해야 하므로 재사용성 및 유지보수성이 낮아진다. - Declarative 방식: Terraform, CloudFormation, Puppet, Pulumi
최종 상태만 정의하는 방식으로 도구가 상태 변화를 자동 계산한다. 이는 코드로 인프라 상태를 명확히 기술하고 재활용하기 쉬우며, 상태 변화 관리가 용이하다.
범용 언어(GPL) vs 도메인 특화 언어(DSL)
- GPL: Chef, Pulumi
Ruby, JavaScript, Python, Go 등 을 사용 가능하여, 풍부한 생태계와 유연성을 제공한다. - DSL: Terraform, Puppet, Ansible, CloudFormation, Heat
(HCL, Puppet Language, YAML, JSON 등)을 사용해 러닝커브가 상대적으로 낮으며 코드가 간결하고 일관성이 높다. 그러나 DSL은 GPL보다 범용성이 떨어지고 복잡한 로직 구현이 제한적인 단점을 지닌다.
마스터 서버(Master) vs 마스터리스(Masterless), 에이전트 기반 vs 에이전트리스(Agentless)
- Chef, Puppet는 일반적으로 마스터 서버 및 각 서버에 설치된 에이전트를 필요로 하며, 이는 추가적인 인프라 관리, 보안 고려, 유지보수 부담을 초래한다.
- Ansible, Terraform, Pulumi, CloudFormation, Heat는 마스터리스 및 에이전트리스 접근으로 동작하며, 클라우드 공급자의 API나 SSH를 통해 직접 제어한다. 이는 추가 인프라나 인증 메커니즘이 거의 필요 없어 단순하고 안정적이다.
커뮤니티 크기 및 성숙도
- Terraform와 Ansible은 제일 큰 대규모 커뮤니티가 존재하며, 다양한 플러그인, 예제, 질문/답변 리소스를 쉽게 구할 수 있다.
- Chef와 Puppet은 성숙하고 안정적이나, 비교적 성장세가 주춤하다.
- CloudFormation, Heat, Pulumi는 각각 특정 제약(클라우드 종속성, 낮은 성숙도)이 존재한다.
댓글