In this video, Jeff Winesett describes using DynamoDB for user session management as a means to keep web and app servers stateless. A stateless architecture is a scalable architecture and DynamoDB helps keep Web and App servers stateless.
- [Instructor] The final AWS service to be covered in this section on decoupling system components is DynamoDB. DynamoDB is a NoSQL, non-relational, schema-less database service that has been built from the ground up to deliver low latency, high performance, and high throughput. It scales automatically to meet application throughput requirements. Instead of using traditional hard drives, the data is stored on solid-state drives which provides very fast data access.
Data is also automatically replicated across multiple availability zones so durability is built right in. The reason I am introducing DynamoDB in this section on decoupling components has less to do with the specific features of DynamoDB itself and more to do with its effectiveness as a tool to help create stateless servers. Sometimes maintaining state is required in an application. A common example is user session management.
When an application requires user authentication and authorization, the authenticated state of a user often needs to be stored in a shared location where all system components have access to the same state information. Because of the way it is built, DynamoDB is a very good solution for the storage of application session state. Many times, web applications are architected in such a way that user session state is stored directly on the web server, but this is not a scalable architecture.
For example, say we have some traffic coming in to a single web server where the application state is being stored directly on the server. This is not an optimal architecture as the system has a clear single point of failure. If this one web server fails, so does the entire system. A quick improvement to the system is to eliminate the single point of failure by adding more web servers. To do so, Amazon's ELB service can be used to add a load balancer and then we can add additional web servers.
However, things are not quite that easy because our application itself has not been built to be able to take advantage of this scalable infrastructure. Since the application session state is still being stored locally on each web server and since, in this example, the load balancer is balancing the traffic equally across each web server, a logged in user will eventually be routed to a web server that does not have the needed session and the application will behave as if this user is not logged in at all.
One might be tempted to address this issue by taking advantage of a configuration available on ELB load balancers. ELB load balancers can be configured to remember which request needs to go with which web server, always sending the same user back to the same web server. This is also referred to as sticky session management on the load balancer and it is an option when using ELB. With this in place, the immediate session issue is resolved because a logged in user always returns to the same server.
But now, we are right back to a single point of failure. If this one server fails, the user will be redirected to another server without the session state and we are back to the same problem. So this solution is not ideal. The better solution is to store the session state outside of the web servers in a centralized location. This is where DynamoDB comes into play. It is optimized for the types of interactions needed for session management, more so than a traditional relational database management system.
And as such, will provide a good solution that will keep application users happy and system components decoupled. Decoupling components lesson number four. Keep the scalable server components of applications as stateless as possible, and when session state is needed, store this state in a centralized storage using DynamoDB.
- Benefits of cloud services
- Making architectures scalable
- Examining cloud constraints
- Virtual servers, EC2, and Elastic IP
- Using the Amazon machine image
- Elastic load balancing
- Using CloudWatch for monitoring
- Security Models
- Elastic block storage
- S3, CloudFront, and Elastic Beanstalk
- Handling queues, workflows, and notifications
- Caching options and services
- Identity and access management
- Creating a custom server image
- Application deployment strategies
- Serverless architectures