Our experience using AWS at launch

    Our task was to ensure the smooth operation of Staply , minimizing costs, while maintaining the flexibility and simplicity of the architecture.
    In this article, we will tell you which server configuration we use during the transition from closed beta to open use. The period when the issue of value is most acute, as there is a load, but there is still no profit. The lack of materials on the period of average loads and the request for synck prompted the writing of this article. Our results:

    • The service handled the load: the "popular" section on HackerNews, Habr and ProductHunt
    • The peak load during these periods was in the region> 400rps, lasting ~ 5 hours.
    • maximum ~ 10 registrations per minute.
    • NewRelic Availability: 96.092% in the last three months and 99.991% in February

    Since the beginning of development, we have used Amazon AWS E2, which allows us to create our own architecture without having to look for ways to bypass hosting restrictions, as is the case with Heroku, while offering extensive cloud solutions.
    To maintain the service in working condition, we tried to avoid a sharp increase in load, gradually increasing traffic, which allowed us to identify bottlenecks in the system and eliminate them in working mode, without emergency situations.

    Amazon recommended

    configuration: Our configuration:
    • t1.micro instance as a balancer (currently, rather, as a router) with Haproxy
    • t1.small and m3.medium instances with nginx passenger and redis
    • S3 file storage
    • RDS m1.small instance with MySql

    Daily bill: ~ 8.21 $

    Attention! Regularly check the detailed invoices, Amazon distributes the payment for many small items of expenses, and the bill for an unused item can be unpleasantly surprising.

    Server configuration

    The service is written in Rails, however, this fact is minimally affected in the article.
    At the beginning of development, one t1.micro instance with swap enabled is sufficient . AWS Free Tier with a free period of use allows cost reduction to zero.

    When the service goes into open access, it is better not to skimp and from the very beginning to lay in the architecture the opportunity to dramatically increase capacities. Distributed multi-server architecture allows you to work with each element separately, without affecting the others (for example, if you need to restart the instance, or increase its power).
    Be sure to use monitoring, a free NewRelic plan will be enough.

    When starting the public version of the project, we launch the second server, m3.medium(1 Intel Xeon CPU, 3.7 GB RAM, magnetic store, configured swappiness).

    Server power was calculated taking into account the configuration of the Rails application:
    • Ruby 2.1.0
    • Nginx + Passenger 4
    • Each thread consumes ~ 200mb of memory.

    For convenient routing of requests between development and production servers, we used one t1.micro instance with Haproxy installed and configured SSL termination .
    The use of Private IP , instead of Public in the Haproxy configuration, can significantly reduce the delay between servers .

    Do not be afraid of premature optimization, now is the right time for her. Each identified bottleneck in the service code, each reduction in response time by hundredths of a second will allow you to support more customers and save. Pay maximum attention to the cycles in the code, in our case, the greatest potential for optimization was in them. Taking out all the excess beyond the limits of cycles, we reduced the response time by dozens of times. Amazon SES is

    used to send emails . It integrates perfectly with Rails with the Action Mailer and provides a free quota of 10,000 messages / day.


    Files are stored in S3, but you should not use it to store statics (scripts, styles, images), the delay will be greater than when storing files on the instance itself.
    File Access Delay:
    • S3: ~ 280ms - 1.80s
    • CloudFront: ~ 60ms - 200ms

    Enable caching of content from S3 by adding the header {'Cache-Control' => 'max-age = 315576000'}.

    To reduce latency, Amazon suggests using CloudFront, a service that distributes content from S3 to regions.
    CloudFront traffic is cheaper than S3 traffic.


    You can use the same instance for the database as the server, but this increases the connections between the elements and reduces the flexibility of the architecture. For the database, we use the RDS db.m1.small instance with the magnetic store, which allows us not to worry about backups and configuration.
    Starting with the earliest beta version, clients used the service and there was data in the database, the safety of which we had to ensure


    It is necessary to take into account the geography of potential customers and the market we want to work in: The whole world can be immediately covered, but the network delay will be serious.
    All elements of architecture must be in the same region.

    Download speed between regions:

    In practice, the delay from St. Petersburg to servers in the US-EAST region can be 6 times greater than when requesting to EU-WEST servers.

    Building a simple and modular architecture from the very beginning will lay a high potential for smooth growth and transition to high loads.

    We are glad to hear your advice and comments, feedback from the Habré has helped us to seriously improve many of the points in our service.

    Resources used:

    Also popular now: