1
00:00:00,510 --> 00:00:01,589
So now let's discuss

2
00:00:01,589 --> 00:00:03,180
advanced concepts of Aurora

3
00:00:03,180 --> 00:00:05,250
that you need to know going into the exam.

4
00:00:05,250 --> 00:00:07,710
So let's talk about Replicas-Auto Scaling.

5
00:00:07,710 --> 00:00:09,360
So let's say we have clients

6
00:00:09,360 --> 00:00:12,360
and we have three Aurora instances right now.

7
00:00:12,360 --> 00:00:15,660
So one will be writing through the writer endpoint

8
00:00:15,660 --> 00:00:17,430
and the other two will be reading

9
00:00:17,430 --> 00:00:19,590
through the reader endpoint, okay?

10
00:00:19,590 --> 00:00:22,170
Now let's say that we are having many, many requests,

11
00:00:22,170 --> 00:00:24,630
read requests on the reader endpoint

12
00:00:24,630 --> 00:00:27,180
and so therefore the Amazon Aurora databases

13
00:00:27,180 --> 00:00:29,490
have an increased CPU usage.

14
00:00:29,490 --> 00:00:32,340
In that case, we can set up Replica-Auto scaling.

15
00:00:32,340 --> 00:00:34,410
and what this will do is that it will add,

16
00:00:34,410 --> 00:00:36,810
obviously, Amazon Aurora replicas.

17
00:00:36,810 --> 00:00:39,090
And then what will happen is that automatically,

18
00:00:39,090 --> 00:00:41,700
the reader endpoint is going to be extended

19
00:00:41,700 --> 00:00:44,580
to cover these new replicas.

20
00:00:44,580 --> 00:00:46,320
And therefore these new replicas will start

21
00:00:46,320 --> 00:00:49,939
receiving some traffic and the reads will be happening

22
00:00:49,939 --> 00:00:51,780
in a more distributed fashion

23
00:00:51,780 --> 00:00:54,720
hopefully bringing down the overall CPU usage.

24
00:00:54,720 --> 00:00:56,652
So this is replica-auto scaling.

25
00:00:56,652 --> 00:01:00,120
The second thing is custom endpoints.

26
00:01:00,120 --> 00:01:02,490
So let's say we have the same setup

27
00:01:02,490 --> 00:01:05,459
but this time we have two different kinds of replicas.

28
00:01:05,459 --> 00:01:09,090
As you can see, we have some db.r3 large

29
00:01:09,090 --> 00:01:11,970
and some db.r5.2xlarge.

30
00:01:11,970 --> 00:01:15,810
So some read replicas are bigger than others.

31
00:01:15,810 --> 00:01:17,340
And the reason you would do this

32
00:01:17,340 --> 00:01:19,320
is that you wanna define a subsets

33
00:01:19,320 --> 00:01:22,980
of your Aurora instances as a custom endpoint.

34
00:01:22,980 --> 00:01:24,877
So let's say we define a custom endpoint

35
00:01:24,877 --> 00:01:28,830
on these two bigger Aurora instances.

36
00:01:28,830 --> 00:01:30,600
The reason we would do so is for example,

37
00:01:30,600 --> 00:01:34,071
that we know that these instances are more powerful

38
00:01:34,071 --> 00:01:36,120
and therefore they're going to be better

39
00:01:36,120 --> 00:01:39,960
to run analytical queries on these specific replicas.

40
00:01:39,960 --> 00:01:43,229
So when you do so you have a custom endpoint that's defined.

41
00:01:43,229 --> 00:01:45,600
And when you have a custom endpoint

42
00:01:45,600 --> 00:01:48,750
generally, the reader endpoint itself is not used

43
00:01:48,750 --> 00:01:50,490
after defining custom endpoints.

44
00:01:50,490 --> 00:01:53,910
So it would not disappear, but you would not use it anymore.

45
00:01:53,910 --> 00:01:58,440
And what you would do practically speaking, is set up

46
00:01:58,440 --> 00:02:02,100
many custom endpoints for many different kind of workloads

47
00:02:02,100 --> 00:02:04,622
therefore allowing you to query only a subsets

48
00:02:04,622 --> 00:02:07,053
of your Aurora replicas.

49
00:02:08,280 --> 00:02:09,930
Next we have serverless.

50
00:02:09,930 --> 00:02:12,780
So this is going to give you automated database

51
00:02:12,780 --> 00:02:15,969
instantiation and auto-scaling based on actual usage

52
00:02:15,969 --> 00:02:19,800
which is great when you have infrequent, intermittent

53
00:02:19,800 --> 00:02:21,810
or unpredictable workloads

54
00:02:21,810 --> 00:02:24,870
and therefore you don't need to do any capacity planning.

55
00:02:24,870 --> 00:02:26,280
You're going to pay per the second

56
00:02:26,280 --> 00:02:29,370
of each Aurora instance that is being spun up

57
00:02:29,370 --> 00:02:31,620
and this can be a lot more cost effective.

58
00:02:31,620 --> 00:02:32,670
So how does that work?

59
00:02:32,670 --> 00:02:36,120
Well, the clients is going to talk to a proxy fleet

60
00:02:36,120 --> 00:02:37,590
that is managed by Aurora

61
00:02:37,590 --> 00:02:40,986
and in the backend many Aurora instances will be created

62
00:02:40,986 --> 00:02:43,830
based on your workload in a serverless fashion.

63
00:02:43,830 --> 00:02:47,433
So you don't have to provision capacity at all in advance.

64
00:02:48,450 --> 00:02:50,070
Then we have a multi-master

65
00:02:50,070 --> 00:02:53,010
and this is in case you want immediate fill over

66
00:02:53,010 --> 00:02:54,420
for the writer nodes,

67
00:02:54,420 --> 00:02:56,970
in case you want high availability for the writer node.

68
00:02:56,970 --> 00:03:01,230
In this case, all the nodes in your Aurora cluster does read

69
00:03:01,230 --> 00:03:03,450
and write versus the idea

70
00:03:03,450 --> 00:03:06,150
that before, if you only have one right node

71
00:03:06,150 --> 00:03:08,130
and it falls down, it fails

72
00:03:08,130 --> 00:03:12,570
then you have to promote the read replica as the new master.

73
00:03:12,570 --> 00:03:15,300
So here we have three Aurora instances.

74
00:03:15,300 --> 00:03:17,400
There's replication happening between all of them,

75
00:03:17,400 --> 00:03:18,900
there's a shared storage volume

76
00:03:18,900 --> 00:03:22,230
and the clients will have multiple database connection.

77
00:03:22,230 --> 00:03:24,510
All the Aurora instances can do writes

78
00:03:24,510 --> 00:03:26,850
and in case one Aurora instance fails,

79
00:03:26,850 --> 00:03:29,160
then you can automatically fail over to another one

80
00:03:29,160 --> 00:03:32,070
giving you immediate failover for the writer node.

81
00:03:32,070 --> 00:03:34,800
And this is the kind of use cases

82
00:03:34,800 --> 00:03:37,740
and scenarios that the exam will test you on.

83
00:03:37,740 --> 00:03:40,170
Finally, we have global Aurora.

84
00:03:40,170 --> 00:03:44,610
So in case we have a Aurora cross region read replica,

85
00:03:44,610 --> 00:03:46,860
it's going to be very helpful for disaster recovery

86
00:03:46,860 --> 00:03:48,330
very simple to put in place

87
00:03:48,330 --> 00:03:51,180
but you can also set up the Aurora global database

88
00:03:51,180 --> 00:03:53,280
which is the recommended way of doing things today.

89
00:03:53,280 --> 00:03:55,290
In this case, you have one primary region

90
00:03:55,290 --> 00:03:57,150
where all the reads and writes happen,

91
00:03:57,150 --> 00:04:01,230
but you can set up up to five secondary read only regions

92
00:04:01,230 --> 00:04:04,110
where the replication should be less than one second

93
00:04:04,110 --> 00:04:08,520
and up to 16 read replicas per secondary region.

94
00:04:08,520 --> 00:04:10,860
And this will help you decrease latency

95
00:04:10,860 --> 00:04:12,840
for the read workloads all over the world.

96
00:04:12,840 --> 00:04:15,090
But also in case you have a database outage

97
00:04:15,090 --> 00:04:17,490
in one region promoting another region

98
00:04:17,490 --> 00:04:20,160
for disaster recovery purposes has an RTO,

99
00:04:20,160 --> 00:04:22,770
so recovery time objective of less than one minute.

100
00:04:22,770 --> 00:04:24,330
So it takes less than one minute to recover

101
00:04:24,330 --> 00:04:25,560
into another region.

102
00:04:25,560 --> 00:04:27,090
And here is a sentence you should look

103
00:04:27,090 --> 00:04:29,040
out for from an exam perspective.

104
00:04:29,040 --> 00:04:32,430
It takes on average, less than one second to replicate data

105
00:04:32,430 --> 00:04:35,640
across region for your Aurora global database.

106
00:04:35,640 --> 00:04:37,380
So this is something that if you see an exam,

107
00:04:37,380 --> 00:04:40,055
it's a hint to use a global Aurora.

108
00:04:40,055 --> 00:04:41,520
So let's have a look.

109
00:04:41,520 --> 00:04:43,530
We have us-east-1 as our primary region

110
00:04:43,530 --> 00:04:46,170
which is where the applications do the read and writes.

111
00:04:46,170 --> 00:04:49,350
And then we'll set up a secondary region in eu-wes-1

112
00:04:49,350 --> 00:04:52,140
where some replication happening with a global database

113
00:04:52,140 --> 00:04:54,951
of Aurora and the applications there can do read only

114
00:04:54,951 --> 00:04:59,070
from that setup but in case us-east-1 fails,

115
00:04:59,070 --> 00:05:02,430
then we can fail over to eu-wes-1 by promoting it

116
00:05:02,430 --> 00:05:05,190
as a read Write Aurora to cluster.

117
00:05:05,190 --> 00:05:07,050
Aurora also has an integration

118
00:05:07,050 --> 00:05:09,120
with machine learning services within AWS.

119
00:05:09,120 --> 00:05:10,890
So the idea with Aurora machine learning

120
00:05:10,890 --> 00:05:13,260
is that you can have ML-based predictions

121
00:05:13,260 --> 00:05:14,160
to your applications.

122
00:05:14,160 --> 00:05:16,770
You have the SQL interface, it's a simple optimized

123
00:05:16,770 --> 00:05:18,840
insecure integration between Aurora

124
00:05:18,840 --> 00:05:21,540
and different AWS machine learning services.

125
00:05:21,540 --> 00:05:23,910
So two supported services are SageMaker,

126
00:05:23,910 --> 00:05:26,310
which allows you to use any kind of machine learning model

127
00:05:26,310 --> 00:05:28,650
in the backend or Amazon Comprehend

128
00:05:28,650 --> 00:05:30,480
if you want to do sentiment analysis.

129
00:05:30,480 --> 00:05:32,100
Now you don't need to be an expert in SageMaker

130
00:05:32,100 --> 00:05:34,552
or Comprehend, you just need to know

131
00:05:34,552 --> 00:05:36,270
that Aurora has an integration with those.

132
00:05:36,270 --> 00:05:38,430
So in order to use Aurora machine learning,

133
00:05:38,430 --> 00:05:41,430
you don't need to have a machine learning experience

134
00:05:41,430 --> 00:05:44,730
and the use cases for this would be to have fraud detection,

135
00:05:44,730 --> 00:05:46,951
ads targeting, sentiment analysis, or product recommendation

136
00:05:46,951 --> 00:05:49,140
all within Aurora.

137
00:05:49,140 --> 00:05:51,420
So to give you the architecture idea,

138
00:05:51,420 --> 00:05:53,010
Aurora is going to be connected

139
00:05:53,010 --> 00:05:54,660
to the machine learning services

140
00:05:54,660 --> 00:05:57,210
in AWS, and your application can just run

141
00:05:57,210 --> 00:05:58,890
a very simple SQL query.

142
00:05:58,890 --> 00:06:01,168
For example, what are the recommended products?

143
00:06:01,168 --> 00:06:03,190
Aurora will send some data

144
00:06:03,190 --> 00:06:06,120
into the machine learning services, such as for example,

145
00:06:06,120 --> 00:06:07,168
the user's profile, the shopping history,

146
00:06:07,168 --> 00:06:08,670
et cetera, et cetera

147
00:06:08,670 --> 00:06:11,220
and then the machine learning service will return

148
00:06:11,220 --> 00:06:13,200
a prediction directly to Aurora.

149
00:06:13,200 --> 00:06:16,680
For example, the user should buy a red shirt and blue pants

150
00:06:16,680 --> 00:06:19,170
and then Aurora can just return the query results

151
00:06:19,170 --> 00:06:21,420
to the application all through

152
00:06:21,420 --> 00:06:25,380
as a result of the SQL query, which is very handy.

153
00:06:25,380 --> 00:06:26,580
So that's it, just a feature you need to know

154
00:06:26,580 --> 00:06:27,660
going to the exam.

155
00:06:27,660 --> 00:06:29,820
So that's it for this lecture, I hope you liked it

156
00:06:29,820 --> 00:06:31,770
and I will see you in the next lecture.