1

00:00:08,240  -->  00:00:16,049
welcome to part one of using AWS
ElasticCache Redis in this video we're

2

00:00:16,049  -->  00:00:21,510
going to go through the ElasticCache 
service and look at some of the features

3

00:00:21,510  -->  00:00:25,800
of it and where we would actually use it
the common use cases for ElasticCache

4

00:00:25,800  -->  00:00:29,160
and we'll also look at getting some
hands-on experience in creating an

5

00:00:29,160  -->  00:00:36,059
ElasticCache cluster using the AWS console
and then later on look at connecting to

6

00:00:36,059  -->  00:00:44,059
that ElasticCache Redis engine to read
and write information to in-memory cache

7

00:00:44,059  -->  00:00:49,200
so ElasticCache it provides scalable
in-memory cache so that is different to

8

00:00:49,200  -->  00:00:56,399
RDS or DynamoDB which is data that will
be persisted for a significant amount of

9

00:00:56,399  -->  00:01:01,859
time, basically for as long as you want
it to be so ElasticCache different

10

00:01:01,859  -->  00:01:07,799
in that is designed for short-term
storage of information and that

11

00:01:07,799  -->  00:01:12,810
information to be accessed very quickly
it currently supports the memcached and

12

00:01:12,810  -->  00:01:21,590
Redis open source engines now the common
use cases for ElastiCache would be to

13

00:01:21,590  -->  00:01:26,310
first of all to reduce load on your
databases so for example you might have

14

00:01:26,310  -->  00:01:32,430
a dynamo DB database and you want to
reduce the first of all the latency on

15

00:01:32,430  -->  00:01:38,520
on that database so speed up your
application you also want to reduce the

16

00:01:38,520  -->  00:01:42,720
amount of reads and writes that database
to reduce your cost and again you reduce

17

00:01:42,720  -->  00:01:48,720
that load on that on that database and
the way you would do that is that just

18

00:01:48,720  -->  00:01:53,810
the same as in dynamo DB you would have
storage of keys and objects of keys the

19

00:01:53,810  -->  00:02:00,180
same you can do with with for example
lesser cash Redis what we're going to be

20

00:02:00,180  -->  00:02:05,820
using in this lab and that that will
enable you to have high-speed access to

21

00:02:05,820  -->  00:02:09,599
that data which will be in memory and
you can put an expiry time on that data

22

00:02:09,599  -->  00:02:13,110
so that so it it doesn't cost you
significantly

23

00:02:13,110  -->  00:02:17,670
then once you've finished using it the
short-term it goes back it will be then

24

00:02:17,670  -->  00:02:24,660
accessed into into that long-term
dynamodb storage another very good use

25

00:02:24,660  -->  00:02:30,990
case is to manage application session
state so what we mean by that is if you

26

00:02:30,990  -->  00:02:35,400
have a look at the diagram there on the
right hand side we can see that we've

27

00:02:35,400  -->  00:02:39,990
got a user which can he or she is
connected in through an elastic load

28

00:02:39,990  -->  00:02:48,120
balancer and will be connected to one of
four ec2 instances so in this situation

29

00:02:48,120  -->  00:02:55,230
the person is connected into the first
ec2 server and they might be on a game

30

00:02:55,230  -->  00:02:59,640
that has high score data they might be
fling at some user profile data in a

31

00:02:59,640  -->  00:03:06,060
forum or whatever so that's temporary
session state storage that we want to

32

00:03:06,060  -->  00:03:10,200
maintain but we don't want to maintain
forever but we want to maintain that in

33

00:03:10,200  -->  00:03:17,640
the short-term so what happens for
example if that ec2 instance falls over

34

00:03:17,640  -->  00:03:23,850
or the ec2 instance is part of an auto
scaling group a group that scales down

35

00:03:23,850  -->  00:03:30,420
and all of a sudden that user is taken
from that first ec2 instance and then

36

00:03:30,420  -->  00:03:35,220
they're rerouted into the second ec2
instance all of a sudden that user has

37

00:03:35,220  -->  00:03:40,019
lost that information that what that
would have it might be a high score of a

38

00:03:40,019  -->  00:03:44,790
game it might be a form data that has
been lost so that creates a lot of

39

00:03:44,790  -->  00:03:49,769
problems for there or creates a lot of
frustration for an end user and doesn't

40

00:03:49,769  -->  00:03:53,700
provide a very good user experience so
we can actually manage that session

41

00:03:53,700  -->  00:03:58,200
state when we've got auto-scaling
instances behind a elastic load balancer

42

00:03:58,200  -->  00:04:03,120
or auto scaling groups behind an elastic
load balancer and that will make sure

43

00:04:03,120  -->  00:04:09,840
that when that back-end scaling is going
on that the user won't be won't have a

44

00:04:09,840  -->  00:04:14,700
bad experience from that so the first
thing we need to do is to create a

45

00:04:14,700  -->  00:04:21,120
security group for our our Redis cluster
and that security group needs to be set

46

00:04:21,120  -->  00:04:25,410
up so that it can allow our web servers
to communicate with that Redis cluster

47

00:04:25,410  -->  00:04:28,590
so
the easiest way to do that is here I've

48

00:04:28,590  -->  00:04:32,160
just going through and created a
security group I won't go through how to

49

00:04:32,160  -->  00:04:35,850
create a super new security group by
this stage of the course you know how to

50

00:04:35,850  -->  00:04:40,140
do that I'll just be boring you to death
by going through the process here so

51

00:04:40,140  -->  00:04:45,750
mainly what we've got here is a custom
tcp rule that is on the port range of

52

00:04:45,750  -->  00:04:52,920
six three seven nine which will be the
port range for your ElasticCache

53

00:04:52,920  -->  00:04:58,530
will be  the port for your ElasticCache Redis
cluster and the source is going to be

54

00:04:58,530  -->  00:05:03,900
the webserver security group there so
we're just allowing inbound on that and

55

00:05:03,900  -->  00:05:10,170
the same on the outbound we're going to
allow okay so we're going to allow

56

00:05:10,170  -->  00:05:13,920
everything destination all on the
outbound and so that's what we need to

57

00:05:13,920  -->  00:05:19,200
do that the the details of that are in
the in the lab notes for this video so

58

00:05:19,200  -->  00:05:22,950
just make sure that you set up that
security group first that Redis SG

59

00:05:22,950  -->  00:05:30,270
security group okay so just jumping into
the ElasticCache console we can see

60

00:05:30,270  -->  00:05:34,470
here but we've got no clusters created
yet so we just have the introduction

61

00:05:34,470  -->  00:05:41,760
screen so before we create an ElasticCache 
cluster we need to have a cache subnet

62

00:05:41,760  -->  00:05:45,390
group to launch that into so we click on
here on the left hand side before we

63

00:05:45,390  -->  00:05:53,460
click on getting started we click on
cache subnet groups and we click on

64

00:05:53,460  -->  00:05:59,730
create cache subnet group and so I've
already created one here and I won't go

65

00:05:59,730  -->  00:06:03,570
through the process again it's all
detailed in the lab notes so I've just

66

00:06:03,570  -->  00:06:09,030
got here is that it's in US East 1 and
that's its details there so we've

67

00:06:09,030  -->  00:06:14,550
created that that subnet group for our
cache and then we can use that to launch

68

00:06:14,550  -->  00:06:19,320
into a little launch our cache cluster
into that so again the the details on

69

00:06:19,320  -->  00:06:22,110
how to do that are very very
straightforward I won't go into that and

70

00:06:22,110  -->  00:06:27,140
it's detailed in the lab notes so just
going back to the ElasticCache dashboard

71

00:06:27,140  -->  00:06:34,440
okay so now we click on get started now
and we select our Redis not memcache so

72

00:06:34,440  -->  00:06:42,080
we collected Redis and click Next
okay so we won't enable replication here

73

00:06:42,080  -->  00:06:45,979
we'll leave that off to keep it simple
but in a real application you would

74

00:06:45,979  -->  00:06:51,289
probably look at multi a-z so we'll
leave that off there for now and then

75

00:06:51,289  -->  00:06:58,550
we'll give our cluster a name okay so by
default it comes up with a large

76

00:06:58,550  -->  00:07:02,120
instance so for a lab we don't want that
we don't want to get a big bill at the

77

00:07:02,120  -->  00:07:05,960
end of the month so we'll jump down to
t2 micro which seems a little bit more

78

00:07:05,960  -->  00:07:13,849
suitable for us we leave s3 location of
our Redis RDB file we'll leave that

79

00:07:13,849  -->  00:07:18,949
empty so click on next okay so this is
where we're going to select our case

80

00:07:18,949  -->  00:07:25,759
subnet group so there it is in and our
available available available ities I

81

00:07:25,759  -->  00:07:31,460
will leave that with no preference
that's fine and our security group so we

82

00:07:31,460  -->  00:07:36,620
need to select our Redis SG security
group that we created previously in the

83

00:07:36,620  -->  00:07:43,279
VPC console so no preference for
maintenance window will disable any SNS

84

00:07:43,279  -->  00:07:46,729
notifications will click on next and
then we have a review of what we've got

85

00:07:46,729  -->  00:07:55,099
there so we'll launch that case cluster
now okay it's currently being created we

86

00:07:55,099  -->  00:08:00,800
close out of this and we can see where
we're currently being created so that's

87

00:08:00,800  -->  00:08:04,550
coming along nicely so we'll just leave
it there for now for the first part of

88

00:08:04,550  -->  00:08:11,089
our ElasticCache Lab and in our next
part we're going to look at connecting

89

00:08:11,089  -->  00:08:17,719
into our ElastiCache Redis cluster and
read and write data to that and and see

90

00:08:17,719  -->  00:08:21,500
how that works and see how we can use
some of these or Redis commands to get

91

00:08:21,500  -->  00:08:27,909
information in and out of our cluster so
I'll see you in part two