1
00:00:00,220 --> 00:00:01,230
‫So now let's talk about

2
00:00:01,230 --> 00:00:03,200
‫auto scaling group scaling policies.

3
00:00:03,200 --> 00:00:04,250
‫And we have two different kinds,

4
00:00:04,250 --> 00:00:06,120
‫we have the dynamic scaling policies first.

5
00:00:06,120 --> 00:00:07,910
‫And so within the dynamics scaling policies,

6
00:00:07,910 --> 00:00:10,410
‫we have three kinds, we have the target tracking scaling,

7
00:00:10,410 --> 00:00:11,500
‫which is pretty easy.

8
00:00:11,500 --> 00:00:13,420
‫It's the most simple and easy to set up.

9
00:00:13,420 --> 00:00:15,190
‫And the idea is that you wanna say, for example,

10
00:00:15,190 --> 00:00:18,830
‫I want to track the average CPU utilization

11
00:00:18,830 --> 00:00:21,840
‫of my autoscaling groups across all my EC2 instances

12
00:00:21,840 --> 00:00:23,820
‫to stay at around 40%.

13
00:00:23,820 --> 00:00:26,640
‫This is when you want to have a default baseline

14
00:00:26,640 --> 00:00:29,010
‫and wanna make sure that you're always available.

15
00:00:29,010 --> 00:00:30,920
‫Simple and step scaling is more involved.

16
00:00:30,920 --> 00:00:33,050
‫So you set up your own CloudWatch alarms

17
00:00:33,050 --> 00:00:34,570
‫and when they're triggered so reasonable,

18
00:00:34,570 --> 00:00:38,690
‫when the CPU goes over 70% for your ASG as a whole,

19
00:00:38,690 --> 00:00:40,900
‫then add two units of capacity.

20
00:00:40,900 --> 00:00:42,750
‫And then you would set up a second rule saying,

21
00:00:42,750 --> 00:00:46,760
‫hey, in case the CPU utilization goes to less than 30%

22
00:00:46,760 --> 00:00:50,320
‫as a whole within my ASG, then remove one unit.

23
00:00:50,320 --> 00:00:54,440
‫But you would have to set up your CloudWatch alarms

24
00:00:54,440 --> 00:00:56,080
‫as well as the steps which is,

25
00:00:56,080 --> 00:00:59,030
‫how many units you wanna add at a time

26
00:00:59,030 --> 00:01:01,510
‫and how many units you want to remove at a time.

27
00:01:01,510 --> 00:01:03,440
‫And finally scheduled actions,

28
00:01:03,440 --> 00:01:05,480
‫which is to anticipate scaling

29
00:01:05,480 --> 00:01:06,970
‫based on the known users patterns.

30
00:01:06,970 --> 00:01:08,170
‫For example, you're saying that,

31
00:01:08,170 --> 00:01:10,520
‫hey, I know that there's going to be a big event

32
00:01:10,520 --> 00:01:11,760
‫at 5:00 PM on Fridays

33
00:01:11,760 --> 00:01:13,550
‫because when people are gonna be done with work

34
00:01:13,550 --> 00:01:15,610
‫and they're going to use my application,

35
00:01:15,610 --> 00:01:18,100
‫and therefore you want you to increase the min capacity

36
00:01:18,100 --> 00:01:21,010
‫automatically of your ASG to 10 at 5:00 PM

37
00:01:21,010 --> 00:01:22,200
‫every single Friday.

38
00:01:22,200 --> 00:01:23,590
‫This is a scheduled action

39
00:01:23,590 --> 00:01:25,370
‫where you know scaling in advance.

40
00:01:25,370 --> 00:01:26,830
‫And there's a new kind of scaling,

41
00:01:26,830 --> 00:01:28,670
‫which is called predictive scaling.

42
00:01:28,670 --> 00:01:29,760
‫So with predictive scaling,

43
00:01:29,760 --> 00:01:32,580
‫you continually have a forecast being made

44
00:01:32,580 --> 00:01:35,200
‫by the autoscaling service in AWS.

45
00:01:35,200 --> 00:01:36,440
‫And it will look at the load

46
00:01:36,440 --> 00:01:39,100
‫and we'll schedule scaling ahead.

47
00:01:39,100 --> 00:01:40,260
‫So what will happen is that

48
00:01:40,260 --> 00:01:43,460
‫the historical load is going to be analyzed over time

49
00:01:43,460 --> 00:01:46,250
‫and then forecast is going to be created.

50
00:01:46,250 --> 00:01:48,190
‫And then based on that forecast,

51
00:01:48,190 --> 00:01:51,480
‫they will be scaling actions being scheduled ahead of time,

52
00:01:51,480 --> 00:01:53,720
‫which is a quite a cool way of doing scaling as well.

53
00:01:53,720 --> 00:01:55,120
‫And I think this is the future

54
00:01:55,120 --> 00:01:56,680
‫because this is machine learning powered,

55
00:01:56,680 --> 00:01:58,940
‫and this really is a hands-off approach

56
00:01:58,940 --> 00:02:01,370
‫to automatic scaling for ASG.

57
00:02:01,370 --> 00:02:04,140
‫So some good metrics with scale on is a big question.

58
00:02:04,140 --> 00:02:07,370
‫So it depends really on what your application is doing

59
00:02:07,370 --> 00:02:08,830
‫and how it's working,

60
00:02:08,830 --> 00:02:10,970
‫but usually here are a few.

61
00:02:10,970 --> 00:02:13,410
‫So number one is CPU utilization

62
00:02:13,410 --> 00:02:16,220
‫because every time your instance receive a request,

63
00:02:16,220 --> 00:02:18,410
‫usually they will do some sort of computation

64
00:02:18,410 --> 00:02:20,560
‫and so it will use some CPU.

65
00:02:20,560 --> 00:02:23,150
‫And so if you look at the average CPU utilization

66
00:02:23,150 --> 00:02:26,060
‫across all your instances and it goes higher,

67
00:02:26,060 --> 00:02:28,100
‫that means that your instances are being more utilized

68
00:02:28,100 --> 00:02:30,820
‫and so it would be a good metric to scale on.

69
00:02:30,820 --> 00:02:32,110
‫Another metric to scale on,

70
00:02:32,110 --> 00:02:34,000
‫it's more like application specific,

71
00:02:34,000 --> 00:02:35,930
‫but it is a request counts per targets,

72
00:02:35,930 --> 00:02:37,510
‫which is based on your testing.

73
00:02:37,510 --> 00:02:39,270
‫You know that your EC2 instances

74
00:02:39,270 --> 00:02:41,060
‫operate at an optimal request

75
00:02:41,060 --> 00:02:44,650
‫of 1000 per request per target at a time

76
00:02:44,650 --> 00:02:46,540
‫and so maybe this is the target you want to have

77
00:02:46,540 --> 00:02:48,680
‫for your scaling.

78
00:02:48,680 --> 00:02:49,870
‫So here's an example.

79
00:02:49,870 --> 00:02:52,920
‫You have an auto scaling group with three EC2 instances,

80
00:02:52,920 --> 00:02:56,250
‫and your lb is currently spreading the instance request

81
00:02:56,250 --> 00:02:57,400
‫across all of them.

82
00:02:57,400 --> 00:02:59,890
‫So right now the value of the request

83
00:02:59,890 --> 00:03:01,850
‫counts per target metric is three

84
00:03:01,850 --> 00:03:04,520
‫because each EC2 instance on average

85
00:03:04,520 --> 00:03:06,933
‫has three requests outstanding.

86
00:03:07,870 --> 00:03:10,080
‫Next, if your application is network bound,

87
00:03:10,080 --> 00:03:12,760
‫so for example, there's a lot of uploads and downloads

88
00:03:12,760 --> 00:03:15,380
‫and you know that network is going to be a bottleneck

89
00:03:15,380 --> 00:03:17,210
‫for your EC2 instances,

90
00:03:17,210 --> 00:03:20,290
‫then you may want to scale on the average network in or out

91
00:03:20,290 --> 00:03:23,430
‫to make sure that if you reach some certain threshold,

92
00:03:23,430 --> 00:03:25,710
‫then you're going to scale based on that.

93
00:03:25,710 --> 00:03:27,880
‫Or any custom metrics that you push to CloudWatch,

94
00:03:27,880 --> 00:03:29,400
‫you can set up your own metrics

95
00:03:29,400 --> 00:03:31,210
‫that are going to be application specific

96
00:03:31,210 --> 00:03:34,950
‫and based on that, you can set up your scaling policies.

97
00:03:34,950 --> 00:03:37,200
‫Now, what else would you need to know about scaling policies

98
00:03:37,200 --> 00:03:38,960
‫is what's called the scaling cooldown.

99
00:03:38,960 --> 00:03:41,950
‫So the idea is that after there is a scaling activity,

100
00:03:41,950 --> 00:03:45,090
‫so whenever you add, or you remove instances,

101
00:03:45,090 --> 00:03:46,990
‫you are entering the cool-down period,

102
00:03:46,990 --> 00:03:50,140
‫which is by default five minutes or 300 seconds.

103
00:03:50,140 --> 00:03:51,907
‫And during that cooldown period,

104
00:03:51,907 --> 00:03:56,440
‫the ASG will not launch or terminate additional instances.

105
00:03:56,440 --> 00:03:59,120
‫And the reason behind this reasoning is that

106
00:03:59,120 --> 00:04:01,630
‫you allow four metrics to stabilize, okay,

107
00:04:01,630 --> 00:04:04,400
‫for your new instance to enter into effect

108
00:04:04,400 --> 00:04:07,200
‫and to see what the new metric will become.

109
00:04:07,200 --> 00:04:08,150
‫So the idea is that

110
00:04:08,150 --> 00:04:10,000
‫when there is a scaling action that occurs,

111
00:04:10,000 --> 00:04:13,050
‫the question is, is there a default cooldown in effects?

112
00:04:13,050 --> 00:04:14,560
‫If yes, then ignore the action.

113
00:04:14,560 --> 00:04:17,230
‫If no, then proceeded with the scaling action

114
00:04:17,230 --> 00:04:19,440
‫which is to launch or terminate instances.

115
00:04:19,440 --> 00:04:22,400
‫And so in advice to you, is to use a ready-to-use AMI

116
00:04:22,400 --> 00:04:26,260
‫to reduce the configuration time for your EC2 instances

117
00:04:26,260 --> 00:04:27,660
‫in order for them to request

118
00:04:27,660 --> 00:04:29,580
‫or to be serving the requests faster.

119
00:04:29,580 --> 00:04:32,810
‫So if you don't spend time configuring your EC2 instance,

120
00:04:32,810 --> 00:04:35,180
‫then they can be in effect right away.

121
00:04:35,180 --> 00:04:37,870
‫And then because there can be active way faster

122
00:04:37,870 --> 00:04:39,570
‫then the cooldown period can be decreased,

123
00:04:39,570 --> 00:04:42,633
‫and you can have a more dynamic scaling up and down

124
00:04:42,633 --> 00:04:44,800
‫of your ASG.

125
00:04:44,800 --> 00:04:46,030
‫And of course you need to make sure

126
00:04:46,030 --> 00:04:48,550
‫to enable something like detailed monitoring for ASG

127
00:04:48,550 --> 00:04:52,620
‫to get access to lower level two metrics every one minute,

128
00:04:52,620 --> 00:04:54,530
‫and to make sure that you have these metrics

129
00:04:54,530 --> 00:04:56,030
‫being updated fast enough.

130
00:04:56,030 --> 00:04:57,200
‫So that's it for this lecture.

131
00:04:57,200 --> 00:04:58,130
‫I hope you liked it,

132
00:04:58,130 --> 00:05:00,080
‫and I will see you in the next lecture.