ASG(Auto Scaling Group) Policies
1) 동적 스케일링 정책
ㄱ. Target Tracking Scaling(대상추적 스케일링)
- 단순하고 쉬우며 모든 EC2 인스턴스에서 오코 스케일링 그룹의 평균 CPU 사용률을 추적하여
CPU 수치가 설정한 범위 내에서 관리될 수 있도록 기준을 정함, 상시 사용이 가능함
ㄴ. Simple / Step Scaling
- Cloud Watch 경보를 설정해서 전체 ASG에 대해서 CPU 사용률이 지정한 용량 이상으로 사용할 경우
유닛을 추가하거나 지정한 용량 이하로 떨어질 경우 유닛을 제거할 수도 있습니다.
- Cloud Watch 경보를 설정할 때 한 번에 추가 및 제거할 용량 단위 수를 단계 별로 설정해야 합니다.
ㄷ. Scheduled Action
- 지정한 사용 패턴을 바탕으로 스케일링을 예상하는 것
예:) 금요일 오후 5시 빅 이벤트가 있으면 여러 사람들이 사용할 것을 대비해서 ASG 최소 용량을 일정에 맞춰
자동으로 증가시키고 예정된 작업을 수행하도록 함
ㄹ. Predictive Scaling(예측 스케일링)
- AWS 내에서 활용하는 Auto Scaling Service를 활용하여 지속적으로 예측을 생성할 수 있음
- 로드를 보고 다음 스케일링을 예측하여 처리하는 것
Auto Scaling Group에서는 인스턴스만 관리해서 스케일링할 수도 있고 인스턴스를 스케일링 할 때 ELB에 매핑하여 관리할 수도
있습니다. 이런 경우 하나의 인스턴스에서 처리할 수 있는 요청이 한정이 되어 있을 경우, 최적으로 처리할려고 이 대상에 스케일링을
할 수 있습니다.
가령, 인스턴스 하나에 3개의 요청을 처리할 때 최적의 퍼포먼스가 나온다고 한다면, 인스턴스 B, C에도 추가 요청건에 대해서
전달하며 Scale-Out 작업을 한다는 것입니다.
ㅁ. Application이 네트워크에 연결된 경우
Average In/Out (Application이 Network 범위 안에 있는 경우) 스케일링 인, 아웃을 할 수 있습니다.
가령, 업로드나 다운로드가 많아서 EC2 인스턴스에 대해 해당 네트워크에서 병목 현상이 발생할 것 같다면,
평균 네트워크 입출력량을 기반으로 스케일링을 수행하면 됩니다.
특정 임계값에 도달할 때 스케일링을 하도록 설정합니다.
또는 Cloud Watch에서 Application 별로 지표를 설정하고 이를 기반으로 스케일링 정책을 수정할 수 있습니다.
▷ 평가 기간 동안 로드된 트래픽을 보고 예측하여서 앞으로의 스케일링 정책을 셋팅하는 것
▷ 앞으로 발생할 이벤트에 대해서 미리 스케일링 정책을 셋팅하는 것
▷ 경보 상태에서 경보를 생성하여 셋팅할 수 있고 해당 경보는 스케일링의 기준이 될 수 있습니다.
문제 정리
1) EC2 인스턴스를 r4.large에서 r4.4xlarge로 확장하는 것은 ________________ 입니다.
▷ 수직 확장성(Vertical Scalability)
2) EC2 인스턴스 수를 확장 및 축소하는 Auto Scaling Group에서 애플리케이션을 실행하는 것을 _______ 라 합니다.
▷ 수평 확장성(Horizontal Scalability)
3) ELB는 ____________ 를 제공합니다.
▷ 애플리케이션에서 사용할 수 있는 static DNS 이름(쉽게 생각해서 사용자가 어떻게 인스턴스에 접근하는지 체크)
: Load Balancer에서 DNS로 검색할 경우 각 Instance들이 반응해서 공공 IP가 바뀌게 됩니다.
요청이 각기 다른 인스턴스로 트래픽이 보내지며, NLB 같은 경우는 가용 영역당 하나의 고정 IPv4를 가지게 되면서 이를 노출하여
타겟 그룹 내 인스턴스에 전달하고 있습니다.
▷ 사용자가 요청을 보내면 해당 IP는 X-Forwarded-For의 요청 쪽 Header에서 확인하면 되지만, 기본적으로 할 수 없음
그래서 로드 밸런서는 인스턴스 상태를 체크하는데, 괜찮은 인스턴스한테 사용자 요청을 뿌려줌
뿌려주는데, 단 DNS로 접근하여 각 인스턴스의 공공 IP에 전달되고, NLB같은 경우는 인스턴스로 갈 때 하나의 IPv4로 고정해서 보냄
(자체적으로 만든 IP라 한다면 Elastic IP일 수 있음)
▷ AWS가 관리하는 기본 인프라가 변경되더라도 AWS는 static EndPoint를 사용하여 로드 밸런서에 액세스할 수 있도록 합니다.
4) 여러분은 ELB가 전면에 있는 10개의 EC2 인스턴스에서 웹 사이트를 실행하고 있습니다.
사용자는 웹 사이트 페이지 간에 이동할 때 웹사이트에서 항상 재인증 요청이 있다는 것에 불만을 가지고 있었지만, 한 개의 EC2 인스턴스인 경우에는 이러한 문제가 발생하지도 않고 원활하게 잘 작동하고 있었습니다. 이 현상의 원인은 무엇일까요?
▷ 이런 경우는 각 웹사이트에 연결할 때 서로 다른 대상 그룹이 호출되면서 인스턴스가 발현되거나 또는 대상 그룹 외 인스턴스가 발현되어서 발생하는 문제입니다.
인스턴스가 하나일 경우는 문제가 있지 않았기 때문에 이렇게 추측할 수 있고, 주소가 바뀔때마다 인스턴스가 바뀌기 때문에 발생하는 것입니다. 이럴 경우에는 작동하고 있는 인스턴스의 고정 세션을 설정해서 지속해서 바뀌는 문제를 해결하면 됩니다.
▶ ELB에 Sticky Session이 활성화되어 있지 않아서 입니다.
▷ 경로 라우팅, URL 호스트 이름에 기반한 라우팅, URL 라우팅, 쿼리스트링, Header 기반한 라우팅 ... 등에 의해 대상 그룹 호출이 달라집니다.
5) Application Load Balancer를 사용하여 EC2 Instance에서 호스팅되는 웹 사이트로 트래픽을 분산하고 있습니다.
웹 사이트는 실제로 Application Load Balancer의 IP 주소인 Private IPv4 주소에서 오는 트래픽만 보는 것으로 나타났습니다.
웹사이트에 연결된 클라이언트의 IP주소를 얻으려면 어떻게 해야 하나요?
▷ X-Forwarded-For 해더에서 클라이언트 IP 주소를 가져오도록 웹사이트의 백앤드(인스턴스 쪽)를 수정합니다.
▷ Application Load Balancer를 사용하여 EC2 인스턴스로 트래픽을 분산할 때 요청을 수신하는 IP 주소는 ALB의 Private IP 주소가 됩니다. 클라이언트의 IP 주소를 가져오기 위해서 ALB는 클라이언트의 IP 주소를 포함한 X-Forwarded-For라는 추가 헤더를 추가합니다.
6) ELB가 전면에 있는 일련의 EC2 인스턴스에서 애플리케이션을 호스팅했습니다. 일주일 후 사용자는 애플리케이션이 때때로 작동하지 않는다고 불평하기 시작합니다. 문제를 조사한 결과 일부 EC2 인스턴스가 때때로 충돌하는 것을 발견했습니다. 사용자가 충돌하는 EC2 인스턴스에 연결하지 못하도록 보호하려면 어떻게 해야 할까요?
▷ ELB에서 인스턴스가 상태가 좋은지 체크하는 옵션을 활성화합니다.
7) Application Load Balancer는 조건에 따라 트래픽을 다른 대상 그룹으로 라우팅 할 수 있습니다. 그 조건은 무엇이 있나요?
- 호스트 이름에 기반한 라우팅
- 요청 URL 경로를 통한 라우팅
- 소스 IP- 주소에 따른 라우팅
- Query String, Header에 기반한 라우팅
8) Application Load Balancer의 대상 그룹에 해당하지 않는 것은?
- Network Load Balancer (X)
- Lambda 함수(O)
- Private IP 주소(O)
- EC2 Instance(O)
- ECS(Elastic Container Service), Docker (O)
9) 규정 준수를 위해 최종 사용자에게 고정 static IP 주소를 노출하여 규제 기관에서 승인한 안정적인 방화벽 규칙 작성 시 어떤 유형의 ELB를 선택하시겠습니까?
▷ 최종 사용자에게 고정 IPv4 or Elastic IP 주소를 노출하여 실제 보이는 것과 접근하는 IP는 다르지만 요청한대로 온전하게 잘
접근하도록 해주는 구조가 NLB구조입니다.
▷ Network Load Balancer에는 AZ당 하나의 static IP 주소가 있으며 Elastic IP주소를 연결할 수 있습니다.
▷ Application Load Balancer 및 Classic Load Balancer에서는 static DNS 이름을 보여줍니다.
10) Application Load Balancer에서 사용자 지정 애플리케이션 기반 쿠키를 생성하려고 합니다. 다음 중 쿠키 이름으로 사용할 수 있는 것은 무엇일까요?
- AWSALBAPP(ALB의 쿠키 이름)
- AWSALBTG(ALB 기반 쿠키이름)
- AWSALB(ALB 쿠키이름)
- AWSELB(CLB 쿠키이름)
- APPUSERC(O)
참고
https://haams704.tistory.com/entry/AWS-Sticky-Session
AWS - Sticky Session
쉽게 생각해서 세션 유지하는 것과 같은 의미라 생각하면 됩니다. 예를 들어 유저1, 유저2, 유저3이 있고 각 유저들은 EC2 인스턴스1, 인스턴스2, 인스턴스3에 정보 요청을 하고 있습니다. ALB(Applicat
haams704.tistory.com
11) us-east-1의 몇몇 EC2 인스턴스에 트래픽을 분산하는 Network Load Balancer가 있습니다. us-east-1b AZ에 2개의 EC2 인스턴스와 us-east-1e AZ에 5개의 EC2 인스턴스가 있습니다. us-east-1b AZ의 EC2 인스턴스에서 CPU 사용률이 더 높다는 것을 확인했습니다. 추가 조사 후 트래픽이 두 AZ에 균등하게 분산되어 있음을 알 수 있습니다. 이 문제를 어떻게 해결하시겠습니까?
▷ 가용영역이 다른 곳에서 인스턴스가 분배되어 작업하고 한 가용영역이 더 많은 트래픽을 받아 사용률이 높다고 나와 있습니다.
트래픽이 100이라면 하나의 가용영역에 50, 다른 가용영역에 50 이렇게 균등하게 분산되는데 가용영역에 있는 인스턴스 수가 달라서
트래픽 부하가 발생하거나 최적의 퍼포먼스가 나오지 않는다면, 가용영역을 교차하여 사용하는 Cross-Zone Load Balancing을 활용하면
다음 트래픽이 인스턴스를 기반으로 균등하게 전달될 것이기 때문에 보다 효율적인 업무 처리가 될 수 있습니다.
12) Application Load Balancer와 Network Load Balancer의 어떤 기능을 통해 하나의 리스너에 여러 SSL 인증서를 로드할 수 있습니까?
▷ ELB에 있는 리스너에서는 여러 브라우저를 접근할 때 각 SSL 인증서를 로드해서 확인하고 거기에 맞는 브라우저에 접근하는데,
여기서 사용하는건 SNI 입니다. 이를 통해 서버 이름을 확인하고 몇가지 호스트 이름 규칙을 통해 어떤 브라우저로 접근해야 하는지
확인 후 트래픽을 전달합니다.
13) 다음 호스트 이름을 기반으로 트래픽을 3개의 대상 그룹으로 리디렉션하도록 구성된 Application Load Balancer가 있습니다: users.example.com, api.external.example.com 및 checkout.example.com. 이러한 각 호스트 이름에 대해 HTTPS를 구성하려고 합니다. 이 작업을 수행하려면 ALB를 어떻게 구성해야 할까요?
▷ 마찬가지로 호스트 이름을 기반으로 트래픽을 전달하는 ALB라 했기에, 호스트 이름을 알아내려면 서버 이름을 관리하는 SNI가 있어야 합니다. 또한 각 호스트 이름에 대해서 HTTPS, SSL 인증서를 구성하려고 한다고 하였으므로, 정답은 SNI를 사용해서 서버 이름을 가져오고 이를 통해 호스트 이름을 추출하여 SSL 인증서를 구성한다고 정의하면 됩니다.
▷ SNI를 사용하면 동일한 수신기에서 각각 자체 SSL 인증서가 있는 여러 HTTPS 어플리케이션을 노출할 수 있습니다.
14) 목표 용량과 최대 용량을 모두 3으로 구성한 Auto Scaling Group에서 관리하는 EC2 인스턴스 집합에 호스팅되는 애플리케이션이 있습니다. 또한, CPU 사용율이 60%에 도달하면 ASG를 확장하도록 구성된 CloudWatch Alarm도 생성되어 있습니다. 이 애플리케이션이 갑자기 많은 트래픽을 수신하여 CPU 사용율이 80%라면 어떤 현상이 발생할까요?
▷ 보통 같으면 경보를 통해 CPU 사용률이 기존 정한 것 보다 추가할 경우 스케일링 정책에 의해 Scale-Out 되는 것이 일반적이나,
목표 용량과 최대 용량이 모두 3으로 같기 때문에 현재 정의한 스케일링 정책은 제대로 실행되지 않을 것입니다.
Scale-Out 이벤트 중에는 Auto Scaling Group 정책으로 정의한 최대 용량을 초과할 수 없기 때문입니다.
15) ApplicationLoad Balancer가 전면에 있는 Auto Scaling Group (ASG)이 있습니다. ALB Health Checks을 사용하도록 ASG를 구성했는데 하나의 EC2 인스턴스가 비정상으로 보고되었습니다. EC2 인스턴스는 어떻게 될까요?
▷ ASG는 EC2 인스턴스가 비정상이 된 경우 종료하고 다른 인스턴스를 새로 생성하여 ELB에 붙입니다.
단, 종료되고 새로 생성되는 동안의 쿨다운 시간(기본 5분)은 대기하도록 합니다.
▷ EC2 Health Check(기본값) 대신 Application Load Balancer Health Checks를 기반으로 EC2 인스턴스의 상태를 확인하도록
ASG를 구성할 수 있습니다. EC2 인스턴스가 ALB Health Checks에 실패하면 비정상으로 표시되고 ASG가 새로운 EC2 인스턴스를
시작하는 동안 종료됩니다.
16) 여러분의 상사가 애플리케이션이 데이터베이스에 전송하는 분당 요청 수를 기반으로 ASG을 스케일링하도록 요청했습니다. 어떻게 해야 할까요?
▷ 백엔드-데이터베이스 연결에 대한 "분당 요청 수"에 대한 Cloud Watch 지표가 없습니다. Cloud Watch 사용자 지정 지표를 생성하여
Cloud Watch 경보를 생성해야 합니다.
17) 애플리케이션은 Application Load Balancer 및 ASG과 함께 배포됩니다. 현재 ASG를 수동으로 확장하고 EC2 인스턴스에 대한 평균 연결 수가 약 1000개인지 확인하는 확장 정책을 정의하려고 합니다. 어떤 스케일링 정책을 사용해야 할까요?
▷ Target Tracking Policy (대상 추적 정책)
18) Auto Scaling Group에서 관리하는 EC2 인스턴스에서 호스팅되는 애플리케이션이 갑자기 급증한 트래픽을 수신하여 ASG가 확장되고 새 EC2 인스턴스가 시작되었습니다. 트래픽은 지속적으로 증가하지만 ASG는 새 EC2 인스턴스를 즉시 시작하지 않고 5분 후에 시작합니다. 이 동작의 가능한 원인은 무엇일까요?
▷ Scale-Out, Scale-In 인 경우 새 인스턴스는 바로 생성되어 시작되는것 또는 종료되어 삭제되는 것이 아닙니다.
쿨다운 시간이 있고 이 시간 동안 메트릭을 안정화하는 시간입니다.
'Cloud' 카테고리의 다른 글
| AWS - Aurora (0) | 2023.01.27 |
|---|---|
| AWS - RDS (0) | 2023.01.25 |
| AWS - ASG(1) (0) | 2023.01.19 |
| AWS - Connection Draining (0) | 2023.01.18 |
| AWS - SSL/TLS (0) | 2023.01.18 |
