Part 1: Web Session Synchronization using JGroups

JGroups is a toolkit for reliable multicast communication. JGroups can also use transports such as 

TCP. JGroups allows developers to create reliable multi point applications where reliability is a deployment issue, and does not have to be implemented by the application developer. This saves application developers significant amounts of time, and allows for the application to be deployed in different environments, without having to change code. It can be used to create groups of processes whose members can send messages to each other. The main features include

• Group creation and deletion. Group members can be spread across LANs or WANs
• Membership detection and notification about joined/left/crashed members
• Sending and receiving of member-to-group messages 

Since AWS Infrastructure currently does not support Multicast protocol, the application layer software should synchronize the session data between them directly using Unicast TCP mechanism. Java based Application servers can use JGroups to synchronize the session data to other Java Web/Application EC2 instances in Unicast TCP of JGroups. It is recommended to use few Larger EC2 Instance types for Web/App layer than lots of smaller EC2 instance types while following JGroups based synchronization because 

• Larger EC2 Instance types have better IO and NW performance for serving web requests + sync data
• Fewer instances will keep the sync traffic minimal  

Pros:
Since this pattern follows a distributed approach towards web session synchronization there is no Single Point of Failure
There is no extra cost or burden of maintaining a centralized Cache server for session store
Cons:
This pattern will be efficient if there are ~5-10 EC2 Web/App servers in the infrastructure.If your web application layer has few hundreds of EC2 instances then Unicast TCP will be inefficient because of following reasons; there will lots of sync traffic data among Java Web/App EC2 instances and EC2 instances will be busy using considerable amount of their CPU cycles for synchronization rather than serving web requests and EC2 web/app memory will filled with redundant session data.  

Note : vCider or VPNCubed seemed to support Multicast on AWS. vCider is acquired by Cisco and have stopped new downloads currently. 

Part 2: AWS High Availability Patterns:Web App Tier

High Availability @ Web/App Layer

To avoid Single Point of Failure in the Web/App layer it is a common practice to launch the Web/App layer in minimum two or more EC2 instances. This is fault tolerant than the single EC2 instance design and offers better application stability. Usually the Web/App Servers are designed either with Stateless or State full models.  Following are some of the common stateful architecture options for HA in Web/App Layer :

Following points needs to be considered while designing Highly Available and State full App Layer on AWS:

• Since AWS Infrastructure currently does not support Multicast protocol currently, the application layer software should synchronize data using Unicast TCP mechanism. Example: Java based App servers can use JGroups or Terracotta NAM to synchronize the cluster sync data information in AWS.
• In case the Web/App servers are written on PHP, .Net, Python etc then all the user and session data can be stored on centralized systems like MemCached EC2 or ElastiCache or Amazon DynamoDB .Deploy redundant ElastiCache Clusters in different Availability Zones for HA in AWS.
• ElasticIP based App Server switch will take ~120 seconds, not recommended for mission critical environments
• Session and User data can be stored on Database as well, this methodology should be carefully evaluated for response latency before implementing.
• Uploaded User files and documents should be stored on common NFS or Gluster Storage Pool or Amazon S3
• Enable Session Sticky Policy in Amazon ELB or Reverse Proxies if Session Synch is not configured. This approach offers HA but not fail over transparency in App layer.

Related Articles : AWS High Availability Patterns Series

Part 2: AWS High Availability Patterns:Web App Tier

Part 3: AWS High Availability Patterns : DNS Load Balancing Tier

Part 4: AWS High Availability Patterns : Database Tier

Part 5: AWS High Availability Patterns : Multiple Availability Zones

Part 6: AWS High Availability Patterns : Using AWS Building Blocks

Part 7: AWS High Availability Patterns : Multi Region Architecture

Part 8: AWS High Availability Patterns : Multiple Cloud Providers

Full Article : Overcoming Outages in AWS : High Availability Architecture Patterns