Airi — cloud website


We have recently launched a new service — cloud for the site, Airi.Russian. Cloud for the site — this is when the whole site is light, transparent, airy and fast. No images, scripts, complex server-side logic, databases, and no DDoS can't get it down. This is when the website is flying. We realize their dream — now any site regardless of platform, internal characteristics or logic of the client can be put in the cloud. And he will work faster and more reliable on all devices and for all users. And it's available for both the smaller sites and for the largest.

Yes, it is similar to Western CloudFlare. And the original model is the same. But only on the expanses of Russia, according to its geography. And evolve we plan differently.

P. S. at the moment Irie is in beta stage, we actively recruit the first users, although the service has already moved into commercial operation, and reliability is a priority.


the

Architecture


Originally we planned to make several components of the service, the maximum splitting levels of responsibility. But later, due to various kinds of restrictions on data integrity and fault tolerance of the system, we came to the following architecture:

The whole service is divided into geographically independent sites, users are directed to a particular node depending on the IP addresses and DNS records. DNS records of geo-balanced (in case of failure of any node we for a short period of time can redirect local users to another node).
    the
  1. Layer DNS. Each node is a pair of servers configured with LVS for maximum fault tolerance. Further zone on different DNS servers respond differently to different regions, creating a geo-balancing.
  2. the
  3. Layer load balancer (LVS). The basic machines that take the entire load. They are intended to connect to the DDoS protection and the distribution of queries at various FEO-CDN servers depending on the domain of the website.
  4. the
  5. FEO-CDN layer (Front-End Optimization and Content Delivery Network). Each node is a caching and optimizing cluster of proxy servers. The architecture of this layer we thought long and continue to think about how to optimize and the operation of the site, and the load on the server. At the moment we have 4 levels of caching and proxying:
      the
    1. Front-end level, it only compresses (using gzip) the content and caches the final HTML page sites if needed. If query is not in the cache, then proxy them on. Collects statistics on the given content.
    2. the
    3. Optimization level. There is a Page Speed with some of our improvements in the part of the lazy loading and caching dynamic pages. The most difficult level from the point of view of the algorithms. All requests not from the cache are sent to the level below.
    4. the
    5. the Caching level. Caches the entire statics and dynamics. Gives everything from the cache if it can. If not — asks the original site. Also classifies low-level queries, and provides the decompress (unzip) the data from the source site.


the

Balancing and failover


During the implementation we considered several scenarios of denial of service (or website). Bring some of the highlights:
    the
  1. Failing DNS layer of any node connects the second of the LVS-pair. If you deny both servers, then DNS queries (with exactly the same content) begins to respond to DNS layers of other nodes.
  2. the
  3. Denied both servers LVS-a pair of balancing layer of any node. In this case, due to a DNS balancing, requests are automatically routed to other nodes.
  4. the
  5. Deny (overloaded) FEO-CDN layer — automatically connect extra spare servers in this layer. If no servers are, then act according to the previous scenario, we set the sites to another host.
  6. the
  7. Original site goes down (becomes unavailable). If the site is cached and the period of unavailability is less than the lifetime of the cache, users will notice nothing. If the period of unavailability for less than a day, continue to issue page from the cache. For dynamic sites — individual policy (parked page, the cached content or redirect).

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

How does acceleration


The most difficult and interesting — how does the acceleration. We analyzed the available filters, Page Speed, and gathered from them a few options suitable for most sites. And called levels of acceleration accordingly: Secure (when any harm to the website is guaranteed not to be caused by), Minimum (when there is minimal risk of harm to the website), Optimal (suitable for most sites, provides significant acceleration, but potentially dangerous) and the Maximum (most risky and the most effective option). In addition, we offers and manual setting of all parameters, if necessary (in full compliance with the existing policy of customization of our product — WEBO Site SpeedUp).

Let me emphasize that by default, all static objects of the website are cached for a long time, and all the text is securely archived. In addition, is available to merge the files, the inclusion of small objects in the content of the pages, the logic of lazy loading and Local Storage, and the use of multiple domains and data:URI for images. In General, the complete beef 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 of requests (website visitors get the site objects from the closest server to it) we solve all problems with site speed "one-click".

the

Rates


We came as friendly to the users and proposed rates free (included 50 GB in a month) to the maximum (50 thousand rubles). The average website can connect 1000-2000 rubles per month (this includes 100-250 GB of traffic per month, enough to 100 thousand users per month).

the

Connect


There are two basic kinds of connection: by changing DNS servers and CNAME using a synonym www. In the first case, we connect the domains that only available without the www (e.g., Irie.RF) — to delegate the domain to our servers so we can fully manage your geo-balancing.

The second type of connection is suitable for sites that are only available via www or both. In the latter case, it is necessary to make the redirect site without www to the site with www and create a DNS entry for the site
the
www IN CNAME cloud.airee.ru.

The site will be served via the cloud.

Of course, all these steps must be completed before after submitting. We don't serve all domains of the Russian Internet :)

In the near future will appear and a personal account for cloud management.

I will be glad to questions and comments. Our goal is to make Irie de-facto standard when placing sites.
Article based on information from habrahabr.ru

Комментарии

Популярные сообщения из этого блога

Automatically create Liquibase migrations for PostgreSQL

Vkontakte sync with address book for iPhone. How it was done

What part of the archived web