고가용성 및 스케일링

Why use a load balancer ?

• 여러 다운스트림 인스턴스에 부하 분산
• 애플리케이션에 대한 단일 액세스 지점(DNS) 노출
• 다운스트림 인스턴스의 장애를 원활하게 처리
• 인스턴스에 대한 정기적인 상태 확인 수행
• 웹사이트에 SSL 종료(HTTPS) 제공
• Enforce stickiness with cookies
• 영역 간 고가용성
• 공용트래픽과 개인 트래픽 분리

왜 ELB를 사용할까요 ?

만약 클라우드에 많은 서버가 존재하고 (EC2) 그들이 end-user에게 같은 서비스를 제공한다고 생각해보자. 우리가 naver.com에 접속할 때 모든 유저가 하나의 서버로 접속하지 않는 것처럼 실제로 존재하는 많은 서비스가 많은 서버를 두고 하나의 도메인 address를 이용해서 트래픽을 분배하게 된다. 이러한 네트워크를 분배하는 기능을 가진 것을 로드밸런스라고 한다.

Elastic Load Balancer는 관리형 로드 밸런서입니다.

• AWS는 업그레이드, 유지 관리, 고가용성을 처리합니다.
• AWS는 몇 가지 구성 노브만 제공합니다.

많은 AWS 제품 및 서비스 등과 통합됩니다.

• EC2, Auto Scaling Group, Amazon ECS
• AWS 인증서 관리자(ACM), CloudWatch
• Route53, AWS WAF, AWS Global Accelerator

자체 로드 밸런서를 설정하는 데 비용이 적게 들지만 결국에는 훨씬 더 많은 노력이 필요합니다.

Health Chcek

• 상태 확인은 로드 밸런서에 중요합니다.
• 이를 통해 로드 밸런서가 트래픽을 전달하는 인스턴스가 요청에 응답할 수 있는지 알 수 있습니다.
• 상태 확인은 포트 및 경로에서 수행됩니다.
• 응답이 200(OK)이 아니면 인스턴스가 비정상적인 상태입니다.
• ELB 상태 확인을 활성화하면 ELB가 비정상(충돌) EC2 인스턴스로는 트래픽을 보내지 않게 됩니다.

타겟그룹이 설정되지 않은 ALB에 발생되는 오류

• HTTP 503 : Service unavailable

AWS 로드밸런서 타입

AWS에는 4가지 유형의 로드밸런서가 있습니다.

Classic Load Balancer (v1 - old generation) - 2009 (CLB)

• HTTP, HTTPS, TCP, SSL (secure TCP)

Application Load Balancer (v2 - new generation) - 2016 (ALB)

• HTTP, HTTPS, WebSocket

Network Load Balancer (v2 - new generation) - 2017 (NLB)

• TCP, TLS (secure TCP), UDP

Gateway Load Balancer - 2020 (GWLB)

• Operates at layer 3 (Network Layer) - IP Protocol
• 전반적으로 더 많은 기능을 제공하는 최신 세대 로드 밸런서를 사용하는 것이 좋습니다.
• 일부 Load Balancer는 내부(비공개) 또는 외부(공개) ELB로 설정할 수 있습니다.

Internet-Facing Load Balancers (외부)

인터넷으로부터 요청을 받아서 각기 다른 EC2로 분배해주는 역할을 한다. 로드밸런서에 해당되는 IP 역시 일반적으로 DNS name을 통해서 입력받게 되며 DNS server가 IP로 binding을 해주게 된다.

Internal Load Balancers (내부)

만약 Private Subnet에 연결되어 있는 많은 서버에 연결될 때 사용된다. 예를 들어 4개의 웹 서버가 있고 4개의 DB 서버가 있을 경우에 각각의 웹서버에 DB 서버가 하나씩 물려있는 구조는 위험도가 크다. 4개의 서버가 로드밸런서를 통해서 DB 서버 중 하나에 접속하는 구조를 갖게 되면 리스크가 줄어들며 이 역할을 하는 것이 Internal Load Balancer이다.

HTTPS Load Balancer

SSL/TLS protocol, HTTPS를 통해서 양단을 암호화하는 방식의 로드밸런싱을 할 수도 있다. 이미 정의된 SSL certificates를 로드밸런서에 설치하여 사용할 수 있다.

Listeners

로드밸런서는 반드시 하나 이상의 Listener가 설정되어야 한다. Listener는 HTTP, HTTPS, TCP, SSL을 모두 지원하며 L4 (TCP / IP connection 단계의 로드밸런싱), L7 (HTTPS, HTTP를 통해서 application layer에 의해서 분배한다) 모두 지원합니다.

Load Balancer Security Group

Load Balancer Security Group

Type	Protocol	Port Range	Source	Description
HTTP	TCP	80	0.0.0.0/0	Allow HTTP
HTTPS	TCP	443	0.0.0.0/0	Allow HTTPS

Application Security Group: Allow traffic only from Load Balancer

Type	Protocol	Port Range	Source	Description
HTTP	TCP	80	sg-03dasdsa23	Allow Traffic only Load Balancer

Classic Load Balancer (v1)

• Supports TCP (Layer 4), HTTP & HTTPS (Layer 7)
• Health checks are TCP or HTTP based
• Fixed hostname XXX.region.elb.amazonaws.com

Application Load Balancer (v2)

• 애플리케이션 로드밸런서는 7계층(HTTP)에서 작동합니다.
• 머신(Target Groups)에서 여러 HTTP 애플리케이션에 대한 로드밸런싱
• 동일한 머신(예: 컨테이너)의 여러 애플리케이션에 대한 로드밸런싱
• HTTP/2 및 WebSocket 지원
• 리디렉션 지원 (예: HTTP에서 HTTPS로)

라우트 테이블에서 다른 대상 그룹으로

• URL의 경로 기반 라우팅 (example.com/users & example.com/posts)
• URL의 호스트 이름을 기반으로 라우팅 (one.example.com 및 other.example.com)
• 쿼리 문자열, 헤더 기반 라우팅 (example.com/users?id=123&order=false)

ALB는 마이크로 서비스 및 컨테이너 기반 애플리케이션 (예: Docker 및 Amazon ECS)에 매우 적합합니다.

• ECS의 동적 포트로 리디렉션하는 포트 매핑 기능이 있습니다.

ALB - HTTP Based Traffic (URL)

ALB - Target Groups

• EC2 인스턴스 (Auto Scaling 그룹에서 관리 가능) - HTTP
• ECS 작업 (ECS 자체에서 관리) - HTTP
• Lambda 함수 - HTTP 요청이 JSON 이벤트로 변환됩니다.
• IP 주소 - 비공개 IP여야 합니다.
• ALB는 여러 대상 그룹으로 라우팅할 수 있습니다.
• 상태 확인은 대상 그룹 수준에서 이루어집니다.

ALB - Query Strings / Parameters Routing

ALB 요약

• 고정 호스트 이름 (xxx.region.elb.amazonaws.com)

애플리케이션 서버는 클라이언트의 IP를 직접 보지 않습니다.

• 클라이언트의 실제 IP는 X-Forwarded-For 헤더에 삽입됩니다.
• Port(X-Forwarded-Port) 및 proto (X-Forwarded-Proto)도 얻을 수 있습니다.

---

Network Load Balancer

• NLB는 AZ당 하나의 고정 IP를 가지며 탄력적 IP 할당을 지원합니다. (특정 IP를 화이트리스트에 추가하는 데 유용)
• NLB는 극한의 성능, TCP 또는 UDP 트래픽에 사용됩니다.
• AWS 프리 티어에 포함되지 않음

네트워크 로드 밸런서 (4계층)은 다음을 허용합니다.

• TCP 및 UDP 트래픽을 인스턴스로 전달
• 초당 수백만 건의 요청 처리
• 100ms 이하의 짧은 지연 시간 (ALB의 경우 400ms)

Network Load Balancer - TCP Based Traffic

Network Load Balancer - Target Groups

• EC2 instances
• IP Address - 반드시 프라이빗 IP이어야 합니다.
• ✅ Application Load Balancer (ALB)

---

Gateway Load Balancer

• AWS에서 다양한 타사 네트워크 가상 어플라이언스 배포, 확장 및 관리
• Example: 방화벽, 침입 탐지 및 방지 시스템, 심층 패킷 검사 시스템, 페이로드 조작, …
• **3계층 (네트워크 계층)**에서 작동 - IP 패킷

다음 기능을 결합

• 투명한 네트워크 게이트웨이 - 단일 진입 / 출구
• 로드 밸런서 - 트래픽을 가상 어플라이언스로 분산
• 포트 6081에서 GENEVE 프로토콜 사용

---

Sticky Session (Session Affinity)

• 동일한 클라이언트가 항상 로드 밸런서 뒤의 동일한 인스턴스로 리디렉션 되도록 고정성을 구현하는 것이 가능합니다.
• Sticky Session은 Classic Load Balancer 및 Application Load Balancer에서 작동합니다.
• Stickness에 사용되는 쿠키에는 만료일이 있습니다.

Use case: 사용자가 세션 데이터를 잃지 않도록 해야할 때

• Stickness를 활성화하면 백엔드 EC2 인스턴스에 대한 부하 불균형이 발생할 수 있습니다.

---

Sticky Session - Cookie names

Application based Cookies

Custom cookie

• 타겟에 의해 생성
• 애플리케이션에 필요한 모든 사용자 정의 속성 포함
• 쿠키 이름은 각 대상 그룹에 대해 개별적으로 지정
• AWSALB, AWSALBAPP 또는 AWSALBTG(ELB용으로 예약)을 이름으로 사용 불가

Application cookie

• 로드 밸런서에서 생성
• 쿠키 이름은 AWSALBAPP

Duration-based cookie

• 로드밸런서에서 생성된 쿠키
• 쿠키 이름은 ALB의 경우 AWSALB, CLB의 경우 AWSELB입니다.

Cross-Zone Load Balancing

Application Load Balancer

• 항상 사용 (사용 중지할 수 없음)
• AZ간 데이터 요금 없음

Network Load Balancer

• 기본적으로 비활성화
• 활성화된 경우 AZ간 데이터에 대한 요금($) 지불

Classic Load Balancer

• 기본적으로 비활성화
• 활성화된 경우 AZ간 데이터에 대한 요금 없음

---

SSL / TLS - Basic

• SSL 인증서를 사용하면 클라이언트와 로드 밸런서 간의 트래픽을 전송 중에 암호화할 수 있습니다. (전송 중 암호화)
• SSL은 연결을 암호화하는 데 사용되는 SSL(Secure Sockets Layer)을 나타냅니다.
• TLS는 최신 버전인 전송 계층 보안을 나타냅니다.
• 요즘은 TLS 인증서를 주로 사용하지만 사람들은 여전히 SSL이라고 부릅니다.
• 공인 SSL 인증서는 인증 기관(CA)에서 발급합니다.
• Comodo, Symantec, GoDaddy, GlobalSign, Digicert, Letsencrypt 등 …
• SSL 인증서에는 만료 날짜(사용자가 설정)가 있으며 갱신해야 합니다.

Load Balancer - SSL Certificates

• 로드 밸런서는 X.509 인증서 (SSL/TLS 서버 인증서)를 사용합니다.
• ACM (AWS Certificate Manager)을 사용하여 인증서를 관리할 수 있습니다.
• 대체로 자신의 인증서를 업로드할 수 있습니다.

HTTPS Listener

• 기본 인증서를 지정해야 합니다.
• 여러 도메인을 지원하기 위해 선택적 인증서 목록을 추가할 수 있습니다.
• 클라이언트는 SNI(서버 이름 표시)를 사용하여 도달하는 호스트 이름을 지정할 수 있습니다.
• 이전 버전의 SSL / TLS (레거시 클라이언트)를 지원하는 보안 정책을 지원하는 기능

note

SNI란 ?

• SNI는 여러 SSL 인증서를 하나의 웹 서버에 로드하는 문제를 해결합니다.

서버 이름 표식(SNI)를 사용하면 동일한 리스너 상에 있는 자체 SSL 인증서를 가진 다수의 HTTPS 애플리케이션을 노출시킬 수 있습니다. SNI는 로드 밸런서에서 동일한 보안 리스너로 다수의 인증서를 바인딩하기만 하면 사용할 수 있습니다. 그러면 ALB가 각 클라이언트마다 최적의 TLS 인증서를 자동으로 선택합니다.

SSL과 TLS는 기술적으로 약간 다르기는 하지만 동일한 용어로 사용되는 경우가 많습니다. 기술적인 측면에서 SSL은 TLS 프로토콜의 이전 형태라고 할 수 있습니다.

TLS는 암호, 쿠키, 신용카드 번호 같은 데이터를 안전하게 전송하기 위한 프로토콜입니다. 이를 위해 전송되는 데이터의 프라이버시, 인증 및 무결성을 지원합니다. TLS는 인증서 기반 인증 방식을 사용합니다. 여기에서 인증서는 웹사이트에서 ID 카드와 같은 역할을 합니다. 즉 인증서에 서명하여 발급하는 사람, 인증 기관(CA)를 신뢰하기 때문에 인증서 데이터의 정확성까지 신뢰하게 됩니다. 브라우저가 TLS를 지원하는 ALB에 연결되면 ALB가 사이트의 공개 키가 포함된 인증서를 제출합니다. 이 공개 키에는 CA의 서명이 암호화되어 있습니다. 이러한 방식으로 클라이언트는 실제 서버라는 사실을 신뢰하고 이 사이트의 공개 키를 사용하여 안전하게 연결을 구성합니다.

SNI는 동일한 ALB에 인증서를 1개 이상 쉽게 사용할 수 있게 합니다. 다수의 인증서가 필요한 공통적인 이유는 동일한 로드 밸런서로 여러 도메인을 처리해야 하기 때문입니다. ALB에 와일드카드 인증서와 SAN(Subject-Alternate-Name) 인증서를 사용하는 것은 항상 가능했지만 몇 가지 제약이 따릅니다. 와일드카드 인증서는 여러 도메인을 지원하기는 하지만 동일한 인증 기관이 각 도메인을 인증해야 합니다. 이 말은 새로운 도메인을 추가할 때마다 인증서를 다시 인증하고 프로비저닝해야 한다는 것을 의미합니다.

TLS는 HTTP 아래 단계인 전송 레이어에 속하기 때문에 클라이언트가 요청하는 호스트 이름을 알지 못합니다. 이때 클라이언트가 처음 연결 시 서버에게 "이것이 내가 인증서를 원하는 도메인입니다"라고 지정할 수 있도록 도와주는 것이 바로 SNI입니다. 그러면 서버가 올바른 인증서를 선택하여 클라이언트에게 응답할 수 있습니다.

• SSL은 최신 프로토콜이며 클라이언트가 초기 SSL Handshake에서 대상 서버의 호스트 이름을 나타내도록 요구합니다.
• SNI는 하나의 리스너로 다수의 SSL 인증서를 가져올 수 있게 해줍니다.
• 그러면 서버가 올바른 인증서를 찾거나 기본 인증서를 반환합니다.

여러 도메인을 하나의 IP 주소로 연결하는 서비스에서 인증서를 특정하기 위해서 SSL 사용

• ALB 및 NLB(new generation), CloudFront에서만 작동
• CLB(구세대)에서는 작동하지 않습니다.

---

Elastic Load Balancers - SSL Certificates

Classic Load Balancer (v1)

• SSL 인증서 하나만 지원
• 여러 SSL 인증서가 있는 여러 호스트 이름에 대해 여러 CLB를 사용

Application Load Balancer (v2)

• 여러 SSL 인증서로 여러 리스너 지원
• SNI(Server Name Indication)를 사용하여 작동

Network Load Balancer (v2)

• 여러 SSL 인증서로 여러 리스너 지원
• SNI (Server Name Indication)를 사용하여 작동

Load Balancing Configuration

Idle Connection Timeout

• client가 로드 밸런서를 통해서 연결을 요청할 때 both connection (from client to server, from server to client)의 불량을 체크하여 타임아웃을 정할 수 있다. 기본적으로 60초가 설정되어 있으며 파일이 전달되는 도중에도 60초가 넘어가면 connection을 중단시킨다. 만약 keep-alive option을 enable시키면 다른 connection으로 넘어갈 경우에 기존의 session을 가지고 가게 할 수 있다.

Cross-Zone Load Balancing

• 같은 AZ 뿐만 아니라 서로 다른 AZ에서도 로드밸런싱을 할 수 있게 해주는 기능이다. 만약 AZ를 다르게 가져가면 fault tolerance를 높일 수 있게 된다.

Connection Draining

• Connection Draining은 deregistering이나 unhealthy된 instance에 더이상의 요청을 보내지 않도록 해주는 기능이므로 일반적으로 on으로 해놓아야 한다. time out을 정해놓으면 (1-3600 seconds) connection을 시도해서 예를 들어 300초인 경우, 300초 동안 connection이 유효한 상태로 돌아오지 않으면 해당 instance를 불능으로 처리하여 연결 요청을 하지 않게 된다.

Sticky Sessions

• 이 기능은 user의 session을 특정 instance로 붙여놓는 것을 뜻한다. user가 session을 유지한 상태라면 모든 요청을 하나의 instance로 유지하는 기능을 뜻한다. 만일 application이 session cookie를 가지고 있는 상태라면 하나의 instance로 session을 고정시켜서 해당 cookie를 지속적으로 사용할 수 있게 한다.

Health Checking

• ELB는 health checking을 지원하는데 inService, OutOfService인지를 알려주게 된다. user의 session이 요청이 없다고 하더라도 로드 밸런서가 ping을 보내게 되어 주기적으로 instance가 정상적인지를 체크하고 상태를 인지하고 알려주게 된다.

---

Connection Draining

• 기능 이름 지정
• Connect Draining - for CLB
• Deregistration Delay - for ALB & NLB
• 인스턴스가 등록 취소되거나 비정상 상태인 동안 "진행 중인 요청"을 완료하는 데 걸리는 시간
• 등록 취소 중인 EC2 인스턴스에 대한 새 요청 전송을 중지합니다.
• 1 ~ 3600초 사이 (기본값: 300초)
• 비활성화 가능 (값을 0으로 설정)
• 요청이 짧은 경우 낮은 값으로 설정

What's an Auto Scaling Group ?

• 현실에서 웹사이트와 애플리케이션의 로드는 변경될 수 있습니다.
• 클라우드에서는 서버를 매우 빠르게 생성하고 제거할 수 있습니다.
• 위와 같은 특성에 의해서 유기적으로 서버를 정해진 임계치에 따라 Scale Out하거나 Scale In 할 수 있도록 도와주는 것이 바로 오토 스케일링 그룹입니다.
• ASG는 무료입니다. (EC2 인스턴스에 대해서만 비용 지불)

Auto Scaling Group의 사용 목적

• 증가된 로드에 맞게 확장 (EC2 인스턴스 추가)
• 감소된 부하에 맞게 축소 (EC2 인스턴스 제거)
• 실행 중인 EC2 인스턴스의 최소 및 최대 수가 있는지 확인합니다.
• 새 인스턴스를 로드 밸런서에 자동으로 등록
• 이전 인스턴스가 종료된 경우 EC2 인스턴스를 다시 생성 (ex: 비정상인 경우)

---

Auto Scaling Group

Auto Scaling Group in AWS with 로드밸런서

Auto Scaling Group 속성들

A Launch Template

• Launch COnfigurations은 더 이상 사용되지 않음
• AMI + Instance Type / Amazon Machine Image + 인스턴스 타입
• EC2 User Data / EC2 유저 데이터
• EBS Volumes / EBS 볼륨
• Security Groups / 보안 그룹
• SSH Key Pair / SSH 키 쌍
• IAM Roles for your EC2 Instances / EC2 인스턴스의 IAM 역할
• Network + Subnets Information / 네트워크 + 서브넷 정보
• Load Balancer Information / 로드 밸런서 정보
• Min Size / Max Size / Initial Capacity
• Scaling Policies

caution

레거시인 론치 환경설정(Launch Configuration)보다 론치 템플릿 (Launch Template)의 사용이 권장됨.

Launch Configuration을 만든 후에는 수정할 수 없습니다.

• 수정하기 위해서는 새로운 Launch Configuration을 수정한 내용을 반영하여 생성한 후에 더 이상 필요하지 않은 이전 시작 구성을 삭제합니다.

Launch Template를 사용하면 온디맨드 인스턴스와 스팟 인스턴스를 모두 사용하여 여러 인스턴스 유형에 용량을 프로비저닝할 수 있습니다.

• Launch Configuration을 사용하여 온디맨드 인스턴스와 스팟 인스턴스를 모두 사용하는 여러 인스턴스 유형에 용량을 프로비저닝할 수 없습니다.

---

Auto Scaling - CloudWatch Alarms & Scaling

• CloudWatch 경보를 기반으로 ASG를 확장할 수 있습니다.
• 경보는 메트릭(예: 평균 CPU 또는 사용자 정의 메트릭)을 모니터링합니다.
• 평균 CPU와 같은 메트릭은 전체 ASG 인스턴스에 대해 계산됩니다.

알람기준

• 수평 확장 정책을 생성할 수 있습니다. (인스턴스 수 증가)
• 축소 정책을 생성할 수 있습니다. (인스턴스 수 감소)

ASG - 동적 스케일링 정책

Target Tarcking Scaling (목표 추적 스케일링)

~를 ~할거야

• 가장 간단하고 쉬운 설정
• 예: 평균 ASG CPU를 약 40%로 유지하고 싶습니다.

Simple / Step Scaling (단순 / 스텝 스케일링)

~가 되면 ~할거야

• CloudWatch 경보가 트리거되면(예: CPU > 70%) 장치 2개 추가
• CloudWatch 경보가 트리거되면(예: CPU < 30%) 장치 1개 제거

Scheduled Actions (예약된 작업)

언제 ~할거야

• 알려진 사용 패턴을 기반으로 확장 예상
• 예: 금요일 오후 5시에 최소 용량을 10으로 늘리세요.

---

ASG - Predictive Scaling

부하를 지속적으로 예측하고 확장을 미리 예약합니다.

예측 스케일링 하기 좋은 지표

• CPUUtilization: 인스턴스 전체의 평균 CPU 사용률
• RequestCountPerTarget: EC2 인스턴스당 요청 수가 안정적인지 확인하기 위해
• Average Network IN / OUT (애플리케이션이 네트워크 바인딩인 경우)
• Any custom metric (CloudWatch를 사용하여 푸시)

---

ASG - Scaling CoolDown

• 스케일링 활동일 발생한 후 휴지 기간(기본값 300초)이 있습니다.
• 휴지 기간 동안 ASG는 추가 인스턴스를 시작하거나 종료하지 않습니다. (지표 안정화를 위해)

Advice

• 즉시 사용 가능한 AMI를 사용하여 요청을 더 빨리 처리하고 휴지 기간을 줄이기 위해 구성 시간을 줄이새요.

문제

오토 스케일링 그룹이 관리하는 EC2 인스턴스에 호스팅된 애플리케이션으로 들어오는 트래픽이 급격하게 증가하여 ASG가 스케일 아웃되고 새로운 EC2 인스턴스가 실행되게 되었습니다. 트래픽은 계속해서 증가하지만, ASG는 5분이 지나기 전까지는 새로운 EC2 인스턴스를 곧바로 실행하지 않습니다. 이런 경우 가능성 있는 원인은 무엇일까요 ?

• 냉각 기간 (휴지 기간)

ASG for Solutions Architect

ASG 기본 종료 정책 (simplified version)

1. 가장 많은 인스턴스가 있는 AZ 찾기
2. AZ에 선택할 인스턴스가 여러 개 있는 경우 시작 구성이 가장 오래된 인스턴스를 삭제합니다.
3. ASG는 기본적으로 AZ 전체에서 인스턴스 수의 균형을 시도합니다.

즉 가장 많은 인스턴스가 있는 가용영역을 찾아 AZ에 선택할 인스턴스가 여러 개 있는 경우 시작 구성이 가장 오래된 인스턴스를 삭제하여 AZ 전체의 인스턴스 수의 균형을 맞춥니다.

비정상 Amazon EC2 인스턴스를 종료하지 않을 경우

인스턴스의 상태 확인 유예 기간이 만료되지 않았을 때

• Amazon EC2 Auto Scaling은 상태 확인 유예기간이 만료될 때까지 EC2 상태 확인 및 ELB 상태 확인을 기반으로 서비스를 시작한 인스턴스를 종료하지 않습니다.

인스턴스가 손상된 상태일 때

• Amazon EC2 Auto Scaling은 손상된 상태의 인스턴스를 즉시 종료하지 않습니다. 대신 Amazon EC2 Auto Scaling은 인스턴스가 복구될 때까지 몇 분 정도 기다립니다. Amazon EC2 Auto Scaling은 상태 확인을 위해 데이터를 보고하지 못하는 인스턴스를 지연시키거나 종료하지 않을 수도 있습니다. 이는 일반적으로 Amazon CloudWatch의 상태 확인 지표에 대한 데이터가 충분하지 않을 때 발생합니다.

인스턴스가 ELB 상태 확인에 실패할 때

• 기본적으로 ASG은 그룹의 상태 확인 구성이 EC2로 설정된 경우 ELB 상태 확인 결과를 사용하여 인스턴스의 상태를 결정하지 않습니다. 결과적으로 Amazon EC2 Auto Scaling은 ELB 상태 확인에 실패한 인스턴스를 종료하지 않습니다. ELB 콘솔에서 인스턴스 상태가 OutOfService이지만 Amazon EC2 Auto Scaling 콘솔에서 인스턴스 상태가 Healthy인 경우 상태 확인 유형이 ELB로 설정되어 있는지 확인합니다.

---

ASG 수명 주기 정책

• 기본적으로 인스턴스가 ASG에서 시작되자마자 서비스가 시작됩니다.
• 인스턴스가 서비스되기 전에 추가 단계를 수행할 수 있습니다. (Pending State)
• 인스턴스가 종료되기 전에 일부 작업을 수행할 수 있는 기능이 있습니다. (Terminating State)

Pending State: 인스턴스가 시작되기 전에 추가 단계 수행 Terminating State: 인스턴스가 종료되기 전에 일부 작업 수행

문제

지난 달, 어느 기업이 보유한 오토 스케일링 그룹 내의 무작위 EC2 인스턴스가 갑자기 충돌을 일으켰습니다. ASG가 비정상 EC2 인스턴스를 종료하고 이를 새로운 EC2 인스턴스로 대체하고 있는 관계로 EC2 인스턴스가 충돌하게 된 원인을 찾을 수 없는 상태입니다. 이 문제를 해결하고 ASG가 비정상 인스턴스를 종료하는 것을 막기 위해서는 어떤 문제 해결 조치를 취해야 할까요 ?

• 문제 해결을 위해 ASG 수명 주기 후크를 사용하여 EC2 인스턴스를 종료 상태로 멈추게 하기
• Auto Scaling 그룹에 대한 ReplaceUnhealthy 프로세스 유형을 일시 중단하고 인스턴스에 유지 관리 패치를 적용합니다. 인스턴스가 준비되면 인스턴스의 상태를 수동으로 다시 정상으로 설정하고 ReplaceUnhealthy 프로세스 유형을 다시 활성화할 수 있습니다.
• 인스턴스를 대기 상태로 전환한 다음 유지 관리 패치를 적용하여 인스턴스를 업데이트합니다. 인스턴스가 준비되면 대기 상태를 종료한 다음 인스턴스를 서비스로 되돌릴 수 있습니다.

Launch Template vs Launch Configuration

• Amazon 머신 이미지의 ID, 인스턴스 유형, 키페어, 보안 그룹 및 EC2 인스턴스를 시작하는 데 사용하는 기타 파라미터(태그, EC2 사용자 데이터...)

Launch Template (newer)

• 여러 버전을 가질 수 있음
• 매개변수 하위 집합 생성 (재사용 및 상속을 위한 부분 구성)
• 온디맨드 및 스팟 인스턴스 (또는 혼합)를 모두 사용하여 프로비저닝
• T2 무제한 버스트 기능을 사용할 수 있습니다.
• AWS에서 사용 권장

Launch Configuration (lagacy)

• 매번 다시 생성해야 함