1
00:00:06,614 --> 00:00:09,806
- Now let's run through another
demo of creating an elastic

2
00:00:09,806 --> 00:00:11,757
load balancer.

3
00:00:11,757 --> 00:00:15,692
Again, from the AWS console
dashboard, I'm going to go

4
00:00:15,692 --> 00:00:19,859
to EC2, that's where we find
the elastic load balancer.

5
00:00:21,522 --> 00:00:23,848
I'm gonna scroll down here
to the bottom, you can see

6
00:00:23,848 --> 00:00:27,957
Load Balancing, under Load
Balancers, we have one that

7
00:00:27,957 --> 00:00:32,404
was created from an earlier
demo, an earlier exercise,

8
00:00:32,404 --> 00:00:35,571
so I'm going to just leave
that one as it is, and we're

9
00:00:35,571 --> 00:00:39,227
going to hit Create Load Balancer.

10
00:00:39,227 --> 00:00:42,670
From here we have two choices,
we can create an application

11
00:00:42,670 --> 00:00:46,812
load balancer, which actually
does layer 7 load balancing

12
00:00:46,812 --> 00:00:50,423
looking at the content, or
we can choose a classic load

13
00:00:50,423 --> 00:00:54,590
balancer which is just a
lower layer at the port layer.

14
00:00:56,402 --> 00:00:59,484
So we're going to choose
classic load balancer,

15
00:00:59,484 --> 00:01:02,948
just as an example, click Continue.

16
00:01:02,948 --> 00:01:06,865
I'm gonna call this one
again AWS Live Lessons.

17
00:01:08,027 --> 00:01:10,643
I'm gonna choose the VPC,
in this case I'm gonna go

18
00:01:10,643 --> 00:01:14,810
with the one that we've
created in an earlier demo.

19
00:01:17,816 --> 00:01:21,983
Here, on second thought, I
wanna go with one that actually

20
00:01:23,169 --> 00:01:25,919
has some instances running in it.

21
00:01:27,434 --> 00:01:31,601
We need at least one listener,
again I can choose HTTP,

22
00:01:32,549 --> 00:01:34,382
HTTPS or just Raw TCP.

23
00:01:36,672 --> 00:01:41,625
For this demo I'm just gonna
choose HTTP and add that

24
00:01:41,625 --> 00:01:45,792
listener, in order for our
elastic load balancer to have

25
00:01:48,153 --> 00:01:52,070
a network footprint into
our VPC, we have to choose

26
00:01:52,070 --> 00:01:56,237
some subnets, and so it happens
that this particular VPC

27
00:01:57,350 --> 00:02:00,078
only has two and both of
them are public, so I'm just

28
00:02:00,078 --> 00:02:03,161
gonna go ahead and add both of those.

29
00:02:04,325 --> 00:02:08,010
Next, we can assign security groups.

30
00:02:08,010 --> 00:02:10,836
Whoops, I ended up inadvertently
adding an extra listener

31
00:02:10,836 --> 00:02:14,650
that we don't need so I'm
gonna remove that one.

32
00:02:14,650 --> 00:02:18,101
We're going to assign security
groups, you can see here

33
00:02:18,101 --> 00:02:22,268
we have a security group for
our web servers, but typically,

34
00:02:23,219 --> 00:02:27,386
it's a good practice to have
a security group per function

35
00:02:28,336 --> 00:02:32,998
or per tier, so our load
balancer would typically get

36
00:02:32,998 --> 00:02:35,675
it's own security group, so
I'm gonna go ahead and say

37
00:02:35,675 --> 00:02:38,914
Create a New Security Group,
I'm gonna call this one

38
00:02:38,914 --> 00:02:40,664
AWS Live Lessons ELB.

39
00:02:45,864 --> 00:02:50,031
And I'm going to say I want
to allow HTTP traffic from

40
00:02:53,568 --> 00:02:57,735
anywhere going to configure
a health check, and from here

41
00:02:59,687 --> 00:03:03,854
the health check is how the
load balancer knows that our

42
00:03:05,078 --> 00:03:08,782
backend instances are
indeed healthy and sending

43
00:03:08,782 --> 00:03:10,954
the proper response.

44
00:03:10,954 --> 00:03:14,498
So it's up to us to
configure this appropriately.

45
00:03:14,498 --> 00:03:18,589
So yes I'm going to assume
that my server is listening

46
00:03:18,589 --> 00:03:22,256
on port 80 and my ping
path will be whatever

47
00:03:23,747 --> 00:03:26,242
that application is set to,
sometimes it could be just

48
00:03:26,242 --> 00:03:30,831
slash, it might be status, you
can configure your webserver

49
00:03:30,831 --> 00:03:35,534
with a very specific health
check path, so long as your

50
00:03:35,534 --> 00:03:39,701
backend server returns an HTTP
200 response, then the ELB

51
00:03:42,015 --> 00:03:43,820
will consider it healthy.

52
00:03:43,820 --> 00:03:47,987
Anything other than a 200, any
300 responses, 400s and 500s

53
00:03:49,492 --> 00:03:51,808
will be considered unhealthy.

54
00:03:51,808 --> 00:03:56,125
In the case of using the
elastic load balancer along with

55
00:03:56,125 --> 00:04:00,292
auto scaling, if the ELB
determines that your instance

56
00:04:01,450 --> 00:04:06,204
is unhealthy because it's gotten
too many non-200 responses

57
00:04:06,204 --> 00:04:10,315
then the ELB will report
an unhealthy status to

58
00:04:10,315 --> 00:04:14,185
the autoscaling group, which
could mean that your instance

59
00:04:14,185 --> 00:04:17,227
will be terminated, sometimes
you want that to happen,

60
00:04:17,227 --> 00:04:20,652
other times you might not,
so really take your time

61
00:04:20,652 --> 00:04:24,209
to understand what the health
check should be for your

62
00:04:24,209 --> 00:04:26,550
particular application.

63
00:04:26,550 --> 00:04:29,181
Here, we're going to give
that health check five seconds

64
00:04:29,181 --> 00:04:33,435
to deliver a response which
actually is a really long time.

65
00:04:33,435 --> 00:04:36,992
We're going to do it every 30
seconds, we can change that

66
00:04:36,992 --> 00:04:41,159
to 60 if we wanted to, we're
going to say that it's gonna

67
00:04:42,244 --> 00:04:46,411
take three checks in a row
returning non-200 responses

68
00:04:47,627 --> 00:04:52,212
to set that particular
instance to be unhealthy.

69
00:04:52,212 --> 00:04:56,384
I'm gonna change this one to
2 and say that it takes 200

70
00:04:56,384 --> 00:05:00,899
responses in a row in order for
the machine to be considered

71
00:05:00,899 --> 00:05:01,732
healthy.

72
00:05:02,736 --> 00:05:05,836
Next we can add EC2 instances,
you can see that we have

73
00:05:05,836 --> 00:05:09,586
our choice of these two that
are running within the same

74
00:05:09,586 --> 00:05:13,003
VPC within the subnets that we've chosen.

75
00:05:13,890 --> 00:05:16,351
I'm gonna go ahead and add
these even though I know

76
00:05:16,351 --> 00:05:20,573
we don't necessarily have
these configured yet for HTTP

77
00:05:20,573 --> 00:05:23,755
traffic but we could come
back and do that later.

78
00:05:23,755 --> 00:05:26,463
You can see here that cross
zone load balancing is enabled

79
00:05:26,463 --> 00:05:30,354
by default, and connection
draining is also enabled

80
00:05:30,354 --> 00:05:34,230
by default, connection draining
says that here we have it

81
00:05:34,230 --> 00:05:38,194
configured for 300 seconds,
which is also a very long time,

82
00:05:38,194 --> 00:05:42,209
it's five minutes, and connection
draining just says that

83
00:05:42,209 --> 00:05:46,196
if we are going to remove an
instance, whether we do it

84
00:05:46,196 --> 00:05:49,919
manually or we allow autoscaling
to do it, if we're going

85
00:05:49,919 --> 00:05:53,739
to remove an instance from
the load balancer, before the

86
00:05:53,739 --> 00:05:58,571
load balancer lets us do that,
it's going to stop receiving

87
00:05:58,571 --> 00:06:02,559
incoming connections and it's
going to allow the outstanding

88
00:06:02,559 --> 00:06:06,714
requests to finish, that's
important because if we just

89
00:06:06,714 --> 00:06:10,495
simply yank an instance out
from behind the load balancer,

90
00:06:10,495 --> 00:06:13,625
users could end up with a blank
white page, they could end

91
00:06:13,625 --> 00:06:16,490
up with a half a file downloaded
and we don't want that,

92
00:06:16,490 --> 00:06:20,313
so connection draining allows
those in flight requests

93
00:06:20,313 --> 00:06:21,563
to be finished.

94
00:06:23,745 --> 00:06:27,072
Though I usually lower this
to something more reasonable,

95
00:06:27,072 --> 00:06:30,247
I generally think 300
seconds is a long time.

96
00:06:30,247 --> 00:06:33,619
Especially for API, most
requests should happen in a mere

97
00:06:33,619 --> 00:06:37,537
fraction of that, so we
could lower that to whatever

98
00:06:37,537 --> 00:06:40,339
makes the most sense for our application.

99
00:06:40,339 --> 00:06:43,451
We're going to add some tags,
again I typically like to add,

100
00:06:43,451 --> 00:06:47,542
this is my particular
pattern, I have my own way

101
00:06:47,542 --> 00:06:50,709
of organizing an infrastructure,
but again, you should be

102
00:06:50,709 --> 00:06:54,601
leveraging tags to organize
it in whatever way makes the

103
00:06:54,601 --> 00:06:58,214
most sense for your business,
ultimately I think the most

104
00:06:58,214 --> 00:07:02,017
important thing regardless of
the names of the tags you use

105
00:07:02,017 --> 00:07:04,953
and the values that you use,
I think the most important

106
00:07:04,953 --> 00:07:08,321
thing is that you find a pattern
and stick to that pattern

107
00:07:08,321 --> 00:07:11,498
so that you can predict
what the tags will be

108
00:07:11,498 --> 00:07:15,665
and be consistent about it, so
here, again, AWS Live Lessons

109
00:07:16,948 --> 00:07:21,115
ELB, and I'm going to add
an environment variable.

110
00:07:24,820 --> 00:07:27,512
And now we can review this,
make sure that we have

111
00:07:27,512 --> 00:07:30,856
everything set the way we
think it should be, we're in

112
00:07:30,856 --> 00:07:34,867
the right subnets, we have
the right instances in place,

113
00:07:34,867 --> 00:07:38,034
and I'm gonna go ahead and hit Create.

114
00:07:39,121 --> 00:07:42,253
There we go, just like that,
our load balancer is created,

115
00:07:42,253 --> 00:07:44,802
and here it is, this is
the one we've just created,

116
00:07:44,802 --> 00:07:49,570
we can scroll down here and
see that it is an internet

117
00:07:49,570 --> 00:07:53,737
facing load balancer, here's
our DNS name, so this is how

118
00:07:55,608 --> 00:07:59,766
we would connect to that,
we would point our end users

119
00:07:59,766 --> 00:08:01,266
to this DNS entry.

120
00:08:02,289 --> 00:08:06,456
More likely we would use this
DNS entry as the destination

121
00:08:07,920 --> 00:08:12,887
of a C name or within Amazon
Route 53 DNS, we could create

122
00:08:12,887 --> 00:08:16,875
what we would call an
alias record out of this.

123
00:08:16,875 --> 00:08:20,303
Here's our instances, you can
see that these two instances

124
00:08:20,303 --> 00:08:23,590
were registered with the load
balancer, and you can see

125
00:08:23,590 --> 00:08:26,481
they are out of service because
they're still registering

126
00:08:26,481 --> 00:08:29,865
with the load balancer, it
sometimes takes it a minute

127
00:08:29,865 --> 00:08:33,457
for the services to fully
register with the load balancer,

128
00:08:33,457 --> 00:08:37,378
and then it'll take even more
time, perhaps another minute

129
00:08:37,378 --> 00:08:40,767
for it to pass two
consecutive health checks.

130
00:08:40,767 --> 00:08:43,017
We can go over here and review
our health check and make

131
00:08:43,017 --> 00:08:45,940
changes to that if we want.

132
00:08:45,940 --> 00:08:48,801
We can see the listeners that
we've put in place, we can

133
00:08:48,801 --> 00:08:53,581
edit that and add a HTTPS
listener, and of course in order

134
00:08:53,581 --> 00:08:56,761
to do that we would have to
have an SSL certificate which

135
00:08:56,761 --> 00:09:01,295
we don't have, but we could get
one for free through the AWS

136
00:09:01,295 --> 00:09:04,295
certificate manager if we wanted to.

137
00:09:05,406 --> 00:09:08,085
So I'm going to cancel that
and just leave it at HTTP

138
00:09:08,085 --> 00:09:09,372
for now.

139
00:09:09,372 --> 00:09:12,748
We can also see monitoring,
this is out of the box

140
00:09:12,748 --> 00:09:16,954
monitoring, so once we start
getting traffic coming through

141
00:09:16,954 --> 00:09:20,018
this load balancer, we can
start to see, you know,

142
00:09:20,018 --> 00:09:23,623
1 being the number of
unhealthy host vs healthy host,

143
00:09:23,623 --> 00:09:26,732
we can see latency, the
number of requests that we're

144
00:09:26,732 --> 00:09:31,522
getting, backend connection
errors, you know, 500s versus

145
00:09:31,522 --> 00:09:33,772
400s versus 200s and so on.

146
00:09:34,883 --> 00:09:37,236
So again, once we have traffic
we'll start to see some

147
00:09:37,236 --> 00:09:38,236
graphs here.

148
00:09:39,266 --> 00:09:43,532
So that's it, that's really
easy to create an elastic

149
00:09:43,532 --> 00:09:44,782
load balancer.