3

I currently have my web application hosted on AWS, and I use two ELB instances, one to load balance the frontend requests to the app servers, and a second to load balance the backend requests FROM the app servers TO the API servers, like so (sorry for the crappy ascii diagram):

           /-->APP1--\    /-->API1
User-->ELB1           ELB2
           \-->APP2--/    \-->API2

In other words, the API requests that the APP servers make are load balanced evenly across the two backend API servers.

But, because I'm caching responses on the API servers, and use a cache invalidation mechanism which is NOT shared between the API servers, I'd like for a user's session to be stuck to one backend API server.

I already have the user's session stuck to one APP server, using the normal ELB load balancer-generated cookie stickiness, but is there any way to get the backend ELB stuck to a session? Of course, those requests are not coming from a browser, so there's nothing to manage cookies, and it seems that ELB's can only manage stickiness with cookies. Can I emulate the necessary cookies my backend requests?

SilentMiles
  • 624
  • 6
  • 8

2 Answers2

1

To close off this question, yes, this is fairly easy to achieve by simply capturing the 'Set-Cookie' response header from the ELB, and then passing the cookie back in subsequent requests. But, see my caveat below.

SilentMiles
  • 624
  • 6
  • 8
0

I don't believe it would be possible to achieve stickiness between your App servers and API servers without doing a whole load of messy work. I could be wrong, and am very open to correction but I don't believe there is an easy solution, unless the language you're using for your App Server logic has something to offer.

Regardless, the best solution here would be to decouple your App Servers and your Cache. It would make more sense to have a single cache shared between the API servers that is served by separate servers. This will increase your infrastructure's fault tolerance and give you better quality data in your cache (especially as you scale up). You could use the ElastiCache service to do this for you and avoid any heavy lifting.

mickzer
  • 5,958
  • 5
  • 34
  • 57
  • It turned out to be fairly easy. I just capture the 'Set-Cookie' response header, and store any AWSELB cookie I receive, and then sent the cookie in subsequent requests. The APP session is now stuck to one API instance. – SilentMiles Mar 20 '16 at 06:10
  • But just a word of caution: If you have a small number of front end/back end servers, it's possible for all front-end servers to get stuck to just one or only a few back-end servers. In other words, this method reduces the load-balancers ability to dynamically balance load. – SilentMiles Apr 04 '16 at 04:12
  • This is clearly outlined in the documentation. Sticky sessions significantly hinder scalability. – mickzer Apr 04 '16 at 16:19
  • Yes, but that refers to normal stickiness -- bonding a front-end user (browse) session to one front-end app server. Sure, that will hinder scalability a little, but as user sessions are typically short lived, it's not a major problem. The situation describe above is a bigger problem -- with small clusters, say just two front-end servers and two back-end servers, there is a significant possibility that both front-end servers will get bonded to just one back end server. That would have a *much* bigger impact on scalability. – SilentMiles Apr 05 '16 at 22:50