AWS-EC2-3

-

Auto Scaling

The purpose we need to use the auto-scaling is to dynamically scale-out the number of services to satisfied for handling the incoming traffic.

Launch Configuration/Template

When the auto-scaling scale-out the auto-scaling group, it will use the launch configuration or launch template to launch a new instance.

Launch Configuration

  • Configurations
    • Instance Type
    • AMI
    • Key Pair
    • Block Storage
    • Security Group
    • User Data
    • IAM Role
    • ...

Launch Template

  • Support versioning
  • Generating template by using the currently running EC2 instance

Auto Scaling Group

The group which contains one or more EC2 instances, which can help to scale-out or scale-in the number of instances, but it cannot do scale-up and scale-down
  • The auto-scaling group is existing in a single region, same to ELB
  • But it can do auto-scaling cross AZ
  • Trying to balance the amount of the instances in different AZs by some scenarios
    • If launching a new instance from an AZ failed, then it will try to launch a new instance in a different AZ from VPC of the region
    • Scale-out priority in the AZ which has less instance against to other AZs
    • Scale-in priority in the AZ which has the most instances against to other AZs
  • The scenarios which will trigger to rebalance the instances for ASG
    • User tries to modify the AZs from ASG
    • User tries to manually remove or launch instance from ASG
    • AZ gets back to on-live from insufficient capacity
    • The price of Spot Instance is under the re-defined price in the AZ from ASG
  • ReBalancing the instances will launch a new instance first and then terminate the old instance at the next
  • Manually attach a new instance into ASG
    • If the attaching the new instance will exceed the capacity, then the attaching will be failed
    • Scenarios
      • Instance status is running
      • Instance AMI is existing
      • Instance is not in the other ASG
      • Instance is in the AZ which is defined by ASG
    • StandBy instances
      • User can set the status of instances to StandBy from ASG
      • The standby instances still existing in ASG and being charged as normal
      • The standby instances are not counted as the ASG living instances
      • The standby instances will not be doing the health check

Health Check

  • Instances Health Check
    • By using the instance itself health check to check the health of instances
    • By using the load balancer health check to check the health of instances
  • Grace Period
    • By default, the health check will wait for 300s for starting doing the health check
    • During this period, the instance will do like installing an operating system, start the operating system, install packages, execute the script from user data, etc.
    • Once the health result is unhealthy, ASG will terminate unhealthy instances first and then launch a new instance at the next.]

Binding ELBs

  • Classic Load Balancer - directly binding to the auto-scaling group
  • Application/Network Load Balancer - assign a Target Group which has been bonded with an ALB/NLB. (Autoscaling Group is the role who control the Target Group by adding the new-launched instance into Target Group)
  • Summary
    • ALB/NLB: distribute traffic to each of the instances in Target Group
    • ASG: control scale-out(Launch and attach new) or scale-in(Terminate and move out) the instances in Target Group

Scaling Policy

Keywords

  • Min - The minimum amount of the ASG allowed, keep the min number of instances
  • Max - The maximum amount of the ASG allowed, keep the max number of instances
  • Desired - According to the scaling policy to adjust the desired amount for ASG instances, treat it like the current best-balanced amount
* If making Min == Max == Desired, the auto-scaling is disabled but will always keep the amount of the amount (only the fault-tolerant feature is enabled)

Policy

  • Dynamic
    • Amount-Based (Keywords) - according to the amount of min, max, desired which the user has defined to do auto-scaling
    • Event-Based - based on the event alarm to trigger the ASG to do the auto-scaling
  • Scheduled
    • Time-Based - according to the schedule plan to trigger the ASG to do the scaling
      • Each timestamp only allow one schedule plan to execute

Target Tracking (metrics value of the instance from CloudWatch)

One of the ways to do the event-based auto-scaling, the easiest way. According to the value from metrics to implement auto-scaling the instances

Metrics Catagories

  • The number of requests (traffic)
  • The average CPU utilization
  • The average network-in (bytes)
  • The average network-out (bytes)

Warm-Up time

Before the time expired, the information on the new instance won't be attached to the ASG Metrics calculation range. (When a new instance being initialization, the CPU utilization is not working for network workload, instead, it is working for launching the new instance.)

Scale-out only

AWS allows setting only the scale-out policy without setting the scale-in policy.

Async Activity

Only one activity could be executing at the same time (scale-out/scale-in)

Auto-Scaling Alarm

The activity will be triggered by the CloudWatch Alarm when the value of the certain item, like the CPU utilization, Disk R/W bytes, Disk R/W count, Network-in, Network-out, etc. reach the threshold value defined by the user.

Simple Scaling

According the a alarm to trigger a action with cool-down time period

Cool-Down time

The time between the previous scaling activity down to the starting of the next scaling activity. (The scaling activity including the instances scaled-out/in to complete and the health check to complete)

Actions

  • The Number / Adding-number/ Removing-number of instances
  • The percentage of instances

Example

  • There is an auto-scaling alarm which keeps reading the value of metrics from the CloudWatch (set reading interval time)
  • Once reach the threshold, the alarm will be raised up
  • ASG received the alarm, like scale-out, it will launch the certain of instances. 
  • At this time, the alarm still reading the value of metrics from CloudWatch, but the launching instances still in initializing and have not ready for use yet. The metrics of the CloudWatch still exclude the new-launching instances, so that alarms keep sending to ASG. [Cool-Down time usage]
* Both ASG and Target group are logic grouping, ASG has the function like controller to launch or terminate the instances, once ASG launch a new EC2 instance, it will add a tag or label to the EC2 host which just launched which is inside of Target Group.

    Step Scaling

    According the metric's continued range to set different actions, same to the Target Tracking Scaling, it based on the metrics value not alarm

    Warm-Up timer

    [Same to the Target Tracking Scaling], the scaling is based on the metrics value, so that when the metrics data of the new launching instance be counted into the CloudWatch metrics data analysis is the matter.

    Monitoring

    The behavior which the ASG keep sending the metrics data to the CloudWatch. (Different services have different monitoring behavior from the CloudWatch)

    EC2 Monitoring

    • Basic Monitoring: default, cannot be disabled, triggered per 5 mins, for free
    • Detailed Monitoring: need to be enabled manually, triggered per 1 min, not for free
    • Custom Monitoring: defined by launch configuration/template
    • Matching the periods between EC2 and ASG:
      • EC2 record metrics data per 1 min, but ASG read metrics data per 5 mins, so that 4 mins metrics data which EC2 recorded is in van.
    ASG Monitoring
    • Default the monitoring is disabled, need to be enabled manually
    • Sending the metrics data to the CloudWatch
      • GroupMinSize
      • GroupMaxSize
      • GroupDesiredCapacity
      • GroupInServiceInstances
      • GroupPendingInstances
      • GroupStandbyInstances
      • GroupTerminatingInstances
      • GroupTotalInstances

    Scheduled Scaling

    After a auto-scaling group setup completely, the user is able to create a scheduled scaling which is based on time.

    Crontab

    A expression for time and cron jobs

    Comments

    Post a Comment

    Popular posts from this blog

    Union Find 模板

    -
    Union Find Union Find Union Find 动态的计算联通块问题 结构 global variables constructor() find(int x) union(int a, int b) 模板 (Map) global variables private Map<Integer, Integer> f; constructor() UnionFind(int n) { this.f = new HashMap<Integer, Integer>(); for (int i = 0; i < n; i++) { f.put(i, i); } } find(int x) int find(int x) { int root = x; // 找到“根” while (f.get(root) != root) { root = f.get(root); } // 拆“整”为“零”，把每个元素直接接到“根”上 while (root != x) { int nx = f.get(x); f.put(x, root); x = nx; } return root; } union(int a, int b) void union(int a, int b) { int rA = find(a); int rB = find(b); if (rA != rB) { f.put(rB, rA); } } 例题 Friend Circles 根据模板添加额外的全局变量，比如此题需要count，在每次合并的时候 count-- ，在初始化的时候或者写一个 setter 和 getter 去给 count 赋值和取值 public class Solution { class UnionFind { private int count; private Map...
    Read more

    Tree的经典题

    -
    Tree的经典题 Tree的经典题 找第k小 Kth Smallest Element in a BST 在树上就不需要使用Heap了，因为inorder traversal本身就是一个从小到大的序列，这里我们有几种方法 1. Recursive traversal 创建全局变量，记录traverse到哪儿了，当走到k的时候把值赋给result即可 时间复杂度 O(n) public class Solution { //设置全局变量 private int count = 0; private int result = 0; public int kthSmallest(TreeNode root, int k) { traversal(root, k); return result; } private void traversal(TreeNode root, int k) { if (root == null) { return; } traversal(root.left, k); //如果count等于k的时候才把结果赋给result //注意count从0开始，所以count先++之后再判断 count++; if (count == k) { result = root.val; } traversal(root.right, k); } } 2. Quick Select on Tree 首先要traverse计算每个点到它的时候子树总共有多少个点，然后用quick select，如果大于k，直接去左边找，如果小于k，判断当左边的个数加1正好等于k，那么这个k就落在root上，如果加1之后还小于k那么就要去向右边找了，因为此时左边没有第k个点。 时间复杂度 O(n) 最好最坏都是 public class Solution { public int kthSmal...
    Read more

    Tree DFS

    -
    Tree DFS Tree DFS Tree上的DFS分为两种（Divide Conquer + Traversal和纯Divide Conquer） 建立当前/用全局变量（根据不同的方式） root 为 空 （ 返回 什么/ 更新 指针） 左 节点和 右 节点 都 为 空 ，用 root 构建 当前 解（ 返回 什么/ 更新 指针） 左 节点和 右 节点 不 为 空 ，用 左右 构建 当前 解 返回 当前 /选择 左 ， 右 ， 中 Divide Conquer + Traversal 不同 一般 没有 全局变量， 创建当前 变量作为当前最终解 通过 左 节点的最终解和 右 节点的最终解， 计算 并更新 当前 变量 判断 左 节点的最终解， 右 节点的最终解， 当前 变量，在三个解中 选择 一个 作为当前层的最终解 返回 更新传入的参数指针 （ 有时会单独建立 class Result 类 ） 流程 建立 当前 变量（不一定第一步） root 为 空 （ 返回 什么） left 节点和 right 节点 都 为 空 ，用 root 构建 当前 解（ 返回 什么/ 更新 指针） left 节点和 right 节点 不 为 空 ，用 左右 解 leftResult , rightResult 计算 当前 解 选择 符合的解 比较 （ leftResult ， rightResult ， result ） + 选出 合适的解 直接使用 ：当前解 使用 选中的解 返回 更新 传入的指针 例题（Minimum Subtree） public class Solution { class Result { TreeNode minSubtree; int minSum; int sum; Result(TreeNode minSubtree, int minSum, int sum) { this.minSubtree = minSubtree; this...
    Read more