day-log

새벽 2시에 알림이 울렸다. 배포 파이프라인이 Error acquiring the state lock을 뱉고 멈춰 있었다. 락 ID를 들고 DynamoDB 콘솔에 들어가 강제로 항목을 지우고, 파이프라인을 재실행. 익숙한 절차였다. 근데 그날따라 이 절차가 어이없게 느껴졌다.우리 팀은 Terraform 1.11 무렵부터 S3 backend + DynamoDB 락을 써 왔다. 몇 년 잘 돌던 조합이다. 그런데 올봄에 팀 내부 논의 끝에 DynamoDB 락 테이블을 정리하기로 했다. 이유는 두 가지였다. 하나는 Terraform과 OpenTofu 양쪽 다 S3 네이티브 락을 밀고 있고 DynamoDB 방식이 사실상 deprecated가 됐다는 것. 다른 하나는 우리 조직에 IaC state가 40개 넘게 흩..

Terraform 1.11에서 S3 backend에 use_lockfile = true 옵션이 GA로 들어온 뒤로, 팀에서도 슬슬 DynamoDB lock table을 걷어내자는 얘기가 나왔다. 이유는 단순했다. DynamoDB 테이블 하나 유지하려고 IAM 정책 관리, provisioned capacity 알람, TTL 스크립트까지 붙어 있는 게 웃긴 상황이었다. state 파일 하나 지키자고 별도 서비스를 하나 더 굴리는 셈이니까.그런데 "S3 하나로 lock까지 다 처리한다"는 말이 처음엔 어색했다. S3는 오래도록 eventual consistency로 유명했던 스토리지고, DynamoDB의 conditional write처럼 원자적인 락을 걸 수 있는 프리미티브가 없다고 알고 있었기 때문이다. ..

Terraform 1.10에서 use_lockfile = true 옵션이 추가됐고, 1.11에 와서는 experimental 딱지가 떨어졌다. DynamoDB 테이블 없이 S3만으로 state lock을 거는 기능이다.처음 봤을 때 솔직히 좀 의심스러웠다. lock 메커니즘이라는 게 결국 "동시에 한 명만 쓰게" 만드는 건데, S3는 object storage고 트랜잭션 같은 게 없는데 어떻게? 그리고 DynamoDB는 강한 일관성(strong consistency)을 보장하는 KV store니까 lock 용도로 충분히 합리적이었다. 굳이 S3로 갈아탈 이유가 있나 싶었다.근데 마이그레이션을 준비하면서 내부를 까보니, 생각보다 깔끔하게 잘 만들어둔 구조였다. 단순히 "DynamoDB를 안 써도 된다"는 ..