Moving WordPress to Amazon Web Services resulted in increased reliability and decreased operational costs for an entrepreneurial organization last year.
WordPress is a popular content management system for the Web. It is flexible and customizable, but it took the Young Entrepreneur Council (YEC), based in Boston, multiple tries to get the supporting infrastructure stable and performing well. YEC uses WordPress to run its external websites as well as some internal applications.
YEC deployed WordPress on Amazon Web Services (AWS) nine months ago when an attempted deployment at a hosting provider did not go as planned.
"This was our first attempt to scale WordPress and it failed miserably," said Robert Calise, CTO for YEC, in a presentation at an AWS Meetup in Boston last month. "We had seven really powerful servers, and our big bulky slow WordPress installation just crushed them."
One of the reasons was the way YEC and the hosting provider had tried to deal with a common, thorny problem in the WordPress world -- session persistence when scaling across multiple servers.
"The way that PHP and WordPress handle sessions natively, if you're accessing our website, you're accessing one server," Calise said in a follow-up interview. "If we were using the native session handler, that means your session information, your login session, any other information, would be on that one server."
Thus, if anything happened to that server, it would log end users out and drop all the information about the session. To overcome this, YEC and the hosting provider it was working with attached multiple WordPress application servers to a single NFS mount on a separate file server.
"All of this was on wonderfully slow magnetic storage and there was lots of disk I/O contention and we had lots of nasty downtime," Calise said during his presentation. "At one point a storage controller failed in the data center and we ended up with 24 hours of downtime."
This incident sent YEC looking for a new way to deploy WordPress.
AWS WordPress deployment tips and tricks
Robert CaliseCTO for YEC
Today, YEC's AWS WordPress deployment consists of the CloudFront CDN to serve static content, which makes for faster delivery and less stress on the WordPress Web servers. Auto-Scaling Groups of Elastic Compute Cloud instances live behind an Elastic Load Balancer, which distributes the workload and avoids downtime. An ElastiCache deployment using memcached keeps session information persistent across multiple servers instead of a spinning-disk-based file system.
Previously, YEC paid $2,500 a month to the hosting provider to run WordPress.
"I think we had at peak seven machines, three or four Web nodes, a dedicated database server, and one NFS mount," Calise said. "We cut our costs in half by moving to Amazon and we now run 30 servers, still for way less money."
But it was really speed of provisioning time that swayed YEC to Amazon. To get a new server with the hosting provider had been a 24 hour process, but servers are available in a matter of seconds with AWS. Calise also praised Auto-Scaling Groups for increasing the reliability and scalability of the AWS WordPress infrastructure.
However, there are some challenges with Auto-Scaling Groups, Calise said. One is with startup speed; beginning with a static Amazon Machine Image (AMI), libraries might need to be updated, the latest code needs to be deployed, and it must be attached to a load balancer.
"The time that this takes is kind of an issue, so [we] preconfigure everything in an AMI," Calise said. "We frequently update that AMI, about once every two to three weeks, and then all we do when the server spins up is use the user data to pull down the latest updates from our [code] repositories … and we're good to go."
In addition, custom SSL certificates in CloudFront are a challenge to get configured and were expensive for YEC to use --AWS charges a fixed monthly fee of $600 for each custom SSL certificate associated with CloudFront distributions. Ultimately, YEC went with Amazon's default SSL certificates instead of customizing CloudFront to show the YEC domain.
"It got to the point where there was really no performance benefit, and it was buried in HTML source -- nobody sees that unless they go looking for it," Calise said.