Здравствуйте, с вами Flops.ru и сегодня мы расскажем о результатах переноса довольно большого и нагруженного проекта в наше облачное окружение. Проект о котором идет речь — линейка адблок-приложений Adguard, разработчики которой любезно поучаствовали в подготовке этой статьи.
В статье мы расскажем о виртуальной инфраструктуре проекта, результатах переноса в облако, а заодно перечислим несколько интересных узких мест и багов, которые удалось обнаружить благодаря миграции. И заодно дадим некоторое количество графиков, иллюстрирующих работу проекта. В общем, приглашаем под кат.
Краткие характеристики проекта
Трафик в час пик — 200-250 Мбит в секунду. суммарный объем памяти всех виртуальных серверов проекта — 70 Гб. Суммарное пиковое потребление CPU — в районе 8 процессорных ядер Xeon 2620. До переезда проект жил на 8 виртуальных машинах, которые располагались на 2 физических серверах. При миграции было принято решение вынести наиболее нагруженные приложения на отдельные серверы (один сервер — одно приложение), и количество машин увеличилось до 12:
- 2 build-сервера с ОС Windows
- 3 нагруженных сервера с бэкэндами для клиентских приложений
- 1 сервер баз данных
- 1 сервер с всевозможными фронтэндами
- 1 Windows сервер с бухгалтерией компании
- 1 сервер тестового окружения
- 3 слабо нагруженных сервера различного назначения (форум, тикеты, багтрекер и прочее)
Поскольку мы поддерживаем и Linux, и Windows, смигрировать удалось все без исключения машины. Мы не будем подробно останавливаться на самом переезде — он прошел без неожиданностей, и вместо этого расскажем об интересных аспектах, которые привлекли внимание после переезда.
Хотя нагрузка, создаваемая проектом, далека от совсем уж экстремального хайлоада, они тем не менее достаточно высока и затрагивает все подсистемы — от сетевого стека до системы хранения данных.
Публичная и локальная сеть
Начнем с сетевого стека. Продуктовый ряд клиента состоит из нескольких десктопных приложений, которые периодически ходят на бэкэнд-серверы за обновлениями и новыми базами. Каждый продукт линейки обслуживается собственным бэкэндом, расположенным на отдельном виртуальном сервере. Поскольку клиентов много, то и нагрузку на сеть они генерируют достаточно приличную. Вот так выглядит график потребления трафика одним из бэкэнд-серверов:
Следует отдельно отметить локальную сеть FLOPS, которая используется для коммуникации между серверами клиента.
- Локальная сеть полностью бесплатна, что позволяет использовать ее без оглядки на трафик.
- Пропускная способность — 1 Гбит.
- В отличие от DigitalOcean и Linode локальная сеть FLOPS приватна и может быть использована для организации доверенного окружения.
- Если вы хотите полностью изолировать некоторые виртуальные серверы от внешнего мира, при этом сохранив им доступ в интернет — вы можете это сделать с помощью локальной сети, настроив NAT на другом вашем сервере.
Дисковая подсистема
Единственное приложение, которое активно работает с диском — это база данных Postgres, размещенная на отдельном виртуальном сервере. В базу активно пишутся логи обращений, служебные данные и статистика, что обуславливает высокую интенсивность записи на диск — до 750 iops на запись и до 1500 iops на чтение в пиках.
Обратим внимание, что даже при таких условиях средняя загрузка (Load Average) остается сравнительно небольшой, главным образом благодаря низкому времени отклика дисковой подсистемы, обусловленному использованием SSD:
В отличие от операций чтения, которые хорошо амортизируются различными кешами и далеко не всегда доходят до дисков, каждая запись в базу сопровождается синхронной записью в Write-ahead log (WAL) и упирается во время отклика блочного устройства. Поэтому без использования SSD пиковая производительность была ниже, а LA — выше.
Результаты переноса
Статистика и мониторинг
Хотя клиент имел собственный мониторинг до переезда, наши средства существенно расширили его инструментарий. Кроме того, клиент начал получать сообщения о событиях, происходящих внутри его серверов, например вот таких:
Подробная статистика и возможность переконфигурации сервера «на лету» позволили очень точно настроить необходимые величины потребления ресурсов для каждого сервера.
Более простое обнаружение багов
Статистика помогла отследить ряд трудноуловимых багов, которые ранее были неизвестны или которые не удавалось локализовать. Вот некоторые из них:
Скачкообразный рост CPU
После переноса и анализа графиков выяснилось, что одно из бэкэнд-приложений демонстрировало очень странное поведение — с течением времени потребление CPU скачкообразно росло на целое число ядер:
После очередного скачка выяснилось, что виной всему — очень сложное (и неправильное) регулярное выражение, периодически приводившее к зависанию потоков внутри этого регэкспа со 100% потреблением CPU.
Неоптимальная работа с gzip содержимым
Клиента сильно озадачивала перманентно высокая нагрузка CPU на бэкэнд-серверах. Причина оказалась в том, что gzip-сжатие ответов сервера средствами java при таких объемах трафика требует больших вычислительных ресурсов. Клиент оптимизировал раздачу контента, и дело пошло значительно лучше. Слева и справа — нагрузка на CPU до и после оптимизации.
Резкие скачки трафика во внешней сети
Одно из явлений, на осмысление которого у клиента ушло достаточно много времени — резкие скачки трафика, подобные этому:
Как оказалось, они были связаны с выходами новых версий. Если вы разрабатываете софт и периодически выпускаете к нему апдейты — рекомендуем сразу предусмотреть ситуации, когда ваши клиенты одновременно приходят их качать. Чем больше весит ваш дистрибутив — тем больше вы рискуете упасть в таких ситуациях :)
Минимизация рисков отказов оборудования
Несмотря на то, что до переноса проект обслуживался двумя серверами, каждый из которых мог бы обслуживать проект в одиночку, возможный выход из строя одного из них гарантировал бы простой в десятки минут и испорченные нервы. Перенос в облако снизил зависимость от физического железа.
Ускорение работы БД
Как можно видеть из графиков выше, БД довольно интенсивно работает с базой данных и в пиках может генерировать до 750 iops на запись и до 1500 iops на чтение. Дисковый массив, использовавшийся клиентом до переезда, обеспечить такую производительность был не в состоянии и являлся узким местом системы. Миграция в облако позволила избавиться от этого «бутылочного горлышка».
Снижение зависимости разработчиков от действий системного администратора
Панель управления облака позволила разработчикам выполнять действия, которые ранее были доступны лишь системному администратору — создание новых виртуальных серверов, запуск клона-копии для проверки тестовой фичи, анализ нагрузки и изменение параметров инстансов. Данные обо всех серверах теперь под рукой, что становится существенным, когда машин много.
Быстрое горизонтальное масштабирование
Один из итогов переезда, который произвел на клиента очень большое впечатление — это возможность очень быстрого горизонтального масштабирования. Вся последовательность действий выглядит следующим образом:
- Клонирование и запуск боевого сервера (5-10 секунд)
- Конфигурирование round-robin DNS или добавление еще одного дестинейшена в конфиге nginx proxy (1-3 минуты)
Экономический эффект
Оценим расходы на до и после переезда.
До: проект размещался на двух colocation-серверах с конфигурацией 96 Gb RAM, 6×1 Tb SATA (аппаратный RAID10), 2x Xeon E5520. Dedicated сервер с подобным конфигом можно найти за 18-20 тысяч рублей в месяц. Их нам нужно два, поэтому стоимость серверов составит 36-40 тысяч в месяц. Выделенная полоса в 300 Мбит обойдется где-нибудь в 13-15 тысяч рублей в месяц. Коммутатор обойдется вероятно еще в 3-5 тысяч. Округляя, можно сказать, что итоговая стоимость будет находиться в районе 52-60 тысяч рублей в месяц.
После: cтоимость 1Гб памяти на фиксированных тарифных планах — 500 рублей в месяц. Полная стоимость серверов с общим объемом RAM в 70 Гб — 35 тысяч рублей. Кроме того, сюда необходимо включить трафик, который не укладывается в суточный лимит. Его стоимость составит примерно 8-12 тысяч рублей в месяц. Итог — 43-47 тысяч рублей в месяц.
Было бы неплохо учесть расходы на установку и настройку (мониторинг, SMS-уведомления, бэкапы, виртуализация) dedicated серверов, но даже без этого аренда ресурсов в облаке в данном конкретном случае обходится на 15-20% дешевле, чем аренда физических серверов под ту же задачу.
Заключение
При сравнении двух способов размещения отдельно взятого сложного проекта — в облаке и на выделенных серверах — облако показало свое убедительное превосходство. Оно оказалось дешевле, удобнее, гибче, помогло устранить ряд слабых мест проекта и дало клиенту возможность абстрагироваться от многих рутинных задач, таких как настройка статистики, мониторинга и бэкапов.
Хотя пока можно назвать отдельные сценарии, где облако будет проигрывать выделенным серверам, мы уверены — с течением времени таких сценариев будет все меньше и меньше.
Традиционно предлагаем вам воспользоваться пробным периодом FLOPS (см. видеоинструкцию) и оценить преимущества самостоятельно. Пробный период составляет 500 рублей или 2 недели (в зависимости от того что закончится раньше). Спасибо за внимание.
Автор: teraflops
