AWS re:Invent 2019: Aurora Serverless: Scalable, cost-effective application deployment (DAT382)

hello everyone welcome to reinvent 2019 appreciate your coming to this presentation we're gonna be talking about Aurora serverless so my name is Shandor Maryse I'm a senior software development manager with the Aurora team also joining me in the presentation as Cathy Gibbs she's a senior solutions architects specializing in databases so she's gonna be giving some demos a little bit later in the presentation I really appreciate all of you coming out here on a Monday night at 7 p.m. I know it's late in the day and you'll want to be out there having dinner but I'm really grateful that you came so let's start just by quickly covering what we're gonna be talking about today as far as the agenda is concerned we're gonna be looking at first of all to put it all in context what is Amazon RDS what is Amazon Aurora and then we're going to be going into what is Aurora serverless talking about what it does when you might want to use it and then kind of taking a look at how does it actually work under the covers what are we doing here how does this offering work going into some detail there I'm going to be talking about some things that are related to Aurora server list that we've come out with in the last year or so that you might want to also check out helping make a raw or server list more useful to you and then we're gonna be finishing up with some live demonstrations to help drive the point home on what you can do with Aurora server lists and several things that are related to it now before we go off into our content here I want to call your attention to a few related sessions that are going to help get you to that next layer of detail on things you might want to follow up on these all actually happen to land on Wednesday so there's accelerating application development with Amazon Aurora on Wednesday December 4th I won't read all of that you can see it there's going deep on Aurora server lists that's gonna be a bit of a more intimate session where you get into smaller audience you get to interact with the presenters a little more easily and finally there's building a high performance apps on Amazon or or server lists that you can check out so please take a look at these sessions if you're interested in following up and learning more about Aurora or Aurora serverless so coming to what is Amazon relational database services well you can think of traditionally a lot of the kinds of things that you as an application developer might hire a DBA or a team of DBAs to manage for you this is what RDS offers as a managed service now just to take an audience poll here can I go to quick show of hands who here already uses some RDS related product today okay just about if you hunt so that's good I won't spend a whole lot of time then introducing RDS to you you're already familiar with this but just to put it in context somewhere along the way in our artiest journey we decided you know we wanted to build something homegrown something more cloud native which is why we build Amazon Arora so let me take the next poll here how many of you are currently active Amazon Aurora users okay still a lot of hands in the audience going up so what does Amazon Aurora I'll introduce it quickly we won't spend too much time there because many of you are already familiar with it but the reason why we built Aurora is because we wanted to offer something that gives you the speed and availability of a commercial database at the simplicity and cost effectiveness of an open source database now what does that really mean in practice well what you often find with commercial databases is that they give you these complex pricing structures where you have to pay for a license for some fixed period of time you have to pay different costs depending on the set of functionally functionality that you want to use but with Amazon Aurora we didn't we didn't want to kind of force you to have to do that we wanted to make it very simple and we wanted air in your business every hour of every day so it's a simple pay-as-you-go cost model but yet at the same time we're trying to offer all of the capabilities and the type of support that you might expect from a commercial database so that is Amazon Aurora in a nutshell now let's talk about what else what are the specific things that we mean when we say commercial capabilities so really we're talking about the type of performance and scalability that you might want what we offer using open source databases as a baseline we've managed to achieve five times the performance of open-source my sequel and three times the performance of open-source Postgres I won't spend too much more time going over all of this because it looks like most of you here today are active Amazon aurora users so I won't dive too deep into all of these but you get the idea now looking a little more under the covers of what's going on with aurora and I'll explain why it's relevant to server lists as we move on the key innovation with Amazon aurora is that we took the whole storage layer and we removed it from the database server we took it off the database host we made it a highly distributed multi tenant storage layer where you don't really have to pre provision your storage anymore you don't really have to worry about storage layer redundancy what we do here is we break your database down into small 10 gigabyte chunks and we stripe it out across thousands of storage nodes and one of the most interesting things about Aurora is that each write that you do is going out to six different storage nodes in parallel and we're getting an act back from four of them and based on that we're guaranteeing durability so one of the best things about the fact that we did this is the fact that now your storage volume is highly elastic so your storage volume can grow based on the amount of usage that it's getting now that's relevant to Aurora serverless and I'll explain why in a moment now looking a little more at the way the storage layer works of Aurora one of the things that we're guaranteeing with this six-way quorum is the fact that you can actually lose a whole availability zone plus one more node and you still are able to read from your database and you're still able to write to it now this all sounds great so why do we need a rora serverless well I'll explain why with Aurora today prior to Aurora server lists we didn't really achieve that auto-scaling LX elasticity at the database server layer now what do I mean when I say that well as your workload fluctuates even though you've got this highly elastic storage layer what you don't necessarily have is a highly Elastic Compute and memory so has anyone here had the experience of running out of database capacity in production by a show of hands okay a few of you alright well it's it's not a good situation to be in right um now what Aurora serverless gives you is this capability where at the database server layer will actually add or remove capacity just depending on your workload so why is this related to Aurora more broadly well what we've now achieved for you is the capability to elastically scale both your storage and your compute layer without really having to worry about it this is something that happens transparently and you don't have to sit there and babysit it so what Aurora server lists will do in a nutshell it will scale up your capacity and the database will go to sleep when you're not using it and it'll come back when you start using it again so let's just go over what inspired us to build Aurora serverless so as we started looking at production workloads after we launched Aurora in the wild this is this is some patterns that we started noticing which was that across our production fleet we found many instances when customers had all of this provision database capacity that they really weren't using most of the time now this was most prevalent in these dev tests type of workloads that you're currently seeing where there's these occasional Peaks and workload and in traffic but really most of the time the database capacity is just sitting there doing nothing interesting so if you were to imagine this type of use case and you were to draw a line reflecting what you've actually got provisioned here you would quickly realize well the vast majority of the time you're paying for resources that you're never using now this is another diff test use case that we saw in the wild which was you know somebody shows up they do some development they run some workload but again the vast majority of the time you're paying for resources that you're not actually using now we continue to dig here and what we started seeing was even production workloads so this is a spiky gaming workload where it's hard to see the the y-axis there a little bit but even here in a production workload you know you draw that horizontal line in terms of what you have provisioned and you realize well you prevent a lot of capacity that you're not actually using most of the time so what does this mean well as an administrator of the database you have to make some choices this is before the world of Aurora serverless so you can either provision for your peak which generally works except you're gonna pay money for something that you're not actually using most of the time you can provision less than peak which obviously costs less but it isn't great because if you actually run out of capacity well now you're your customers may be suffering or you can basically babysit the database you can continuously monitor it you can trigger scaling up and down whenever you need it to but that requires a lot of expertise that has a lot of risk you risk downtime you risk data loss you risk various manners of outage if you go this route so let's take a look at if you go this route of babysitting your database capacity what does it actually look like so imagine here we are today you're running on Aurora you've got your application you're running against your master and then you start realizing okay my capacity is getting a little bit low I think I might want to scale up so what I'm gonna do here is go ahead and add a replica scale target which thankfully because if Aurora is very easy to do you don't have to worry about replication that's all handled for you but the tricky part comes when you say all right I've got this replica I think it's ready to go now I'm gonna cut over my traffic to this replica well depending on how you're connecting to that secondary node this may incur some downtime and if you're not fully synchronized in terms of your rights well it's not going to result in data loss in the case of Aurora but it definitely will result in some degraded experience for a period of time while the cutover occurs so the other thing that you'll notice if you've ever done something like this before is the fact that even though you've switched over to a larger server there's a lot of buffer pools and caches and things that need to be warmed up even after the cut offers happen so putting aside the fact that you incurred this downtime you've also incurred the fact that well there's this warmup period during which the experience is somewhat degraded now many customers that we talk - while we were thinking about building Aurora server lists they circumvented this problem by putting this proxy layer in the middle and the reason this is advantageous is because well it gives you a way that you can quickly redirect your traffic to the secondary server without really much in the way of downtime so looking at this well okay you can do the cut over what you notice here is the fact that the application has not had to reroute its connections it's still pointing to the same place the whole time but the problem is you've actually moved the single point of failure you're up the stack a little bit you of course could do things where you have multiple proxy servers but it starts to get very complicated very fast and you haven't really solved the problem of dealing with this warm up period that I described so that brings us to Aurora serverless well how does this work so the key innovations we've made here is around the fact that we've introduced a proxy layer that is highly distributed highly multi-tenant there's no single point of failure and we've also introduced this warm pool now what the warm pool of database nodes does is it allows you to quickly grab a node off the shelf without having to wait for any type of provision in time and plug it in in terms of giving you a scale target and this is not something that you actually have to worry about because it's all handled for you behind the request router layer now let's talk a bit about how does Aurora serverless actually work in more detail so let's continue into the architectural picture of what's going on here behind the scenes so here with Aurora server lists we have your application we have your database server what we've introduced as I mentioned is this multi tenant fleet of proxies that you don't need to worry about in fact for most intents and purposes you can really pretend that they don't exist because you're able to connect to them as if it were a normal database if you will like any other database and in fact your connections actually get distributed across the proxy so you don't need to worry about which proxy node you're connected to and any individual proxy node failure would not result in downtime for your service and what we know thing we've added here is this monitoring service where we're constantly checking on the utilization of your database server and we're trying to figure out is it underutilized is it over utilized it's checking across the fleet periodically and when it decides that we need to actually do a scale up or down operation the first thing it's going to do is grab a replication server off the shelf it's going to grab one out of the warm pool this is not something that you need to do it's all done for you and we go ahead and start warming it up now while we're doing this warm-up there's no downtime there's no performance degradation to your primary node so it doesn't really matter how long it takes usually it takes about five minutes to do this but the point being during this time your application is not degraded in any meaningful way so we go ahead and start transferring the buffer pool the caches over to the secondary database server and then we start looking for what we call a safe scale point which is there's no active transaction writing in that given moment that we can't cut across so once we find this this moment what we do is we freeze the workload which sounds a little scary at face value but in fact we're talking about a small number of seconds and in many cases under one second now during this time we're basically transferring all of Accession States over to the secondary database server getting everything ready and then finally we're saying okay we're ready to go the workload resumes now the things to note here are the fact that none of the connections dropped and you can just continue on with your workload and this whole operation takes a small number of seconds in many cases it takes under one second and to your application what it really looks like there's no errors there's no downtime it's just a small latency spike while we do the cutover now when the workload goes idle in other words when there's no active connections to the proxy node what we do is we say well okay the database server isn't doing anything it can just go to sleep but meanwhile the whole proxy fleet is still sitting there available for you to connect to and the moment you do connect to it well we grab a database server out of the warm pool we go ahead and connect to it and we start up your workload as if nothing happened now when a proxy node fails unlike the architectural picture is rated earlier it's not like your whole application goes offline because we've basically distributed all of your connections across this fleet of thousands of proxy servers a small number of connections will drop and then can immediately reconnect to a different proxy server most database clients you can easily configure to do this automatically so there's no hassle to it so all of this adds up to a simpler simpler database management experience there's just list to worry about in terms of everything that I went through while it's interesting to understand how all of it works these aren't things you really need to worry about in terms of where your database is connection its connecting to and what size of server that you're connecting to you don't need to worry about CPU credits you don't need to worry about which availability zone it's running in I'm not going to go through the full list but there's just a lot of things you don't need to worry about anymore so around this time people have heard a list they say ok it sounds great how does it actually work in practice now to illustrate that I'll be going through a few graphs but to get even deeper into that a little bit later in the presentation Cathy's going to be going through some demos to show you a working live version of an Aurora server list database so let's take a look here this is a synthetic workload that we created now what are we looking at so we're looking at throughput transactions per second and over time we're basically cranking up this workload and what we're seeing is these incremental steps where behind the scenes what the database is doing is it's saying okay you need more capacity I'll go ahead and scale you up now this is down to the sick and granularity so what you see is the small drop in throughput at the moment that we're scaling but it very quickly recovers now this is a bit of a fast-forward graph this isn't in real-time but what we're doing here is overlaying the previous information with how much capacity do you have provisioned so what you see is Aurora serverless incrementally adding capacity as the workload is getting bigger and bigger and corresponding with that you're seeing these these brief momentary Falls and transactions per second that comes right back now what we're doing here is we're overlaying your capacity with latency so similarly as you add more database capacity your latency goes down because there's simply more capacity there to handle the requests that you're throwing at it and just to round out the picture here I promise this is the last one what we have is latency overlaid with throughput so you can kind of see how they inversely correspond to one another so now I'm going to be moving on to talking about what else what else is there out there what else have we done to make connecting to your database easier now one of the most common requests we heard about after we announced Aurora serverless was well this sounds great now what I want to do is build a server list application and have it interact with my server list database now previously this was a very difficult thing to do so let me take a quick audience poll here how many people are currently building applications on server list technology at AWS okay getting about half the room I'm gonna say now one piece of feedback we've heard that may many of you may relate to is the fact that while building applications on server list technology prior to now was very difficult if you're using a relational database behind the scenes for all of the reasons mentioned here managing connections is very difficult because your application code can spin up on any server and open connections and then go away without really closing the meaning fully there's a lot of network configuration that has to be done there's a lot of things you have to worry about in terms of permissions management so what we heard was a lot of feedback asking for simpler and easier ways to connect to your databases particularly your server list databases we heard a lot of customers ask for easier ways to get to them inside and outside of be pcs they don't want to necessarily have to deal with these heavyweight JDBC or ODBC client-side drivers and they don't want to have to worry about connection limits or anything like that so at this point in the presentation I'm going to turn over to Kathy and she's going to tell you more about what we've done about that and going through some demos Thank You Kathy great thanks there we go figure out how to use the clicker okay so the first one we're going to talk about here is the data API this is something that's fairly new just brought out this year what this allows us to do and we kind of talked about it a little bit or Shandor did when we're talking about those heavy applications one of the word heaviest part when you're talking about a database and especially a relational database is being able to connect to the database so if I have a mobile application maybe it's a mobile game something like that I don't want to have to have a program that makes my mobile application sign into the database write JDBC connection ODBC it's still pretty hit not very light and when we're talking about this so we created this data API that doesn't require any of that alright so it gives you an HTTP endpoint that you can connect to and it doesn't persist that connection inside the database so we'll go into that a little bit further in the slides that we have make sure that I got everything yep okay so it's just more of what you want and when you're starting to talk about creating serverless applications it helps you do that right so I don't have a server list application but no I still have to have a thin client or a thick client somewhere for my game to connect into something I just have that really lightweight and so it really does show that server list as well as it just speeds things up I don't have that heavy connection that I have to worry about as part of that process okay so my next slide I'm not going to talk a whole lot about this because I'm going to show you some of this okay so we don't have to look at the screen here let's talk about the demos so the first demo that we're going to look at I need your help with audience participation all right what this is is really talking about what we just kind of mentioned what I just mentioned if you could if you could on your phone text to this number and I'll read that out for people can't see it the city that you're from that's just a fun little way that we can kind of all of that information the text number is one four seven eight seven seven two six eight six two okay excuse me while I my screen froze okay I can it is one four seven eight seven seven two six eight six two everybody get that I don't want to move off the screen if people are so kind of looking at it okay one more time one four seven eight seven seven two six eight six two and just send the city that you're from so for me that would be Denver I'm based out of Colorado okay okay so let me go ahead I'm gonna make this larger so everybody can see and I'm going to switch over to our demo did a love it when technology works for you at 7:00 p.m. on a Monday okay so what I'm gonna do here and I'm gonna go forward there was the phone number I thought that it was on there but it wasn't okay so what this it does is we have a little Lamba script and it's inputting whenever it gets that phone number it's triggering off so that it will update a particular table on our Postgres instance okay specifically on our Aurora serverless Postgres instance now what I can do here no I guess I should go into this what we have with this data API is we now can run scripts from the console and that's where I am so I'm in the console here you can see over here query editor I've got an editor which when I first pull it up it has like a number of tables if you want to go play with it my recent am I saved so what I'm gonna do is I'm going to click here but it's asking me to do that okay all right so this is my little instance my serverless instance when I click on run if you notice now I started with just a couple and now you can see where all of your mates are from okay so as I go through and I run as people are going through and updating this one of the things that you see is you get a knock-back and we'll go into that a little bit more but it's just a fun way to show that we didn't need to have any kind of thin client you guys weren't asked for a user ID you weren't asked for a password to be able to do this there wasn't any kind of fun application that you had to log into this just called a lambda script which then updated a table okay so for a little bit more information on that let me go back to our slide that has the phone number but more important this is part of that lambda script this is the part where when you typed in your city you got an acknowledgment back okay it would take too long it's not that big of a script but you know I don't want to go through 70 lines of code to show you all of this what you can see here is a very simple lambda output okay our input would be the way to say it so I'm running this lambda script and this is the lambda that actually will send you an acknowledgment saying yep that's your city okay so it's really beneficial when we talk about specifically I like mentioning mobile games because I think that it is a perfect scenario for serverless but you can also come up with other ideas that would allow it that again now I don't have to worry about having that connection okay on top of the fact that it's really cool now that I can run sequel within the console something that a lot of people have asked us about okay all right mmm so let's go ahead and just show a little bit of a demo I know that Shandor is a stack up 'l is anybody using serverless right now a couple people or slow dwindling down every question that we ask ok so what I'm gonna do is I am gonna go ahead open up my other screen here and show you my databases oh and I'm gonna show it so you can see it sorry about that ok hopefully people can see this ok I have four instances here and have a couple Postgres of MySQL that MySQL was um that's what we were using when we did the texting your city so what I'm using here is you can see that I've got a couple of one as this reinvent and one is MySQL if you look over here I've got zero capacity units and one capacity unit okay so my Postgres I've gone in and I'll show you how to do that while this is running I've gone in and said that I want it to go all the way down to zero so what does that mean all right what that means is that my data has not gone away this is not some type of ephemeral storage that we're talking about it means that I don't have any connections into the database so I'm not using any of those capacity units right when people think about dev instances or a particular production instance that only runs Monday through Friday so I can shut it down on Saturday and Sunday ok so that's what this means so what I'm going to do is I'm going to go back into the console I'm sorry the query editor in the console and I'm just going to not type people have probably done that in demos right so the first thing I'm going to do is I'm going to create my table and if you notice when I go back to the screen up there or well one more time I do have the tiny URL of what I used to do this so it's a great way to be able to go in and say okay how can I test this on my system and see what you guys were working with okay so I've got this created I'm gonna run it okay so it's creating my table operation is pending alright so the next thing I'm gonna do while that's pending as I'm just gonna run it a simple insert into that okay success success is always good if you see in there so I'm just gonna highlight that gets again that way it's not gonna mess up anything okay no wow this is running we're gonna go back to what I was showing okay so that's how quick just in us talking that could create table and running that insert is now up to four capacity units if you see there and that's what that ACU means is that capacity unit okay so a couple of things that as this is running and as this is growing and I'll show you to look at is that if I click here and I want more information then I can go into cloud watch and get this but I can go into my monitoring and the first thing that's coming up is this now this is at last hour we can look at last three days if we want to okay so you can see the work that I've done before but as it's going through we can see how there's scaling up okay so one thing that I do want to show while we're still running that as well is I'm gonna go back in here and I'm just going to show you well go back into my RDS instead of creating a new instance go in here go to my Postgres okay so when I look at how I have this set up I've got my monitoring my configuration okay so you can see here the different things that I can set up and how that is and that's how you would set up your individual server list Aurora for Postgres okay so I can set up the number of ACU units when I first do that through the console I can set it up to two I actually can choose a parameter that will say hey if I have nothing going on in my instance bring that all the way down to zero save me some money right one of the things that we would do is server less okay most important people don't usually think of this they think oh we want a minimum because we want zero or two or something like that also set the maximum because we don't want it to grow like crazy and if you just set it default although our defaults are not the maximum right now but if I set something up in a CLI and I just said you know my maximum then I could be kind of kicking myself for what I'm doing shooting myself in the foot so what I was thinking mmm so those are the two important things now just to to kind of reiterate what shadow we're saying when you first have that zero capacity units it is going to take longer to get that connectivity going then if I'm growing so the time that it took from zero to four is gonna be longer than the time it would take from four to six to eight okay so something to remember one of the things reasons I mentioned that is I had a customer that had a production instance and from nine to eleven they were a college and so from nine to eleven during this semester all of their students logged on that's when they got all of their work so instead of waiting for Aurora to start that you can pre warm it you can say okay I want to start up and I want to start at a particular ACU or that capacity unit okay all right so one more time here we'll go we could look at the graph but let's okay let me go here now you can see if you saw my CPU and went from 41 percent to 81 percent so what that means to me is that's about to grow again all right so I don't want to sit here and watch it have you guys watched the the screen as you know yep that's how it works but just to show you the background of that okay so let's go one more time to monitoring and refresh I'm looking at the last three days I actually want to look here what do that okay so there's my first and it went up to that for ACU it will start sizing once you go up higher and higher okay the only thing and I can show you in our graph that shows it but know that we actually are more aggressive assigning a Cu in the beginning so I'm gonna grow faster then I'm gonna decrease now we're not going to throttle you it's not gonna be something where oh you know in two seconds I grew crazy and then I'm down to nothing but it is if you look at different scales than even the scale of the graphs that shandur showed you that when you first grow it's a lot faster than when it tails off and it tails off in a step fashion okay alrighty so let me go back here make sure that that's on there alright this so I've mentioned a couple of things to know this is a little bit more and things that as a solution architect I get asked quite frequently number one and this one's in two if I have a really busy system and I'm trying to grow if I have a long-running transaction server less right now we'll wait until that transaction finishes makes sense right I can't necessarily freeze a transaction like we were talking about to grow when it's still actively running right so it's something to be aware of even something as far as hey if I know I've got to grow I'm gonna go kill that right something that you need to plan for a couple of other things that people often ask me and there is if you notice there's a link down there that surfer list doesn't technically have all the features that aurora does so we talked about it a little bit briefly with replicas so i don't have something where I can go to a server list and then I can kick off a replica it still has six copies of that data across three availability zones but I'm not going to be able to assign a replica to that okay a couple others that were talking about backtrack backtrack is available for Aurora at my sequel that is not available on serverless okay so different things that we're talking about there's a list there where we have it if you think about it some of the things that come up it makes sense right if I'm not using it all that much maybe restoring from a snapshot I can probably get my data from that snapshot instead of having to do a backtrack in the system okay so there's a couple different ways to learn about serverless and I do want to put that out there there's all kinds of YouTube videos but you can also if you have an account manager reach out to your account manager and set up our training sessions things like that as long as as well as being able to go into the digital training here that we're talking about okay so now if there are questions we have two microphones that they will turn on that you can go up and ask a question and I'll ask Chandler to come back up and let it rip question right here yes and they can kind of see that based on reading the current capacity or the current requests kind of coming into the server is there any kind of analysis to kind of pinpoint and kind of detect those Peaks on like a recurring system and kind of scale automatic before that um that's the first question and I'm gonna get a sink wish now as well before yes can I dive in the second question I have is is there documentation on how to migrate from the current system to the server lists for people that are currently on the old system okay good question yeah great question thank you so the first one was essentially what I heard was is there a mechanism where the service could learn your workload patterns and make predictive actions not yet you know that's not something that we've gotten to yet I could definitely envision a world where something like Aurora serverless could take those kinds of things into account look at past historic patterns we haven't built that capability yet we would love to though the other question was about migrating in and out is there documentation on it yes there absolutely is you can certainly find that documentation by searching our support site the simplest way today to migrate in is to take a snapshot of your Aurora provision database and restore it into server lists the database migration service also supports replicating into Aurora server lists over time we want to look at other ways of making it even easier to migrate in or out but but that's what we support so far yeah the other thing the only other thing I would add to that is the first part of the question which is if you start to notice something going on you can programmatically set up so you don't have to wait for server lists to automatically increase you can say okay at noon we know that normally and we need 4 so at 11:55 or something I'm gonna increase it yeah okay why don't we go over here are you first okay go for it Thanks I'm so honest here in the reinvent I love awesome is there any reason not to scale all the way down to 0 any disadvantages so why don't you all was yeah 0 so I can talk a little bit about that so the question was is there any reason why you might not want to scale down to 0 and as Kathy did mention you can configure it such that it will always stay at some minimum amount of provision capacity so the kind of reason why is well the simplest reason would be you want to guarantee a certain latency when your date when your workload goes to sleep and then comes back because of course there's going to be a latency penalty involved if we remove all of your database capacity and then re-add it so what we're at currently today is somewhere in the 30-ish all sort of average and I'm not guaranteeing here the 30 sick and range to spinning back up now if you're trying to do a page load for example you know in front of a relational database 30 seconds might be completely unacceptable so you might want to set that minimum to above zero you know you might want to turn off the thing that makes it go to sleep so that there's always some database capacity available at least that minimum amount right right so you can just configure it so that you never have to worry about that problem of course that doesn't mean you're paying for that capacity whether you're using it or not and of course over time we would like to make that boot time faster right well well let me come back to that so that I make sure I get through everyone's questions we can talk more about the sort of boot up called start time it's something we want to improve on but let me come back to that yeah and the only thing the other thing I want to add with that is that I'm not sure I'd call it a cold boot because people assume then that there are servers that are down it isn't that it's that you've got your storage out here and it takes a 30 seconds which is not a long time to go grab my instance and kind of attach everything the first time so that's I understand from a yeah from a hundred thousand foot yeah yep it takes about 30 seconds yep yep let me get through some more questions here we can come back to that definitely go ahead sir I forgot my question yes [Laughter] I have I have two questions so question one if thermal life is not cheap right if if I had my read capacity if let's say my server provision CPU was running 80% of the time federalize does not make sense yes it's expensive right so have you figured out a math like for lambda we have figured out a math at 60/40 if 60% of the time your resources are busy don't do server less because it's not cheap for Aurora the reason why I ask for the math if we have a unique situation we have a service which is heavily used like one hour a day but for a restauranteur 23 hours we have a visit which pings that service for it's for the sake of simplicity whether it's up or not which goes and hits the database to get some data right now because it is a per second billing for 23 hours I am still hitting per second so I don't know whether serverless is a good choice for us for such a workload or not you have an opinion on that before I have second question I don't have the precise math that you're going to be able to use for all use cases but for what you described server lists may still be a very legitimate use case even if you're only pinging it to a light extent for 23 hours because what it will do is it will scale down to the minimum amount of capacity to handle that light pinging so for that period of time you'll be paying quite likely you know the cheapest capacity unit that we offer and then you can either let it automatically scale up during that one hour of the day or you can you can go and explicitly ask it to scale up beforehand to to the right amount so what it's gonna give you is is that ability to show scale seamlessly even though you know you may not be taking advantage of all of the capabilities and it's gonna well if you don't go and take some manual action it will scale up to handle the the higher workload but you may want to do that proactively just so that there's no sort of warmup period pending on your use case so for what you described it sounds like Aurora serverless could be a great use usage for it okay we'll give it a shot yeah second question not related to silver less per se but related to RDS what we also learned if you use I am because in one of your pieces of presentation you said use I I am as your identity what we noticed if you use I am with RDS your performance is very poor it's about five five requests per second something like that compared to creating a native local user do you know if that problem has been fixed or is it on the road map for RDS team to fix that the specific performance issue I assume you're talking about is the fact that if you want to open up a whole boatload of new connections right it's not about the performance of existing connections and of course you can expect that if you're doing I am authentication authenticating does take a little bit longer because we have to step outside of the database to validate your credentials right now what we do is we do cache those credentials we do cache that validation so that you know we don't have to repeat that operation we are working on improving the performance so that it can handle more scale more connections and more bursts of connections definitely well we're working on that so I hope that answers your quiz thank you so much yes sir so echo is really weird I have an application that's currently running on premise that needs to be moved somewhere for four reasons and I want to move at AWS it's a mail server that uses my sequel as a transaction layer essentially the messages that are being sent out to mailing lists get written into this database table for use by custom application to kind of display in a web GUI the messages that somebody has to release for their mailing list or what messages have been sent to a mailing list that they subscribe to but I'm worried about the cold I'm not gonna call it cold I'm worried about the warm up period of 30 seconds and it seems like there were a lot of questions around this and mine I think is a little bit different what happens during that 30 seconds my say I put this into a lambda function right now it's code that's running on a server but mm-hmm this seems like a great k use case for serverless on both the database side and the compute side if I set a scale down at zero the database shuts off because there have been no messages sent in the last three hours iMessage needs to be written into the database what happens when my lambda function tries to reach out so you is your question what happens during that warm up period yes is it going to fail is it going to wait oh he wrote me going like this I'm going yeah so your application will open a connection and try to issue a query and nothing will come back until the warm-up finishes you won't get an error you will get any type of connection failure it will just look as if well the database is working on it and then when the server comes up and everything is ready to go we'll give you back your results so from an application side that's what it looks like I'm not sure if your question was what's going on behind the scenes well you can imagine when we're doing a cut over between two database servers obviously we have the original server which is continuing to handle the workload and meanwhile we're warming up the secondary you know where we're taking it out of the warm pool we're configuring it connecting it to the right network starting up the database process mounting the storage volume in the case where we're jumping between two servers all of that can kind of happen behind the scenes while the original database server continues in the case of doing a cold boot up well that original server doesn't exist it's literally gone away or back to the warm pool so we're taking all those steps however we can't do it behind the scenes if you will because there's no alternative so I hope that answers your question mostly okay during this period now where are the transactions actually stored well if you're talking about transactions that have already occurred in the past no the no server is uh-oh I've made the transaction right that caused the third so you've sent some transactions to the database where do they sit well they're sitting at the proxy layer there's basically we're accumulating transactions and queries at the proxy layer while we wait for the server that's sitting behind the scenes to come up as soon as the server is up we go ahead and send them down to the database server so they're sitting at the proxy he had something to think about that the connection doesn't ever go straight to the database it always hits that proxy so what's happening in the transaction they're just waiting they're just on pause until they can connect yes sir about the SE limitation with that these reasons cannot scale up while a long transaction is in progress that is fine but in a scenario where you have frequent transactions let's say multi seconds not not too big but is it fair to say that in that scenario the system can actually never scale because there's a constant influx of not very long but long enough transactions well if this scenario is about your having continuously running 30 second plus transactions that are always overlapping some of the time then we wouldn't be able to scale you because we're never able to find that safe point where we could do so without any type of data loss in the wild we very rarely seen those types of workloads typically these are heavy analytics type workloads where you probably don't want to be using something like Aurora even to be running those types of workloads so it's pretty uncommon that we see those types of use cases where we can never find a safe scale point it does happen though and and it's it's worth looking at you know your workload before migrating to something like Amazon Aurora server list because if you are if you are one of those workloads where you're constantly running 30 second transactions and they're overlapping and there's literally zero time when there isn't an act or transaction you're probably not going to get the best out of something like Aurora serverless they're kind of a best practices documentation on how to assess the workloads to trigger to fight that pattern absolutely um has anyone here heard of a tool that RDS offers called performance insights ok so that's that's something we'll you haven't heard it you can check it out but that's something that you can enable on our dias or Aurora that really gives you deep telemetry into your workload it allows you to see what transactions are running and do all kinds of sophisticated analysis to understand your workload better so that's probably where I'd start in terms of recommending analyzing your workload so yeah check that out Thanks yeah I do want to point out that that particular scenario that I've talked about usually when I've seen that happen it's a mistake it's usually something's going on and then one developer didn't know that something else was happening or somebody run a report outside of when they were supposed to so it was it's never been something that I've seen where it's part of the workload but mistakes happen right and that stuff happens all the time and so you want to make sure that you're aware yes my question is pretty simple I was just curious if support for my sequel 5.7 is on your roadmap yeah it's one of the most common requests we get is to support Aurora server lists four five seven compatibility and yes it absolutely is on our roadmap definitely something we're looking into and yeah we get a lot of requests for it obviously in the long run we're committed to maintaining compatibility with open source both for Aurora in general but also with Aurora serverless so absolutely cool thank you you're welcome everybody likes that microphone over there okay we're gonna have to force this side of the room right now assuming that your workload is predictable is there any argument assuming you don't need to read back from your database to batch your your rights to the database heat up the instance right everything at once and just kind of do it intermittently as opposed to just running a lower capacity all the time sorry I'm not sure I understood the quiz so let's say I have a workload where I'm processing maybe a couple hundred transactions per minute yeah is there any reason to pull it for 15 minutes scale up a large instance put it all in either from a billing or performance perspective with the incremental background the incremental back off as opposed to just having a lesser capacity well I would so if you have a pool of Rights that you need to execute a pool of transactions and it doesn't it's not time critical quite exactly when you run them I would generally assume for that type of use case probably pre provisioning a fixed amount of capacity and just distributing the transactions across that time window would be the optimal way to run from a cost standpoint that that's what I would assume it's a little hard for me to speculate without more workload details but if if you have a way of exactly predicting what your workload is going to look like and distributing it across time then just pre provisioning the capacity you need and distributing it would probably be better now I could imagine a use case where the rights are all touching related data perhaps and and you know maybe running them all around the same time gives you some performance benefit it's a little hard for me to know though without actually looking at your workload too much detail here so yeah okay I was thinking is that RTS you can stop it now has something that's fairly recent and so that would be another way to do it - is that I just started when I need to run it then I stopped it yeah all right well it looks like our our queues have cleared out so I'll thank everybody for joining us this evening appreciate your staying oh sorry one more okay how does the pricing work when you do the scale up scale down like how do you compute actually the cost because like normally when you scale up or down it goes to the next tier correct like right so well behind the scenes there's an actual server going on and we call it a rora server list really to illustrate the fact that you don't have to worry what kind of server it is but we essentially charge you the equivalent of what you would cost if you were provisioning on that server type plus some premium for the fact that you're running through the proxy and utilizing the technology but basically from the moment that your scale-up happens you will start getting charged the equivalent cost that you would pay for that server type behind since the proxies involved like do you think it'll be more expensive than the regular already is like if I maintain the same correct yeah there is additional cost to using Aurora server lists and you can find the details of that on our pricing page what we often find is if you are running he's one of these cyclic or episodic workloads that you know in the fullness of time you are saving money by running on Aurora server list because of the fact that you're able to use a provision on lower capacity some of the time but if you have a highly predictable workload and you know exactly how much capacity you need you're gonna do better from a cost standpoint by using a rower provisioned instead of Aurora serverless right now we don't have anything that really kind of details that out a lot of that is using performance insights and looking at your own you know it's kind of that it depends answer looking at your environment and seeing if it makes sense and possibly working with somebody from AWS to help you out with that yeah all right well thank you everybody for joining us this evening really appreciate it thank you thank you have a great reinvent thanks a lot

Channel: AWS Events

Views: 5,222

Rating: 4.7142859 out of 5

Keywords: re:Invent 2019, Amazon, AWS re:Invent, DAT382, Databases, Amazon Aurora, Amazon RDS

Id: 9mTwxghXvlE

Length: 56min 4sec (3364 seconds)

Published: Tue Dec 03 2019