Amazon Relational Database Service (Amazon RDS)

[Music] [Music] [Music] [Music] [Music] [Music] [Music] [Music] [Music] [Music] [Music] [Music] [Music] [Music] here we go here we go here we go here we go here we go here we go here we go [Music] [Music] [Music] [Music] [Music] [Music] [Music] [Music] all right here let me switch over to my slide deck just give me a second here so welcome everyone my name is Vlad leshawna I'm a database specialist Solutions Architect with AWS and I'm here to tell you a little bit about Amazon relational database service for short RDS just just by way of introduction is maybe we can kind of do a show of hands cool here has already had some experience with our manage databases like RDS alright so a few folks in the room so we'll try to keep the content matching the audience and ensure that you are covering also some of the basics but we're also kind of going to dive deep as needed if you have questions just feel free to raise your hand and ask them we'll be more than happy to answer them so let's get started like I said we're gonna talk a little bit about what Amazon RDS is how to get started with it what's the easiest way to get started with it and then talking about some of the more advanced features and capabilities of that platform if you want to kind of think about it in terms of kind of adopting these services from a startup perspective you typically kind of want to start getting you want to get started quickly provisional data base for your application as you're developing it as you're working on building a broad and then moving on as you're transitioning into a production system where you were working with actual customers where you're having actual workloads running adopting some of the more advanced features like high availability and so on so we're gonna follow this natural transition through this discussion this morning and then after this we're gonna have a quick lab on how to get started and you'll see some of these topics a little bit more hands-on and as you're testing them out so amazon RDS is a managed relational database service and what we mean by that is that we take the database engines some of them are the commercial engines listed over there some of them are the open source engines and we put a management layer around them to provide automation for very common tasks that a lot of folks that operate databases have to otherwise do manually and what that brings to the table is ease of administration you don't have to worry about things like patching or installing software provisioning those databases are maintaining them over time we take care of that for you using our automation and we also provide you easy capabilities to scale those databases so you don't have to over provision all the way from the beginning so the database itself the size and the resources that you have can grow as your applications are growing as your needs are growing and and as we're delivering some of these features and as you're transitioning into production and using these systems in production then we want to offer high scalability and high availability in an easily consumable package where you setting up databases to be highly available to be replicated topologies like that they're typically complex processes and they also require a lot of maintenance so with data with our RDS all of these tasks become just a simple matter of checking a box or you know setting a flag in a configuration so we want to really make all of these very very easy to use all of these capabilities while we provide you with highly performant databases and environments that are highly secure to meet all all the potential security needs of an actual production application so when we're thinking about database is in administering databases if you were to do everything yourself there's a whole host of things that you have to worry about starting from the hardware side building the server's getting the service of racking them putting them in the data center installing OSS maintaining patching scaling the database is monitoring all of that stuff then you have to worry potentially about compliance you might worry about security and isolation how do you ensure that those workloads perform as they should be backup high availability before even go to the higher-level operations that really really bring value to the business which is optimizing that actual workload to make sure that you're utilizing those resources as efficiently as possible so this is what happens when you have to do it all by yourself with RDS we take a lot of that away so you can focus on the on the tasks that really bring bringing value to your business right focus on the things that matter like the schema design the query construction the optimization of those queries so how do we get started with Amazon or Amazon RDS we the first thing you have to do is pick a database engine right and we offer two commercial database engines and three open source engines now these are the actual bits and bytes of the commercial engines or the open source engines they're the actual and in that we just simply wrap a management layer around them they're all they work and behave in most cases the same way as they would if you were to run those systems in your data centers or any point on your own servers is they're all supported by block storage provided by Amazon EBS our block storage service and we also have an offering that we call cloud native this is Amazon now this is a database that we've designed and redesigned and re-implemented from the ground up to be called native to scale according to the patterns that were developing in the cloud and that database is my sequel impostor sequel completely compatible and that database is also built on a scalable log structured and distributed storage system that is proprietary and specifically tuned for database workloads we're going to discuss Amazon aurora in a later session in more depth I'm not gonna focus a lot on that I'm going to focus mostly on the RDS engines and what it means to run one of those engines in a managed environment so when you get to set up a database you got to pick one of these five options basically that which you pick depends obviously on your workload on your needs and considerations but the next decision that you would have to make is which version of that database to to choose if you're building a new application from the ground up and you don't have to worry about any sort of legacy dependencies or anything like that then you would likely want to pick the most recent version of these databases and what we do is with these engines which we are offering a variety of versions and we're offering all of the major versions that are available in the marketplace today even for the commercial ones as well as for the open-source ones including the newest ones such as my sequel 8.0 Mauri DB 10.3 phosphorus 10 and 11 in preview oracle 12.2 sequel server 2017 so all of these engines provide much more better features compared to the older ones but there are reasons customers pick some of the other database engine versions for all of these and that is if your application depends on certain capabilities in those older versions or there's some you know validation requirements you're deploying off-the-shelf solution that has been validated specifically for one of those versions you want of course pick that one and as the versions of these database engines evolves over time we will keep up and deliver those so when new versions come in will provide them part of the RDS platform when old versions get retired and deprecated by the vendors and by the community we will also stop supporting them as well now that doesn't mean that we're you know we're forcing you to upgrade they're just not going to be available for you to run new workloads on and once you've decided on which engine to use then the next thing you have to decide is what sort of instance type to use and remember I mentioned that these are the traditional database engines so they typically get deployed on servers with specific compute capacities and in RDS we offer three options we offer burstable compute database instance class family and this is really really good for you workloads that are transient in nature variable Devon test type workloads where you're just starting up and trying to kind of get started they're really cost effective to operate and provide a fairly large fairly wide choice of database sizes from one virtual CPU in one gig of ram all the way to about eight virtual CPUs and 32 gigs around the key with this family is that the compute is burst of all you don't get the full capacity of a specific virtual CPU you're getting a portion of that as a baseline and the ability to burst as long as you're accumulating credit so basically whenever you're not using your baseline you accumulate credit and when you need to burst above that baseline of Syria of CPU capacity you're consuming some of those credits out of that pool and when you run out of credits unless you're activating unlimited mode if you don't activate unlimited mode you're gonna be throttled back to the baseline if you activate unlimited mode then you're paying extra for those compute cycles that you're consuming about above that baseline so there's two different options there you either you know are limited to the burst capabilities and the baseline that you have or you pay for the extra compute above the allocations that are provided with that instance by the tea to migrants this type is eligible for the free tier so that's a really good instance to start with if you want to just play around and understand how our services works the next two families of instances are typically used in production use cases so you've got the general purpose M family which has a ratio of four gigabytes of ram per virtual CPU core so as the number of virtual CPUs grows the number the amount of memory that you get allocated matches that as well and you can pick from instances all the way as small as two virtual CPUs all the way up to 96 virtual CPUs with the m5 family so these are really really good instances that provide you with a high-performance networking and they're good for compute intensive database workload so if your query is doing a lot of aggregations computations on data that leverages CPU a lot this instance family is going to be a great choice the memory optimized instance families for those workloads that benefit from a lot of memory where you can cache a lot of your data set in memory they handle a lot of concurrency you have high-performance networking available for those as well and they're also effective for very high connection comes because there's a lot of memory available to be consumed by you know all of the memory structures for the different connections that get established for the database and in fact with RDS for Oracle we support even bigger instance types the X 1 and X 1 e times that go all the way up to almost 4 terabytes worth of RAM so in terms of compute capacities you can see how RDS scales from the tiniest types of workloads that you want to start with all the way to this high-performance end of database workloads so the next thing that you have to choose once you've established the database engine that you need and the compute capacities that you want for your database is what sort of storage to use and how much storage there's fundamentally two storage options available for RDS there's general-purpose SSD storage which is very cost effective for a lot of database workloads especially if they're variable in nature and there's provision I ops both are SSD based storage provision I ops will give you high performance and consistency so it will deliver within 10 percent of the eye ops that you indicate 99 percent of the time so if you think about it when you get started with the database workload you probably will start with general-purpose SSD that's cost effective the performance of the storage grows with the size of the storage so if you have a hundred gigabyte volume you get 300 cups if you have a terabyte volume you get $3,000 ups and you also get burst capacities for volumes that are smaller than one right in size so again it's the same model as with the tea instances you have a certain amount of credits that you can consume above the baseline I ops and then if you don't consume the amount of IUP's that are allocated in the baseline you accumulate more that then you can used for bursting or provision I obviously just tell us how much performance do you need and what size of storage do you need and we will deliver that type of performance and size consistently so provision I ops are much more used in production workloads right especially once you've established what your workload looks like what sort of performance requirement it has whereas general purposes as these much more prevalently use for smaller workloads for workloads that you're still testing and trying to understand how to tune those workloads while you're understanding what your performance your long-term performance needs are there's of course a gray area there are many many use cases where both gp2 and provision I ops can be just as effective I encourage you to test that it's fair its workload specific in many cases so I encourage you to test that and see which one gives you potentially the best cost option given the performance that you need as well and another question that we get asked fairly frequently is can I run Amazon RDS in my own data centers until about reinvent last year our answer was no but since we invent we're happy to say that you yes yes you can so in preview today we have Amazon RDS instances running in vSphere clusters on top of vmware so and this addresses use cases where customers have hybrid environments where you might have the databases on-premise but you still want to benefit from the RDS automation or you might have environment that's both sides both on AWS and in a data center and you want a consistent way of managing those and be able to automate backups from monthly from the data center into AWS use cases like that as well as of course migrations if you're migrating those workloads over so Amazon RDS running in your data center gets some of the same features that Amazon RDS in AWS provides you have automated management including provisioning and patching of those instances you have a unified console so the console that you have in AWS can control the resources in your data center as well through a consistent view of that data you can get storage and compute scaling in many in similar ways as you do in in AWS and you can perform monitoring both with the vSphere tools as well as the AWS tools like cloud watch again it provides you easy ways to do backup and restores them for example backup and restore on-premises databases directly on AWS if you want to shift them over for whatever reason or for if there's a dr type scenario we support my sequel maria DB Posterous sequel server and oracle in that environment as well and it kind of looks like this so you'll see the way we accomplish this is we have on Amazon RDS connector now so this is a service that essentially enables you to talk between the AWS service side you know the API is and the service side of Amazon RDS which is still sitting in one of our AWS regions and the resources that are sitting in the data center in a vSphere environment you will need connectivity between the two so this is not an offline system right so you will need an ability to actually talk to our control system that's sitting in AWS right for this to work so it's not an entirely offline model where you just have your own isolate Narnia's any questions so far yes so with our dias the question is can you extend the sizes of the volumes in RDS with rate configuration in case of with RDS so what in in a managed environment in RDS you do not get the ability to interact directly with a storage layer at all you simply tell us how much what the size that you wish to use it and you tell us what performance what I hopes you need interview select provision I ops and we deliver that performance we don't you don't get any ability to control or stripe or any you don't control the physical disks at all this is fully managed through our layers so the maximum I hope that you saw in the previous slide there they are the maximum I ops available in RDS in the RDS system yes sir okay so the question is how do you connect an RDS database instance to an EMR cluster for that matter any other workload so Amazon RDS will provide you with a DNS name which is which points to that cluster right while you don't get access to login as an administrator or anything like that to that underlying operating system anything else you get that connection string you get that endpoint and you simply connect to it using a my sequel appliance so for example in an hour you mark cluster environment that could be just a JDBC connector that simply connects to that endpoint and starts writing data into the RDS tables so if it's my sequel you basically connect to port 3306 using my sequel driver if it's sequel server it is the sequel server connect and so on all right yes sir so minor patches you have there are two options so there is an option where you can check a box and say all to apply minor updates and we will apply those updates on your behalf when they become available in your maintenance window so when you configure a cluster one of the advanced settings that you're going to set and I'll talk a little bit about them shortly is a maintenance window once a week when we can perform maintenance on your class and that maintenance can be anything from operations that you scheduled like change my instance type or change the configuration parameters or patch right to things that we have to do from you know to make sure that the platform operates at them you know your systems are secure and so on so during that time that that maintenance window that happens once a week we may perform maintenance on your behalf usually and we may reboot the database at that time if the maintenance that you scheduled or we need to perform requires that there's no guarantee that it's going to be rebooted but if it does that's where that's going to happen you can also manage that yourself so you don't uncheck that you don't check that box and don't do that minor updates automatically and you can manage it yourself and then at that point when you're ready to operate to the newest patch version you simply instruct us to operate and then we're gonna either schedule it or you have an opportunity to just specify do it now right bypass the maintenance window just do it now so it's in your control how do you execute that so any minor upgrades happen like that my major upgrades like going for my sequel five point six to five point seven there's specific upgrade paths for those some of those can be done in place some of them require you to do restore from snapshot but we don't do those on on your behalf automatically because typically those types of updates require application validation so on so you would be responsible to make the call when you upgrade to a major version yes sir yes yes so the compute is scalable so if you nee if you run a workload and you realize your instance size is too small or you know may be too big and you want to save some money or anything like that you can simply tell RDS to change the compute nodes and that will require a reboot and some downtime on your application but that can be minimized with higher visibility features in some cases but yes you can absolutely change this yes a sequel server yes sequel server does support windows authentication but not the other engines alright so let's talk a little bit about managing high availability and more complex database deployments the first question that we always get asked at this topic is how do you how do I ensure my database is highly available and we have one thing that's called multi easy configuration and what that means is that we're actually going to deploy two database nodes two servers if you will right and we will replicate from one to the other they all sit in a different availability zone one is considered a primary and the other one is considered a standby or a secondary you do not get to interact with that standby at all right it's just there in the event of a failure and if there is an issue we're going to simply failover to the other one the replication between those servers is synchronous in nature it's a block level replication so that both of those nodes have a full copy of your data so there's not going to be any data loss when you do the failover there's obviously going to be in some availability and impact but the data will not be lost except anything that hasn't been committed yet that was in flight at the time of the potential outage so it works like this I talked about that end point that we have that's a DNS endpoint that you connect your applications to so that normally points to your primary database node in a multi easy cluster so if there's a failure and that one goes down what we do is execute a failover we promote a standby to be the new primary the database engine will come up on that instance it's gonna go through the crash recovery steps as it would normally do with any database and then it's going to make it available for use our automation at that point is going to remap that DNS end point to point to the new primary and we're gonna then provision a new secondary node and re-establish that replication the other way around to ensure data durability and then your application simply goes to Amazon route 53 which is our DNS service and asks it for the new IP address it will get the new IP address corresponding to that end point and starts connecting to that instance so that whole process is designed to take in most cases between one or two minutes right that's as fast as those failover can happen in most cases it's quicker than that but it also matters that your applications have to be intelligent enough to realize that if there's a failure they should retry those connections and they make sure that they don't cache the DNS because if they catch the DNS beyond what we tell we'll be on our tee time to live our expiration times then your application will still try to connect to the old node even though the actual primary node has changed in the main time it's been available so it does require a little bit of tuning on the application side yes sir so those are availability zones in the same region so they're designed in such a way to support these high available workloads and you won't while there is some latency going from one availability to the other that latency is going to be something that applications can tolerate in a high availability scenario so we're talking about you know maybe one or two millisecond discrepancy between those so it's not a very significant it's not like your your standby note is an entirely different geography they're all going to be in the same region they're gonna be far enough apart for fault isolation those availability zones but they're going to be geographically more or less located in the same area like yeah Northern California or Oregon or Northern Virginia you know so those types of areas so they're good so we are managing the latency between those availability is also ensure that there's and there's minimal impact or applications when you cross them and most customers have application servers balanced across multiple availability zones anyway because that's the practice on on the application side to protect against any sort of availability or data center level type outages right they're very infrequent but you know it's something that we do with customers design their applications to tolerate so in that case your your application servers that talk to the database they're going to cross that boundary anyway because they're gonna be load bounced across multiple IDs can you repeat that so the question is a lot of institutions have a mandated requirement to do failover testing yes you can we take WS there is a simple API call that allows you to initiate a manual failover so you can do the testing yourself and understand what the impact on your applications yes we do and I'm about to talk about that in a little bit sir so from a high availability perspective this is a solution the other component of our replication technology now in our in the RDS platform is read scalability so RDS provides read replicas that allow you to scale your reads and we accomplish that using a synchronous replication so you can create up to five read replicas for any source database you can monitor the replication lag in cloud watch and that those capabilities are supported for my sequel mariya DB and Posterous single region read replicas are also supported for Oracle Enterprise Edition we're working on support for sequel server so this is a synchronous replication that's accomplished using the native tools of that database engine it's my sequel it's going to be been logs if it's Posterous is gonna be using your wall log so this solution allows you to essentially have replicas I during the same region or in a different region so we don't necessarily look at it as a high availability solution because the replication is a synchronous and subject to data loss it's certainly a solution that plays a role when you're designing your dr strategy or when you need reid scaling but from a high from a high assurance that you don't have data loss from a high durability insurance perspective Multi Z is going to be the high availability solution there yes it is for those engines as well except Oracle so for Maria DB my sequel and Postgres it's available across regions as well and this brings up the bigger question how do you plan for disaster recovery realistically it's going to be a combination of those two features it's going to be a combination of high availability with multi easy and read replicas potentially in a different region if you want full dr in an entirely different region so that's one way of doing it we also have backups in manual snapshot so you can do backup based dr solutions as well we also support delayed replication with a my sequel database engine and that allows you to essentially kind of protect your database for accidental changes for example if you accidentally deleted table in your database you know you can use the late replication when to make sure that there is a window of time we don't apply and replicate that change over to a different region allowing you to restore potentially easier from that kind of a scenario so how does RDS backups work so there's really two mechanisms to have managed backups in our in the RDS platform they serve slightly different use cases although they're significant over so you can do manual snapshots this is a storage level snapshot of your database instance and you tell us when you want to execute up backup and you tell us if you need to restore that a database from that snapshot there is no performance penalty for backups if you're running multi except that there's a brief into a brief pause in your i/o if you're running a single easy RDS database because we want to create the disk and ensure that we get a consistent snapshot for you and we leverage the back of the snapshot capability is provided by Amazon EBS behind the scenes to enable the RDS snapshot capabilities the other option is automated backup Indy's really give you a point in time restore capability so we will take similar snapshots once a day of your database and then we will capture the transaction logs of your database on a continuous basis and ship them off to us through every roughly about every five minutes so that gives you essentially the ability to restore to any point in time all the way up to the almost the last five minutes of your data fix and we do that by simply going the opposite path we're gonna take the latest Daly snapshot we're gonna restore that one and start applying the transactions from the logs that backup logs that we capture snapshots can be copied across regions as well so if you want a very cost effective DR solution and you you're not too worried about you know the RPO RTO you don't need those to be very very small then you can simply just take you know the snapshots of your database and ship them to to a different region and then have them in the other region available in case you need them sometimes you can share those with other accounts so we see customers for example create a secondary account an entirely different account in a div that they use for dr purposes in a different region that way they isolate for any sort of other issues that they might encounter somebody you know malicious gaining access to your account in the primary region and interacting with your resources you always have that secondary account with a last resort backup in there so you can share them you can move them to different regions as well if it's automated backups what's the latest you question is what's the latest you can go back with the back using snapshots if it's a manual snap so that you take we don't delete it you you delete it so you can keep it for years if you need to there's gonna be practical implications if you we see some customers for example those database engines are gonna get old after a while right so then we encourage you to occasionally you know restore those backups and upgrade them to the newest versions of my see oh the database engines right because if you're waiting ten years and then trying to restore one that's ten years all the database and you might not work quite as expected might not be supported as this implications like that they are available so you can keep those manual snapshots for as long as you need the automated backups with a point in time restore it's 35 days back in time so the question is what's the difference between EBS and Amazon s3 from you know is it a cost impact so there's fundamentally different technologies Amazon s3 is object storage it's a key blob based storage model that scales indefinitely Amazon EBS provides you with neck network based block storage that is exposed as a drive on your server basically right it's so there's fundamental difference it does it actually you can scale the vault it doesn't scale automatically right but you can tell you know if you provision one terabyte you can go in and say I need scale it up to two terabytes and so so you can do those things there's the cost is different and the durability guarantees are different Amazonas s3 is a regional service data is replicated across the region multiple copies within the region but you interact with individual blog blobs right basically files EBS is a block storage device that sits in a specific availability zone so it's close to a server for high i/o hops right for high performance right in block level operations but you know it doesn't have the durability of replicating that data across multiple regions unless you're using something I'm multi-use iam we do it at a higher level and for you on your behalf EBS snapshots are stored in s3 for the regional durability them yeah I mean the equivalent concept in a you know in a data center environment would be a sand but it's not quite the same thing so how do we monitor and operate and I'm Amazon RDS database oh sorry there's a question there yes so those maximum five the question is the read replicas are in region R are we able to have multi regional read replicas so the question the answer is yes those maximum five read replicas that you get they can either be in the same region or in a different region so you can have two of them for example in the local region and another one in like you can have two local here and I don't know in Oregon and then have one in Dublin another one in Tokyo and another one in Singapore for example right taken so there the cost every RDS instance what the follow-up question was what's the cost model for that every RDS instance you pay hourly for the compute and for the amount of storage that every one of those RDS instances consumes that includes your read replicas so if you have one terabyte main database and you have five read replicas then you're gonna have five one terabyte storage volumes and five compute nodes across regions there's an additional cost for data transit between regions as well so it will depend on how what the right volume is of your database or my changes you're generating over time that will determine what that impact of that cost aspect is so we've got the database running we've set up high availability potential if it's a production so how do we monitor and how do we operate to state up a database like that there's four fundamental services that we use from a monitoring perspective and these build a comprehensive ecosystem of tools monitoring tools you can use you would typically start with Amazon CloudWatch metrics and cloud watch alarms so this service allows you to monitor core metrics like CPU memory utilization IO replica lag throughput latency of your work network based latencies of your workload so it gives you essentially a good view of the course metrics performance metrics of your database and the inter the monitoring interval is usually down to one minute so and you can then configure alarms on these metrics so for example you can set up an alarm that says in my deep database CPU utilization is above 80 percent for two minutes maybe somebody needs to be paid to take a look at what's happening on that database so you can set up those types of alarms another component of cloud watch is called watch logs so you can centralize all of the logs from your databases into cloud watch logs take them off those the instances publish them to our crawl watch log service where you can see all of your errors and per system based on how long you want to retain those logs in that service you don't have to use cloud watch logs but it's a nice way to centralize everything into one place and give you good filtering and graphing and monitor and monitoring capabilities on top of that if you just need your logs every so often you can also download them for go directly from the RDS console or the api's without centralizing but typically customers have run operate large fleets of RDS instances they want a centralized way to analyze what's going on and retain some of those logs perhaps past the time that that Hardware no longer exists right you might retire an RDS incident but you might still want to keep the logs if you know you've seen an anomaly at some point in the past and then the third component that we offer part of the RDS platform is our enhanced monitoring so the club watch metrics are nice but the granularity of one minute sometimes isn't enough for certain workloads you want to be a little bit more detailed especially if your workload has variability that exceeds that right and you might have you know spikes in usage that happen at the second resolution potentially or ten seconds so enhance monitoring is an agent-based monitoring solution we have an agent on those RDS instances I simply samples and publishes those enhanced monitoring metrics and you get added capabilities that way you get better resolution say on CPU utilization there's file system related metrics there's process related metrics in there are your related metrics so there's additional capabilities that I'll give you a more granular view of the database now if you do enable enhanced monitoring there is an extra cost associated to that because those logs are actually automatically published to club watch logs on your behalf so depending on your resolution and how much the volume of matrix that your database is generating the corresponding cost and cloud watch logs would be reflected there and the fourth component is performance insights this is a relatively new offering and we brought it in because you know it's not enough to have metrics that look at the instance itself it's fine you know it's nice to see you know if your database is exceeding 80% capacity that's one thing right but it doesn't really tell you why right so performance insights is designed to give you query and weight level performance data so it's going to look at your queries that you're running on that database and extract matrix how long does it spend in compute time how long does it spend waiting for logs how much how long does it spend waiting for data to be written to or flush to disk all of those counters will be accumulated and surfaced through performance insights so that gives DBAs for example a good ability to be able to optimize data database work was if you have queries and you see that you know they're very very slow you're gonna look at performance insights look at what they're spending their time doing and then you can make actionable decisions perhaps you see that all of your queries are waiting on i/o that would be a clear indication that you might need a different storage technology bigger story size more eye ops maybe a different instance class with more storage throughput capabilities we can make those types of decisions more accurately based on actual performance eight of your queries so the dashboard for performance insights looks somewhat like this you'll see a graph at the top of essentially an aggregate view of all your queries and all of the weights over time that your data that you know those queries are encountering it's a really really easy way to start with that gives you a clear identification if there's something wrong there but then you can also drill down into the individual query patterns and down all the way to the specific queries if you see anomalies that way so it just helps you identify bottlenecks in the database based on users based on weights based on the queries that you're running who's running those and criteria like that gives you an adjustable time frame and the really cool thing about that is you get seven days worth of performance data for free when you enable it so it's perfect for developers it's perfect for folks that are developing workloads initially and they're trying to test and understand what the impacts of certain query decisions they have now if you have a production workload and you have a use case that you need to monitor the performance of your keywords and see if there's any degradation over long periods of time right if my execute this Mike is my execution plan that I in a match it's the query pattern two years ago still valid today for those types of decisions we have long term data retention as well up to two years for performance data but that's an additional cost depending on the number of virtual CPUs that your clusters are so you get seven days for free which is honestly useful and more than enough for most use cases but you also have the flexibility of retaining that data for longer if needed the other topic when we're talking about monitoring and operating databases are is best practices how do we ensure that in an RDS environment we're still adhering to the best practices for running those particular database engines and when we're looking at best practices holistically there's really four areas where those are coming from just because you're running in Amazon RDS doesn't mean that the best practices that are for that specific engine and have been well established over time no longer apply in fact it's the opposite the whole idea of reusing RDS is to use a database engine that has established best practice it has established operating procedures and you can leverage all of that knowledge all of those best practices even in an RDS environment another source of best practices are a SS well architected framework so this is holistically an area where you can essentially assess your workloads in terms of how well their architecture from an AWS perspective databases are a portion of that so the framework will work on five pillars security reliability performance operations and cost optimization and it will give you questions and ways to optimize to ensure that you're optimized for that place so that also applies to best practices in RDS and finally you've got the RDS documentation and the capabilities of the RDS plot so those are also sources for best practices one that's relatively News RDS recommendations so this is a feature of the platform itself and it provides you in develop individualized guidance by analyzing those resources that you're running so it's going to look for example if you have an instance that house is running an old version of the software and if that's the case it'll suggest to you to upgrade it to patch it and you can do it right there from the console by clicking a simple button it's going to also offer offering guidance on a couple of other specific configurations maybe you're running a production workloads and you're running single lazy might give it a guidance of using multi AZ or enabling enhanced monitoring or things like that over time we're going to improve this capability to give you more capabilities around based on the workload itself the capabilities today are mostly configuration based and you can look at all of these rights in the console where are you gonna have a dashboard and the ability to take actions based on some of those suggestions and Yukie I also have the ability to track what's happening in RDS in terms of events what sort of what is occurring what is what sort of events are instant or your instance is encountering when you're running them RDS has event notifications to let you know when things are happening like if it's if there's a if there's a failover we're going to issue in a notification or an event so you know when that starts occurring you can either leverage the built-in integration with amazon's and not a simple notification service or you can plop publish them to Amazon Cloud Watch events which is a centralized in event engine in a supports cross account event delivery as well so again if the pattern is if you have an and network operation center or a security team that's isolated you probably want to feed those events into that team there's different types of events based on the resources that you're running instances cluster snapshots security groups and so on and different types of categories of events availability related deletion configuration changes and so on so you can monitor very granularly everything that has to do with your database and the last thing I wanted to cover its cost optimizations there are really two main ways to cover cost optimization and cost optimize your usage one of them is starting and stopping your instances if you're in a development environment then you can simply turn off to stop that instance whenever the developers aren't using it and then start it up again in the morning when the developers come into the office and start using it again and you're saving the compute cost during that time span that you're the instance is stopped you don't pay for the computer hours of those instances there's some limitations like you can't start stop instances are part of a complex topology with read replicas and so on or they're you know the master for read replicas and so on and we're gonna turn them back on automatically if they've been stopped from for seven days so we're gonna kick them back up there's more cost-effective ways if you want to stop something long-term you simply take a snapshot at that point and just restore it whenever you need it again later on if you're looking to store something long-term so so this is really designed for the smaller use case it's in the second cost optimization he's using reserved instances once here in a production setting you know the load of your workload you know what sort of resources you need at that point you can reserve those compute instances in order to get a better cost optimization from a compute side so you're you're going to essentially pay for the compute ahead of time and not being charged the hourly rate so that's it but you're gonna get discounts depending on which option you choose one year three year and the combinations up to you know potentially even seventy percent of your day or of your cost so those savings can be quite significant once you're at the point where you can plan the compute costs so in summary Amazon RDS takes care of the time-consuming database management tasks but otherwise you would have to do yourself whenever you're operating databases you can you know it allows you to pick the right configurations for the workloads and then adjust when the scale changes when you you know your workload changes your skin you have more users it also gives you a range of options and capabilities that allow you to run from simple databases all the way to complex replicated and highly available topologies and it gives you a suite of built-in tools to monitor manage and operate your databases so you so you don't necessarily have to use external tools or complicated scripts or capabilities that you develop in-house you can use what's available in the platform to get those capable to deliver the results that you need and this is it as far as our session this morning we have a lab that will allow you to launch RDS instance and kind of play with the management console to understand how it works what sort of decisions you would normally do when you're launching an workload that's backed by an RDS database this is during lunch so it's going to be a working lunch I'm going to put the URL on screen for you to to see where to get the lab guide from and in the meantime if there's any questions please free to reach out to me I'll be here assisting with the lab so just grab me [Music]

Channel: Amazon Web Services

Views: 11,549

Rating: 4.8730159 out of 5

Keywords: AWS, Amazon Web Services, Cloud, cloud computing, AWS Cloud

Id: igRfulrrYCo

Length: 63min 18sec (3798 seconds)

Published: Mon Feb 18 2019