1 00:00:00,300 --> 00:00:02,540 Let's talk about Amazon ElastiCache. 2 00:00:02,540 --> 00:00:04,380 So the same way you get RDS 3 00:00:04,380 --> 00:00:06,480 to have managed Relational Databases, 4 00:00:06,480 --> 00:00:10,100 ElastiCache is going to help you get managed Redis 5 00:00:10,100 --> 00:00:12,920 or Memcached which are cache technologies. 6 00:00:12,920 --> 00:00:13,770 So what are caches? 7 00:00:13,770 --> 00:00:15,896 Well they are in-memory databases 8 00:00:15,896 --> 00:00:17,830 with really high performance 9 00:00:17,830 --> 00:00:21,520 and low latency and what the cache will help you with 10 00:00:21,520 --> 00:00:25,020 is to help reduce a load off of databases 11 00:00:25,020 --> 00:00:27,780 for read intensive workloads. 12 00:00:27,780 --> 00:00:30,460 The idea that the common queries are going to be cache 13 00:00:30,460 --> 00:00:33,470 and therefore the database will not be queried every time, 14 00:00:33,470 --> 00:00:35,949 just your cache can be used every time 15 00:00:35,949 --> 00:00:37,950 to retrieve the results of these queries. 16 00:00:37,950 --> 00:00:40,380 What this also helps you do is makes your application 17 00:00:40,380 --> 00:00:42,768 stateless by putting the state of your application 18 00:00:42,768 --> 00:00:45,500 into Amazon ElastiCache. 19 00:00:45,500 --> 00:00:48,800 And because we have the same benefits of RDS, 20 00:00:48,800 --> 00:00:51,160 AWS will take the same maintenance 21 00:00:51,160 --> 00:00:54,110 of the operating system, the patching, the optimizations, 22 00:00:54,110 --> 00:00:55,547 the setup, configuration, monitoring, 23 00:00:55,547 --> 00:00:58,340 failure recovery and backups. 24 00:00:58,340 --> 00:00:59,816 Now if you use Amazon ElastiCache, 25 00:00:59,816 --> 00:01:02,048 just so you know that it will require you 26 00:01:02,048 --> 00:01:05,048 to do some heavy application code changes 27 00:01:05,048 --> 00:01:06,776 for your application. 28 00:01:06,776 --> 00:01:08,760 This is not something you just enable 29 00:01:08,760 --> 00:01:10,130 and off you go, you have a cache. 30 00:01:10,130 --> 00:01:13,050 You need to change your application to query the cache 31 00:01:13,050 --> 00:01:14,537 before or after querying the database 32 00:01:14,537 --> 00:01:17,003 and we'll see the strategies in a minute. 33 00:01:18,240 --> 00:01:21,180 So now let's talk about the architecture 34 00:01:21,180 --> 00:01:23,170 for using ElastiCache. 35 00:01:23,170 --> 00:01:25,310 And there could be many but I'm just giving you an example. 36 00:01:25,310 --> 00:01:28,510 So let's say we have an ElastiCache, an RDI database 37 00:01:28,510 --> 00:01:30,000 and your application. 38 00:01:30,000 --> 00:01:32,176 The application will query ElastiCache. 39 00:01:32,176 --> 00:01:35,150 To see if the query hours are being made 40 00:01:35,150 --> 00:01:37,180 and if it has already been made 41 00:01:37,180 --> 00:01:38,790 and it is stored in the ElastiCache 42 00:01:38,790 --> 00:01:40,160 then it's called a cache hit 43 00:01:40,160 --> 00:01:41,660 and then it just gets the answers straight 44 00:01:41,660 --> 00:01:43,100 from the ElastiCache 45 00:01:43,100 --> 00:01:47,530 and we are saving a trip to the database to do the query. 46 00:01:47,530 --> 00:01:50,640 Now in case of a cache miss, then we need to fetch 47 00:01:50,640 --> 00:01:52,110 the data from the database. 48 00:01:52,110 --> 00:01:54,000 We're going to read it from the database 49 00:01:54,000 --> 00:01:55,448 and then for other application 50 00:01:55,448 --> 00:01:59,060 or other instances where the same query will be made, 51 00:01:59,060 --> 00:02:01,997 we can write the data back into the cache 52 00:02:01,997 --> 00:02:06,696 so that the same query next time will result in a cache hit. 53 00:02:06,696 --> 00:02:09,580 The idea that it will help to relieve load 54 00:02:09,580 --> 00:02:10,776 from your RDS database 55 00:02:10,776 --> 00:02:13,157 and because you're storing data in the cache, 56 00:02:13,157 --> 00:02:16,277 there must be a cache invalidation strategy 57 00:02:16,277 --> 00:02:18,677 to make sure that only the most current data 58 00:02:18,677 --> 00:02:20,200 is used in there. 59 00:02:20,200 --> 00:02:21,980 And this is the whole difficulty 60 00:02:21,980 --> 00:02:24,400 around using caching technologies. 61 00:02:24,400 --> 00:02:28,020 Another architecture is around storing the user session 62 00:02:28,020 --> 00:02:29,830 to make your application stateless. 63 00:02:29,830 --> 00:02:31,940 So the idea is that your user will do a login 64 00:02:31,940 --> 00:02:34,210 into any account of your applications 65 00:02:34,210 --> 00:02:36,570 and then the application will write the session data 66 00:02:36,570 --> 00:02:38,390 into Amazon ElastiCache. 67 00:02:38,390 --> 00:02:41,450 Now if your user is redirected to another instance 68 00:02:41,450 --> 00:02:42,710 of your application, 69 00:02:42,710 --> 00:02:45,150 then your application can retrieve this session cache, 70 00:02:45,150 --> 00:02:47,510 the session directly from the Amazon ElastiCache 71 00:02:47,510 --> 00:02:51,174 and therefore your user still logs in and he doesn't need 72 00:02:51,174 --> 00:02:52,440 to log in one more time. 73 00:02:52,440 --> 00:02:53,770 And so the idea is that now you made 74 00:02:53,770 --> 00:02:56,490 your application stateless by writing the session data 75 00:02:56,490 --> 00:02:58,773 of your user into Amazon ElastiCache. 76 00:03:00,210 --> 00:03:01,440 Now something that can come up in the exam 77 00:03:01,440 --> 00:03:03,210 is for you to understand the difference 78 00:03:03,210 --> 00:03:06,070 between Redis and Memcached at a high level. 79 00:03:06,070 --> 00:03:08,940 So Redis is a technology that allows you 80 00:03:08,940 --> 00:03:12,007 to do multi AZ with Auto-Failover 81 00:03:12,007 --> 00:03:15,840 and the Read Replicas are used to scale the reads 82 00:03:15,840 --> 00:03:17,880 and also have high availability. 83 00:03:17,880 --> 00:03:19,890 So this looks a little bit like RDS. 84 00:03:19,890 --> 00:03:23,356 There is also Data Durability thanks to persistence 85 00:03:23,356 --> 00:03:26,300 and you have backup and restore features. 86 00:03:26,300 --> 00:03:29,210 So this looks a lot like RDS 87 00:03:29,210 --> 00:03:32,930 whereas Memcached is using multi-node 88 00:03:32,930 --> 00:03:35,030 for partitioning of data so it's called sharding. 89 00:03:35,030 --> 00:03:36,830 There is no high availability. 90 00:03:36,830 --> 00:03:38,620 There's no replication happening. 91 00:03:38,620 --> 00:03:40,310 It's not a persistent cache. 92 00:03:40,310 --> 00:03:41,839 There is no backup and restore 93 00:03:41,839 --> 00:03:44,448 and this is a multi-threaded architecture 94 00:03:44,448 --> 00:03:47,520 so we have multiple instances of together working 95 00:03:47,520 --> 00:03:49,440 in cache with some sharding. 96 00:03:49,440 --> 00:03:51,300 So the idea here that you need to remember 97 00:03:51,300 --> 00:03:55,360 is that Redis really is here for high availability, backup, 98 00:03:55,360 --> 00:03:57,080 Read Replicas, this kind of stuff 99 00:03:57,080 --> 00:03:59,480 whereas Memcached is a pure case of distributed 100 00:03:59,480 --> 00:04:01,620 where you can't afford to lose your data, 101 00:04:01,620 --> 00:04:03,030 there's no high availability 102 00:04:03,030 --> 00:04:04,150 and there's no backup and restore. 103 00:04:04,150 --> 00:04:06,510 So these are the main differences that you are going to have 104 00:04:06,510 --> 00:04:07,970 between the two technologies. 105 00:04:07,970 --> 00:04:08,920 So that's it. 106 00:04:08,920 --> 00:04:09,753 I hope you liked it 107 00:04:09,753 --> 00:04:11,620 and I will see you in the next lecture.