AWS Terraform 라이프사이클 규칙
Source: Dev.to
소개
Infrastructure as Code (IaC)는 리소스가 업데이트, 교체 및 삭제되는 방식을 완전히 제어할 때 가장 강력합니다. Terraform은 이러한 동작을 미세 조정하고, 예기치 않은 중단을 방지하며, 조직 정책을 강제하는 lifecycle 메타‑인수 집합을 제공합니다. 이러한 lifecycle 규칙은 안정성, 예측 가능성 및 컴플라이언스가 중요한 프로덕션급 AWS 환경에서 필수적입니다.
이 문서는 각 Terraform lifecycle 규칙을 자세히 설명하고, 작동 방식, 실용적인 사용 사례 및 실제 AWS 배포에서 왜 중요한지를 다룹니다.
create_before_destroy
대체 리소스를 기존 리소스를 파괴하기 전에 생성하도록 보장합니다. 이는 무중단이 필요할 때 특히 중요합니다.
- 기본적으로 Terraform은 먼저 기존 리소스를 파괴하는데, 이는 실시간 트래픽을 제공하는 EC2 인스턴스와 같은 중요한 리소스에서 서비스 중단을 초래할 수 있습니다.
create_before_destroy를 사용하면 Terraform이 새 인스턴스를 먼저 프로비저닝하고, 의존성을 전환한 뒤 기존 인스턴스를 제거합니다.
일반적인 사용 사례
- 로드 밸런서 뒤에 있는 EC2 인스턴스
- 중단 없는 가용성이 요구되는 RDS 리소스
- 블루‑그린 배포 패턴
- 중단이 용납되지 않는 인프라
lifecycle {
create_before_destroy = true
}
prevent_destroy
리소스가 완전히 파괴되는 것을 방지합니다. 파괴를 시도하는 작업이 있으면 Terraform은 오류를 발생시킵니다.
- 실수로 삭제하면 되돌릴 수 없는 손상이 발생할 수 있습니다. 데이터베이스, 민감한 로그가 있는 S3 버킷, 상태를 유지하는 시스템은 의도치 않게 삭제되어서는 안 됩니다.
- 이 규칙은 안전망을 제공하여 중요한 리소스를 제거하기 전에 수동 개입을 요구합니다.
일반적인 사용 사례
- 프로덕션 데이터베이스
- 중요한 S3 버킷
- 여러 시스템에서 사용되는 IAM 역할
- 민감하거나 컴플라이언스가 요구되는 데이터를 포함하는 모든 리소스
lifecycle {
prevent_destroy = true
}
ignore_changes
Terraform은 일반적으로 코딩된 원하는 상태로 리소스를 되돌리려 합니다. ignore_changes는 Terraform이 외부에서(예: AWS 서비스나 다른 팀에 의해) 변경될 수 있는 특정 속성을 추적하거나 되돌리지 않도록 지시합니다.
- 불필요한 변동을 방지하고 Terraform이 AWS‑관리형 서비스와 충돌하는 것을 피합니다.
일반적인 사용 사례
- Auto Scaling Group의 Desired Capacity
- 모니터링 도구가 자동으로 추가하는 태그
- 여러 팀이 관리하는 보안 그룹
- AWS 서비스가 제어하는 값
lifecycle {
ignore_changes = [desired_capacity]
}
replace_triggered_by
다른 리소스가 변경될 때마다 해당 리소스를 재생성하도록 강제합니다. 종속된 변경이 다른 구성 요소의 기능에 영향을 미칠 때 유용합니다.
- EC2 인스턴스 구성 자체는 변경되지 않았더라도, 보안 그룹이 변경되면 보안 또는 컴플라이언스 이유로 교체가 필요할 수 있습니다.
일반적인 사용 사례
- 보안 그룹이 변경될 때 EC2 인스턴스 교체
- 구성 업데이트에 따라 리소스 재생성
- 불변 인프라 관행 강제
lifecycle {
replace_triggered_by = [aws_security_group.app_sg.id]
}
precondition
리소스 생성 또는 수정 이전에 특정 조건을 검증합니다. 조건이 실패하면 Terraform은 중단되고 사용자 정의 오류 메시지를 표시합니다.
- 워크플로 초기에 잘못된 구성을 방지합니다.
- 배포가 시작되기 전에 허용된 리전, 필수 태그, 유효한 파라미터만 사용되도록 보장합니다.
일반적인 사용 사례
- 특정 AWS 리전에서만 배포 허용
- 태그 존재 여부 검증
- 필수 환경 변수 존재 확인
- 리소스 한도 체크
precondition {
condition = contains(var.allowed_regions, data.aws_region.current.name)
error_message = "Region not allowed for deployment."
}
postcondition
리소스가 생성되거나 업데이트된 후에 조건을 검증합니다. 조건이 실패하면 Terraform은 해당 리소스를 무효로 표시합니다.
- 최종 상태가 정책이나 기대에 부합하는지 확인합니다.
- 예시: 버킷 생성 후 반드시 특정 태그가 존재하도록 강제.
일반적인 사용 사례
- 중요한 태그 존재 보장
- 리소스 속성 검증
- 조직 표준에 대한 컴플라이언스 강제
- 생성 후 리소스 상태 체크
postcondition {
condition = contains(keys(self.tags), "Environment")
error_message = "Environment tag is required."
}
결론
Terraform lifecycle 규칙은 탄력적인 AWS 인프라를 구축하는 데 필수적입니다. 이들은 중단을 방지하고, 중요한 데이터를 보호하며, 컴플라이언스를 보장하고, 업데이트 시 예측 가능한 동작을 유지하도록 돕습니다. 이러한 도구를 사용하면 어떤 리소스를 생성할지뿐만 아니라 그 리소스가 전체 수명 주기 동안 어떻게 동작할지도 제어할 수 있습니다.
프로덕션 워크로드를 배포하든, 자동화 파이프라인을 구현하든, 팀 간에 인프라를 관리하든, lifecycle 규칙은 Terraform 워크플로에 안전성, 일관성 및 신뢰성을 제공합니다.