CDN — три буквы, которые слышал каждый айтишник

Почему всем нужна сеть доставки контента
6 минут

При построении клиент-серверных систем разработчикам часто требуется доставлять контент (картинки, видео, скрипты) от сервера к юзеру. В простом блоге, где нужно тысяче посетителей в месяц показать на странице пару картинок, отправлять контент с сервера можно любым удобным способом. Но если мы обслуживаем большую онлайн-игру, в которой миллионы юзеров получают тысячи разных картинок, придется хорошо подумать.

Ваш сервер с контентом должен уметь обслуживать тысячи коннектов, быстро вынимать данные с диска и слать их оптимальным способом по кратчайшему пути. Для решения проблем доставки контента с максимальной скоростью разрабатывают системы CDN — Content Delivery Network (сети доставки контента). Разберем, что это за инженерное решение, как его проектировать и внедрять в проекты.

Передача информации занимает время

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

  1. Попросить операционную систему найти файл.
  2. В ответ на ваш запрос операционная система, предварительно доделав свои дела, поставит задачу поиска файлов на выполнение и начнет копаться в таблицах размещения данных на диске.
  3. Найдя файл, если он есть, операционка проверит права доступа к нему и другие метапараметры.
  4. Если с метаданными файла все хорошо, ОС начнет копаться в диске компьютера и искать этот файл там. Работа над поиском данных может прерываться разными неотложными задачами, которые постоянно валятся на ядро.
  5. Найдя файл, операционная система начнет его читать. Приготовьтесь: процесс может быть долгим. Особенно, если файл большой и записан на диск блоками, раскиданными по разным участкам памяти. Иногда на диске может не найтись непрерывной области в 1 гигабайт, тогда файл будет побит на куски разного размера и помещен, куда поместится.
  6. После прочтения файла или в процессе чтения, если он очень большой, веб-сервер начнет отдавать бинарные данные по сети. Любая подобная сетевая операция занимает много времени — нужно формировать пакеты с данными, подписывать их, слать, проверять результаты. Это как работа почтового отделения небольшой индустриально развитой страны.
  7. Когда все данные отданы, ОС нужно почистить за собой — закрыть коннекты и дескрипторы файлов, прибраться в памяти и проделать еще пачку мелких задач по освобождению ресурсов, принимавших участие в отправке данных.

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

Отдаем файлы быстро

Чтобы серверы не плавились и справлялись, ваша задача — правильно их тюнинговать:

  1. Снять с сервера все задачи, кроме задач по отдаче файлов. Не надо вешать систему управления базами данных рядом — это плохая идея!
  2. Тюнить операционную систему. Политики выделения памяти и дисковых объемов определяются различными параметрами, их можно менять на уровне операционной системы или файловой системы, с которой эта ОС работает. Нужно обязательно вникнуть в тонкости вроде журналирования, размера блока файловой системы в килобайтах, ограничения на открытие файлов и других. Параметров много, для всего этого нужна помощь квалифицированного админа. Или очень много времени и сил на самостоятельное чтение доков.
  3. Оснастить серверы CDN крутым железом — быстрая память, быстрые SSD диски. Не скупитесь!

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

Не захлебываемся контентом

Чтобы все желающие вовремя получали контент с сервера, нужно подвести к серверам CDN достаточное количество широких каналов связи. Сделайте простые прикидки — оцените вашу аудиторию на пике нагрузки, количество отдаваемых файлов на среднего пользователя и средний размер одного файла. Посмотрите, пройдет ли такое количество байтов в ваши каналы.

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

Размещаем CDN-сервер рядом с пользователями

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

Допустим, вы обслуживаете российскую аудиторию, а ваш CDN-сервер стоит в США. В такой ситуации получается, что на каждый запрос файла пакеты ходят по сети через океан и возвращаются обратно. Конечно, это вызовет задержки. Но к счастью, эта проблема лечится легко — достаточно поставить серверы поближе к аудитории: в российские дата-центры. Так не придется ходить за океан за ценными байтами, время ожидания существенно снизится.

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

Почему слово из трех букв нужно всем

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

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

Group 40Group 44Group 43Group 46Group 41Group 27Group 42Group 39