[DevOps/IaC] 코드로 관리하는 인프라 : 테라폼(Terraform) State 파일과 동시성 충돌 방지

Об этом предложении

클라우드 인프라의 규모가 커지고 복잡해짐에 따라, AWS 콘솔이나 GCP 웹 UI에서 수동으로 리소스를 클릭해 생성하는 방식은 한계에 부딪히게 됩니다. 변경 이력 추적이 어렵고, 사람이 개입하면서 오타나 실수가 발생할 확률이 비약적으로 높아지기 때문입니다. 이를 해결하기 위해 등장한 개념이 IaC(Infrastructure as Code, 코드로 관리하는 인프라)이며, 그 중심에 테라폼(Terraform)이 있습니다. 이번 글에서 테라폼의 핵심 메커니즘인 State 파일( terraform.tfstate )의 역할과, 팀 단위 협업 시 발생할 수 있는 동시성 충돌(Race Condition)을 AWS S3와 DynamoDB 를 활용해 어떻게 안전하게 해결하는지 파헤쳐 봅시다. 1. 테라폼의 핵심 : terraform.tfstate 란? 테라폼으로 인프라를 생성( terraform apply )하면 프로젝트 루트 경로에 terraform.tfstate 라는 JSON 포맷의 파일이 생깁니다. { "version": 4, "terraform_version": "1.5.0", "serial": 12, "resources": [ { "mode": "managed", "type": "aws_instance", "name": "web_server", "provider": "provider[\"registry.terraform.io/hashicorp/aws\"]", "instances": [ ... ] } ] } State 파일이 존재하는 이유 테라폼은 선언적(Declarative) 언어 입니다. 개발자가 "이러한 인프라 상태를 만들어라"라고 코드(HCL)를 작성하면, 테라폼은 [실제 클라우드의 현재 상태]와 [코드에 정의된 원하는 상태(Desired State)]를 비교하여 필요한 변경 사항(Diff)만 계산해 반영합니다. 이때 "실제 클라우드 리소스와 내가 작성한 코드를 매핑해주는 유일한 매개체"가 바로 State 파일입니다. 2. 로컬 State 파일의 위험성 기본 설정 상태에서는 terraform.tfstate 파일이 개발자의 로컬 컴퓨터 에 저장됩니다. 혼자 사이드 프로젝트를 진행할 때는 문제가 없어 보이지만, 팀 단위로 프로덕션 인프라를 다룰 때는 심각한 문제를 야기합니다. 팀원 간 State 불일치 A 엔지니어가 EC2를 생성한 후 State 파일을 Git에 올리지 않거나 늦게 올리면, B 엔지니어는 이를 모르고 다른 작업을 진행하다가 인프라를 덮어쓰거나 에러를 발생시킵니다. Git 충돌 및 보안 위험 State 파일에는 클라우드 리소스의 상세 정보(IP, ID)뿐만 아니라, DB 패스워드나 Secret Key같은 민감 정보(Plaintext)가 그대로 노출될 수 있습니다. 이를 Git 버전 관리에 올리는 것은 심각한 보안 사고로 이어집니다. 동시 실행 충돌 (Race Condition) A와 B 엔지니어가 동시에 terraform apply 를 실행하면 State 파일이 꼬이면서 인프라가 파괴될 수 있습니다. 3. 해결책 : Remote Backend (AWS S3) + State Locking (DynamoDB) 이 문제를 해결하기 위해 테라폼은 State 파일을 중앙 원격 저장소에 보관하는 Remote Backend 기능과, 동시에 접근하지 못하도록 잠그는 State Locking 메커니즘을 제공합니다. AWS 환경에서는 S3(저장소)와 DynamoDB(잠금장치)의 조합이 글로벌 표준(De facto standard)으로 사용됩니다. ┌────────────────────────┐ │ AWS S3 (Remote) │ ─── State 파일 중앙 저장 및 암호화 │ terraform.tfstate │ └────────────────────────┘ ▲ │ Read / Write [Developer A] ───apply───> [Terraform] <───apply─── [Developer B] │ ▼ ┌────────────────────────┐ │ AWS DynamoDB │ ─── LockID 기반 State Locking │ (Lock Table) │ └────────────────────────┘ 1 S3 (Remote State Storage) 역할 : terraform.tfstate 파일을 로컬이 아닌 중앙 S3 버킷에 보관합니다. 장점 S3의 버전 관리(Versioning) 기능을 켜두면, State 파일이 손상되었을 때 이전 버전으로 언제든 복구할 수 있습니다. S3의 암호화(SSE-S3/KMS) 및 IAM 접근 제어를 통해 민감한 인프라 상태 정보를 안전하게 보호합니다. 2 DynamoDB (State Lock Table) 역할 : 누군가 terraform apply 이나 apply 를 실행하는 순간, DynamoDB 테이블에 LockID 항목을 생성하여 State 파일을 잠급니다(Lock). 장점 개발자 A가 배포 중일 때 개발자 B가 배포를 시도하면, DynamoDB의 락을 확인하고 Error acquiring the state lock 에러를 뿜으며 실행을 즉시 중단시킵니다. 배포가 성공적으로 끝나면 DynamoDB의 락 항목이 자동으로 삭제( Unlock )되어 다음 사람이 사용할 수 있게 됩니다. 4. HCL 설정 코드 및 구현 가이드 실제 테라폼 코드( main.tf 또는 backend.tf )에 작성하는 설정 예시입니다. Step 1. S3 버킷과 DynamoDB 테이블 사전 생성 (최초 1회는 AWS 콘솔이나 별도 테라폼 코드로 생성합니다.) S3 Bucket : my-company-tfstate-bucket (버전 관리 활성화 필수) DynamoDB Table : my-company-tfstate-lock (Partition Key는 반드시 LockID (String)로 지정) Step 2. 테라폼 Backend 블록 작성 # backend.tf terraform { required_version = ">= 1.0" backend "s3" { bucket = "my-company-tfstate-bucket" # S3 버킷 이름 key = "dev/infrastructure/terraform.tfstate" # 저장될 경로 region = "ap-northeast-2" encrypt = true # S3 암호화 사용 dynamodb_table = "my-company-tfstate-lock" # DynamoDB 락 테이블 이름 } } Step 3. 초기화 및 적용 설정이 완료된 후 아래 명령어를 실행하면, 테라폼이 로컬에 있던 State 파일을 S3로 안전하게 이관(Migrate)합니다. $ terraform init Initializing the backend... Do you want to copy existing state to the new backend? Enter a value: yes Successfully configured the backend "s3"! Terraform will now use this backend until the configuration changes. 이제 terraform apply 를 실행하면 테라폼 로그에 다음과 같이 락을 획득하고 해제하는 과정이 나타납니다. $ terraform apply Acquiring state lock. This may take a few moments... # 1. DynamoDB 락 획득 ... [인프라 생성 및 마이그레이션 진행] ... Releasing state lock. This may take a few moments... # 2. DynamoDB 락 해제 Apply complete! Resources: 1 added, 0 changed, 0 destroyed. 💡 마무리하며 IaC 기법을 도입할 때 단순히 테라폼 코드를 작성하는 것에만 집중하고 State 파일 관리 전략을 수립하지 않으면, 팀 규모가 커졌을 때 심각한 인프라 장애와 정합성 깨짐 현상을 겪게 됩니다. S3를 활용한 중앙 집중식 원격 저장 및 버전 관리 와 DynamoDB를 통한 동시성 락(State Lock) 구성은 안전한 데브옵스(DevOps) 파이프라인을 구축하기 위한 선택이 아닌 필수 아키텍처 입니다.