The structuration of a website’s architecture is extremely important. Indeed, if it is ill thought of, it can prevent the website from serving all its visitors in good conditions, prevent future evolutions, and thus slow down the client’s growth. That is why some good practices have to be respected in every architecture, one of the main ones being the microservices trend: the cutting of an architecture in several independent services, specialized in one single task.
For an e-commerce website, every visitor lost represents a potential loss of turnover, and negatively impacts the company’s brand image. 79% of Internet users that are not satisfied with an e-commerce website’s performance will indeed not visit the website again1. It is thus all the more vital to have an adapted and efficient underlying architecture.
NBS System’s experts, who are e-commerce managed hosting specialists, thought a lot about what could be the ideal architecture of a website, especially an e-commerce one, using a PHP framework or solution. Today, we give you their conclusions: an architecture one shoud get as close of as possible, depending on the context and constraints of both the hosting provider and the client.
On most e-commerce websites, the first contentious point is MySQL. It makes sense: a database can contain hundreds of products (each with its variations: size, color…), store the information of hundreds of visitors… MySQL does not support simultaneous readings/writings, thus the loading time can become very long, like on a product page for instance. MySQL has its limits, and it can turn out to be quite delicate to find the balance between performance and reliability.
The basic principle of the architecture that we will show you is thus to sollicit the database as little as possible. For that, a maximum of services have to be externalized, by multiplying layers… and caches! That is how the contentious point becomes the treatment of dynamic requests needing PHP, which is much easier to handle, as we will see.
The first layer of the architecture aims at being a “front line” serving the static components of the website. It is composed of two NGINX webservers of an average size, on which is installed Varnish, a cache management software. If the latter is well configured, it enables to cache the HTML static elements of the page (structure, menu…). It concerns all elements that do not change from one user to another.
The static elements that are not HTML are stored on two media servers. Varnish is also installed on these NGINX servers : it handles the caching of these elements and limits the effective load of the servers. For a website selling abroad, an optimum configuration also requires a CDN on which these servers will be replicated, in order to minimize the loading time of the pages for international users for instance.
Here, there is a problem: browsers are limited in the number of files they can download simultaneously. For instance, in a case where a browser can download 10 elements simultaneously, where the page contains 30 images, and where the download of an image lasts 1 second, it will take 3 seconds for all the images on the page to be loaded.
To overcome this, one can link several domain names to these media servers (example.com / media.example.com / share.example.com / toto.example.com…). Thus, the browser will think it is dealing with several websites, and will download more elements simultaneously. Associating 3 domain names to the medias, to continue the previous example, reduces the loading time from 3 to 1 second.
Let us go back to the beginning: we talked about NGINX webservers, without explaining their role. Thanks to the Varnish installed on these and on the media servers, there are only a few requests left to treat: the ones needing a PHP interpretation. It corresponds to the elements of the page that can change depending on the users: state of the connection, of the basket, etc.
It does not mean that the rest of the website is not dynamic: to handle dynamic content, such as personnalization for instance (emphasis of a product, etc.), one can use ESI and AJAX. However, the structure of the page itself does not change.
There are also Tomcat servers on this first layer. They host the SolR service, which is a search engine. Indeed, the frameworks’ native research usually sends a lot of requests to the database, which (as we saw in the introduction) jeopardizes the performances. The externalization of this service, thanks to SolR, enables to optimize those performances. The content, given by the framework, is indexed by SolR and stored in RAM: the search is thus much quicker, and does not require any connection to the database.
We saw that the first layer handled the static elements of the website. To serve dynamic elements needing a PHP interpretation, the NGINX frontal servers send requests to the second layer: the PHP-FPM servers. They get most of the load, since PHP requests are the heavier ones to treat: thus, the website’s scalability is handled at this lever. It is indeed possible to install as many PHP-FPM servers as needed to efficiently serve all website visitors.
The best practice consists in having dedicated servers for the sales channel and checkout, and others dedicated to the rest of the website. Thus, if the latter fall (because of an overload for instance), the clients that are already engaged in the sales channel can end their purchases without suffering any slowdown or unavailability. In the same way, if a client goes directly to their basket without going through the home page, it will be accessible! This configuration allows to limit the losses if there is a problem.
Just like in every infrastructure, after all this come the bastions. At NBS System, they are mutualized on the server handling the administration, but if you have some budget, it is better to have a specific bastion.
The first use of these servers is to administrate the website: on this server, the client has access to their back office. A bastion is a unique entry point for a client, from which they can access the other servers through a SFTP or SSH connection.
The bastions can have several complementary uses:
- File replication: the client can, for instance, drop off source files that will be replicated on all of the servers of their architecture.
- Log consultation: the hosting company has to give the client access to his or her logs, through these servers
- Code deployment: code deployment tools (Git, Capistrano, etc.) can be dealt with from the bastions.
- Business applications
- Cron tasks: these planned tasks are also handled from this layer.
To sum up, on these bastions are installed all the services which the client can directly influence.
Then come the underlying services, which can also be found in every infrastructure. This layer is made firstly of MySQL database servers, a least a master and a replica. The master handles the writing requests, while the replica handles the reading ones : this configuration provides increased performances. In a redundant infrastructure, like it is presented on our schema, these servers can be doubled (fail-over): thus, if the master or its replica fall, it is still possible to separate the readings and writings on two different servers, rather than put everything on the same server (degraded mode, implying a loss in performances).
In addition of these MySQL servers, there are Redis servers on this layer. Redis is a tool allowing to handle the applicative cache, and the sessions generated by the application, among other specifics. There again, it limits the calls to the database… And if the servers have been separated according to their use at the global level of the architecture, it is also a best practice to adopt at a smaller level: having a Redis instance per use (one for the cache, one for the sessions, one for the full page cache in the case of Magento for instance) enables to optimize performances. Indeed, Redis is mono-threaded: separating the instances allow for instance to have access to sessions, even if Redis blocks at the cache level.
Advantages of this architecture
Like we just said, this architecture has the particularity to use a different server for each use. This provides the client with a certain freedom, they understand and know the use of each of these servers, but not only. This task separation enables a better troubleshooting, and a better resource management: one can add some resources exactly where they are needed! Indeed, on a server containing, for instance, both the frontal servers and the PHP treatment service, there is no way to tell the machine that such resource has to be dedicated to such service. With the architecture we present to you, this problem is dealt with!
Moreover, it is optimized to the fullest: in the case of a traffic increase, one only has to add PHP-FPM servers to swell the website’s capacity. Indeed, all the rest is already ready to welcome as many visitors as needed, so all one needs to do is to add computing power ! To add servers, NBS System uses ETCs (Extends to Cloud): they are dormant servers, that can be activated on demand in a few minutes, for maximal reactivity.
Thus, this architecture is, according to our experts, an ideal infrastructure for an e-commerce website: it is scalable, efficient and understandable by the client. The cost of this architecture might look high, but on the long term it is worth it: as we said, one only needs to add ETCs in order to increase the website’s capacities.
If you want to know more, feel free to contact us!
Source: Julien Khamis