팀에서 테라폼을 도입하고 얻은 것들

배경 소개 

팀에서 새로 인프라 구조, 아키텍처를 구성해야 하는 일이 있었다. 우리 팀은 Container 기반으로 서버를 운영하여, AWS ECS + Fargate를 사용하여 배포하기로 결정했다. 이때 VPC, ECR, ECS의 배포 정책이나 오토 스케일링을 모두 Terraform으로 관리하여 인프라 구성을 코드로 작성할 수 있도록 작업하였다. 이 글에선 이런 구조를 선택한 근거와 함께, 테라폼을 사용해서 얻을 수 있었던 팀 시점의 이점을 소개하려고 한다.
 

ECS + Fargate

우선 컨테이너를 사용한 배포를 전제로 하였다. 배포를 위한 파일 관리보다 컨테이너 이미지 관리가 훨씬 쉽고, 컨테이너 런타임만 있는 환경이라면 쉽게 배포하고 앱을 확인해 볼 수 있으니까. AWS의 '이 글'을 참고하여 우리 팀에 가장 어울리는 컨테이너 관리 환경을 비교하였다. 비교 옵션은 Beanstalk, ECS, EKS이었고, 작은 팀이라 모두가 배포 방법에 익숙하면서도 빠르게 환경을 구성해야 하는 상황에서 ECS가 가장 적합하다고 느꼈다.
 
ECS는 컨테이너 오케스트레이션 서비스이다. 컨테이너가 운영되는 환경으로 EC2와 Fargate를 선택할 수 있는데, Fargate는 AWS에서 완전 관리형으로 클러스터를 띄울 수 있는 환경을 제공하는 기술이다. 이해하길 Lambda처럼, AWS에서 모두 관리하는 서버 리스 컨테이너 컴퓨팅 엔진으로 이해했다. EC2 운영에 필요한 관리들을 모두 AWS에 맡기고, 애플리케이션 개발에 집중할 수 있도록 한다. 인프라 관리 리소스를 최소화하고 적은 러닝 커브와 빠른 개발이라는 팀의 성격에는 Fargate가 더 적절하다고 생각했다.
 

테라폼과 IaC

이렇게 선정한 ECS의 구축을 위한 AWS 리소스들은 모두 테라폼으로 작성, 코드로 관리하였다. 처음에는 다소 러닝 커브가 있었지만, 기반 코드를 만들어 소개하고 직접 한, 두 개 애플리케이션을 배포해 보면서 다들 금방 손에 익어하셨다. 낯선 코드, IaC 이점이 제대로 안보이셨을 텐데, 학습 열정 넘치는 팀원들을 만나 이 부분으로 열심히 리드해 볼 수 있었고, 이제는 다들 IaC의 이점을 확인하고 나 없이도 테라폼을 운영이 가능하실 정도까지 익숙해지셨다고 생각하고 있다. 다음은 그 과정에서 느꼈던 큰 이점들이다.
 

1. 빠른 찾기가 가능하다.

이를테면 Fargate 태스크의 메모리 설정을 확인하려 한다면 기존에는 AWS 콘솔을 찾아야 할 것이다. 콘솔에서 메뉴를 찾고, 리소스를 찾고, 메모리가 표시된 위치를 확인해야 할 것이다. 코드로 관리하고 나선 그런 일이 없다. 우리 팀은 모두 인텔리제이를 쓰고 있는데, 찾기 단축키를 누르고 원하는 리소스를 찾으면 찾고자 하는 정보가 코드로 적혀있다. 
 
특히 주석으로 리소스에 설명을 추가하거나 Git으로 형상 관리하여 어떤 사람이, 언제 작업했는지를 명확하게 찾을 수 있다는 점이 너무 크다. 문제가 생기면 그 시점의 변경을 찾고 고치거나, 빠르게 롤백할 수 있다. 이런 빠른 검색의 시원함이 너무 좋았다.

resource "aws_ecs_task_definition" "ecs_task_base" {
  family             = "task-base"
  execution_role_arn = aws_iam_role.ecs_task_execution_role.arn
  network_mode       = "awsvpc"
  requires_compatibilities = ["FARGATE"]
  cpu                = 256
  memory             = 512 
  ...
}

 

2. 인프라 지식이 향상되었다.

AWS에서 자원을 생성하면 뒤에선 알지 못하는 많은 자원들이 자동으로 생성되고 관리자는 이를 놓치기 쉬웠다. 코드로 인프라를 관리할 때는 이런 자동으로 생성되는 자원들, 알아서 처리했고, 또 놓쳤던 많은 옵션들, 리소스 간 관계들을 모두 직접 정의해야 한다. 그렇기에 어렵다고 느낄 수 있지만, 또 그렇기에 콘솔로는 못 배우는 인프라 지식들을 배울 수 있었다.
 
또 코드 리뷰가 가능하다. 콘솔로 인프라 작업을 했을 때는 "저 작업 마쳤어요, ~를 구성했어요"가 작업의 보고일 것이다. IaC를 도입한 우리 팀은 인프라 작업 후 인텔리제이를 켰다. 모니터를 상대에게 돌리고, 내가 작업한 내용을 코드로 설명했다. 코드의 구성을 통해 인지하지 못하는 리소스가 발생하진 않았는지 확인할 수 있었고, 리소스 간 관계를 파악하기에 좋았다. 평소에는 그냥 지나쳤던 리소스의 세세한 옵션들을 확인하고 리뷰할 수 있었다. 실제로 팀원들의 AWS 이해가 급격하게 상승했다고 느낀다.
 

3. 정책을 코드로 관리할 수 있다.

- 태스크의 메모리가 얼마 이상이면 몇 개까지 스케일 아웃 할 것인가.
- LB의 Target group 헬스 체크는 몇 초 이후부터 실행할 것이고, 몇 초 간격으로 몇 번 시도할 것인가.
- 애플리케이션 배포는 어떤 방식으로 전환될 것인가.
- 로그는 몇 일간 기록할 것인가
 
콘솔로 관리했으면 이런 주요 인프라 정책들을 문서로 관리했을 것이다. 정책을 확인하려면 콘솔이나 문서를 찾아야 한다는 번거로움이 있을 것이고, 그 둘의 싱크도 의심해야 할 것이다. IaC를 처리하고선 이런 정책들을 모두 코드로 남길 수 있었다. 그리고 그 내용이 싱크 되어 있는지는 걱정하지 않아도 될 것이다. 또 정책이 바뀐다면 그 부분의 변수만 값을 변경하면 그만이다. 
 
실제로 부하테스트와 함께 오토 스케일링을 정책을 확인할 때나 배포 시 중단이 발생하는지를 확인하는 과정에서 단순히 그 부분의 숫자만 변경하여 테라폼 적용하는 것으로, 다양한 케이스를 빠르게 테스트하며 가장 적합한 값을 찾을 수 있었다. 
 

resource "aws_appautoscaling_policy" "scale_out_policy_base" {
  name              = "scale-out-policy-base-${substr(uuid(), 0, 5)}"
  policy_type       = "TargetTrackingScaling"

  target_tracking_scaling_policy_configuration {
    target_value       = 60.0
    scale_out_cooldown = 120
    predefined_metric_specification {
      predefined_metric_type = "ECSServiceAverageMemoryUtilization"
    }
  }

 
 

ECS + Fargate Terraform 뼈대 코드

테라폼으로 서비스 운영을 구성하기 위한 뼈대 코드를 공유한다.

https://github.com/ecsimsw/terraform-ecs-skeleton
 
코드에는 아래 모듈과 리소스들이 정의되어 있다. 이 Terraform만 돌리면 다른 구성없이 ECS로 서비스가 운영되고 헬스 체크, 오토 스케일링, 요청 처리가 된다. 단, 생성되는 ECR에 본인의 컨테이너 이미지를 업로드하고, ECS의 service에 배포하고자 하는 이미지 정보는 정의해야 한다.
 

vpc :
   - Internet gateway
   - NAT gateway
   - Public subnet 
   - Private subnet
   - Route table
service : 
   - Ecs cluster
   - Service
   - Fargate task
   - Auto scale policy
   - CloudWatch Log stream
   - Container repository (ECR)
lb :
   - ALB
   - Security group
events : 
   - Sns
   - Sqs

 
무엇보다 IaC의 힘을 확인해 보셨으면 좋겠다. 열심히 구성한 아키텍처가 코드로 관리되어 리뷰될 수 있고, 검색될 수 있고, 간단하게 재배포될 수 있음을 경험해봤으면 한다. AWS 인프라 설계와 리소스 이해에도 큰 도움이 될 것이라 생각한다.