CDP:State Sharing Pattern

From AWS-CloudDesignPattern
Revision as of 00:32, 28 November 2012 by Cdpadmin (Talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search
Architect

Sharing State Information

Contents

Problem to Be Solved

Often state information that contains information that is unique to the user (HTTP session information) is used when generating dynamic content. However, when multiple web/AP servers are running under the control of the Load Balancer, if you have each individual web/AP server possess state information, this could cause the state information to be lost if there were a server failure or if you intentionally reduce the number of servers.

Explanation of the Cloud Solution/Pattern

This pattern lets you maintain state information in a scale-out structure. This ensures inheritance of state information when the number of servers is increased and prevents loss of state information when the number of servers is decreased (including when there is a failure). The state information is placed in a high-durability shared data store (memory/disk), to be information that is referenced by multiple servers. This makes the server "stateless," having no state information. Even if a new server is added, it is the shared data store that is referenced to cause the state information to be inherited.

Implementation

The AWS data stores include "ElastiCache," "SimpleDB (KVS)," and "DynamoDB (KVS)." All of these let you store state information. Select One of these, depending on the requirements.

  • Prepare a data store for storing the state information.
  • Use, as a key in the data store, an ID that identifies the user (a session ID or user ID), and store the user information as a value.
  • Store, reference, and update the state information in the data store, instead of storing it in the web/AP server.

Configuration

2XNdewVsgellO3x8-0BDDA.png

Benefits

  • This lets you use the scale-out Pattern without having to worry about inheritance or loss of state information.

Cautions

  • Because access to state information from multiple web/AP servers is concentrated on a single location, you must use caution to prevent the performance of the data store from becoming a bottleneck. If the performance requirements are challenging, consider selecting DynamoDB, which rarely becomes a bottleneck.
  • Depending on the requirements, the Amazon Relational Database Service (RDS) (a relational database management system) or the Amazon Simple Storage Service (S3) (Internet storage) may be used for the data store.
Personal tools
Namespaces
Variants
Actions
Navigation
Toolbox