Как протестировать сеть доставки контента

Как не сломать интернет.

Вступление

Сеть доставки контента (CDN) — это кэш, который находится между вашим сайтом и пользователем.

Это полезно, когда ваш сайт становится популярным, и вам не нужно постоянно увеличивать свой веб-сервер, чтобы справиться с нагрузкой. Это позволяет избежать момента, когда веб-сайт выходит из строя из-за чрезмерной нагрузки. Моя племянница получила рождественский подарок invisibility cloak которому нужно приложение, чтобы оно заработало. Сайт не мог справиться с нагрузкой большинства продаваемых продуктов, активируемых в рождественское утро. Осторожное использование CDN (среди других методов) может быть использовано, чтобы избежать смущающих ошибок.

CDN — отличный способ значительно повысить производительность вашего сайта.

Ваш сайт является источником в этой диаграмме.

По умолчанию это начнет кэшировать каждый запрос. Как только вы начнете добавлять заголовки кеша на ваши страницы, вы сможете контролировать, как CDN будет кешировать страницу. Будут части сайта, которые вы не захотите кэшировать. Держите их разделенными определенной структурой пути, чтобы упростить вашу жизнь (здесь хорошо работает префикс /api ).

Преимущество этого состоит в том, что CDN сможет предоставлять контент вашим пользователям гораздо быстрее, чем вы, так как они будут ближе к ним. Это может занять 100 мс от звонка в США из Европы. Это будет иметь существенное значение.

Кроме того, большая часть нагрузки на ваш сайт будет удалена (единственными посетителями являются узлы CDN с просроченным кэшем). Если сайт статичен, а кеш прогрелся (каждая посещенная страница), то можно на короткое время отключить исходный сайт и при этом запустить сайт. Это делает возможным развертывание сайта, который находится под большой нагрузкой.

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

Один сайт, над которым я работал, был способен обрабатывать большие нагрузки (десятки тысяч одновременных сессий в Google Analytics), несмотря на то, что сайт обслуживался из одного узла heroku. Этот сайт смог опубликовать обновления примерно за секунду. Мы явно управляли тем, что нам нужно было кешировать, применили обновление к нашему сайту, а затем сказали CDN, чтобы сделать недействительными измененные страницы.

Как правило, CDN позволяет вам иметь краткие всплески большой нагрузки и взимает небольшую плату за дополнительное использование — что намного дешевле, чем необходимость продолжать масштабирование серверов.

Есть несколько CDN, доступных для использования, и тот, с которым я больше всего знаком, это Fastly. Fastly — это распределенная версия кэша Varnish. Лак кэша доступен для запуска в качестве образа докера. Это означает, что есть возможность протестировать ваш CDN!

Я собираюсь продемонстрировать, как настроить экспресс-веб-сервер для кэширования через Varnish в наборе образов докеров. Это позволит писать тесты, чтобы продемонстрировать, что кэширование работает должным образом перед развертыванием в реальной среде.

Как

Я написал пример кода можно найти здесь:

Образец кода

Он состоит из простого экспресс-приложения, которое выполняется в контейнере Docker. Docker Compose используется для создания связанных изображений Docker.

Это может быть начато с помощью:

docker-compose build && docker-compose up

Необработанное приложение выставлено на порт 3000

Кэшированное приложение выставлено на порт 5000

Это конечная точка, которая кэшируется:

Возвращает

Повторный вызов вернет тот же результат:

Обратите внимание, что тело такое же, но возраст сообщается.

Эта версия имеет заголовки кэша и не будет кэшироваться:

повторение вызова дает:

Это демонстрирует, как проверить cdn в контейнере Docker. Это станет более полезным, если вы хотите иметь больший контроль над конфигурацией. Varnish настраивается с использованием языка Varnish Configuaration: Varnish Documentation — который позволяет полностью контролировать поведение веб-сайта.

Например, вы можете проверить наличие cookie и вернуть другую страницу в зависимости от значения (вошедшие в систему пользователи получают одну, неаутентифицированные получают другую).

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

Вы также можете изменить ответ, чтобы скрыть подробности о приложении. Удивительно, сколько сайтов рекламируют точную версию веб-сервера, которую они используют. Это можно увидеть просто с помощью curl: curl -v bbc.co.uk

Вы можете использовать CDN для изменения поведения размещенного сайта без изменения самого размещенного сайта. Это может позволить вам быстро исправить проблему, пока готовится реальное решение. Например, вы можете поднять удерживающую страницу для определенного URL.

Желательно не указывать CDN постоянно кэшировать, поскольку любые ошибки могут постоянно находиться в браузере — это может быть проблемой, если вы кэшируете библиотеку javacript и случайно кэшируете сломанную версию.

Я бы также порекомендовал настроить вашу CDN программно, чтобы она была тестируемой и повторяемой. Будьте очень осторожны с тем, чтобы CDN выполнял слишком много работы, поскольку вы столкнетесь с нечетными граничными условиями, такими как кэширование страницы ошибки.

Убедитесь, что вы знаете, как удалить конкретную страницу. Сайт, над которым я работал, добавил этого в чат-бота в расслабленном состоянии. Она смогла очистить страницу, отправив ей слабое сообщение — это было идеально, когда вам нужно было поддержать проблему и быть вдали от своей машины.

Можно использовать AWS S3 в качестве кэша, но желательно добавить перед ним CDN, чтобы вы могли контролировать возвращаемые заголовки.

Обучение при подготовке образца.

Образы док-станции Alpine достаточно быстро запускаются и загружаются по сравнению с полнофункциональными версиями. Это очень маленькие изображения докера

Тесты должны ждать на лаковом сервере, который запускается. Обычно я использовал бы сценарий wait-for-it.sh, который позволяет ожидать завершения данной службы. Однако, поскольку я использую альпийский док-контейнер, у нас нет доступного bash. Это означает, что я использовал утилиту waitforit .

Также обратите внимание на различные параметры сети, используемые в docker-compose. Вы можете использовать псевдоним другого контейнера-докера в качестве локальной записи dns, если он указан в разделе depen_on. Это даже доступно для тестов, запускаемых внутри контейнера.

Как насчет других CDN

Теперь, если вы действительно хотите протестировать CDN из реальной жизни, вот этот проект:

Это позволяет вам развернуть Wiremock в Heroku.

Если вы сконфигурируете свой CDN для обслуживания этого приложения Heroku в качестве источника, то вы можете полностью протестировать поведение CDN. Wiremock предоставляет вам программируемый веб-сервер, который предоставляет вам API, который позволяет изменять ответ, поэтому можно сделать так, чтобы страница возвращала фиксированное значение, а затем начала возвращать ошибки. Это дает вам возможность протестировать всю спецификацию HTTP, если вы этого хотите, но это выходит за рамки данной статьи.

Обычно CDN контролируется группой инфраструктуры в вашей организации. Разрешение конфигурации на тестирование позволит вам использовать гораздо больше расширенных функций CDN.