Terraform S3 Backend의 DynamoDB 잠금 기능 종료

 

Terraform은 상태 파일(.tfstate)을 통해 현재 인프라의 구성을 추적하고 관리한다. 여러 명이 동시에 Terraform 작업을 수행할 경우, 상태 파일이 수정되면서 충돌이나 파일 손상을 일으킬 수 있다. 이러한 상황을 방지하기 위해 상태 파일 잠금 기능을 사용하는데, AWS S3를 backend로 사용하는 경우 DynamoDB를 활용한 상태 파일 잠금 기능을 사용해 왔다.

 

S3 자체 잠금 기능 도입

---

Terraform 1.10 버전부터 DynamoDB 없이도 S3 자체적으로 상태 잠금을 구현할 수 있는 새로운 기능이 실험적(experimental)으로 도입되었다. 이후 1.11 버전부터 GA(General Availability)로 제공되기 시작했고, 향후 버전에서는 기존 DynamoDB 기반 잠금을 완전히 제거할 계획이라고 한다.

 

그럼 기존 방식과 어떠한 차이점이 있는지 알아보자.

 

기존의 DynamoDB 상태 잠금 방식

---

Terraform이 실행되면 DynamoDB를 이용한 상태 잠금 기능은 다음과 같이 동작한다.

 

1. Terraform 작업 시작 시 DynamoDB 테이블에 잠금 항목 생성

• Terraform이 실행되면, DynamoDB 테이블에 고유한 LockID를 포함한 항목을 생성한다. 이때, 기존 항목이 없을 경우에만 추가되도록 한다.
• 잠금 항목이 이미 존재한다면, DynamoDB는 요청을 거부한다.

2. Terraform 작업 중 잠금 항목 유지

• DynamoDB의 잠금 항목은 작업이 진행되는 동안 유지된다.
• 이 항목이 존재하는 동안 새로운 Terraform 작업이 실행되면 DynamoDB는 오류를 반환하여 새로운 작업을 차단한다.

3. Terraform 작업 완료 후 잠금 항목 삭제

• Terraform이 작업이 완료되면 잠금 항목을 삭제하고, 이때부터 다른 Terraform 작업을 진행할 수 있다.

 

변경되는 S3 자체 상태 잠금 방식

---

S3 자체 상태 잠금 기능은 AWS의 S3의 "조건부 쓰기(Conditional Writes)" 기능과 관련이 있다. 이 기능은 S3 객체를 생성하거나 수정할 때 특정 조건을 만족해야만 작업이 수행되도록 하는 기능이다. 이를 통해 S3 객체의 덮어쓰기나 충돌을 방지할 수 있고, Terraform은 이 기능을 활용하여 상태 잠금 기능을 구현하게 된다.

참고

조건부 쓰기(Conditional Writes)에 대한 자세한 내용은 여기를 참고한다.

 

Terraform이 실행되면 S3 자체 상태 잠금은 다음과 같이 동작한다.

 

1. Terraform 작업 시작 시 .tflock 파일 생성

• Terraform 작업이 실행되면 '.tflock' 파일을 S3에 생성한다. 이때, If-None-Match 헤더를 사용하여 파일이 존재하지 않을 경우에만 생성되도록 한다.
• '.tflock' 파일이 이미 존재한다면, S3는 요청을 거부한다.

2. Terraform 작업 중 '.tflock' 파일 유지

• '.tflock' 파일은 작업이 진행되는 동안 유지된다.
• 이 파일이 존재하는 동안 새로운 Terraform 작업이 실행되면, S3는 새로운 작업을 차단한다.

3. Terraform 작업 완료 후 '.tflock' 파일 삭제

• Terraform이 작업이 완료되면 '.tflock' 파일을 삭제하고, 이때부터 다른 Terraform 작업을 진행할 수 있다.

 

S3 자체 상태 잠금을 활성화하는 것은 매우 간단하다. 먼저 다음과 같이 IAM 정책에 대한 권한이 필요하다.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:PutObject",
        "s3:DeleteObject"
      ],
      "Resource": "arn:aws:s3:::{S3_Bucket_Name}/*"
    }
  ]
}

 

다음과 같이 기존 DynamoDB 관련 설정을 주석 처리하거나 제거하고, 'user_lockfile = true' 옵션을 추가하면 된다.

terraform {

  #... 중략
  
  backend "s3" {
    key          = "test/terraform.tfstate"
    bucket       = "test-s3"
    region       = "ap-northeast-2"
    # dynamodb_table = "test-ddb-tflock"  # 제거 또는 주석    
    use_lockfile = true                   # S3 자체 잠금 기능 활성화
  }
}

 

그런 다음 Terraform init 명령어를 통해 변경된 backend 설정을 반영하면 끝이다. 위에서 언급했듯이 Terraform 버전이 1.10 이상이어야 한다.

$ terraform init -reconfigure

 

설정이 완료되었다면 terraform 명령어를 실행한 후 S3 버킷을 확인한다. 그러면 다음과 같이 '.tflock' 파일이 생성된 것을 확인할 수 있다.

 

Terraform 작업이 완료되어 종료되면 위에서 생성되었던 '.tflock' 파일은 지워져 있을 것이다.

 

S3 자체 상태 잠금을 사용함으로써 얻게 되는 장점

---

기존 DynamoDB를 사용하다 S3 자체 상태 잠금 방식으로 변경함으로써 얻게 되는 장점을 정리하자면 다음과 같다.

 

1. 구성 단순화

기존 DynamoDB 기반 잠금 방식에서는 DynamoDB 테이블을 생성하고 관리해야 했지만, S3 자체 상태 잠금은 추가 리소스 없이 S3만으로 구현 가능하다. Terraform 백엔드 설정에서 'use_lockfile = true' 옵션만 추가하면 되기 때문에 인프라 구조가 단순해지고 초기 설정이 간단해진다.

 

2. 비용 절감

DynamoDB 하나를 사용할 때는 비용이 크지 않지만 여러 프로젝트와 환경에서 사용하는 경우 비용을 무시할 수 없다. 또한 S3 자체 상태 잠금은 S3의 조건부 쓰기를 활용하기 때문에 별도의 추가 요금이 발생하지 않아 비용을 절감할 수 있다. 

 

3. 유연성 확보

DynamoDB는 AWS 전용 서비스라 AWS 환경에서만 사용이 가능했다. 반면, S3 자체 잠금은 S3 호환 스토리지를 사용하는 멀티 클라우드 환경에서도 사용할 수 있어 기존 방식보다 더 유연한 인프라 구성이 가능하다.

 

4. 권한 관리 간소화

DynamoDB와 S3를 모두 관리해야 했던 기존 방식과는 달리, S3 자체 잠금은 S3 버킷에 필요한 권한(s3:GetObject, s3:PutObject, s3:DeleteObject)만 설정하면 되기 때문에 IAM 정책이 더 단순해져 관리가 수월해진다.