Airi - the cloud for the site

Recently, we launched a new service - a cloud for the site, iri.org . The cloud for a site is when the whole site is light, transparent, airy and fast. No pictures, scripts, complex server logic, databases and no DDoS can drop it. This is when the site flies. We have realized our dream - now any site, regardless of the platform, internal features or client logic, can be put into the cloud. And it will work faster and more reliably on all devices and for all users. And it is available for both the smallest sites, and for the largest.

Yes, it looks like western CloudFlare. And we have the same original model. But only in the open spaces of Russia, according to its geography. And we plan to develop differently.

PS Now Airi is in beta stage, we are actively recruiting the first users , although the service has already moved into commercial operation, and reliability is a priority.
')

Architecture

Initially, we planned to make several components of the service, maximally dividing the levels of responsibility. But later, due to various restrictions on data integrity and system resiliency, we got to the following architecture:

The entire service is divided into geographically independent nodes, users are directed to a particular node, depending on the IP address and DNS record. DNS records are geo-balanced (if any node fails, we can redirect local users to another node for a short period of time).

1. DNS layer. Each node is a pair of servers configured with LVS for maximum resiliency. Additionally, zones on different DNS servers respond differently for different regions, creating geo-balancing.
2. Balancing Layer (LVS). The main machines that take on all the load. They are also intended to connect to DDoS protection and redistribute requests to different FEO-CDN servers, depending on the site domain.
3. FEO-CDN layer (from Front-End Optimization and Content Delivery Network). Each node is a caching and optimizing cluster of proxy servers. Over the architecture of this layer, we thought for a long time, and we continue to think about how to optimize as much as possible the work of the site and the load on the servers. Currently we have 4 levels of caching and proxying:
   
   1. Front-end level, only compresses (via gzip) content and caches the final HTML pages of the site, if necessary. If the query is not in the cache, then proxy them further. Collects statistics on the given content.
   2. Optimizing level. Page Speed ​​is deployed here with some of our improvements in deferred loading and dynamic page caching. The most difficult level in terms of the algorithms used. All non-cache requests are sent to a lower level.
   3. Caching level Caches all static and, if possible, dynamic. Returns everything from the cache, if it can. If not, it requests the source site. It also logs low-level queries and provides unpacking (unzip) of data from the source site.

Balancing and failover

During the implementation, we considered several failure scenarios of the service (or site). I will give some basic ones:

1. The DNS layer of a host fails - the second one of the LVS pair is connected. If both servers fail, then DNS queries (exactly the same content) begin to respond to the DNS layers of the other nodes.
2. Both servers fail to LVS-pair balancing layer of any node. In this case, requests for DNS balancing are automatically sent to other nodes.
3. Fails (overloaded) FEO-CDN layer - automatically connect additional spare servers on this layer. If there are no servers available, then we act according to the previous scenario - we transfer sites to another node.
4. The channel (DDoS) is overloaded on one or several nodes - we automatically connect QRator for “problem” balancing layers.
5. Source site fails (becomes unavailable). If the site is cached and the period of inaccessibility is less than the lifetime of the cache, then users do not notice anything. If the period of unavailability is less than a day, then we continue to issue the site pages from the cache. For dynamic sites, an individual policy (stub pages, cached content, or redirection).

The main problem areas and risks are eliminated by the architecture, so we can talk about fault tolerance of 99.9%.

How acceleration works

The most difficult and interesting is how acceleration works. We analyzed the available Page Speed ​​filters, collected several options from them that are suitable for most sites. And they called the acceleration levels accordingly: Safe (when no harm is guaranteed to the site), Minimal (when there are minimal risks to harm the site), Optimal (suitable for most sites, provides significant acceleration, but potentially dangerous) and Maximum (the most risky and the most effective option). In addition, we also offer manual configuration of all parameters, if necessary (in full accordance with the existing policy of setting up our product - WEBO Site SpeedUp ).

I emphasize that by default all static site objects are permanently cached, and all text objects are reliably archived. In addition, file merging, inclusion of small objects in page content, delayed loading logic and Local Storage, as well as the use of multiple domains and data: URI for images are available. In general, full stuffing for those who want to customize everything. And a guaranteed level of speed and reliability of the site for everyone else.

In conjunction with geo-balancing requests (site visitors receive site objects from the server closest to them), we solve all problems with the site speed “in one click”.

Tariffs

We are as friendly as possible to users - and we offer tariffs from free (included 50 GB of outgoing traffic per month) to maximum (from 50 thousand rubles). The average site can connect for 1000-2000 rubles per month (this includes 100-250 GB of traffic per month, up to 100 thousand users per month is enough).

Connection

There are two main types of connections: through changing DNS servers and via CNAME, a synonym for www. In the first case, we connect domains that are accessible only without www (for example, iri.rf) - you need to delegate the domain to our servers so that we can fully manage geo-balancing.

The second type of connection is suitable for sites that are accessible only through www or both. In the latter case, you need to redirect from the site without www to the site with www and create a DNS record for the site

  www IN CNAME cloud.airee.ru. 

After that, the site will be served through the cloud.

Of course, all these actions need to be performed after sending the application . We do not serve all domains of the Runet yet :)

In the very near future, a personal account will appear for managing the cloud.

I will be glad to questions and comments. Our goal is to make Airi a de facto standard when hosting websites on the Runet.