title: AWS auto-scaling websocket cluster
body: <p>So I am changing lots of my sites' "live" updates (currently working over AJAX) to use Websockets. Tried Pusher.com, pricing ridiculously high for my amount of traffic, so I got slanger (cheers Steve!) up on a big fat EC2 instance, redis EC instance, all good. Now for about 100M frames/day it seems to work fine, but I'd like to think ahead and consider what happens when I'll have even more traffic.</p>
  
  <p>AWS ELBs do not support WS communication as I have read around here and on the AWS forums so far (quite lame considering people are asking for this since WS first popped up, thanks AWS!). So I am thinking to:</p>
  
  <p>0) start with one instance, ws.mydomain.com</p>
  
  <p>1) set up an auto-scaling group</p>
  
  <p>2) cloudwatch alert on average CPU/memory usage</p>
  
  <p>3) when it goes above 75% fire a SQS message saying something like "scale up now"</p>
  
  <p>4) when message at #3 is received by some other random server polling the queue then fire up a new instance, add it to the group (ohnoes, that AWS API again!) and add the public IP to the Route53 DNS for ws.mydomain.com, so there will be 2 of them</p>
  
  <p>5) when load drops fire another message, basically doing everything the other way around</p>
  
  <p>So the question is: Could this work or should it be easier to go with an ELB in front of the slanger nodes?</p>
  
  <p>TIA</p>
  
  <p>Later edit:</p>
  
  <p>1) don't care if we don't get the client IP</p>
  
  <p>2) the slanger docs advertise that connection states are stored into redis so it does not matter to which node the clients connect to, so we don't need any session stickiness</p>