엉금엉금 테라폼 적용하기 (7) - 탄력적 IP와 DNS 연동해서 EC2 만들기

탄력적 IP와 DNS 연동해서 EC2 만들기

Terraform

 

1. 테라폼으로 ECS 생성 중 이슈 발생

우리 프로젝트는 AWS의 ECS를 활용하여 스프링 부트 애플리케이션을 운영하고 있다. 그리고 스프링 부트 애플리케이션에서 Zipkin의 추적 기능을 사용하기 위해서는, Zipkin 서버의 정확한 주소(엔드 포인트)가 필요했다. 그러나 테라폼으로  ECS 클러스터와 EC2 인스턴스를 재생성할 때마다 Zipkin 서버의 IP 주소가 변경되는 문제가 발생했다.

 

처음 고려했던 해결책 중 하나는 Application Load Balancer(ALB)를 사용하는 것이었다. 이 방식은 Zipkin 서버를 위한 별도의 ALB를 생성하고, 이 ALB의 퍼블릭 IP를 스프링 부트 애플리케이션에 설정하는 것이었다. 하지만, ALB는 주로 트래픽 분산 처리를 목적으로 사용되며, 이 경우와 같이 단순히 고정 IP 주소를 제공하는 용도로 사용하기에는 비용적으로 비효율적이라는 결론에 도달했다. 또한, 프로젝트의 기존 ALB 비용도 이미 상당히 높은 상태였다.

 

다음으로 고려했던 해결 방안은 Elastic IP(탄력적 IP)를 사용하는 것이었다. Elastic IP를 Zipkin 인스턴스에 연결하면, 인스턴스가 재생성되어도 IP 주소가 변하지 않는 장점이 있었다. 그러나 이 방안도 고려 중, 어차피 나중에 프로젝트에 적용할 도메인 이름을 구매할 계획이 있었기때문에 단순히 고정 IP로 해결하는게 아니라 도메인까지 연동해서 해결하기로 했다.

 

그래서 최종적으로 선택한 해결책은 Amazon Route 53 DNS 서비스를 사용하여 Elastic IP와 도메인 이름을 연동하는 것이었다. 이 방법을 통해, 탄력적 IP 주소가 변경되더라도 도메인 이름을 통해 Zipkin 서버에 안정적으로 접근할 수 있게 되었다. 이는 스프링 부트 애플리케이션 코드의 Zipkin 엔드포인트 주소를 변경할 필요 없이, 일관된 도메인 주소를 통해 서비스를 운영할 수 있게 해주었다.

 

이러한 결정은 효율성, 비용, 그리고 장기적인 관리 측면에서 최선의 선택이었다. Elastic IP와 DNS 연동 방식은 안정적인 서비스 운영을 보장하고, 불필요한 코드 변경을 줄여 개발 효율성을 높였으며, 향후 확장성과 유연성을 고려한 장기적인 해결책이 되었다.

 

(Amazon Route 53 DNS 생성과 서브 도메인 추가에 대한 자세한 내용은 추후 별도의 글에서 다루도록 하겠다. 그리고 이번 글에서는 탄력적 IP와 구매한 DNS가 이미 있다고 가정하고 진행한 내용이다.)

 

 

2. 탄력적 IP와 DNS 간단 개념 정리

탄력적 IP (Elastic IP)

 

Elastic IP 주소는 AWS에서 제공하는 고정된 공용 IP 주소다. 이 주소는 특정 AWS 리소스에 할당되며, 해당 리소스가 변경되거나 재시작될 때도 IP 주소가 변하지 않는다. 예를 들어, EC2 인스턴스에 Elastic IP를 할당하면, 인스턴스가 재시작되거나 다른 인스턴스로 이동해도 IP 주소는 동일하게 유지된다.

 

Elastic IP의 핵심 장점은 안정성과 유연성에 있다. 고정된 IP 주소를 사용함으로써, 언제든지 동일한 주소로 인스턴스에 접근할 수 있다. 이는 서버나 애플리케이션에 대한 신뢰성 있는 접근을 보장하며, 특히 중요한 서비스나 장기적인 프로젝트에서 유리하다. 또한, 인스턴스 장애 시 빠르게 다른 인스턴스에 IP 주소를 재할당함으로써 시스템의 가용성을 유지할 수 있다.

 

Route 53 DNS

 

Route 53은 AWS의 확장 가능한 도메인 이름 시스템(DNS) 서비스로, 도메인 이름을 IP 주소로 변환하는 기능을 제공한다. 사용자가 웹 브라우저나 애플리케이션을 통해 도메인 이름으로 요청을 보내면, Route 53은 적절한 서버의 IP 주소로 트래픽을 라우팅한다.

 

Route 53의 주요 기능은 도메인 이름의 관리, 효과적인 트래픽 라우팅, 그리고 건강 검사가 있다. 사용자는 Route 53을 통해 새 도메인을 등록하거나 기존 도메인을 관리할 수 있다. 또한, 다양한 라우팅 정책을 이용하여 트래픽을 효율적으로 분산시키고, 웹 서버의 가용성을 모니터링할 수 있다.

 

 

3. 추가적인 작업

우리 프로젝트에서는 대부분의 서비스를 ALB와 연동하여, EC2 Launch Template과 함께 용량 공급자를 사용해 EC2 인스턴스를 생성하고 관리해왔다. 이 방식은 클라우드 리소스의 효율적인 관리와 더불어 스케일링의 유연성을 제공한다.

 

그러나 Zipkin 서비스는 이와 다른 접근을 필요로 했다. Zipkin의 경우, 특별한 설정이 필요하며, 그 중에서도 탄력적 IP 할당과 DNS 설정이 중요한 부분을 차지한다. 이러한 요구사항을 충족시키기 위해, 우리는 Zipkin을 위한 별도의 EC2 인스턴스를 구성하기로 결정했다. 이는 기존의 EC2 인스턴스 구성과 다르게, 특정 애플리케이션의 요구사항에 맞추어져 있다.

 

아래부터는 Zipkin용 EC2 인스턴스를 설정하는 과정을 살펴볼 것이다. 이 설정에는 Zipkin 전용 EC2 인스턴스의 생성 및 관련 네트워크와 보안 설정이 포함된다. 여기에는 탄력적 IP와 Route 53을 통한 DNS 레코드 설정이 포함되어 있어, Zipkin 서버가 안정적으로 작동하며 외부 접근이 가능하도록 보장한다.

 

 

4. EC2 인스턴스 모듈

main.tf

resource "aws_instance" "zipkin_instance" {
  ami                    = var.ami_id
  instance_type          = var.instance_type
  key_name               = var.key_name
  subnet_id              = var.subnet_id
  vpc_security_group_ids = var.vpc_security_group_ids
  iam_instance_profile   = var.iam_instance_profile

  # 변수로부터 파일 경로를 동적으로 설정
  user_data              = file("${path.module}/${var.user_data_file}")  

  tags = {
    Name = var.instance_name
  }
}

resource "aws_eip_association" "zipkin_eip_association" {
  instance_id   = aws_instance.zipkin_instance.id
  allocation_id = var.eip_allocation_id
}

resource "aws_route53_record" "zipkin_dns" {
  zone_id = var.route53_zone_id
  name    = var.route53_record_name
  type    = "A"
  ttl     = var.route53_record_ttl
  records = [aws_eip_association.zipkin_eip_association.public_ip]
}

 

위 코드에는 세개의 resouce가 있다. 각 리소스별로 상세히 정리해보자.

 

EC2 인스턴스 생성 (resource "aws_instance" "zipkin_instance")

 

이 리소스는 AMI, 인스턴스 타입, SSH 키, 서브넷 ID, 보안 그룹, IAM 인스턴스 프로파일 등의 파라미터를 사용하여 EC2 인스턴스를 생성한다. user_data는 인스턴스 시작 시 실행할 스크립트를 정의한다.

 

• ami: Amazon Machine Image (AMI) ID를 사용하여 EC2 인스턴스의 운영 체제(OS)를 정의한다.
• instance_type: 인스턴스의 사양(예: t4g.micro)을 지정한다.
• key_name: EC2 인스턴스에 접근하기 위한 SSH 키의 이름을 지정한다.
• subnet_id: 인스턴스가 위치할 서브넷 ID를 지정한다.
• vpc_security_group_ids: 인스턴스에 적용할 보안 그룹 ID를 지정한다.
• iam_instance_profile: 인스턴스에 할당할 IAM 역할을 정의한다.
• user_data: 인스턴스 시작 시 실행할 스크립트의 파일 경로를 지정한다. 이 스크립트는 인스턴스 구성이나 소프트웨어 설치 등을 자동화하는 데 사용된다.
• tags: 인스턴스에 이름 태그를 할당하여 관리를 용이하게 한다.

 

Elastic IP 연결 (resource "aws_eip_association" "zipkin_eip_association")

 

이 리소스는 특정 EC2 인스턴스(aws_instance.zipkin_instance.id)에 Elastic IP(eip_allocation_id)를 연결한다. 이를 통해 인스턴스에 고정된 공용 IP 주소가 제공된다.

 

• instance_id: Elastic IP를 연결할 EC2 인스턴스의 ID를 지정한다. 이 코드에서 사용되는 instance_id는 aws_instance "zipkin_instance" 리소스를 통해 생성된 EC2 인스턴스의 ID를 참조한다. 즉, 이전에 정의된 EC2 인스턴스에 할당된 고유 ID를 사용하여, 해당 인스턴스에 Elastic IP를 연결하는 데 사용된다.
• allocation_id: 연결할 Elastic IP의 할당 ID를 지정한다. Elastic IP가 해당 EC2 인스턴스에 할당되면, 인스턴스는 고정된 공용 IP 주소를 갖게 되며, 이 주소는 인스턴스가 재시작되거나 다른 인스턴스로 이동해도 변경되지 않는다.

 

Route 53 DNS 레코드 설정 (aws_route53_record "zipkin_dns"):

 

이 리소스는 AWS Route 53의 기존 DNS 호스팅 영역(zone) 내에 새로운 서브 도메인(레코드)을 생성하고 관리하는 것에 초점을 맞추고 있다. 이 코드는 전체 DNS 시스템을 생성하는 것이 아니라, 특정 도메인(route53_record_name)에 대한 A 타입 레코드를 추가하고, 필요에 따라 변경 또는 삭제하는 작업을 자동화한다. 생성된 레코드는 Elastic IP 주소를 가리키도록 설정된다.

 

• zone_id: DNS 레코드를 생성할 Route 53 호스팅 영역의 ID를 지정한다.
• name: DNS 레코드의 이름(도메인 이름)을 지정한다.
• type: DNS 레코드 유형을 지정합니다. 여기서는 "A" 레코드 유형이 사용된다.
• ttl: DNS 레코드의 Time To Live(TTL) 값을 지정한다. TTL은 DNS 쿼리 응답이 캐시되는 시간을 초 단위로 설정한다.
• records: DNS 레코드가 가리킬 값으로, 여기서는 Elastic IP 주소가 사용된다.

 

이 구성을 통해 Zipkin 서비스를 위한 전용 EC2 인스턴스가 생성되며, 이 인스턴스는 탄력적 IP 주소와 DNS 레코드를 통해 안정적으로 접근 가능하게 된다. 이렇게 설정함으로써, Zipkin 서버의 IP 주소는 고정되며, Route 53을 통해 설정된 도메인 이름으로 서버에 접근할 수 있게 된다. 이는 서버의 IP 주소가 변경되더라도 스프링 부트 애플리케이션의 Zipkin 설정을 변경할 필요가 없도록 해준다.

 

잠시 여기서 DNS의 type과 ttl에 대해서 간략하게 살펴보자

 

💡 DNS type

 

DNS 레코드 타입은 여러 종류가 있으며, 각 타입은 다른 용도로 사용된다. 일반적인 타입 중 몇 가지를 소개하면 다음과 같다:

1. A 레코드 (Address Record): 도메인 이름을 IPv4 주소로 매핑한다. 예를 들어, example.com을 192.0.2.1과 같은 IP 주소로 지정할 때 사용된다. 이는 가장 일반적인 레코드 타입 중 하나다.
2. AAAA 레코드 (IPv6 Address Record): 도메인 이름을 IPv6 주소로 매핑한다. A 레코드와 유사하지만, IPv6 주소를 사용한다.
   CNAME 레코드 (Canonical Name Record): 하나의 도메인 이름을 다른 도메인 이름으로 리디렉션한다. 예를 들어, http://www.example.com을 example.com으로 리디렉션할 때 사용된다.
3. MX 레코드 (Mail Exchange Record): 이메일 서버의 주소와 우선순위를 지정한다.
4. TXT 레코드 (Text Record): 도메인에 텍스트 정보를 제공한다. 다양한 용도로 사용되며, 일반적으로 도메인 소유 확인과 같은 목적으로 사용된다.

우리 프로젝트에서 "A 레코드"를 사용한 이유는 특정 도메인 이름을 IPv4 주소, 즉 Elastic IP로 직접 매핑하기 위함이다. 이는 웹 브라우저나 다른 클라이언트가 해당 도메인 이름을 요청할 때, 지정된 고정 IP 주소로 연결되도록 하는 가장 직접적인 방법이다.

 

💡 DNS ttl

 

ttl은 Time To Live의 약자로, DNS 레코드의 캐시 시간을 초 단위로 지정한다. DNS 쿼리 응답이 클라이언트 시스템이나 중간 DNS 서버에 캐시되는 시간을 결정한다. ttl 값이 낮을수록 DNS 정보가 자주 갱신되며, 높을수록 덜 자주 갱신된다.

예를 들어, ttl이 300으로 설정되면, DNS 레코드의 정보는 5분(300초) 동안 캐시되고 이후에는 새로운 쿼리가 필요하게 된다. 이는 도메인에 대한 IP 주소 변경이나 다른 DNS 설정 변경이 자주 발생하지 않는 경우 적합한 설정이다. 짧은 ttl은 DNS 변경사항이 빠르게 전파되도록 하지만, 너무 짧으면 빈번한 DNS 조회로 인한 추가적인 네트워크 트래픽이 발생할 수 있다. 따라서 ttl 값은 서비스의 특성과 요구사항에 따라 적절하게 조절해야 한다.

 

outputs.tf

 

이 파일은 테라폼의 출력값을 정의한다. 여기에서는 두 가지 정보를 출력하고 있다.

output "instance_id" {
  value = aws_instance.zipkin_instance.id
}

output "instance_public_ip" {
  value = aws_instance.zipkin_instance.public_ip
}

• instance_id: 이 출력값은 생성된 EC2 인스턴스의 고유 식별자(ID)를 제공한다. 이 ID는 인스턴스의 관리 및 참조에 사용된다.
• instance_public_ip: 이 출력값은 생성된 EC2 인스턴스의 공용 IP 주소를 제공한다. 이 주소를 사용하여 인스턴스에 외부에서 접근할 수 있다.

 

variables.tf

 

이 파일은 테라폼 코드에서 사용되는 변수들을 정의한다. 각 변수는 특정 인프라 구성 요소의 설정을 위해 사용된다.

variable "ami_id" {}

variable "instance_type" {}

variable "key_name" {}

variable "subnet_id" {}

variable "vpc_security_group_ids" {}

variable "iam_instance_profile" {}

variable "user_data_file" {}

variable "eip_allocation_id" {}

variable "route53_zone_id" {}

variable "route53_record_name" {}

variable "route53_record_ttl" {}

variable "instance_name" {

description = "The name of the EC2 instance"

type = string

}

• ami_id, instance_type, key_name, subnet_id, vpc_security_group_ids, iam_instance_profile, user_data_file: 이 변수들은 EC2 인스턴스 생성 시 사용되는 설정 값들을 지정한다.
• eip_allocation_id: Elastic IP의 할당 ID를 지정한다.
• route53_zone_id, route53_record_name, route53_record_ttl: Route 53 DNS 레코드 설정에 사용된다.
• instance_name: EC2 인스턴스의 이름을 지정한다. description 필드로 변수의 용도에 대한 설명을 추가할 수 있으며, type = string은 변수 값이 문자열 타입임을 명시한다.

 

user_data.sh

 

이 스크립트 파일은 EC2 인스턴스가 처음 시작될 때 실행된다

#!/bin/bash
echo ECS_CLUSTER=zipkin-ecs-cluster >> /etc/ecs/ecs.config

 

위의 명령은 생성된 EC2 인스턴스에 ECS 클러스터 설정을 추가한다. 이렇게 함으로써, 인스턴스는 zipkin-ecs-cluster라는 이름의 ECS 클러스터에 자동으로 등록된다. /etc/ecs/ecs.config 파일은 Amazon ECS 에이전트가 인스턴스에 구성된 클러스터를 인식하는 데 사용되는 파일이다.

 

5. 루트 디렉토리의 main.tf

아래 이미지는 launch template, 용량 공급자를 사용하지 않고 직접 EC2 인스턴스를 생성하는 모듈을 사용하는 모습이다.

EC2 인스턴스 사용

 

아래는 ECS 클러스터를 생성하는 코드다.

ECS 클러스터 생성

 

아래는 ECS 서비스를 생성하는 코드다.

ECS 서비스 생성

 

아래는 zipkin의 태스크 정의를 생성하는 코드다.

 

 

아래는 이제 테라폼을 적용하는 전체 코드를 작성한 내용이다.

provider "aws" {
  region = "us-west-2"  // 예시 AWS 리전 설정
}

module "network_module" {
  source      = "./network"  // 네트워크 모듈 경로
  vpc_id      = "vpc-xxxxxx"         // 예시 VPC ID
  subnet_ids  = ["subnet-xxxxx", "subnet-yyyyy"]  // 예시 서브넷 ID들
}

# EC2 런치 템플릿 설정. EC2 인스턴스를 생성하기 위한 설정을 정의한다.
module "test_launch_template" {
  source                = "./ec2_launch_template"
  name_prefix           = "test-ec2"
  image_id              = "ami-xxxxxxxxxxxxxxxxx"  // 예시 AMI ID
  instance_type         = "t2.micro"
  key_name              = "test-keypair"
  vpc_security_group_ids = ["sg-xxxxxxxxxxxxxxx"]  // 예시 보안 그룹 ID
  iam_instance_profile  = "testInstanceRole"
  ec2_instance_name     = "ec2_test"
  user_data_file        = "test_user_data.sh"
}

# 테스트용 오토 스케일링 그룹 생성
module "test_asg" {
  source               = "./autoscaling_group"
  vpc_subnets          = ["subnet-aaaaaa", "subnet-bbbbbb", "subnet-cccccc"]  // 예시 서브넷 ID들
  launch_template_id   = module.test_launch_template.launch_template_id
  name_prefix          = "test"
}

# ECS 용량 공급자 모듈 생성
module "ecs_capacity_provider" {
  source                     = "./ecs_capacity_provider"
  name                       = "example-ecs-capacity-provider"
  auto_scaling_group_arn     = "arn:aws:autoscaling:us-west-2:123456789012:autoScalingGroup:xxxx-xxxx-xxxx:autoScalingGroupName/xxxx-xxxx"
  maximum_scaling_step_size  = 1
  minimum_scaling_step_size  = 1
  status                     = "ENABLED"
  target_capacity            = 100
  cluster_name               = "example-ecs-cluster"
  base                       = 1
  weight                     = 100
}

# EC2 인스턴스 설정 - 지프킨 전용
module "ec2_instance" {
  source                = "./ec2_instance"
  ami_id                = "ami-abcdefgh12345678"
  instance_type         = "t4g.micro"            
  key_name              = "example-keypair"      
  subnet_id             = "subnet-1234abcd"      
  vpc_security_group_ids = ["sg-1234abcd"]       
  user_data_file        = "example_user_data.sh" 
  instance_name         = "example-instance"     
  iam_instance_profile  = "exampleInstanceRole"  
  eip_allocation_id     = "eipalloc-12345678"    
  route53_zone_id       = "Z123ABC456XYZ789"     
  route53_record_name   = "example.domain.com"   
  route53_record_ttl    = "300"                  
}

# zipkin ECS 클러스터 생성
module "ecs_zipkin_cluster" {
  source = "./ecs_cluster"

  cluster_name = "zipkin-ecs-cluster"
}

# 테스트 ECS 클러스터 생성
module "ecs_member_cluster" {
  source        = "./ecs_cluster"
  cluster_name  = "example-ecs-cluster"
}

# ALB를 적용하는 ECS 서비스 생성
module "ecs_cluster_service_member" {
  source              = "./ecs_service"
  ecs_service_name    = "member-service-prod"
  ecs_cluster_name    = module.ecs_member_cluster.ecs_cluster_name
  asg_arn             = "arn:aws:autoscaling:us-west-2:123456789012:autoScalingGroup:yyyy-yyyy-yyyy:autoScalingGroupName/yyyy-yyyy"
  task_definition     = "arn:aws:ecs:us-west-2:123456789012:task-definition/member-task"
  capacity_provider_name = "example-capacity-provider"

  target_group_arn       = "arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/dummy-tg/xxxxx"
  container_name         = "dummy-container"
  container_port         = 8081
}

# ALB를 적용하지 않는 ECS 서비스 생성
module "ecs_cluster_service_zipkin" {
  source            = "./ecs_service"
  ecs_service_name  = "zipkin-service-prod"
  ecs_cluster_name  = "example-zipkin-cluster"
  task_definition   = "arn:aws:ecs:us-west-2:123456789012:task-definition/zipkin-task"
}

# 지프킨 ECS 서비스 생성. 지프킨을 위한 ECS 서비스를 설정한다.
module "ecs_cluster_service_zipkin" {
  source = "./ecs_service"

  ecs_service_name = "zipkin-service"
  ecs_cluster_name = "example-zipkin-cluster"  // ECS 클러스터 이름을 변경한다.

  # 태스크 정의를 설정한다. 이전에 정의한 태스크 정의 모듈을 참조한다.
  task_definition   = module.zipkin_task_definition.task_definition_arn
}



# ECS 태스크 정의: 멤버 
module "member_task_definition" {
  source              = "./task_definition"
  family_name         = "dummy-member-prod"
  execution_role_arn  = "arn:aws:iam::123456789012:role/ecsTaskExecutionRole"
  cpu                 = 512
  memory              = 512

  # 컨테이너 정의 JSON 예시
  container_definitions = jsonencode([
    {
      name           = "dummy-member-container"
      image          = "123456789012.dkr.ecr.us-west-2.amazonaws.com/dummy-member"
      cpu            = 512
      memory         = 512
      essential      = true
      portMappings = [
        {
          containerPort = 8081
          hostPort      = 0
          protocol      = "tcp"
        }
      ]
      secrets = [
        // 비밀 데이터 예시
        {
          name      = "SECRET_NAME"
          valueFrom = "arn:aws:secretsmanager:us-west-2:123456789012:secret:dummy-secret"
        }
        // 추가적인 비밀 데이터
      ]
      logConfiguration = {
        logDriver = "awslogs"
        options = {
          "awslogs-group"         = "/ecs/dummy-member-prod"
          "awslogs-region"        = "us-west-2"
          "awslogs-stream-prefix" = "ecs"
        }
      }
    }
  ])
}


# 지프킨 태스크 정의. 지프킨 컨테이너를 실행하기 위한 설정을 정의한다.
module "zipkin_task_definition" {
  source = "./task_definition"
  family_name = "zipkin-family"
  execution_role_arn = "arn:aws:iam::123456789012:role/ecsTaskExecutionRole"
  cpu = 512
  memory = 512

  # 컨테이너 정의 JSON을 설정한다. 지프킨 이미지와 로그 설정을 포함한다.
  container_definitions = jsonencode([
    {
      name         = "zipkin-container"
      image        = "123456789012.dkr.ecr.us-west-2.amazonaws.com/zipkin-image"
      cpu          = 512
      memory       = 512
      essential    = true
      portMappings = [
        {
          containerPort = 9411
          hostPort      = 9411
          protocol      = "tcp"
        }
      ]
      logConfiguration = {
        logDriver = "awslogs"
        options = {
          "awslogs-group"         = "/ecs/zipkin"
          "awslogs-region"        = "us-west-2"
          "awslogs-stream-prefix" = "ecs"
        }
      }
    }
  ])
}

 

 

 

6. 마무리

여기까지 오기까지는 정말 많은 시간과 노력이 필요했다. 우리나라에서 테라폼에 관한 자료는 아직 부족한 편이고, 우리 프로젝트에 바로 적용할 수 있는 좋은 예시 코드를 찾기도 쉽지 않았다. 테라폼에 대한 기본적인 개념은 널리 알려져 있지만, 실제로 어떻게 코드를 작성해야 하는지에 대한 구체적인 정보는 찾기 어려웠다.

그래도 챗 GPT한테도 물어봐가면서 코드를 작성하고 실제 프로젝트를 진행하면서 처음에는 모든 코드를 하나의 main.tf 파일에 작성했다. 그러나 점점 코드가 복잡해지고 관리가 어려워짐에 따라, 모듈화를 진행하기로 결정했다. 이 과정을 통해 코드가 훨씬 명확해지고 이해하기 쉬워졌다.

테라폼을 처음 도입할 때는 진입장벽이 상당히 높게 느껴졌다. 하지만 실제로 코드를 작성하고, 그 결과 AWS 비용이 전달 대비 90%나 절감된 것을 직접 확인하니, 그 어떤 것보다 큰 성취감을 느꼈다. 이 경험은 어려운 도전에 맞서서 성공을 거둘 수 있다는 것을 보여주는 좋은 사례가 되었다.

이 블로그 글을 통해, 나와 비슷한 환경에서 인프라를 구축하고 있거나, 비용 절감을 위해 테라폼을 도입하려는 개발자들에게 실질적인 도움이 되기를 바란다. 나의 경험이 그들의 프로젝트에 유용한 통찰과 지침을 제공할 수 있기를 희망한다.

 

Dynamic 블록으로 AWS 서비스와 태스크 정의하기

엉금엉금 테라폼 적용하기 (6) - Dynamic 블록으로 AWS 서비스와 태스크 정의하기

 

 

 

이 포스트는 Team chillwave에서 사이드 프로젝트 중 적용했던 부분을 다시 공부하며 기록한 것입니다.

시간이 괜찮다면 팀원 '개발자의 서랍'님의 블로그도 한번 봐주세요 :)

개발자의 서랍