Terraform force-unlock으로 인한 State 오염 및 38개 리소스 파괴 위기 복구

How we recovered tfstate after force-unlock raced a CI apply

Muhammad Hassaan Javed2026년 5월 19일12분intermediate

AI 요약

Context

S3 State Backend와 DynamoDB Lock을 사용하는 Terraform 환경에서 CI 작업과 수동 Apply 작업의 충돌 발생. Lock ID 미확인 상태의 force-unlock 실행으로 인한 동시 쓰기(Concurrent Write)가 State 파일의 정합성을 파괴한 상황.

Technical Solution

S3 Object Versioning 기반의 상태 이력 추적을 통한 최신 오염 시점 식별
S3 API를 활용해 충돌 전 마지막 정상 State Version(16:42 UTC)을 정밀하게 발췌
오염된 Live State를 제거하고 검증된 과거 버전으로 Restore 하는 롤백 전략 수행
단순 복구 후 누락된 변경분을 보완하기 위해 실제 인프라와 State 간 Drift를 분석한 Surgical Import 적용
State 파일의 타임스탬프와 CI 로그, 쉘 히스토리를 교차 검증하여 Race Condition 발생 시퀀스 규명

실천 포인트

1. State Lock 발생 시 Lock ID를 통해 실제 프로세스(CI Job 등)가 동작 중인지 우선 확인

2. Destroy Plan이 비정상적으로 높게 측정될 경우 Apply 중단 및 S3 Object Versioning 리스트 확인

3. State 복구 시 '전체 복구 후 필요한 리소스만 개별 Import' 하는 2단계 전략 수립

4. State 파일의 정량적 변경 빈도(예: 90초 내 3회 쓰기)를 통해 Race Condition 여부 판단

태그

#S3 Versioning #Terraform #Infrastructure as Code #State Locking #Race Condition

원문 읽기