[AWS - Terraform] Auto Scaling

* 참조 사항
- 필자는 학습을 목적으로 main.tf에 전체 인프라 구축 코드를 작성하였으며, 이에 대해 각기 설명함
- .tf 파일을 resource 별로 분할할 시, 필자와 코드가 다를 수 있음
- Terraform 기초부터 순차적으로 보길 권장 (1번 게시물의 이해가 매우 중요)

1. Architecture Create : https://isc9511.tistory.com/163

2. Bucket 생성 및 파일 업로드 : https://isc9511.tistory.com/164

3. IAM Role 생성 및 정책 Attachment : https://isc9511.tistory.com/165

4. Network Setting : https://isc9511.tistory.com/166

5. RDS 생성 : https://isc9511.tistory.com/167

6. Instance(EC2) 생성 : https://isc9511.tistory.com/168

 

 

 

* Auto Scaling : EC2에서 운용되는 애플리케이션의 부하를 적절하게 처리할 수 있도록 지정한 수로 EC2 인스턴스를 생성, 삭제 하도록 자동으로 구성하는 서비스

 

 

 

* Code 내용
- Auto Scaling의 경우 원본 인스턴스를 기준으로 동일한 역할을 수행할 수 있도록 AMI Imaging을 수행하여 복제한 Template을 Attach하여 인스턴스가 자동으로 생성, 삭제 되도록함

- 원본 EC2 AMI Imaging(Template 생성) -> 시작 구성(Launch Configuration) 설정 -> Auto Scaling Group 생성

1) AMI Imaging을 통한 Auto Scaling용 Template 생성

# 설정이 완전한 인스턴스 대상으로 AMI Imaging
resource "aws_ami_from_instance" "app-layer-AS-template-ami" {
  name = "AppTierImage"
  source_instance_id = aws_instance.applayer.id
  depends_on = [aws_instance.applayer]
    # 인스턴스 명령어가 많이 입력되므로 완료된 후에 AMI Imaging 진행
      # 만약 테스트 시, 정상적으로 명령어가 프로비저닝이 안되었다면 time_sleep 리소스를 지정해서 대기 시간을 걸어야함
}

2) 시작 구성 (Launch Configuration) 설정

# Auto Scaling Group 설정 전 Launch Configuration(시작 구성) 설정
resource "aws_launch_configuration" "applayer-launch-config" {
  name_prefix = "applayer-launch-config"
  image_id = aws_ami_from_instance.app-layer-AS-template-ami.id
  instance_type = "t2.micro"
  security_groups = [aws_security_group.private-instance-sg.id]
}

3) Auto Scaling Group 생성

# Auto Scaling Group 생성
resource "aws_autoscaling_group" "applayer-autoscaling-group" {
  name = "AppTierASG"
  launch_configuration = aws_launch_configuration.applayer-launch-config.name
  vpc_zone_identifier = [aws_subnet.private-subnet-az1.id, aws_subnet.private-subnet-az2.id]
  desired_capacity = 2 # Auto Scaling 그룹 초기 크기
  max_size = 2 # 부하에 따른 최대 인스턴스 수
  min_size = 2 # 부하에 따른 최소 인스턴스 수
  health_check_grace_period = 300
  health_check_type = "EC2"

  target_group_arns = [aws_lb_target_group.app-tier-alb-tg.arn]
    # ASG에서 생성된 인스턴스의 경우 위 방식으로 LoadBalancer TargetGroup에 등록 가능
  depends_on = [aws_lb_target_group.app-tier-alb-tg]
    # LB Target Group이 생성되어 ARN이 지정된 후 위 명령어가 사용될 수 있기 때문에 Depends_on 사용
}

 

 

 

* 주의 사항
- Auto Scaling의 경우 보통 Load Balancer(LB)와 함께 사용되며, LB의 Target Group에 등록되어 지정 포트를 사용한 트래픽 전송이 되도록 지정되기 때문에 다음 챕터에서 LB 생성 코드와 이어지게 되는 점 주의

- depends_on의 경우 특정 리소스 코드가 수행된 후, 다음 리소스 코드가 수행되는 종속성이지만, user_data 등 특정 명령어의 소화가 완전하지 않은 상태에서 인프라 생성이 인식되어 의도와 다르게 코드가 수행되는 경우가 존재
(ex- 인스턴스 user_data 코드가 길 시, 명령어 적용 진행중일 시, AMI Imaging을 진행하면 원본 인스턴스가 재부팅되어 의도상 구현 불가)
-> 이런 경우 depends_on 외에 time_sleep을 통해 대기 시간을 설정하고 depends_on을 각각 설정해 줘야함
(실제로 이런 Case로 인해 트러블슈팅이 굉장히 오래걸려서 미치는 경험을 해본적이 있음)

# time sleep + user_data 예시 코드
# 인스턴스 생성 코드 중략...

resource "time_sleep" "wait-for-app-instance" {
  depends_on = [aws_instance.applayer]
  create_duration = "300s" # 인스턴스 생성 후 5분후에 AWS AMI 수행되도록 지정
    # 아래 AMI 이미징 관련 명령어가 Instance 생성 직후에 수행되면, user_data 명령어 적용이 덜 된 상태로 사용되어 의도한대로 동작하지 않을 수 있음
    # 해당 Time_sleep을 통해 인스턴스 생성에 따라 5분의 갭을 만들어줌
}



# 설정이 완전한 인스턴스 대상으로 AMI Imaging
resource "aws_ami_from_instance" "app-layer-AS-template-ami" {
  name = "appTierImage"
  source_instance_id = aws_instance.applayer.id
  depends_on = [time_sleep.wait-for-app-instance]
    # 인스턴스 AMI 이미징 시, 기존 인스턴스가 재부팅 되기 때문에 명령어 프로비전이 안된 경우 문제 발생 가능
    # AMI가 인스턴스 생성 직후 바로 수행되지 않도록 timeSleep으로 의존성 설정
}