ASG (r1)

ASG는 클라우드 컴퓨팅 환경에서 컴퓨팅 인스턴스의 집합을 자동으로 관리하는 서비스이다. 주된 목적은 애플리케이션의 가용성을 유지하면서 수요 변화에 맞춰 인스턴스 수를 동적으로 조정하는 것이다. 이를 통해 트래픽 증가 시에는 성능을 유지하고, 트래픽 감소 시에는 불필요한 비용을 절감할 수 있다.

ASG의 핵심은 사전에 정의한 최소, 원하는, 최대 인스턴스 수를 기준으로 그룹의 크기를 관리한다는 점이다. 이 서비스는 주로 가상 머신이나 컨테이너 인스턴스를 대상으로 하며, 사용자가 설정한 스케일링 정책에 따라 자동으로 인스턴스를 추가하거나 제거한다. 목표는 항상 정상적으로 작동하는 인스턴스의 개수를 유지하여 애플리케이션의 내결함성과 확장성을 보장하는 데 있다.

정리하면, ASG는 클라우드 인프라의 운영 부담을 줄이고, 비용 효율성과 시스템 안정성을 동시에 달성하기 위한 필수적인 자동화 도구이다.

ASG는 시작 템플릿 또는 시작 구성, 하나 이상의 가용 영역에 걸친 EC2 인스턴스 그룹, 그리고 그룹의 크기를 관리하는 스케일링 정책이라는 세 가지 핵심 구성 요소로 이루어져 있다.

첫 번째 구성 요소인 시작 템플릿 또는 시작 구성은 ASG가 새 인스턴스를 시작할 때 사용할 청사진이다. 여기에는 AMI ID, 인스턴스 유형, 보안 그룹, 키 페어, 스토리지 구성 등 인스턴스의 사양과 설정이 정의되어 있다. 시작 구성은 레거시 방식이며, 시작 템플릿은 최신 방식으로 더 많은 구성 옵션과 버전 관리를 제공한다.

두 번째 구성 요소는 ASG가 생성하고 관리하는 실제 EC2 인스턴스들의 집합이다. 이 인스턴스들은 사용자가 지정한 최소, 원하는, 최대 용량 설정에 따라 하나 이상의 가용 영역에 분산되어 배치된다. 이는 단일 장애 지점을 제거하고 가용성을 높이는 데 기여한다.

마지막 핵심 구성 요소는 스케일링 정책이다. 이 정책은 ASG가 언제, 어떻게 인스턴스 수를 조절할지 결정하는 규칙 모음이다. 정책은 CloudWatch 지표(예: CPU 사용률)를 기반으로 한 목표 추적, 단순 조정(특정 수만큼 증감), 또는 예약된 작업(특정 시간에 조정) 등 다양한 유형으로 구성할 수 있다.

스케일링 정책은 ASG가 언제, 어떻게 인스턴스 수를 조절할지 결정하는 규칙 집합이다. 이 정책은 사전에 정의된 조건이나 일정에 따라 자동으로 적용된다. 주로 클라우드 워치 지표를 기반으로 하며, 사용자가 설정한 임계값을 기준으로 스케일 아웃(인스턴스 추가) 또는 스케일 인(인스턴스 제거) 작업을 트리거한다.

정책은 크게 동적 스케일링과 예측 스케일링, 일정 기반 스케일링으로 구분된다. 동적 스케일링은 실시간 메트릭 변화에 대응하는 가장 일반적인 방식이다. 예측 스케일링은 머신 러닝을 활용해 과거 사용 패턴을 분석하여 미래의 부하를 예측하고 사전에 용량을 조정한다. 일정 기반 스케일링은 특정 시간대(예: 업무 시간, 세일 기간)에 용량을 미리 변경해야 할 때 사용된다.

정책을 구성할 때는 스케일링 조정 유형(단순, 단계 조정, 대상 추적), 최소/최대/희망 용량, 쿨다운(Cooldown) 기간 등을 함께 설정한다. 단계 조정 정책은 지표가 벗어난 정도에 따라 다른 수의 인스턴스를 조정할 수 있게 해주며, 대상 추적 정책은 특정 지표 값을 목표로 유지하도록 지속적으로 조정한다. 적절한 정책 설정은 애플리케이션의 성능을 보장하면서도 비용을 효율적으로 관리하는 핵심 요소이다.

상태 확인은 ASG가 그룹 내 인스턴스의 정상 작동 여부를 지속적으로 모니터링하는 프로세스이다. 일반적으로 로드 밸런서의 타겟 그룹 상태 확인이나 EC2 시스템 상태 확인을 통해 수행된다. 인스턴스가 정상 상태로 판단되지 않으면, ASG는 해당 인스턴스를 비정상 상태로 표시하고 장애 조치 절차를 시작한다.

장애 조치는 비정상 인스턴스를 자동으로 교체하는 과정이다. ASG는 비정상 인스턴스를 종료하고, 사전에 정의된 시작 템플릿 또는 시작 구성에 따라 새로운 인스턴스를 자동으로 프로비저닝한다. 이 과정은 애플리케이션의 가용성을 유지하고 최소한의 인스턴스 수를 보장하는 데 핵심적이다.

상태 확인의 빈도와 임계값은 구성 가능하다. 예를 들어, 연속 2회의 상태 확인 실패 후 인스턴스를 비정상으로 판단하도록 설정할 수 있다. 장애 조치 시간은 인스턴스 종료, 새 인스턴스 시작, 애플리케이션 초기화에 소요되는 시간에 따라 달라진다. 이를 최소화하기 위해 상태 확인 유예 기간을 적절히 설정하여 인스턴스 초기화 시간을 고려해야 한다.

시작 템플릿(Launch Template) 또는 시작 구성(Launch Configuration)은 ASG가 새 인스턴스를 시작할 때 사용할 기본 청사진이다. 이 템플릿에는 인스턴스의 사양, AMI(Amazon Machine Image), 인스턴스 유형, 보안 그룹, 키 페어, 스토리지 구성, 그리고 사용자 데이터(User Data) 스크립트 등이 정의되어 있다. 시작 구성은 이전 세대의 구성 방식이며, 시작 템플릿은 더 유연하고 기능이 풍부한 최신 방식으로 권장된다[1].

시작 템플릿을 구성할 때는 애플리케이션의 요구 사항에 맞춰 세부 사항을 설정한다. 주요 설정 항목은 다음과 같다.

시작 템플릿을 올바르게 구성하는 것은 ASG의 효율적인 운영의 기초가 된다. 특히 사용자 데이터를 활용하면 인스턴스가 시작될 때마다 애플리케이션 코드를 자동으로 배포하거나, 필요한 소프트웨어 패키지를 설치하며, 환경 변수를 구성할 수 있다. 이는 수동 개입 없이도 일관되고 준비된 인스턴스를 제공하여 가용성과 확장성을 보장하는 핵심 요소이다.

스케일링 트리거는 ASG가 인스턴스 수를 조정해야 하는 시점과 방법을 결정하는 규칙이다. 이 트리거는 주로 클라우드워치 지표를 기반으로 설정되며, 특정 임계값을 초과하거나 미달할 때 스케일링 작업을 실행한다. 일반적으로 CPU 사용률, 네트워크 트래픽, 애플리케이션 지표 등이 모니터링 대상이 된다.

트리거 설정은 크게 단순 스케일링과 단계적 스케일링으로 구분된다. 단순 스케일링은 하나의 지표와 임계값을 사용하여 인스턴스를 한 번에 추가하거나 제거하는 방식이다. 단계적 스케일링은 지표 값의 편차 크기에 따라 다른 조정 규모를 적용할 수 있어 더욱 정교한 제어가 가능하다. 예를 들어, CPU 사용률이 70%를 초과하면 인스턴스를 1개 추가하고, 85%를 초과하면 2개를 추가하도록 설정할 수 있다.

트리거 구성 시 중요한 요소는 쿨다운 기간이다. 이는 스케일링 작업이 연속적으로 발생하는 것을 방지하기 위해 설정하는 대기 시간이다. 인스턴스를 추가한 직후 시스템이 안정화되기 전에 또 다른 스케일링 평가가 이루어지는 것을 막아 불필요한 변동과 비용을 줄인다. 또한, 최소/최대 용량 및 원하는 용량 설정과 함께 트리거는 ASG의 전체적인 운영 범위를 정의한다.

트리거는 시작 템플릿이나 시작 구성과 결합되어 작동한다. 스케일 아웃 시 트리거는 시작 템플릿에 정의된 설정을 바탕으로 새로운 인스턴스를 프로비저닝한다. 사용자는 애플리케이션의 부하 패턴을 분석하여 적절한 지표를 선정하고, 안정적인 서비스 제공과 비용 효율성 사이의 균형을 맞추는 트리거 정책을 설계해야 한다.

ASG는 애플리케이션의 가용성을 유지하고 향상시키는 데 핵심적인 역할을 한다. 주된 방식은 인스턴스 그룹의 크기를 자동으로 조정하여 항상 정상적인 인스턴스가 지정된 최소 수 이상 실행되도록 보장하는 것이다. 예를 들어, 최소 크기를 2로 설정하면, 하나의 인스턴스에 장애가 발생하더라도 다른 인스턴스가 요청을 계속 처리할 수 있다. 이는 단일 장애점을 제거하는 데 기여한다.

ASG의 상태 확인 및 자동 교체 메커니즘은 가용성 향상에 직접적으로 기여한다. ASG는 Elastic Load Balancing 상태 확인이나 EC2 상태 확인을 통해 각 인스턴스의 건강 상태를 지속적으로 모니터링한다. 정상 상태로 판단되지 않는 인스턴스를 감지하면, ASG는 해당 인스턴스를 자동으로 종료하고 새로운 인스턴스를 시작 템플릿에 따라 프로비저닝한다. 이 과정은 사용자 개입 없이 자동으로 수행되어 서비스 중단 시간을 최소화한다.

다양한 가용 영역에 인스턴스를 분산 배치하는 것도 ASG의 중요한 기능이다. 사용자는 여러 가용 영역을 지정할 수 있으며, ASG는 새 인스턴스를 시작할 때 이러한 영역에 균등하게 분산시킨다. 이는 특정 데이터센터의 물리적 장애나 네트워크 문제가 발생했을 때, 다른 가용 영역의 인스턴스가 서비스를 지속할 수 있도록 함으로써 애플리케이션의 내결함성을 높인다.

ASG는 애플리케이션의 부하에 따라 자동으로 컴퓨팅 인스턴스의 수를 조정함으로써 비용을 최적화하는 핵심 메커니즘을 제공한다. 이는 사용자가 최대 부하를 기준으로 고정된 수의 인스턴스를 항상 운영할 필요 없이, 실제 수요에 맞춰 리소스를 탄력적으로 확장하거나 축소할 수 있게 한다. 결과적으로 사용하지 않는 시간 동안의 불필요한 인프라 비용을 크게 절감할 수 있다.

비용 최적화는 주로 다양한 스케일링 정책을 통해 달성된다. 사용자는 CPU 사용률, 네트워크 트래픽, 사용자 지정 지표 등의 조건을 설정하여 스케일링을 트리거할 수 있다. 예를 들어, 업무 시간 동안에는 트래픽 증가에 대비해 인스턴스 수를 늘리고, 야간이나 주말에는 최소한의 인스턴스만 유지하도록 정책을 구성할 수 있다. 또한, 예측 스케일링이나 스케줄 기반 스케일링을 활용하면 반복적인 트래픽 패턴을 예측하여 사전에 리소스를 조정함으로써 비용 효율성을 더욱 높일 수 있다.

이러한 최적화는 단순히 인스턴스 수를 줄이는 것을 넘어, 적절한 인스턴스 유형 선택과 결합될 때 그 효과가 극대화된다. ASG는 시작 템플릿을 통해 최신 AMI와 비용 효율적인 인스턴스 패밀리를 지정할 수 있게 지원한다. 또한, 스팟 인스턴스와 온디맨드 인스턴스를 혼합하여 사용하는 전략을 ASG에 적용하면 애플리케이션의 내결함성을 유지하면서 컴퓨팅 비용을 획기적으로 낮출 수 있다.

ASG는 웹 애플리케이션을 호스팅할 때 가용성과 확장성을 보장하는 핵심 인프라 구성 요소로 자주 활용된다. 트래픽 패턴이 변동성이 큰 웹 서비스의 특성상, ASG는 수요에 따라 인스턴스의 수를 자동으로 조정하여 애플리케이션의 응답성을 유지한다. 일반적으로 로드 밸런서와 연동되어 구성되며, 로드 밸런서는 들어오는 사용자 요청을 ASG 그룹 내 정상적인 인스턴스들에게 분산시킨다.

구체적인 작동 방식은 다음과 같다. 애플리케이션에 대한 트래픽이 증가하면, CPU 사용률이나 네트워크 인바운드 트래픽 같은 미리 정의된 클라우드워치 지표가 임계값을 초과한다. 이는 스케일 아웃 정책의 트리거가 되어 ASG가 새로운 웹 서버 인스턴스를 자동으로 프로비저닝하고 시작한다. 새 인스턴스는 사전에 정의된 시작 템플릿에 따라 애플리케이션 코드와 구성을 갖추고, 로드 밸런서 대상 그룹에 등록되어 서비스에 참여하기 시작한다. 반대로 트래픽이 줄어들면 스케일 인 정책이 활성화되어 불필요한 인스턴스를 종료하여 비용을 절감한다.

이러한 자동 스케일링은 예측 불가능한 트래픽 급증, 예를 들어 마케팅 캠페인이나 언론 보도로 인한 순간적인 접속 폭주 시에도 서비스 중단을 방지하는 데 효과적이다. 또한, ASG의 상태 확인 메커니즘은 개별 인스턴스의 건강 상태를 지속적으로 모니터링한다. 애플리케이션 오류나 하드웨어 문제로 인해 인스턴스가 비정상 상태로 판단되면, ASG는 해당 인스턴스를 자동으로 종료하고 새로운 인스턴스로 교체하여 서비스의 내결함성을 높인다.

결과적으로, ASG를 활용한 웹 애플리케이션 호스팅은 수동 개입을 최소화하면서도 사용자 경험을 일정 수준 이상으로 유지하고, 컴퓨팅 리소스 사용에 대한 비용 효율성을 극대화할 수 있는 아키텍처를 제공한다.

ASG는 일정한 시간에 대량의 데이터를 처리하거나 주기적인 컴퓨팅 작업을 실행하는 배치 작업에 적합한 인프라 관리 방식을 제공한다. 배치 작업은 일반적으로 짧은 시간 동안 높은 컴퓨팅 자원을 필요로 하며, 작업 완료 후 인스턴스가 더 이상 필요하지 않다는 특징이 있다.

ASG를 사용하면 사전에 정의된 시작 템플릿과 스케일링 정책을 기반으로 배치 작업 시작 시 필요한 수의 인스턴스를 자동으로 프로비저닝할 수 있다. 작업이 완료되면 ASG는 불필요해진 인스턴스를 자동으로 종료하여 리소스 낭비를 방지한다. 이는 온디맨드 인스턴스만을 사용할 때보다 비용을 절감하는 데 효과적이다. 주로 데이터 분석, 미디어 파일 변환, 일일 리포트 생성, 대규모 시뮬레이션 등에 활용된다.

배치 작업 처리를 위한 ASG 구성은 일반적으로 다음과 같은 단계를 거친다.

이러한 방식을 통해 사용자는 복잡한 인프라 관리 없이 배치 작업에 필요한 컴퓨팅 용량을 탄력적으로 확보하고, 작업 종료 후 자원을 즉시 반납할 수 있다. 이는 클라우드 컴퓨팅의 핵심 가치인 탄력성과 비용 효율성을 실현하는 전형적인 사례이다.

ASG의 성능과 상태를 효과적으로 관리하려면 지표 모니터링과 알림 설정이 필수적이다. 주요 클라우드 제공업체는 CloudWatch와 같은 모니터링 서비스를 통해 ASG 및 그 인스턴스에 대한 다양한 지표를 실시간으로 수집하고 시각화한다. 주요 모니터링 지표로는 CPUUtilization, NetworkIn, NetworkOut 같은 인스턴스 수준의 지표와 GroupMinSize, GroupMaxSize, GroupDesiredCapacity, GroupInServiceInstances 같은 ASG 그룹 자체의 지표가 있다. 특히 GroupTotalInstances와 GroupInServiceInstances의 차이를 통해 비정상 인스턴스 수를 파악할 수 있다.

이러한 지표를 바탕으로 임계값을 초과하는 상황이 발생하면 자동으로 알림을 생성하도록 CloudWatch 알람을 설정한다. 예를 들어, 평균 CPU 사용률이 80%를 일정 시간 동안 초과하면 알람 상태가 ALARM으로 변경되고, 이는 Amazon SNS를 통해 이메일, SMS 또는 다른 엔드포인트로 알림을 전송하거나 AWS Lambda 함수를 트리거하도록 구성할 수 있다. 알람은 스케일링 정책의 트리거로 직접 사용될 수도 있다.

효과적인 모니터링을 위해서는 비즈니스 요구사항에 맞는 맞춤형 지표를 정의하고, 알람 임계값은 애플리케이션의 정상 동작 패턴을 기반으로 설정해야 한다. 지나치게 민감한 알람은 불필요한 노이즈를 발생시키고, 느슨한 알람은 실제 문제를 놓칠 수 있다. 또한, 알람 알림과 자동화된 대응 메커니즘(예: 문제 인스턴스 자동 교체)을 연계하여 운영 부담을 줄이고 시스템의 회복 탄력성을 높이는 것이 좋다.

라이프사이클 훅은 ASG가 인스턴스를 시작하거나 종료하는 과정에서 사용자 정의 작업을 수행할 수 있도록 하는 일시 중지 지점이다. 이 훅을 활용하면 인스턴스가 ASG에 완전히 추가되기 전에 애플리케이션 구성이나 소프트웨어 설치를 완료하거나, 인스턴스가 종료되기 전에 연결 드레인이나 상태 저장 데이터 백업과 같은 정리 작업을 실행할 수 있다.

주요 라이프사이클 훅은 다음과 같다.

훅이 활성화되면 ASG는 관련 SNS 주제로 알림을 보내거나, AWS Lambda 함수를 호출하거나, 사용자가 지정한 EC2 인스턴스에서 커스텀 스크립트를 실행할 수 있다. 작업이 완료되면 사용자 또는 자동화 스크립트는 훅을 완료 상태로 표시해야 하며, 그렇지 않으면 인스턴스는 기본 타임아웃 시간(기본 1시간) 동안 해당 라이프사이클 상태에 갇히게 된다. 이를 통해 애플리케이션의 무중단 배포나 안전한 스케일 인 작업을 구현하는 데 필수적인 제어력을 제공한다.

ASG는 단독으로 운영되기보다는 로드 밬런서와 긴밀하게 연동되어 완전한 고가용성 아키텍처를 구성하는 경우가 일반적이다. 로드 밸런서는 사용자 트래픽을 ASG 내의 정상적인 인스턴스들에 고르게 분배하는 역할을 담당한다. 이 연동을 통해 ASG 그룹에 새 인스턴스가 추가되거나 제거될 때마다 로드 밸런서의 타겟 그룹 멤버십이 자동으로 업데이트되어 트래픽 분배가 원활하게 이루어진다.

연동 설정은 주로 로드 밬런서의 대상 그룹을 ASG 생성 또는 수정 시에 지정하는 방식으로 이루어진다. ASG는 주기적으로 그룹 내 인스턴스의 상태를 확인하며, 이 상태 확인은 ASG 자체의 상태 확인과 로드 밸런서의 상태 확인을 결합하여 사용할 수 있다. 로드 밸런서 상태 확인이 실패한 인스턴스는 ASG에 의해 자동으로 교체 대상이 되어 비정상 인스턴스로부터의 트래픽 차단과 애플리케이션의 전반적인 안정성을 보장한다.

다양한 로드 밸런서 유형과 연동이 가능하다. 예를 들어, Application Load Balancer는 HTTP/HTTPS 트래픽의 고급 라우팅에 적합하며, Network Load Balancer는 초고성능 및 TCP/UDP 트래픽 처리에 주로 사용된다. ASG와 로드 밸런서의 조합은 트래픽 변동에 따른 자동 확장 및 축소와 함께, 지속적인 트래픽 분산과 장애 조치를 제공하는 핵심 패턴이다.

ASG는 전통적으로 가상 머신 기반의 인스턴스를 관리하는 데 최적화되어 있지만, 현대적인 컨테이너 기반 애플리케이션 배포에도 중요한 역할을 한다. 컨테이너 오케스트레이션 플랫폼인 쿠버네티스는 자체적인 파드 스케일링 메커니즘(HPA, VPA)을 가지고 있지만, 이러한 파드들이 실행되는 노드 인프라의 확장과 축소에는 여전히 ASG의 원리가 적용된다.

AWS 환경에서 쿠버네티스 클러스터를 구성할 때, 노드 그룹은 종종 ASG를 기반으로 생성된다. EKS 관리형 노드 그룹이나 Karpenter 같은 프로비저너는 내부적으로 ASG를 활용하여 워크로드 요구에 따라 노드 수를 자동으로 조정한다. 이 경우, 스케일링 정책의 트리거는 쿠버네티스 메트릭 서버나 클라우드워치 지표와 같은 컨테이너 수준의 메트릭에 의해 결정될 수 있다.

다른 클라우드 환경의 컨테이너 서비스(GKE, AKS)도 유사한 원리로 동작하며, 이를 통해 하이브리드 스케일링 모델이 구현된다. 애플리케이션 수준의 스케일링은 오케스트레이션 레이어가 담당하고, 인프라 수준의 스케일링은 ASG가 담당하여 리소스 효율성과 비용 절감을 동시에 달성한다[4].