Статьи

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

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

Вступление

Сеть доставки контента (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

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

1
curl -v localhost:5000/now

Возвращает

01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
20
21
22
*   Trying ::1...
* TCP_NODELAY set
* Connected to localhost (::1) port 5000 (#0)
> GET /now HTTP/1.1
> Host: localhost:5000
> User-Agent: curl/7.64.1
> Accept: */*
>
< HTTP/1.1 200 OK
< X-Powered-By: Express
< Content-Type: text/html; charset=utf-8
< Content-Length: 13
< ETag: W/"d-ALnVQnzapyFibAJUsj/ugNkTGeo"
< Date: Tue, 31 Dec 2019 08:54:54 GMT
< X-Varnish: 32775
< Age: 0
< Via: 1.1 varnish-v4
< Accept-Ranges: bytes
< Connection: keep-alive
<
* Connection #0 to host localhost left intact
1577782494578* Closing connection 0

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

1
curl -v localhost:5000/now
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
20
21
22
*   Trying ::1...
* TCP_NODELAY set
* Connected to localhost (::1) port 5000 (#0)
> GET /now HTTP/1.1
> Host: localhost:5000
> User-Agent: curl/7.64.1
> Accept: */*
>
< HTTP/1.1 200 OK
< X-Powered-By: Express
< Content-Type: text/html; charset=utf-8
< Content-Length: 13
< ETag: W/"d-ALnVQnzapyFibAJUsj/ugNkTGeo"
< Date: Tue, 31 Dec 2019 08:54:54 GMT
< X-Varnish: 32778 32776
< Age: 39
< Via: 1.1 varnish-v4
< Accept-Ranges: bytes
< Connection: keep-alive
<
* Connection #0 to host localhost left intact
1577782494578* Closing connection 0

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

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

1
curl -v localhost:5000/now-nocache
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
20
21
22
23
*   Trying ::1...
* TCP_NODELAY set
* Connected to localhost (::1) port 5000 (#0)
> GET /now-nocache HTTP/1.1
> Host: localhost:5000
> User-Agent: curl/7.64.1
> Accept: */*
>
< HTTP/1.1 200 OK
< X-Powered-By: Express
< Cache-control: private, max-age=0, no-cache
< Content-Type: text/html; charset=utf-8
< Content-Length: 13
< ETag: W/"d-rBzErqEgrVIYGMP1QHJVW2pE10k"
< Date: Tue, 31 Dec 2019 08:56:38 GMT
< X-Varnish: 32780
< Age: 0
< Via: 1.1 varnish-v4
< Accept-Ranges: bytes
< Connection: keep-alive
<
* Connection #0 to host localhost left intact
1577782598029* Closing connection 0

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

01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
20
21
22
23
*   Trying ::1...
* TCP_NODELAY set
* Connected to localhost (::1) port 5000 (#0)
> GET /now-nocache HTTP/1.1
> Host: localhost:5000
> User-Agent: curl/7.64.1
> Accept: */*
>
< HTTP/1.1 200 OK
< X-Powered-By: Express
< Cache-control: private, max-age=0, no-cache
< Content-Type: text/html; charset=utf-8
< Content-Length: 13
< ETag: W/"d-FVW0D0z387XypqaGgxU3K6yNXX4"
< Date: Tue, 31 Dec 2019 08:57:19 GMT
< X-Varnish: 6
< Age: 0
< Via: 1.1 varnish-v4
< Accept-Ranges: bytes
< Connection: keep-alive
<
* Connection #0 to host localhost left intact
1577782639781* Closing connection 0

Это демонстрирует, как проверить 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.

Опубликовано на Java Code Geeks с разрешения Кристофера Эйра, партнера нашей программы JCG . Смотрите оригинальную статью здесь: Как протестировать сеть доставки контента

Мнения, высказанные участниками Java Code Geeks, являются их собственными.