Как улучшить производительность сайта в 8 раз: наш опыт интеграции сервисов AWS

Аутсорсинговая компания по разработке ПО AgiliWay совместно с компанией-дистрибьютором Softprom by ERC поставили и внедрили сервисы AWS в ROI4CIO и повысили производительность сайта в 8 раз.

Даты проекта


28.09.2017 – 18.10.2017: подбор оптимальной конфигурации сервера, подбор оптимальных сервисов на AWS и полный переход на AWS, включая доменное имя.

Проблема


Сервис, использовавшийся на сайте до внедрения AWS, не выдерживал работу с «тяжелым» функционалом, в частности, необходимость обработки большого количества информации. В результате при определенном количестве пользователей показатели CPU и RAM сервера поднимались до 100% и в работе сайта происходил сбой.

Результат


Благодаря использованию сервера и сервисов AWS, нагрузка на сайт и базу данных уменьшилась в 2 раза, сайт выдерживает в несколько раз большее количество одновременно присутствующих пользователей. Производительность сайта удалось увеличить в 8 раз, при этом стоимость владения им выросла всего в 2 раза.

ROI — 800%

Проблема


«Команда столкнулась с проблемой недостатка производительности сайта. Во время тестирования при одновременном подключении определенного количества пользователей задержка отклика была больше 10 секунд. При увеличении нагрузки база не выдерживала, сервис „отказывался“ работать.»
Олег Пицык, Архитектор ИТ-систем ROI4CIO, Agiliway.

Решение


До принятия решения о внедрении сервисов AWS для проекта ROI4CIO, было проведено тестирование возможного размещения на другом облачном ресурсе. Анализировались AWS, Vultr, goDaddy, Linode и другие. Сравнительные результаты тестирования показали однозначное преимущество сервисов AWS.

Архитектура ROI4CIO до AWS
image

В результате взаимодействия Softprom by ERC совместно с Agiliway разработали оптимальное решение для улучшения производительности сайта. Представители Agiliway, как разработчика и архитектора систем ROI4CIO, занимались настройкой сервера приложений и базы. Softprom by ERC выступал как поставщик платформ AWS и в роли консультанта по функциональному использованию сервисов AWS. Кроме того, сотрудники Softprom by ERC занимались настройкой мониторинга, уведомлений и автоматизации Lambda.

Домен сайта разместили в Amazon Route 53. Это высокодоступный и масштабируемый облачный веб-сервис системы доменных имен (DNS).

Для обеспечения комплексной защиты от всех известных инфраструктурных атак (уровень 3 и 4) использовали систему анти DDoS AWS Shield.

Для оптимизации нагрузок, требующих больших вычислительных мощностей, использовали виртуальный сервер EC2 типа C4, а также настроили auto scaling ресурсов и балансировку входящей нагрузки на сервер. В моменты пиковой загруженности сайта вычислительные ресурсы автоматически масштабируются, что позволяет выдержать практически любую нагрузку.

С целью повышения надежности и отказоустойчивости, а также уменьшения затрат на администрирование, для размещения базы данных был выбран сервис баз данных Amazon Relational Database Service, выполняющий функции выделения аппаратного обеспечения, настройки базы данных, установки исправлений и резервного копирования.

Для повышения скорости работы сайта был также использован ElastiCashe — веб-сервис, упрощающий развертывание и масштабирование в облаке хранилища или кэша памяти, а также управление ими.

С помощью сервиса AWS CloudWatch был настроен расширенный мониторинг приложения и базы данных. Создавая различные правила, администратор сразу же получает sms-уведомление на мобильный и на e-mail в случае возникновения любой непредвиденной ситуации. Для реализации функции отправки сообщений в CloudWatch был интегрирoван сервис уведомлений AWS SNS (simple notification service). Помимо отправки сообщений, при определенных обстоятельствах срабатывают триггеры, которые активируют функции автоматизации, реализованные с помощью сервиса бессерверных вычислений AWS Lambda.

Бекапы базы данных и сервера приложений автоматически создаются по расписанию и сохраняются в облачном хранилище AWS S3.

Обновленный вариант архитектуры
image

«В основном все усилия были направлены на повышение производительности. Но также немало внимания уделили отказоустойчивости и резервному копированию. По цифрам, наверное, можно выделить еще пропускную способность дискового хранилища базы (IOPS). Использовали диск с повышенной пропускной способностью Provisioned IOPS. На каждый инстанс БД может быть выделено до 40 000 IOPS.»
Влад Гавриленко, ИТ директор Softprom by ERC.

«Перенесли сервер очень быстро, буквально за 2 дня. Потом занимались настройкой сервисов. Это заняло около недели»
Влад Гавриленко, ИТ директор Softprom by ERC.

Результат


Благодаря внедрению сервисов AWS, команда обеспечила восьмикратное увеличение производительности ресурса и одновременную автоматизацию трудоемких задач администрирования. При этом стоимость владения выросла всего вдвое. После исправления кода запросов и внедрения всех сервисов сайт сохраняет непрерывную и стабильную работоспособность даже при высоком уровне нагрузок.
ROI4CIO
80,00
Сервисы для покупателей и продавцов ИТ.
Поделиться публикацией

Комментарии 27

    +3
    Каким образом изменение хостинга привело к увеличению количества одновременных пользователей на сайте?

    У меня только одна версия: прошлый хостинг был настолько плох, что его Гугл понизил в выдаче.
      0
      Время ответа увеличилось -> Гугл поднял в выдаче.
        0
        Всё же скорее уменьшилось.
          0
          Да, я написал криво, простите :(
        0
        Спасибо за вопрос. Эта фраза была про нагрузку. Проблема первоначальная была в том, что при определенном количестве пользователей показатели CPU и RAM сервера поднимались до 100% и в работе сайта происходил сбой. Решение описано в ответах на другие комментарии и тексте. Но если про пользователей. Для тестирования нагрузки использовалась программа Apache Jmeter. Тестирование проводилось с разным количеством юзеров (Threads) примерно от 10 до 1000. Под них, соответственно до поставленных задач, настраивалась (Ramp-Up Period) от 10 к 1000 секундам, чтобы обеспечить тест на уровне “1 пользователь в 1 секунду”, иногда для больших нагрузок использовали меньше времени, и количество циклов Loop Count.
        0
        Блин, вот AWS по стоимости хостинга нифига не дешёвый, сервисы тоже у них настроены не на производительность, а на стабильность.
        Это судя по всему раньше был просто ужасный дорого хостинг.
        Или ключевое «Потом занимались настройкой сервисов. Это заняло около недели»
        Если бы настроили нормально сервисы на старой платфформе — думаю, что производительность тоже выросла бы
          0
          Нам и стабильность была нужна. Сначала анализировались AWS, Vultr, goDaddy, Linode и другие. Наш выбор пал как раз на AWS, и мы делимся своим опытом. Наш предыдущий провайдер, как и другие облачные хостеры, не дает возможности реализации сложного проекта ввиду отсутствия сервисов или их аналогов таких как AWS RDS, ELB, ASG. Покупка и реализация таких возможностей на «своём железе» заняла бы огромное количество человеко-часов и требовала бы постоянной поддержки, чего не требуется в случае с AWS. Поэтому изначально просто перевели сайт на AWS, без каких-либо сервисов.
          +1
          Больше тегов.
          AWS не панацея, особенно в России. К примеру ресурс unsplash использует AWS.
          С недавнего времени третий сегмент AWS стал недоступен у большинства провайдеров. Т.к. на одном из ресурсов, AWS содержал запрещенный в РФ материал. Соответсвено под раздачу попало множество ресурсов, которые использовали данный AWS.
            0
            Мы согласны, что в целом можно использовать другие хостинги, но мы выбрали AWS для управленческого звена конфигурации проекта и в целом делимся своим опытом и хотим показать, что существует возможность использования данных сервисов для решения подобных проблем. Проект международный и хостинги изначально рассматривались в Европе.
            +4
            Что это за мусор я только-что пролистал?
              +4
              Интересно ROI люди считают. Делят флопсы на деньги, впаяв бизнесу двойные прямые расходы и замену хостера. Современные economics, success story и cloud :)
                0
                У нас ресурс рассчитывает ROI, учитывая параметры пользователя ИТ-продуктов и характеристики продукта. Можете попробовать на примере популярного продукта Microsoft Office 365
                Так рассчитывался ROI и этого внедрения.
                +3
                Имел бы право — заминусовал бы статью… Кроме сухого текста, в которой ни грама инфографики, больше ничего нет…
                Такое ощущение, что статья не для жителей хабра, а для заказчика из мухосранска…
                  0
                  Спасибо за акцентирование внимания, вы абсолютно правы. Мы добавили инфографику архитектуры “до” и обновленный вариант, можете посмотреть в тексте и в развернутом ответе на другой вопрос, чтобы не повторяться. Еще раз спасибо.
                  0
                  В плане производительности основное техническое решение было, как я понял, дать больше ресурсов? У старого хостера уперлись в потолок вертикального масштабирования, который у него был ниже? Или основным стало создание кеша для тяжёлых запросов? Или сделали горизонтальное масштабирование?
                    0
                    В потолок мы не уперлись. Нам просто необходимо было кеш, базу вынести с локального инстанса и настроить лоад балансер, на котором мы держим наш SSL сертификат, соответственно это все дает выигрыш по перфоменсу и масштабируемости.
                      0

                      Ну 100% загрузки процессора — это потолок, хотя бы в рамках текущего тарифного плана хостера.


                      Ну, тогда именно AWS и даже облака в целом, особого прироста производительности не дали. Разделяемый кэш на отдельной ноде или даже кластере, разделяемая база на отдельной ноде или кластере, кластер апп-серверов (желательно stateless или soft state) с балансировщиком — стандартные пути горизонтального масштабирования, хоть в облаке, хоть на базе своего парка железных серверов.

                    0

                    Тем не более, несмотря на крайне паршивый контент и кучу негативных отзывов — 1.7 к просмотров.

                      0
                      Именно поэтому этот кАнтент тут и оказался. Диалектика.
                        0
                        Большинство зашло посмотреть «что за ужас был раньше, если удалось так поднять скорость».
                        +1
                        Не хабровский какой-то пост получился. Никакой конкретики.
                        Какие сервисы крутятся на серверах (почта, базы данных, Java, PHP, nodeJS, это вообще Web или кокой-то REST)?
                        Сколько и каких серверов использовалось до и после?
                        В каких попугаях мерили нагрузку до и после? CPU — весьма неоднозначный показатель особенно если было 100%?
                        Почему если бюджет вырос вдвое нельзя было добавить пару серверов в изначальную конфигурацию?
                        Какая она была изначально? Другой не облачный хостер? Или серверная комната? Канал в сеть какой был?
                        Почти ни один технический аспект не освещен, не удивительно, что народ минусует.
                        Даже если поменять заголовок на: «Как мы переехали на AWS» и то ничего не понятно. Что уж говорить про «улучшить производительность сайта в 8 раз»
                          0
                          Да, вы правы, этот пост больше про организации и настройки сервисов на AWS для нормальной работы веб-сайта.
                          Если углубиться в конкретику, то изначально сайт был на VPS от другого провайдера (не будем называть с кого переходили, чтобы не создавать антирекламу) и имел такую конфигурацию: 2 vCPU, 4096mb RAM, 60gb SSD, 3GB/s bandwidth. Наш предыдущий провайдер, как и другие облачные хостеры, не дает возможности реализации сложного проекта ввиду отсутствия сервисов или их аналогов таких как AWS RDS, ELB, ASG. Покупка и реализация таких возможностей на «своём железе» заняла бы огромное количество человеко-часов и требовала бы постоянной поддержки, чего не требуется в случае с AWS. Поэтому изначально просто перевели сайт на AWS, без каких-либо сервисов. Вариант реализации этой серверной архитектуры изображён на рис.
                          image
                          Но в силу масштабирования проекта и увеличения функционала было принято решение во избежание рисков перейти на более надежный хостинг, который легко позволяет настраивать нужные сервисы и легок в администрировании. Тем более в современном мире, где любой «дурак» может без особых усилий устроить тебе DDos-атаку при помощи разных веб-инструментов. Поэтому выбрали AWS, где на серверах крутится PHP, почтовик, nodeJS и REST.
                          Для тестирования нагрузки использовалась программа Apache Jmeter. Тестирование проводилось с разным количеством юзеров (Threads) примерно от 10 до 1000. Под них, соответственно до поставленных задач, настраивалась (Ramp-Up Period) от 10 к 1000 секундам, чтобы обеспечить тест на уровне “1 пользователь в 1 секунду”, иногда для больших нагрузок использовали меньше времени, и количество циклов Loop Count.
                          По результатам тестирования был проделан ряд работ, как по оптимизации проекта, так и по конфигурации серверов. А именно: разделение сложного функционала на разные микро сервисы, каждый из которых находится в своем AWS-контейнере, настроено auto scaling group, DB read replics, Elastic Cashe, медиа-контент был вынесен на S3.
                          Из сложного функционала у нас калькуляторы. ROI-калькулятор и калькулятор цены ИТ-продуктов. Примеры можно посмотреть по ссылкам, чтобы было нагляднее (на ссылках даны примеры расчета цены и ROI конкретных продуктов, а такие расчеты возможны абсолютно для всех без исключения решений и продуктов, даже самых сложных). Именно такие расчеты при одновременном использовании определенном количеством пользователей ранее тормозили работу сервиса.
                          Обновленный вариант архитектуры
                          image
                            +1
                            Спасибо за ответ. Но он все еще недостаточно «технический» :-) Перечитайте мой вопрос снова и найдите конкретный ответ на каждый, заданный мной изначально вопрос. Я не смог найти ответ практически ни на один из заданных. Кроме подтверждения того что переезд был с одного из необлачных хостеров на AWS. Но далее — туман… никаких попугаев «до» и «после». Изначально: 2 vCPU, 4096mb RAM, 60gb SSD, 3GB/s bandwidth. Памяти маловато почти для любой задачи. Соединение в сеть — возможно не испрользовалось и на 10% а возможно на 100% — опять нет конкретики. После переезда — упало до 10%? или до 90%? а CPU? В целом статья читается как ракламный проспект и возможно для не специалистов вполне «звучит». Предоставленные разъяснения тоже носят хоть и более технический и «архитектурный» характер все же не дает ответа на то как и почему AWS «улучшить производительность сайта в 8 раз». А скорее просто говорит: обращайтесь к нам и будет вам счастье!
                              0
                              Спасибо за ваши вопросы. Мы постараемся на все ответить.
                              В начале на одном сервере было все Apcahe, PHP версия 5.6 (уже перешли на 7), MariaDB, почта и также кэш локально хранили. Теперь на AWS все разнесли.

                              Сначала использовался сервер 2 vCPU, 4096mb RAM, 60gb SSD, 3GB/s bandwidth, после переезда на AWS используем c4.xlarge (конфигурацию можно посмотреть на сайте AWS)

                              Выводы касательно нагрузки делали по времени по таким показателям (Load Time, First Byte, Start Render, Response time и также по пропускной способности выполняемых запросов). С переходам на AWS мы вынесли SSL сертификат на ELB, что сократило время получения First Byte на 0,5 сек. Вынесли медиа-контент на EFS, чтобы нормально отрабатывал автоскелинг и вынесли кэш на AWS Elastic Cache. Также, благодаря RDS, где настроили несколько Read Replica, увеличилась пропускная способность запросов к БД, количество одновременных конекшенов в БД. Так при старом хостере при тестировании 100 человек с интервалом 10 секунд, 10 чел/сек – сайт падал. Новый спокойно выдерживает тестирование 500 человек с интервалом 10 секунд, 50 чел/сек.

                              К вашей заметке “обращайтесь к нам и будет вам счастье!” — счастье всем, мы надеемся, будет :) Но если вдруг эта статья похожа на рекламу AWS, то это совершенно не так. Наш ресурс не продает ни продукты, ни услуги по интеграции. Мы для покупателей ИТ вообще работаем бесплатно. И пока мы на стадии бета-тестирования — для поставщиков ИТ тоже. Мы — площадка, которая помогает поставщикам, покупателям и производителям найти друг друга на наиболее выгодных и быстрых для всех условиях. Сами AWS купили, интегрировали другие. Мы поделились тем, что нам помогло, т.к. это и слоган проекта “Узнайте пользу ИТ” — стараемся придерживаться, узнавать и другим рассказывать, в данном случае на собственном примере.

                              Кстати, мы очень заинтересованы в таких тестерах как Вы. Вам было бы интересно взглянуть на весь проект и дать свои комментарии? Воспользоваться теми функциями, которые могут быть вам интересны. Еще раз напомним, мы на стадии бета-тестирования, поэтому это очень актуально для нас. Вот проект
                                0
                                Хотел ответить развернуто снова. Но затем перечитал последний абзац. Может мне показалось но
                                «Кстати, мы очень заинтересованы в таких тестерах как Вы.»
                                думал это комплимент. Типа я дотошный в хорошем смысле слова и вам нужна профессиональная помощь.
                                «Вам было бы интересно взглянуть на весь проект и дать свои комментарии?»
                                хотел ответить «да». Но затем вчитался:
                                «Воспользоваться теми функциями, которые могут быть вам интересны.»
                                Опять какая то реклама каких то гипотетических но весьма полезных и очень полезных не только мне, но видимо ВСЕМ «функций».
                                «Еще раз напомним, мы на стадии бета-тестирования, поэтому это очень актуально для нас. Вот проект»
                                на секунду показалось, что вам таки нужен совет и мое мнение. Но пройдя по ссылке которая ведет на ваш сайт, а не на какой не проект, понял что вы супер маркетологи. Хабра минус, Хабра плюс — вам без разницы! Ссылочная масса растет, ключевые слова на месте. SEO работает, а все остальное по боку! Молодцы!
                                  0
                                  Спасибо Вам за Ваши ответы.
                                  «думал это комплимент. Типа я дотошный в хорошем смысле слова и вам нужна профессиональная помощь.» — Вы все правильно поняли, нам важно мнение и комментарии о проекте, тем более от таких внимательных, как Вы.
                                  Если фичи, предлагаемые проектом, не пересекаются с вашии профессиональными интересами — Вы можете дать общее мнение о восприятии вами проекта, о чем он даже. Если Вам будет это интересно.
                                  У нас есть проблема, из-за первых страниц сайта многие воспринимают проект как маркет плейс, но это не так.
                                  «что вам таки нужен совет и мое мнение.» — он-таки нужен :) И если вы поделитесь им — будем благодарны.
                                  «Но пройдя по ссылке которая ведет на ваш сайт, а не на какой не проект» — это сайт проекта. Вот здесь и хотелось бы узнать подробнее, что именно вас смутило и вызвало реакцию, «что это не проект». — будем благодарны.
                                  «понял что вы супер маркетологи.» — вот это настоящий комплимент, потому что маркетологов у нас еще нет, да и PR мы еще не занимаемся, и ссылочная масса не столько важна, мы готовим проект к этому, нам сейчас важно пройти стадию бета-тестирования, услышать мнения о проекте и сделать его лучше прежде чем двигать проект в массы.
                                  Эта статья была с целью поеделиться своим опытом. С нашим потенциальным пиаром она не пересекается, так как проект международный и наша основная целевая аудитория — это западный рынок. Спасибо.
                          0
                          Нас действительно масштабно заминусовали за эту статью. Благодарим за все вопросы, как конструктивную критику. Мы готовы максимально ответить на все вопросы, которые у Вас возникают. Благодаря Вашим комментариям мы обратили внимание на несовершенство статьи и дополним ее деталями, которые Вас интересовали. Спасибо за все вопросы.
                          Эта статья про наш опыт преодоления разных проблем, которые исторически сложились при разработке проекта, и возможность их решить, на наш взгляд, не самым плохим образом, — это переездом на AWS. Плюс в статье на собственном примере мы раскрыли ключевые возможности ресурса — это взаимодействия между Производителем в данном примере AWS и дистрибьютором, а также возможность расчета выгоды (roi), что в нашем случае принесло нам выигрыш по деньгам и по времени разработки.

                          Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                          Самое читаемое