로드밸런서의 인스턴스 갯수의 최소 최대 값을 정해놓고 사용. 설정값보다 수가 적은 경우 인스턴스 갯수를 확장(scale out), 적을 경우 축소(scale in)
In the cloud you can create and get rid of servers very quickly
The goal of an ASG is to :
1) Scale out (add EC2 instances) to match an increased load
2) Scale in (remove EC2 instances) to match a decreased load
3) Ensure we have a minimum and a maximum number of machines running
4) Automatically Register new instances to a load balancer
# ASGs have the follong attributes
- A launch configuration
1) AMI + Instance Type
2) EC2 User Data
3) EBS Volumes
4) Security Groups
5) SSH Key Pair
- Min Size/Max Size/Initial Capacity
- Network + Subnets Information
- Load Balancer Information
# Auto Scaling Alarms
CloudWatch alarm 을 이용하여 ASG 를 컨트롤 (Alarm 은 ASG 를 컨트롤 하기 위한 트리거 역할)
- It is possible to scale an ASG based on CloudWatch alarms
- An Alarm monitors a metric (such as Average CPU)
- Metrics are computed(집계/산정) for the overall ASG instances
- Based on the alarm :
-- We can create scale-out policies (increase the number of instances)
-- We can create scale-in policies (decrease the number of instances)
[ Auto Scaling New Rules ]
직접적으로 EC2 상태(CPU사용률 등)를 기반으로 확장 기준을 정의할 수 있음
- It is now possible to define "better" auto scaling rules that are directly managed by EC2
1) Target Average CPU Usage
2) Number of requests on the ELB per instance
3) Average Network In
4) Average Network Out
- These rules are easier to set up and can make more sense
[ Auto Scaling Custom Metric ]
사용자 정의 기준에 의해 확장 룰을 정할 수 있음.
We can auto scale based on a custom metric (eg. number of connected users)
1) Send custom metric from application on EC2 to CloudWatch
2) Create CloudWatch alarm to react to low/high values
3) Use the CloudWatch alarm as the scaling policy for ASG
# ASG Brain Dump
- Scaling policies can be on CPU, Network... and can even be on custom metrics or based on a schedule (if you know your visitors patterns)
- ASGs use Launch configurations or Launch Templates(newer)
- To update an ASG, you must provide a new launch configuration/launch template
- IAM roles attached to an ASG will get assigned to EC2 instances
- ASG are free. You pay for the underlying resources being launched
- Having instances under an ASG means that if they get terminated for whatever reason, the ASG will automatically create new ones as a replacement. (Extra safety)
- ASG can terminate instances marked as unhealthy by an LB (and hence replace them)
[ Scaling Policies of ASG ]
1. Target Tracking Scaling (타겟 기준점 정함)
- Most simple and easy to set-up
eg. I want the average ASG CPU to stay at around 40%
2. Simple/Step Scaling (상한 하한 기준 정함)
- When a CloudWatch alarm is triggered (example CPU > 70%), then add 2 units
- Whena CloudWatch alarm is triggered (example CPU < 30%), then remove 1 unit
3. Scheduled Actions (특정 스케쥴에 확장/축소)
- Anticipate a scaling based on known usage patterns
- eg. increase the min capacity to 10 at 5 PM on Fridays
# Simple Scaling vs Step Scaling :
보통 Step Scaling 사용을 추천
- Simple Scaling 은 Scaling 이 완료될 때 까지, 그리고 cooldown 시간을 기다린 후 Alarm 에 응답.
- Step Scaling 은 Scaling 이 진행 중일 때도 Alarm 에 응답. 경보 메시지 수신 가능
직전의 ASG에 의한 인스턴스 확장/축소가 실제로 효과를 내기 전에 추가적인 확장/축소가 일어나지 않도록 일정 시간 딜레이를 주는 옵션.
쿨다운 시간이 너무 길 경우 축소(scale in)시 바로 꺼져도 되는 인스턴스가 살아있어 무의미한 인스턴스 사용요금이 발생 할 수 있음. 이 경우 쿨다운 시간을 줄여 비용절감을 할 수 있음.
짧은 시간 동안 여러번의 확장/축소가 이뤄져야 할 경우 쿨다운 시간을 적게 주어야 함.
- The cooldown period helps to ensure that your Auto Scaling group doesn't launch or terminate additional instances before the previous scaling activity takes effect.
- In addition to default cooldown for Auto Scaling group, we can create cooldowns that apply to a specific simple scaling policy
- A scaling-specific cooldown period overrides the default cooldown period.
- One common use for scaling-specific cooldowns is with a scale-in policy-a policy that terminates instances based on a specific criteria or metric. Because this policy terminates instances, Amazon EC2 Auto Scaling needs less time to determine whether to terminate additional instances.
- If the default cooldown period of 300 secs is too long - you can reduce costs by applying a scaling-specific cooldown period of 180 secs to the scale-in policy.
- If your application is scaling up and down multiple times each hour, modify the ASG cool-down timers and the CloudWatch Alarm Period that triggers the scale in
[ ASG for Solutions Architects *** ]
ASG 축소시 인스턴스 제거 정책. 인스턴스가 가장 많은 AZ 를 찾은 후, 그 안에서 가장 오래된 런치 설정의 인스턴스를 찾아 제거
1. ASG Default Termination Policy :
1) Find the AZ which has the most number of instances
2) If there are multiple instances in the AZ to choose from, delete the one with the oldest launch configuration
* ASG tries the balance the number of instances across AZ by default.
2. Lifecycle Hooks
- You have the ability to perform extra steps before the instance goes in service (Pending state)
- You have the ability to perform some actions before the instance is terminated (terminating state)
eg. logging
3. Launch Template vs Launch Configuration
* Both :
ID of AMI, the instance type, the instance type, a key pair, security groups, and the other parameters that you use to launch EC2 instances (tags, EC2 user-data..)
* Differences :
1) Launch Configuration (legacy) :
- Must be re-created every time
2) Luanch Template (newer) :
- Can have multiple versions
- Create parameters subsets (partial configuration for re-use and inheritance)
- Provision using both On-Demand and Spot instances (or a mix)
Sometimes you want control over the EC2 Instance placement strategy
That strategy can be defined using placement groups
When you create a placement group, you specify one of the following strategies for the group:
1) Cluster : clusters instances into a low-latency group in a single AZ
동일한 AZ, 동일한 Rack 으로 저지연, 네트워크성능 뛰어남
- Pros : Great network (10 Gbps bandwidth between instances)
- Cons : If the rack fails, all instances fails at the same time
- Use case :
Big Data job that needs to complete fast
Application that needs extremely low latency and high network throughput
2) Spread : spreads instances across underlyng hardware (max 7 instances per group per AZ) eg. critical applications
AZ여러군데 퍼뜨리는 방법으로, 모든 instance의 동시 처리실패 가능성을 낮춤, AZ 하나에 7개 인스턴스 제한
- Pros :
Can span across AZ
Reduced risk is simultaneous failure
EC2 Instances are on different physical hardware
- Cons :
Limited to 7 instances per AZ per placement group
- Use case :
Application that needs to maximize high availability
Critical Applications where each instance must be isolated from failure from each other
3) Partition : spreads instances across many different partitions (which rely on different sets of racks) within an AZ. Scales to 100s of EC2 instance per group (Hadoop, Cassandra, Kafka)
파티션 여러개에 인스턴스를 퍼뜨리는 방식으로, AZ 당 최대 7개의 파티션 제한, 최대 100개의 인스턴스 제약
- Up to 7 partitions per AZ
- Up to 100s of EC2 instances
- The instances in a partition do not share racks with the instances in the other partitions
- A partition failure can affect many EC2 but won't affect other partitions
- EC2 instances get access to the partition information as metadata
- Use cases :
HDFS, HBase, Kafka, Cassandra
[ # Placement Group 설정 ]
1) Placement Group 생성 :
create Placement Group > Strategy 선택 (Clustered/Spread/Partition) > 생성
2) Placement Group 설정 :
launch Instance > choose AMI > Choose Instance Type > Configure Instance 단계에서 Placement group 선택
* Partition 의 경우 auto distribution/혹은 파티션 지정 가능
* Clustered Placement group 은 free tier Instance Type 에서 선택 불가
These images can be customised at runtime using EC2 User data
- AMIs can be built for Linux or Windows machines
# Why would you use a custom AMI?
- Using a custom built AMI can provide the following advantages:
- Pre-installed packages needed
- Faster boot time (no need for EC2 user data at boot time)
- Machine comes configured with monitoring/enterprise software
- Security concerns - control over the machines in the network
- Control of maintenance and update of AMIs over time
- Active Directory Integration out of the box
- Installing your app ahead of time (for faster deployes when auto-scaling)
- Using someone else's AMI that is optimised for running an app, DB, etc..
# Using Public AMIs
- You can leverage AMIs from other people
- You can also pay for other people's AMI by the hour
-- These people have optimised the software
-- The machine is easy to run and configure
-- You basically rent "expertise" from the AMI creator
- AMI can be found and published on the Amazon Marketplace
* Warning : Do not use an AMI you don't trust, Some AMIs might come with malware or may not be secure
[ # AMI Storage ]
- Your AMI take space and they live in Amazone S3
- Amazon S3 is a durable, cheap and resilient storage where most of your backups will live (but you won't see them in the S3 console)
- By default, your AMIs are private, and locked for your account/region
- An AMI created for a region can only be seen in that region
- AMI is region locked and the same ID cannot be used across regions
- You can also make your AMIs public and share them with our AWS accounts or sell them on the AMI Marketplace
[ # AMI pricing ]
- AMIs live in Amazon S3, so you get charged for the actual space in takes in Amazon S3
- Amazon S3 pricing in US-EAST-I:
First 50TB/month: $0.023 per GB
Next 450TB/month:$0.022 per GB
- Overall it is quite inexpensive to store private AMIs
- Make sure to remove the AMIs you don't use
[ Cross Acount AMI Copy ]
AMI 는 공유가 가능.
타 계정의 AMI 를 복사하고자 할 경우 AMI 소유자가 권한을 부여해야 가능.
- You can share an AMI with another AWS account.
- Sharing an AMI doesn't affect the ownership of the AMI
- If you copy an AMI that has been shared with your account, you are the owner of the target AMI in your account
- To copy an AMI that was shared with you from another account, the owner of the source AMI must grant you read permissions for the storage that backs the AMI, either the associated EBS snapshot (for an Amazon EBS-backed AMI) or an associated S3 bucket (for an instance store-backed AMI).
* Limits
Windows AMI 와 같은 billingProduct AMI는 다른 계정으로부터 카피할 수 없음.
billingProduct AMI 로 EC2 인스턴스를 런칭한 후 해당 인스턴스로 AMI를 생성하여 복사하는 방식으로 복사가 가능.
1) You can't copy an encrypted AMI that was shared with you from another account. Instead, if the underlying snapshot and encryption key were shared with you, you can copy the snapshot while re-encrypting it with a key of your own. You own the copied snapshot, and can register it as a new AMI.
2) You can't copy an AMI with an associated billingProduct code that was shared with you from another account. This includes Windows AMIs and AMIs from the AWS Marketplace. To copy a shared AMI with a billingProduct code, launch an EC2 instance in your account using the shared AMI and then create an AMI from the instance.
# 내 AMI 를 기타 유저(AWS account)에게 공유하기
AMI 우클릭 > Modify Image Permissions > AWS account number 입력 및 Add Permission 클릭
* Add "create volume" permissions to the following associated snapshots when creating permissions
- 위 옵션을 체크할 경우 AMI에 대한 직접 copy 를 허용, 체크하지 않을 경우 직접 copy 를 불허.
- billingProduct AMI 를 카피하는 방식과 동일하게 본 AMI로 EC2 를 런칭한 후, AMI를 생성하는 방식으로 copy 가능
