Part One
In this three-part series of blogs, we want to walk you through the operation of the Code Enigma High-Performance Stack. You'll see how our drop-in LAMP replacement achieves its blistering performance.
We'll dig into:
-
Part 1 - The Hosting Platform
-
Part 2 - Security
-
Part 3 - Developer Tools
So, let's get going…
The Hosting Platform
Amazon Web Services (AWS) - our Infrastructure Partner
Code Enigma chooses to platform our virtualised infrastructure at Amazon Web Services (AWS). Their public cloud give us the same control we used to have with our (now sunsetted) Private Cloud product. Their networks are designed to be highly resilient and scalable. We can work with any of the AWS locations (or regions) and datacentres (or AZs) available. We tend to default to Dublin - it's in the EU, so robust data protection and it has great features and stability. With our own ISO 27001 certification in place, this means you get through the line, solid management frameworks and operating procedures at every level of the service.
Designing server layouts
Building on top of the AWS platform, we design server layouts to meet our client needs. But as an example, our popular fault-tolerant Highly Available layout is set out as follows:
-
2 x HAProxy loadbalancers (fault tolerant pair, sometimes replaced by ELB)
-
2 x application servers (web server and cache layers, in different AZs)
-
2 x Apache Solr servers (fault tolerant pair, also in different AZs)
-
AWS RDS (for highly available database services, again, multi-AZ)
We usually propose to clients interested in a high-tolerance layout the addition of two AWS EFS exports (for example, one for Drupal unstructured assets, the other for Solr indexes) to support the virtualised infrastructure. If we propose an AutoScale solution, we would also add AWS ElastiCache, if required for middleware caching, and Simple Email Service (SES) for sending email where the addressing may change. Sometimes a NAT Gateway might also be added, to give you a static IP address to whitelist for outbound traffic.
Every component of the software stack responsible for serving your application has redundancy, due to the AWS availability zones model. The AWS EFS we use to provide Network Attached Storage for your servers is a highly available service by design. There's no single point of failure in this solution.
Common components of our software stack
There are common features in our software stack, whether you take the Highly Available layout above, or a single server.
-
At the base all of our servers are Debian Linux.
-
As a load balancer, if we don't use an AWS ELB then we use the popular HAProxy software. It natively supports an active/passive setup for fault tolerance. And it allows us to let each client have their own load balancers, so any custom requirements can be easily compartmentalised. HAProxy also natively supports clustering, should you need to scale, though this is built into ELBs.
-
On the application server we usually run the popular Varnish reverse proxy cache. This significantly enhances the speed of serving pages to anonymous visitors. It's done by serving static cached pages from the server's RAM instead of building a new page every request.
-
Running on the same app server we use Nginx as a web server, because it has significant performance gains over Apache. To execute PHP scripts we use PHP-FPM, which is an implementation of FastCGI for PHP, which has the Zend Opcache opcode caching extension available as well, for caching of compiled PHP, which would otherwise have to be recompiled at every request, due to PHP being an interpreted language.
-
Behind all that there is a further caching layer, provided by memcached. It's a generic Linux caching system we use with Drupal to keep requests from the MySQL database. We can store any "disposable" data, such as user sessions and Drupal's own internal caches (pages, blocks, views, etc.) in memcached. This avoids unnecessary database queries. memcached also clusters, so you can use both application servers as components in the same pool. As noted above, if you have an AutoScale cluster this memcached layer may be moved to AWS ElastiCache instead.
-
The application servers and the load balancers can both be scaled horizontally with no difficulty, due to our approach to server management and the shared unstructured resource storage supplied by the sNAS product, AWS EFS.
-
For search, we can provide Apache Solr, but also ElasticSearch. You could also include additional components, such as Apache Tika for searching inside uploaded documents. Because these Solr servers are dedicated to your website, you have complete control over their configuration.
-
Finally, we usually use AWS' RDS for the database layer (their MySQL-as-a-Service product). This is highly available and fault tolerant by design. We configure it to operate across multiple AZs to increase the fault tolerance further.
-
These components represent our standard approach. But we're completely open to tailoring servers to client needs. Some clients prefer to use Apache over Nginx, or 'proper' MySQL on a database server instead of RDS, or Redis instead of memcached. This isn't a problem. We'll work with you to ensure you get the server layout and software components you're comfortable with.
Real-world performance - comfortably handling 2,000 requests a second
This is a software stack we've tested extensively. As an example, working with the Wellcome Trust in London we carried out "real world" performance benchmarking using their "Mosaic Science" ezine (built with Drupal 7) as the test application. We found the Drupal website, when combined with a CDN and our standard highly available layout, could comfortably handle 2,000 requests per second. Even with no CDN and no additional caching, we were able to handle around 150 pageviews per second, which equates to over 500,000 pageviews an hour. And we can easily add in AWS CloudFront to go even faster.
If you're interested in our hosted services, please contact us.
Next time, in part 2 of our 3 part journey, we take a serious look at the security of your servers…