Connected topics

Load balancer и Reverse proxy

Load balancer - распределяет входящие запросы от клиента среди групп серверов, для каждого случая возвращает ответ от выбранного сервера для подходящего клиента.

Подробности: Применяются для того, когда сайту необходимо несколько серверов для обработки большого количества запросов, потому что один сервер не может их обработать эффективно. Также это делает сайт более надежным, потому что в случае падения одного сервака, информацию можно будет получить от другого. Более того, каждый сервер хостит один и тот же контент, лоад беленсер распределяет нагрузку на сервера и наилучшим образом использует мощность сервера, предотвращает его перегрузку, выбирает оптимальный путь получения ответа от сервера. Отличная опция, которая также доступна лоад беленсерам - постоянство сессии, когда запросы для конкретного клиента отправляются на один и тот же сервер.

Reverse proxy - принимает запрос от клиента и перенаправляет его серверу, который может его выполнить и вернуть ответ клиенту.

Подробности: всегда стоит поддерживать реверс прокси для приложения даже с одним веб сервером или сервером приложения. Оно является чем-то вроде публичного лица приложения. Его адрес используется веб сайтом и он ограничивает принятие запросов от веб браузеров и мобильных приложений для контента, который размещается на веб сайте.

Плюсы:

1. Безопасность - информация про серверы на бэкенде находится только в зоне видимости внутренней сети. Злоумышленники не смогут подконнектиться к ним для использования уязвимостей. Многие прокси сервера могут включают в себя фичи, которые помогают защитить backend сервера от distributed denial-of-service (DDoS) атак, например путем отклонения трафика от конкретного клиентского IP адреса (blacklisting) или лимитировать количество коннекшинов принимаемых каждым клиентом.
2. Масштабируемость и легкость - поскольку клиенты видят только IP - адрес обратного прокси (reverse proxy), мы можем менять конфигурацию инфраструктуры бэкенда. Особенно актуально для load-balanced среды, где можно масштабировать количество серверов для соответствие объему трафика.
3. Веб-ускорение (web acceleration) - сокращает время, которое требуется для генерации ответа и его возвращения клиенту. Например, с помощью сл технологий:
   • Сжатие - сжимает ответы сервера перед тем как возвратить их клиенту, уменьшая тем самым пропускную способность необходимую им, которая ускоряет их транзит по сети.
   • SSL termination - с помощью дешифрования входящих запросов и шифрования ответов сервера, обратный прокси освобождает ресурсы на серверах бэкэнда, которые они могут тогда посвятить своей основной цели, serving content.
   • Кэширование - перед тем как возвратить ответ сервера бэкэнда клиенту, обратный прокси сохраняет его копию локально. Когда клиент выполняют тот же запрос, обратный прокси вместо повторного запроса к бэкенду может отдать закэшированное значение. Это уменьшает время ответа и нагрузку на бэкенд сервер.

A/B тестирование

A/B-тестирование (сплит-тестированием (от англ. split testing — раздельное тестирование)) — это маркетинговый метод, использующийся для оценки и управления эффективностью веб-страницы. С помощью него можно влиять на конверсию , стимулировать сбыт и повышать прибыльность веб-проекта, позволяет влиять на различные метрики сайта. Поэтому выбор объекта тестирования зависит от цели и задач, которые ставится.

Зачем?

• Позволяет оценивать количественные показатели работы двух вариантов веб-страницы, а также сравнивать их между собой.

• Помогает оценивать эффективность изменений страницы (например, добавления новых элементов дизайна или призывов к действию).Практический смысл использования заключается в поиске и внедрении компонентов страницы, увеличивающих ее результативность.

Что?

• Улучшаем основные показатели, которые необходимо (определенные по целям проекта): конверсия, экономические метрики, поведенческие факторы;

Шаги

• Оценка метрик существующей веб страницы A и поиска способов ее улучшения.
• Совершаем изменение, которое потенциально может улучшить текущую страницу и создаем фактически страницу B.

• С помощью инструментов для проведения сплит-тестирования в случайном порядке разделяется трафик между страницами A и B на две приблизительно равные части (в случае, если есть риск уменьшения посетителей из-за применимых изменений, можно сократить объем трафика для страницы B в начале, после его увеличивая в случае happy case). В итоге, чтобы обеспечить валидность и объективность тестирования, необходимо направить на страницы A и B по 50% посетителей, пришедших на сайт.

• Собрав достаточно информации, оцениваются результаты тестирования по коэффициенту конверсии.

Что тестировать

Чаще всего тестируют следующие элементы веб-страниц:

• Текст и внешний вид конверсионных кнопок, а также их расположение.
• Заголовок и описание продукта.
• Размеры, внешний вид и расположение конверсионных форм.
• Макет и дизайн страницы.
• Цену товара и другие элементы бизнес-предложения.
• Изображения товаров и другие иллюстрации.
• Количество текста на странице.

Анализ

Для сравнения случайных величин оценивают средние значения, а для оценки среднего значения требуется некоторое время, чтобы накопить историю.

Эффект от внесения изменения определяют как разность между средними значениями ключевого показателя в сегментах.

Также оценивается значимость результатов с помощью статистических гипотез.

Инструменты для использования

Чтобы выполнить A/B-тестирование, необходимо воспользоваться одним из специализированных сервисов:

• Content Experiments компании Google

• Optimizely - платный сервис. К преимуществам данного сервиса относится возможность создания экспериментов в визуальном интерфейсе, что избавляет маркетолога от необходимости работать с HTML-кодом тестируемых страниц.

• RealRoi.ru — бесплатен и очень прост в использовании.

• Visual Website Optimizer - платный сервис. Этот сервис позволяет тестировать только созданные с его помощью страницы.

Service Discovery

Проблема: Например, в течение недели вписать все новые серверы в инфраструктуру, раскатать на них ваш магазин и все дополнительные сервисы.

Решение:

• Пойти в настройки балансировщика и вписать там руками адреса новых машин.
• Service Discovery - система, которая ведет специальный журнал, в который серверы и компоненты инфраструктуры сообщают о своих адресах и состоянии, как только они появляются в кластере.

Подробнее:

Любые системы, которым нужно знать обо всех серверах, в курсе, что всё это можно узнать в этом журнале (если у них есть на это права). Балансировщик нагрузки, вместо обращения к своим собственным файлам конфигов, раз в N секунд обращается в Service Discovery и запрашивает там список живых серверов приложений.

После очередного цикла работы балансировщик получит обновленный список серверов приложений и начнет распределять нагрузку по всем новым машинам.

В Service Discovery можно запихивать любые компоненты инфраструктуры — базы данных, серверы кэширования, микросервисы, резервные машины.

При любых изменениях в системе все заинтересованные части получат обновленные состояния инфраструктуры и изменят свою работу под новые условия.

Какие бывают:

ZooKeeper

Проект от Apache Foundation. Написан на Java, крепок и стабилен, тяжеловат в настройке и уступает по многим параметрам его более современным потомкам. При разработке новых приложений лучше не использовать.

Etcd

Простой, быстрый и очень гибкий продукт. В нем можно регистрировать серверы, хранить конфиги и держать состояния всех компонентов инфраструктуры. Крайне прост и надежен, но лишён многих полезных фич. Акценты на скорость и гибкость.

Consul

Лидер современного топа Service Discovery. Чуть более тяжелый и медленный, чем Etcd, взамен предлагающий кучи крутых плюшек (веб-интерфейс для работы со списками сервисов и т.д.).

Kubernetes

Kubernetes умеет много всего, в том числе и Service Discovery. Это не его основное предназначение, но для ряда проектов (особенно для тех, кто всё упаковывает в контейнеры и строит из них крупные кластеры) средства Service Discovery, предлагаемые Kubernetes по умолчанию, вполне подойдут.