ELB vs Nginx

    Ещё раз привет!

    У меня появилась шикарная задача для исследования, и своими результатами я хочу поделиться с сообществом. Смысл задачи состоит в том, чтоб определить лучший вариант деплоя NGINX в AWS EC2/VPC. Лучший он должен быть с многих сторон, особенно со стороны высоконадёжности (High Availability) и скорости ответа. Особенно важным фактором так же является быстрота обработки SSL запросов, поэтому были проведены тесты на SSL-производительность.

    Все инстансы находятся в одной сети VPC, ELB тоже поднимается в этой же сети.

    Было рассмотрено несколько вариаций деплоймента, но выбор пал на 2 основные конфигурации, тесты над которыми я и провёл.

    Конфигурация 1. ELB




    Преимущества:
    • Обычная схема для многих приложений. ELB стоит перед двумя и более инстансами NGINX'a, пропускает трафик, тем самым делаю конфигурацию высоконадёжной (HA). Если фейлится одна из нод, трафик на неё не идёт.
    • Легко масштабируемая схема.

    Недостатки:
    • Плюс один хоп к сети.
    • Не под контролем.

    Конфигурация 2. NGINX




    Прeимущества:
    • Прямой доступ к балансировщику без посторонних проксей.
    • Полный контроль над инфраструктурой.

    Недостатки:
    • Настройка высоконадёжности усложняется применением heartbeat проверок и общения между серверами.
    • Тяжело масштабируется

    Тестирование


    Тестирование проходило на m1.medium инстансах (3.75 GiB memory, 2 EC2 Compute Unit (1 virtual core with 2 EC2 Compute Unit)). В качестве веб сервера использовался nginx с дефолтной страничкой. Тест проводился из другого региона AWS с помощью Apache Bench: 6 конкурентных пользователей спрашивали 400 раз страничку. Тест повторялся 100 раз в каждом случае.

    Итак, было проведено 4 теста. Обе конфигурации отвечали на http и https запросы.

    Non-SSL


    Тесты направлены на выявления влияния ELB на скорость ответа структуры. Предполагается, что конфигурации с ELB будет медленнее отзываться, т.к. в сети присутствует дополнительный узел. Но так же требуется взять во внимание то, что за ELB может быть больше одного (в нашем случае 2) инстанса NGINX, которые могут быть производительнее одного.

    График среднего времени ответов



    Средний результат всех ответов (в мс):
    ELB: 209.586
    NGINX: 207.934

    Выводы

    Как видим, результаты практически не отличаются. Хотя и на графике конфигурация NGINX постоянно быстрее ELB, но разница в 1-2% абсолютно приемлема. И так как конфигурация ELB значительно легче в настройке, более стабильна и имеет практически то же время ответа, что и NGINX, мы можем отдать ей предпочтение.

    SSL


    Тесты направлены на выяснения производительности конфигураций относительно SSL шифрования. В конфигурации ELB SSL шифрование производит ELB, в конфигурации NGINX — один NGINX балансировщик.

    График среднего времени ответов



    Средний результат всех ответов (в мс):
    ELB: 455.921
    NGINX: 437.745

    Выводы

    В начале тестирования ELB значительно отставал в ответах. Но после 30го запроса мы видим прирост в производительности. Это обосновано тем, что ELB был вертикально масштабирован. После повышения вычислительных мощностей, производительность стала почти одинаковой, как видно по графику.

    Как известно, ELB — это m1.micro инстанс, который может быть вертикально масштабирован, если он не справляется с задачами. Это никак не контролируется и производится автоматически. Но, благодаря партнёрским отношениям с AWS, можно добиться установки минимального шейпа для ELB, и, например, ELB никогда не будет меньше m1.medium. Делается это для того, чтоб максимально ускорить работу инфраструктуры. Если воспользоваться этой энтерпрайз опцией, то выбор места для SSL шифрования зависит от простоты настройки и других факторов. Пока эти вопросы не рассматривались, но результаты тестов показали, что обе конфигурации приблизительно равнозначны.

    Послесловие


    Были проведены тесты производительности конфигураций с и без использования ELB в AWS EC2/VPC. Показатели говорят о том, что присутствие ELB очень незначительно влияет на время отклика, хотя тем самым облегчает настройку высокодоступных решений. Так же, с использованием дополнительных опций AWS, особо не важно в каком месте проводить обработку SSL. В других же случаях, с достаточными мощностями (как минимум не t1.micro), её стоит проводить не на ELB.

    Если у вас есть другие интересные идеи о том, как сравнить эти конфигурации, я открыт для них. Сейчас всё бежит и можно легко прогнать ещё несколько тестов.

    UPD
    Были проведены тесты для HAproxy. Как и ожидалось, HAproxy незначительно быстрее NGINX.
    Средний тайминг реквеста:
    • HAproxy: 203.345 ms
    • ELB over HAproxy: 204.97 ms

    Общая картина выглядит следующим образом:

    EPAM

    116,06

    Компания

    Поделиться публикацией

    Похожие публикации

    Комментарии 17
      0
      Я сейчас рассматриваю вариант 1 только вместо ngnix тестирую traffic server.
        0
        А результаты тестирования какие-нибудь есть?
          +1
          Сравниваю с haproxy + squid. На проксироваании результаты сравимые, а на кешировании то TS быстрее и io ниже. Ну и ssl из коробки. haproxy добавил в ветку 1,5 ssl. Но для меня уже опоздал.

          Циферок нет. Добавлю тестовую ноду в мониторинг — появятся
            +1
            Главной задачей для меня сейчас является Nginx HA деплоймент. Nginx будет допиливаться до функционала, максимально приближенного к Citrix NetScaler. Ну и важны узкие места, связанные с SSL.
        0
        После того, как пришли на EC2, считать ELB «Не под контролем» уже глупо. Инстансы не больше под контролем, чем ELB.
        А поскольку не видно разницы — зачем?
          0
          Возможно вы и правы. Это уже давно не недостаток.
            0
            Самый неприятный момент — когда ложатся EBS, падает и часть ELB.Можно конечно держать в разных зонах два балансера как фейловер…
              0
              Да, ELB иногда фейлят. Надёжнее всего использовать instance-store машинки, которые заменяют друг друга «ин кейс оф фейл»
          0
          Проведены тесты с HAproxy.
            +1
            А где объяснение скачков на графике nginx?
              0
              Я понятия не имею, почему произошли эти скачки. Если бы был софт сзади какой-то, чтоб можно было траблшутить, то еще ладно. А там же чистый дефолтный nginx.
                0
                Если оно не повторялось между тестами, то его на графике не должно быть.

                p.s.: s/sll/ssl/g
                  0
                  Спс, заменил.
              0
              Как на HAProxy проводилось SSL-termination?
                0
                В стабильных ветках этой фичи нет. В дев ветке — уже есть.
                0
                6 конкурентных пользователей спрашивали 400 раз страничку. Тест повторялся 100 раз в каждом случае.


                1. А можно ли считать эти показатели достоверными?
                2. Настройки дефолтные были или подкрученные?
                  0
                  1. Я другого просто не придумал.
                  2. Настройки абсолютно дефолтные.

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

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