🚀 Terraform 실무 시나리오 15선: DevOps 엔지니어가 반드시 알아야 할 실무 위주의 핵심 질문/상세 답변

[cloudbro-radar]

# 현장에서 적용할 수 있는 Terraform 의 상세한 15가지 실무 시나리오를 공유합니다.

1. 시나리오: EC2 인스턴스의 무중단 배포

• 질문 : EC2 인스턴스의 AMI ID를 다운타임 없이 업데이트해야 합니다. Terraform은 기본적으로 인스턴스를 삭제 후 다시 생성하려고 합니다. 다운타임을 피하려면 어떻게 해야 할까요?**

• 답변: lifecycle 규칙에서 Create Before Destroy를 사용합니다.

resource "aws_instance" "example" {
  ami           = var.ami_id
  instance_type = "t3.micro"

  lifecycle {
    create_before_destroy = true
  }
}

이 설정은 기존 인스턴스가 삭제되기 전에 새로운 인스턴스가 먼저 생성되도록 보장합니다. 또한 Auto Scaling Group(ASG)을 사용하여 롤링 업데이트를 적용할 수도 있습니다.

---

2. 시나리오: 크로스 리전 인프라 관리

• 질문 : 동일한 Terraform 설정에서 us-east-1 리전에 S3 버킷을, ap-south-1 리전에 EC2 인스턴스를 배포해야 합니다. 이를 어떻게 구현할 수 있을까요?

• 답변: 여러 provider 구성을 사용합니다

provider "aws" {
  alias  = "us-east"
  region = "us-east-1"
}

provider "aws" {
  alias  = "us-south"
  region = "ap-south-1"
}

resource "aws_s3_bucket" "example" {
  provider = aws.us-east
  bucket   = "my-bucket-us-east"
}

resource "aws_instance" "example" {
  provider      = aws.us-south
  ami           = "ami-123456"
  instance_type = "t2.micro"
}

각 리소스는 명시적으로 provider alias에 할당됩니다.

---

3. 시나리오: 프로덕션 환경에서의 Terraform Drift 처리

• 질문 : Terraform으로 관리 중인 AWS 인프라가 다른 팀에 의해 수동으로 수정되었습니다. Terraform에서는 변경 사항이 보이지 않지만 AWS 콘솔에서는 차이가 확인됩니다. 이를 어떻게 탐지하고 수정할 수 있을까요?

• 답변: terraform plan -refresh-only 명령으로 변경 사항을 적용하지 않고 drift를 탐지합니다.
  terraform state list를 사용하여 추적 중인 리소스를 확인합니다. 리소스가 누락된 경우 다음과 같이 다시 import합니다:

terraform import aws_instance.example i-1234567890abcdef0

필요하다면 terraform apply를 실행하여 예상되는 구성으로 복원합니다.

---

4. 시나리오: Terraform 보안 정책 강제 적용

• 질문 : 회사는 AWS 비용을 통제하기 위해 t2.micro 인스턴스만 사용하도록 제한하려고 합니다. Terraform에서 이를 어떻게 강제할 수 있을까요?

• 답변: variables.tf 파일에 Terraform validation rule을 사용하여 인스턴스 타입을 제한합니다:

variable "instance_type" {
  description = "AWS EC2 instance type"
  type        = string
  validation {
    condition     = contains(["t2.micro"], var.instance_type)
    error_message = "Only t2.micro instance type is allowed."
  }
}

이렇게 하면 승인되지 않은 인스턴스 타입으로 Terraform을 적용할 수 없게 됩니다.

---

5. 시나리오: Terraform을 활용한 Blue-Green Deployment

• 질문 :Terraform을 사용해 Auto Scaling Group(ASG)에 Blue-Green 배포 전략을 구현해야 합니다. 이를 어떻게 달성할 수 있을까요?

• 답변: 두 개의 ASG(blue와 green)를 Elastic Load Balancer(ELB) 뒤에 배치합니다:

resource "aws_launch_template" "blue" {
  name     = "blue-template"
  image_id = var.ami_blue
}

resource "aws_launch_template" "green" {
  name     = "green-template"
  image_id = var.ami_green
}

resource "aws_autoscaling_group" "blue" {
  launch_template {
    id = aws_launch_template.blue.id
  }
}

resource "aws_autoscaling_group" "green" {
  launch_template {
    id = aws_launch_template.green.id
  }
}

resource "aws_lb_listener_rule" "switch" {
  listener_arn = aws_lb_listener.http.arn
  priority     = 100
  conditions {
    field  = "path-pattern"
    values = ["*"]
  }
  actions {
    type             = "forward"
    target_group_arn = aws_lb_target_group.green.arn
  }
}

새 버전을 배포할 때는 ALB의 target group을 변경하여 트래픽을 전환합니다.

---

6. 시나리오: API Rate Limit으로 인한 terraform apply 실패

• 질문 : 단일 terraform apply에서 100개 이상의 AWS 리소스를 생성하려고 하는데, AWS API rate limit 때문에 프로세스가 실패합니다. 이를 어떻게 해결할 수 있을까요?

• 답변: AWS provider에서 retry 설정을 사용합니다:

provider "aws" {
  region      = "us-east-1"
  max_retries = 5
}

depends_on을 사용해 리소스 생성을 단계적으로 진행합니다:

resource "aws_instance" "one" {
  ami = "ami-123456"
}

resource "aws_instance" "two" {
  ami        = "ami-123456"
  depends_on = [aws_instance.one]
}

Terraform Workspaces를 활용하여 워크로드를 분할합니다.

---

7. 시나리오: 중요 리소스의 실수로 인한 삭제 방지

• 질문 : Terraform으로 관리 중인 프로덕션 RDS 데이터베이스가 실수로 삭제되지 않도록 하려면 어떻게 해야 할까요?

• 답변: prevent_destroy lifecycle 규칙을 사용합니다:

resource "aws_db_instance" "production_db" {
  identifier     = "prod-db"
  engine         = "mysql"
  instance_class = "db.t3.large"

  lifecycle {
    prevent_destroy = true
  }
}

terraform destroy가 실행되면 이 리소스에 대해서는 실패하게 됩니다.

---

8. 시나리오: 멀티 테넌트 AWS 계정의 Terraform 관리

• 질문 : 조직에 AWS 계정이 여러 개(Dev, QA, Prod) 있습니다. 배포를 효율적으로 관리하려면 어떻게 해야 할까요?

• 답변: Terraform Workspaces를 사용해 멀티 환경을 관리합니다:

terraform workspace new dev
terraform workspace new prod
terraform workspace select prod

Terraform 설정에서는 다음과 같이 구성합니다:

provider "aws" {
  region = "us-east-1"
  alias  = terraform.workspace
}

resource "aws_s3_bucket" "example" {
  bucket = "my-bucket-${terraform.workspace}"
}

---

9. 시나리오: Terraform 상태 잠금(State Lock) 이슈 처리

• 질문 : 팀에서 S3에 원격 상태를 사용 중입니다. 팀원의 Terraform 실행이 실패하면서 상태가 잠긴 채로 남았습니다. 이 문제를 어떻게 해결하나요?

• 답변: terraform { backend "s3" { } }를 사용할 때 Terraform은 DynamoDB에서 상태를 자동으로 잠급니다.

잠금이 지속되면 다음을 실행합니다:

terraform force-unlock <LOCK_ID>

잠금을 해제하기 전에 terraform state list와 terraform state show로 상태를 확인합니다.

---

10. 시나리오: 실패한 Terraform 배포 롤백

• 질문 : terraform apply가 리소스를 잘못 수정해 장애가 발생했습니다. 이전 상태로 빠르게 롤백하려면 어떻게 해야 할까요?

• 답변: 이전 상태 파일이 원격(S3, Terraform Cloud)에 저장되어 있다면 복원합니다:

terraform state pull > backup.tfstate
terraform state push backup.tfstate

잘못된 코드를 되돌린 뒤 Terraform을 다시 적용합니다. 필요하다면 terraform apply를 실행하기 전에 중요 리소스를 수동으로 복구합니다.

---

11. 시나리오: Terraform 모듈로 동적 리소스 스케일링

• 질문 : 인프라가 환경(dev, prod)에 따라 서로 다른 EC2 인스턴스 타입을 요구합니다. Terraform 모듈에서 인스턴스 타입을 동적으로 지정하려면 어떻게 해야 할까요?

• 답변: terraform.tfvars 또는 variables.tf 내부의 map을 사용합니다:

variable "instance_type_map" {
  type = map(string)
  default = {
    dev  = "t2.micro"
    prod = "t3.large"
  }
}

resource "aws_instance" "example" {
  ami           = "ami-123456"
  instance_type = var.instance_type_map[var.environment]
}

Terraform 변수에 environment = "prod"를 전달하여 올바른 인스턴스 타입을 선택합니다.

---

12. 시나리오: Terraform에서 시크릿을 안전하게 관리

• 질문 : Terraform 코드에서 AWS 자격 증명이 필요합니다. 하드코딩 없이 이 시크릿을 안전하게 관리하려면 어떻게 해야 할까요?

• 답변: AWS Secrets Manager를 사용해 동적으로 시크릿을 조회합니다:

data "aws_secretsmanager_secret_version" "db_creds" {
  secret_id = "my-db-creds"
}

resource "aws_db_instance" "db" {
  username = jsondecode(data.aws_secretsmanager_secret_version.db_creds.secret_string)["username"]
  password = jsondecode(data.aws_secretsmanager_secret_version.db_creds.secret_string)["password"]
}

또는 환경 변수(TF_VAR_secret)와 함께 Terraform 변수를 사용합니다.

---

13. 시나리오: 대형 Terraform 상태(State) 효율적으로 관리

• 질문 : Terraform 상태 파일이 너무 커져 성능이 저하됩니다. 효율적으로 관리하려면 어떻게 해야 할까요?

• 답변: Terraform State Splitting을 사용합니다: 서로 다른 workspace나 backend로 리소스를 분리해 여러 상태 파일로 관리합니다.
  Terraform State Locking을 활성화합니다: 동시성 이슈 방지를 위해 S3와 DynamoDB를 사용합니다:

terraform {
  backend "s3" {
    bucket         = "my-terraform-state"
    key            = "prod/terraform.tfstate"
    region         = "us-east-1"
    dynamodb_table = "terraform-lock"
  }
}

또한 terraform workspace new dev 등 Terraform Workspaces로 환경을 격리합니다.

---

14. 시나리오: EKS에서 워커 노드 오토스케일링

• 질문 : Kubernetes 클러스터가 AWS EKS에서 동작합니다. Terraform으로 워커 노드를 동적으로 오토스케일링하려면 어떻게 구성하나요?

• 답변: AWS Auto Scaling Group을 Terraform으로 구성합니다:

resource "aws_autoscaling_group" "eks_nodes" {
  min_size         = 2
  max_size         = 10
  desired_capacity = 3

  tag {
    key                 = "kubernetes.io/cluster/my-cluster"
    value               = "owned"
    propagate_at_launch = true
  }
}

Cluster Autoscaler와 결합하여 노드 수를 동적으로 조정합니다.

---

15. 시나리오: Terraform에서 리소스 재생성 회피

• 질문 : EC2 인스턴스 타입을 업데이트했는데, Terraform이 in-place 수정 대신 삭제 후 재생성을 시도합니다. 이를 어떻게 방지하나요?

• 답변: ignore_changes lifecycle 규칙을 사용해 기존 리소스를 유지합니다:

resource "aws_instance" "example" {
  ami           = "ami-123456"
  instance_type = "t2.micro"

  lifecycle {
    ignore_changes = [instance_type]
  }
}

수정이 꼭 필요하다면 Terraform 외부에서 수동으로 변경한 뒤 다음으로 변경 사항을 import합니다:

terraform import aws_instance.example i-1234567890abcdef

[출처] https://medium.com/devops-dev/15-terraform-scenarios-every-devops-engineer-should-know-part-3-e1e2307333ab