Terraform 고급

Source: Dev.to

왜 Terraform인가?

Terraform는 클라우드 인프라를 자동화하기 위해 사용됩니다. 그래서 사람이 직접 만들 필요가 없습니다:

• VPC
• 서브넷
• 보안 그룹
• ECS 클러스터
• 작업 정의(Task definitions)
• 로드 밸런서
• IAM 역할
• RDS
• S3
• DynamoDB
• 시크릿(Secrets)
• ECR 레지스트리
• Route53
• CloudWatch 알람

Terraform 없이

• 엔지니어가 콘솔을 클릭클릭
• 히스토리가 없음
• 리뷰/추적이 안 됨
• 실수로 인한 잘못된 설정
• 환경을 재현하기 어려움
• 장애 후 복구가 어려움
• 확장이 어려움
• 수십 개의 환경을 유지하는 것이 불가능

Terraform과 함께

모든 것이 코드이며 전체 인프라가 반복 가능합니다:

• 시스템 전체를 처음부터 다시 만들 수 있음
• 팀이 Git 히스토리, PR 리뷰, CI/CD 파이프라인을 사용
• 한 명령으로 모든 클라우드 리소스를 올바르게 업데이트

프로젝트에 포함된 내용:

• 7개의 마이크로서비스(Python)
• ECS 클러스터
• ALB
• Couchbase
• Confluent Cloud
• PostgreSQL/RDS
• VPN / VPC
• Kafka 브로커
• Lambda(선택 사항)
• S3 상태 백엔드

---

모든 시니어 DevOps가 알아야 할 Terraform 핵심 개념

(A) Terraform은

• 선언형 – 무엇을 원하는지 기술하면, Terraform이 어떻게 만들지 결정합니다.

(B) Terraform 파일

면접 시 각 파일이 존재하는 이유를 설명할 수 있어야 합니다.

---

Terraform State — 기업이 기대하는 내용

Terraform은 생성한 모든 것을 다음 파일에 “기억”합니다:

terraform.tfstate

상태 파일에는 다음이 포함됩니다:

• 모든 AWS 리소스 ID
• 리소스 간 의존성
• 현재 구성
• 각 리소스의 속성

🚨 이 파일은 매우 중요합니다 — 잃어버리면 치명적
기업은 tfstate를 로컬에 저장하지 않고 원격 백엔드를 사용합니다:

• S3 → .tfstate 파일 저장
• DynamoDB → 상태 잠금 관리

---

왜 S3 백엔드인가? (프로젝트 예시)

프로젝트에는 다음이 포함됩니다:

• GitHub Actions
• 서로 다른 머신에서 로컬 개발
• 여러 번의 terraform apply 실행

각 머신이 로컬 tfstate를 저장한다면 다음과 같은 문제가 발생합니다:

• 동시 적용 시 덮어쓰기
• GitHub Actions가 로컬 변경을 볼 수 없음
• Terraform이 중복 혹은 파괴적인 작업을 수행하게 됨

S3가 이 문제들을 해결합니다:

• 모든 Terraform 실행에 대한 중앙 상태 제공
• GitHub Actions와 로컬 머신이 동일한 상태를 읽음
• 로컬 terraform.tfstate 파일을 삭제해도 안전
• 상태가 버전 관리되어 롤백 가능

---

왜 DynamoDB 잠금인가? (오늘 겪은 정확한 이슈)

Terraform은 동시 적용을 방지해야 합니다. 실행 중:

terraform plan
terraform apply

Terraform은 DynamoDB에 잠금을 기록합니다:

LockID = kafka-enterprise-orders-tfstate/terraform.tfstate

• GitHub Actions가 로컬 실행 중에 시작되면, 잠금이 손상을 방지합니다.
• 이전 실행이 크래시되면 잠금이 영구히 남을 수 있어 수동 삭제가 필요합니다.

---

Terraform Apply 흐름 (프로젝트 실제 흐름)

1. terraform init

   • AWS 공급자 다운로드
   • 백엔드 설정 읽기
   • S3와 DynamoDB 연결

2. terraform plan

   • 원하는 인프라(코드)와 실제 AWS 상태 비교
   • 예정된 변경 사항 표시

3. terraform apply

   • ECS 작업 정의와 서비스 생성/업데이트
   • ALB 대상 그룹 및 리스너 업데이트
   • 보안 그룹 및 서브넷 연결 수정
   • IAM 역할 관리
   • 필요 시 RDS 인스턴스 생성
   • 출력값 생성(ALB DNS, SG ID 등)

---

Terraform Drift 감지 (시니어 역할에 매우 중요)

Terraform은 항상 상태 파일과 실제 리소스 간의 드리프트를 감지합니다.

예시 1 – 서브넷을 수동으로 삭제한 경우

Terraform은 다음을 보고합니다:

InvalidSubnetID.NotFound

그 후 누락된 서브넷을 재생성하거나 실행을 실패시키고 수동 수정이 필요함을 알립니다.

---

Terraform 변수 및 시크릿 (프로젝트)

GitHub Actions에서 Terraform에 다음 변수를 전달합니다:

TF_VAR_container_image_producer
TF_VAR_container_image_payment
TF_VAR_container_image_fraud
TF_VAR_container_image_analytics
TF_VAR_web_backend_image
TF_VAR_web_frontend_image
TF_VAR_confluent_bootstrap_servers
TF_VAR_confluent_api_key
TF_VAR_confluent_api_secret
TF_VAR_rds_password
TF_VAR_existing_vpc_id
TF_VAR_existing_public_subnet_ids
TF_VAR_existing_private_subnet_ids
TF_VAR_existing_ecs_tasks_sg_id
TF_VAR_existing_alb_sg_id
TF_VAR_existing_rds_sg_id

이 변수들은 코드가 컨테이너 이미지와 기타 시크릿을 동적으로 읽을 수 있게 해 줍니다. 코드가 푸시되면 CI/CD가 이미지를 빌드하고 GHCR에 푸시한 뒤, 이미지 태그를 Terraform에 주입해 ECS 작업 정의를 업데이트합니다.

---

시니어 DevOps 면접에서 Terraform — 기대하는 것

반드시 알아야 할 주제

• Terraform 상태
• 백엔드(S3, Azure Blob, GCS)
• 잠금(DynamoDB)
• 모듈
• 워크스페이스
• 공급자
• 데이터 소스
• 변수 & 출력값
• 의존성 그래프
• 라이프사이클 규칙
• terraform import
• terraform taint
• terraform graph
• CI/CD 파이프라인
• 시크릿 관리

실제 예시로 설명하는 방법

“우리 Terraform은 ECS, ALB, VPC, RDS, SG, Kafka 리소스를 관리합니다.
상태는 S3에 중앙화되고 DynamoDB 잠금으로 동시성 문제를 방지합니다.
GitHub Actions는 CI에서 빌드된 이미지를 TF_VAR_ 변수로 주입해 ECS 작업 정의를 업데이트합니다.”

---

왜 프로젝트에 Terraform이 필요한가

17개 이상의 상호 의존 AWS 리소스를 함께 업데이트해야 합니다:

• 컨테이너 이미지 변경 → ECS 작업 업데이트
• 포트 변경 → ALB 대상 그룹 업데이트
• AWS 리전 변경 → VPC, 서브넷, RDS 재생성 필요
• Kafka 클러스터 변경 → 환경 변수 업데이트
• 보안 그룹 변경 → ECS & ALB 업데이트

Terraform은 모든 리소스의 올바른 순서와 일관성을 보장합니다.

---

Terraform 내부 동작 방식 (“그래프 이론”)

Terraform은 의존성 그래프를 구성합니다:

aws_vpc -> subnets -> route tables -> security groups -> 
alb -> ecs_cluster -> ecs_services -> tasks

그 후 작업을 실행합니다:

• 병렬로 실행 가능한 리소스는 동시에 진행
• 순차로 실행해야 하는 리소스는 의존성에 따라 순서대로 진행

---

오늘 발생한 ECS 오류 — Terraform이 인프라 문제를 감지

• 잘못된 보안 그룹 – 시크릿에 잘못된 값이 포함돼 Terraform이 거부함.
• 수동으로 삭제된 서브넷 – Terraform이 누락된 서브넷을 경고하고, 서브넷 ID를 수정하도록 안내함.

---

Terraform CI/CD — 파이프라인

1. Docker 이미지 빌드
2. 이미지를 GitHub Container Registry에 푸시
3. Terraform 실행(플랜 & 적용)
4. 새로운 작업 정의로 ECS 서비스 업데이트
5. 새로운 컨테이너가 즉시 배포

이 워크플로우는 엔터프라이즈 수준의 반복 가능한 배포 프로세스를 제공합니다.