[Project] 기술 스택 발표 - IaC와 TerraForm 이란?

 

 

참고 : https://aws.amazon.com/ko/what-is/iac/

코드형 인프라란?- IaC 설명 - AWS

 

 

 

1. IaC란?

 

IaC(Infrastructure as Code, 코드형 인프라)는 수동 프로세스 및 설정 대신 코드를 사용하여 컴퓨팅 인프라를 프로비저닝하고 지원하는 기능이다. 쉽게 말하면 AWS 콘솔에 들어가서 서버를 하나하나 클릭해서 만드는 대신, 필요한 인프라를 파일에 적어두고 도구가 그대로 만들게 하는 방식이다.

 

이게 필요한 이유는 수동 작업의 한계 때문이다. 수동 인프라 관리는 시간이 많이 걸리고 오류가 발생하기 쉬운데, 애플리케이션을 대규모로 관리할수록 더 그렇다. 사람이 직접 하다 보면 개발 환경에서는 바꿔놓은 설정이 테스트 환경에는 빠져 있는 식으로 환경끼리 어긋나는 일도 생긴다.

 

이미지 출처: AltexSoft

위 그림은 IaC가 동작하는 흐름을 보여준다. 먼저 개발자가 인프라를 정의하는 코드를 작성한다. 이 코드는 스크립트(Scripts), 템플릿(Templates), 정책(Policies) 같은 형태로 만들어지는데, 어떤 서버를 몇 대 띄울지, 네트워크는 어떻게 구성할지, 어떤 규칙을 지켜야 하는지 등이 여기에 담긴다. 작성한 코드는 일반 소스 코드처럼 Git 같은 버전 관리 시스템에 저장된다. 그래서 인프라 설정이 언제, 누구에 의해, 어떻게 바뀌었는지 기록이 남고, 문제가 생기면 이전 버전으로 되돌릴 수 있다. 그다음 Terraform, Ansible, Chef, Puppet, AWS CloudFormation 같은 IaC 도구가 이 코드를 읽어서 실제 인프라(서버, 스토리지, 클라우드 리소스 등)에 반영한다.

 

Terraform과 CloudFormation은 서버, 네트워크 같은 인프라 자체를 만드는 프로비저닝 도구이고, Ansible, Chef, Puppet은 이미 만들어진 서버 안에 패키지를 설치하거나 설정을 맞추는 구성 관리 도구에 가깝다. 

 

 

IaC를 쓰면 얻는 장점은 크게 세 가지다.

 

장점	내용
환경 복제가 쉬움	같은 코드로 똑같은 환경을 다른 곳에 그대로 만들 수 있다
설정 오류 감소	문제가 생기면 이전 버전 코드로 롤백할 수 있다
변경 이력 관리	인프라 설정 파일도 Git으로 관리하니까 변경이 기록된다

 

 

IaC를 작성하는 방식은 선언형과 명령형 두 가지로 나뉜다. 선언형은 최종적으로 이런 상태였으면 좋겠다고 적으면 도구가 알아서 그 상태를 만들어 주는 방식이고, 명령형은 그 상태까지 가는 과정을 한 단계씩 직접 적는 방식이다. 명령형은 선언형보다 작성하기 번거롭지만, 이벤트 순서가 중요한 복잡한 배포에서는 필요할 때가 있다. 이때 Terraform은 선언형에 속한다.

 

 

 

 

2. Terraform이란?

Terraform은 HashiCorp에서 만든 IaC 도구다. HCL이라는 자체 언어로 인프라를 정의하고, 명령어 몇 개로 실제 리소스를 생성하거나 삭제할 수 있다. AWS에도 CloudFormation이라는 IaC 서비스가 있는데, 이건 AWS 전용이다.

Terraform은 Provider라는 플러그인 구조를 써서 AWS, GCP, Azure, 쿠버네티스 등 여러 플랫폼을 같은 문법으로 다룰 수 있다.

 

 

Provider	AWS 같은 대상 플랫폼과 통신하는 플러그인
Resource	실제로 만들 인프라 단위 (EC2, VPC, S3 버킷 등)
State	현재 인프라 상태를 기록한 파일(terraform.tfstate). 코드와 비교해서 무엇을 바꿔야 하는지 계산할 때 쓴다
Module	여러 리소스를 묶어서 재사용할 수 있게 만든 단위

 

 

 

테라폼 사용 흐름

1. terraform init	작업 디렉터리를 초기화하고 필요한 Provider를 내려받는다
2. terraform plan	코드와 현재 상태를 비교해서 어떤 리소스가 생성, 변경, 삭제될지 미리 보여준다
3. terraform apply	plan 내용을 실제 인프라에 반영한다
4. terraform destroy	Terraform으로 만든 리소스를 한 번에 삭

 

terraform init으로 Provider를 내려받아 초기화하고, terraform plan으로 어떤 리소스가 생기고 바뀌는지 미리 확인한 다음, terraform apply로 실제 반영한다. 다 쓴 뒤에는 terraform destroy로 만든 리소스를 한 번에 지울 수 있다. 

 

주의할 점

 

State 파일에는 리소스 정보와 함께 비밀번호 같은 민감한 값이 들어갈 수 있어서 Git에 그대로 올리면 안 된다. 보통 .gitignore에 추가하고, 여러 명이 같은 인프라를 관리할 때는 S3 같은 원격 저장소(Remote Backend)에 State를 두고 공유한다. 또 Terraform 밖에서 리소스를 직접 수정하면 코드와 실제 상태가 달라지는데, 이를 드리프트(Drift)라고 한다. 이 상태에서 다음 apply를 실행하면 Terraform이 코드 기준으로 되돌려버릴 수 있으니, 변경은 가능한 한 코드를 통해서 하는 게 좋다.

 

3. 프로젝트에서는 어떻게 쓰일까?

온프레미스 쿠버네티스 클러스터에서 In-Place Resize로 먼저 부하를 감당하고, 그걸로도 부족하면 AWS로 확장(버스팅)하는 하이브리드 오토스케일러다. AWS 연동은 이후 단계에서 진행할 예정이라, 지금은 온프레미스 클러스터 위에 올라가는 구성 요소들을 Terraform으로 관리하는 데 먼저 사용한다.

 

Terraform은 클라우드 리소스만 만드는 도구가 아니다. Kubernetes Provider와 Helm Provider를 쓰면 kubeconfig로 로컬 클러스터에 접속해서 네임스페이스, 배포, 차트 설치 같은 작업을 코드로 관리할 수 있다. 그래서 지금 단계에서는 아래 리소스들을 Terraform으로 정의한다.

대상	만드는 리소스	용도
Namespace	monitoring, database, app	역할별로 리소스 분리
Prometheus	kube-prometheus-stack (Helm)	오토스케일링 판단에 쓸 메트릭 수집
MongoDB	MongoDB StatefulSet (Helm)	로그 저장 (error / 비중요 로그 분리)
애플리케이션	Frontend, Backend Deployment와 Service	부하 테스트 대상 앱

예를 들어 모니터링용 네임스페이스를 만들고 Prometheus를 설치하는 코드는 아래처럼 작성할 수 있다.

terraform {
  required_providers {
    kubernetes = {
      source = "hashicorp/kubernetes"
    }
    helm = {
      source  = "hashicorp/helm"
      version = "~> 3.0"
    }
  }
}

provider "kubernetes" {
  config_path = "~/.kube/config"
}

provider "helm" {
  kubernetes = {
    config_path = "~/.kube/config"
  }
}

resource "kubernetes_namespace" "monitoring" {
  metadata {
    name = "monitoring"
  }
}

resource "helm_release" "prometheus" {
  name       = "prometheus"
  repository = "https://prometheus-community.github.io/helm-charts"
  chart      = "kube-prometheus-stack"
  namespace  = kubernetes_namespace.monitoring.metadata[0].name
}

 

코드를 보면 helm_release가 kubernetes_namespace를 참조하고 있다. Terraform은 이런 참조 관계를 보고 네임스페이스를 먼저 만든 뒤 Prometheus를 설치하는 순서를 알아서 정한다. 선언형 도구라 실행 순서를 직접 적지 않아도 되는 것이다.

 

나중에 이 구조를 그대로 이어서 쓸 수 있다. 같은 Terraform 프로젝트에 AWS Provider만 추가해서 VPC, EC2, S3 같은 리소스를 정의하면 되기 때문에, 온프레미스와 클라우드 인프라를 한 곳에서 관리하게 된다.

 

4. 정리

 

1. IaC는 인프라를 코드로 관리해서 같은 환경을 언제든 다시 만들 수 있게 하고, 설정 실수를 줄이고, 변경 이력을 남기는 방식이다. Terraform은 그중에서도 여러 플랫폼을 같은 문법으로 다룰 수 있는 선언형 도구이다. 

 

 

2. Terraform은 원하는 최종 상태를 코드로 적으면 State 파일에 기록된 현재 상태와 비교해서 필요한 변경만 적용한다. plan으로 변경 사항을 미리 확인한 뒤 apply로 반영하고, 필요 없어지면 destroy로 한 번에 정리할 수 있다. 다만 State 파일 관리와 드리프트는 신경 써야 하는 부분이다.