Auto Scaling Varnish on Amazon EC2 (AWS)

Varnish is an HTTP accelerator designed for content-heavy dynamic web sites. It sits in front of your web server. Varnish caches and stores web pages in memory so that web servers don't have to create the same web page over and over again. Varnish Cache serves pages much faster than any application server; giving the website a significant speed up. We have seen use cases with Varnish , where pages can be delivered sub-second to the browsers. Varnish is usually suitable for applications like Online Newspapers/magazines , Online Classifieds , Media sites which has more read pages and less of write operations (Publish once - Read many scenarios).

Example : In an online newspaper site , content is published once and not updated often . But it is read by millions in a day. Varnish page caching is suitable for this scenario because the fully formed-published page can be cached and served from the Varnish Layer instead of hitting the web server every time.

In online classifieds scenario , ads will be posted->published and will not change quite often. In some classified sites , the ads usually go through an approval process before publishing. In such scenarios the ads can be cached and served from Varnish itself instead of backend servers

Varnish can be scaled using following strategies in AWS:

1. Varnish Scale up
2. Varnish Scale out

Varnish Scale up :

This is most simplest strategy to implement in the scaling process. When your varnish cache memory or CPU is the bottleneck , we can always increase the Varnish EC2 instance to next higher capacity. This task can be done manually or automated in AWS. Follow the below steps while scaling up Varnish manually or automatically :

For example : Varnish-EC2-A (m1.large) is scaled up to (Varnish-EC2-B)

• Identify the next higher EC2 instance type based on the bottleneck , usually more RAM is better for varnish
• Take a backup of the varnishlog from Varnish-EC2-A 
• Preload the Varnish-EC2-B with Varnish-EC2-A logs (or) cache warm this with frequent pages

Different EIP under Route 53:

• Attach Varnish-EC2-B with a new ElasticIP (EIP)
• Check whether Amazon Route53 is configured with round robin algorithm 
• Attach Varnish-EC2-B EIP to Route53
• Detach Varnish-EC2-A EIP from Route53 once Varnish-B IP is propagated
• When you Detach Varnish-EC2-A EIP , if some end clients have cached this IP , then website access might throw errors

Same EIP under Route 53:

• If you feel Varnish-EC2-A IP might be cached in some clients , then you an attach properly warmed Varnish-EC2-B to same Varnish-A EIP. 
• This action might impact the website for ~60-180 seconds till Varnish-B is attached with same Varnish-A EIP.

We will see about Varnish Scale out in the next article