Today we find out how to setup HAProxy as “slow-fast” request balancer for heroku application using Amazon Elastic Compute Cloud.
- non optimized application
- Heroku account
- Amazon EC2 account
Prepare AWS tools
Although you can manage AWS via WEB interface we prefer command line tools.
- Download Amazon EC2 API Tools
- Login to EC2 consle
- Obtain your AWS_ACCESS_KEY and AWS_SECRET_KEY on to Access Credentials page
Now switch to console and setup your credentials for tools.
$ export AWS_ACCESS_KEY=your_AWS_ACCESS_KEY_ID
$ export AWS_SECRET_KEY=your_AWS_SECRET_KEY
Check access by invoking (for example):
Tools are ready.
Create balancer ssh access key
In order to access balancer we need ssh private key.
Choose name for your key (e.g. haproxy-balancer) and create it by:
$ ec2-add-keypair haproxy-balancer
KEYPAIR haproxy-balancer 0a:ea:f9:f6:4c:29:80:33:0c:2e:af:7b:8c:dc:5c:5b:24:65:53:6f
-----BEGIN RSA PRIVATE KEY-----
-----END RSA PRIVATE KEY-----
Save output to some file e.g haproxy-balancer.pem. Don’t forget to set right permissions:
$ chmod 600 haproxy-balancer.pem
Open to ports in order to access our instances via SSH and HTTP:
$ ec2-authorize default -P tcp -p 22
$ ec2-authorize default -P tcp -p 80
Note. From security point of view we recommend to create special access group for balancer instead of using default group.
Setup balancer on AWS
We are going to use standard latest Ubuntu AMI. On alestic page choose desired ubuntu version.
Be sure to choose AMI from us-east-1 region because heroku instances are located exactly in this region,
otherwise you will have network latency.
On moment of writing this article latest AMI is:
Ubuntu 12.10 Quantal EBS boot ami-7539b41c
Run instance using haproxy-balancer credentials into us-east-1 region on t1.micro instance:
$ ec2-run-instances ami-7539b41c -k haproxy-balancer -t t1.micro --region us-east-1
In order to find out status and IP of instance wait a while and run:
$ ec2-describe-instances i-99de1ce8
Connect to balancer instance:
$ ssh -i haproxy-balancer.pem email@example.com
Install HAProxy package:
ubuntu@ip-10-112-71-4:~$ sudo apt-get install haproxy
(Optionally) Install git package:
ubuntu@ip-10-112-71-4:~$ sudo apt-get install git
Clone our HAProxy request balancer configuration.
You are free to use own HAProxy configuration just follow ideas in our configuration.
Anyway we strongly recommend you to keep your configuration under control version system (git. subversion, etc).
And then deliver changes to server from SCM repository instead of editing it directly on the server.
For simplity we clone sample configuration and change it on the server:
ubuntu@ip-10-112-71-4:~$ sudo mv /etc/haproxy/ haproxy.origin
ubuntu@ip-10-112-71-4:~$ sudo git clone git://github.com/railsware/haproxy-slow-fast-request-balancer.git /etc/haproxy
Tune slow urls in:
Enable HAProxy by setting ENABLED=1 into /etc/default/haproxy:
ubuntu@ip-10-112-71-4:~$ sudo vim /etc/default/haproxy
ubuntu@ip-10-112-71-4:~$ sudo vim /etc/init.d/haproxy start
Switch to HAProxy balancer
Now we can try visit slow/fast urls of our application using balancer IP address or perform some load/stress testing.
When everything is ok we are ready to change application DNS host settings to balancer IP.
We recommend to allocate and assign elastic IP for this purporse. It allows you easy switch to another balancer if something goes wrong.
Allocate new IP addresss:
$ ADDRESS 188.8.131.52 standard
Assign address to your Balancer IP address:
$ ec2-associate-address 184.108.40.206 -i i-99de1ce8
ADDRESS 220.127.116.11 i-99de1ce8
Check again by visiting your application via assigned elastic IP.
Finally change your DNS “A” record of to balancer IP according your DNS provider manual.
Also Heroku Custom Domains article can be useful.
If something went wrong switch back DNS settings to use heroku application directly.
As we already mentioned this solution is “temporary”. It gives your application opportunity to survive under high traffic.
You may use “slow-fast” balancer until you fix your slow resources by moving them to background or changing your architecture.
Then you may switch back to direct application usage.
We are hope you find this article helpful.
Most recent posts
- Responsive layout tests with Capybara and RSpec
- SQL Joins Visualizer – build SQL JOIN between two tables by using Venn diagrams
- Flexbox as a solution for browser reflow optimization
- Make AngularJS 1.0.7 work with Jasmine 2.0
- Git housekeeping tutorial: clean-up outdated branches in local and remote repositories