CDN

Проектирование собственной сети доставки контента

Сеть доставки содержимого — географически распределённая сетевая инфраструктура, позволяющая оптимизировать доставку и дистрибуцию содержимого конечным пользователям в сети Интернет. Использование контент-провайдерами CDN способствует увеличению скорости загрузки интернет-пользователями аудио-, видео-, программного, игрового и других видов цифрового содержимого в точках присутствия сети CDN. Wikipedia (RU)

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

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

Основные термины

Прежде чем начать предметный разговор об особенностях CDN, определимся с основной терминологией.

Источник данных (origin) — HTTP/HTTPS ресурс, на котором хранятся исходные файлы или данные, раздаваемые через CDN;

PoP (point of presence, точка присутствия) — кэширующий сервер в составе CDN, расположенный в определенной географической локации. Для обозначения таких серверов также используется термин edge.

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

Статический контент — контент, хранимый на сервере в неизменяемом виде (например, бинарные файлы, аудио- и видеофайлы, JS и CSS).

Функционал и компоненты

Панель управления (control) — веб-интерфейс для централизованного управления услугами доступными через API — добавление ресурсов для проксирования, настройка правил кеширования, управление доступностью в различных странах, включение и выключение WAF;

Биллинг (billing) — отображение состояния и пополнение баланса учетной записи, списание средств;

Узел передачи данных (edge) — сервер настроенный для проксирования динамического контента, например, сайты и API и кеширования статического контента (изображения, аудио, видео, стили и шрифты и т.п.) и Web application firewall;

Логирование — узлы передачи данных (edge) передают логи на сервер логов (logs) по протоколу syslog, где все входящие сообщения обрабатываются агентом (logs agent) и далее данные на основе сообщений записываются в биллинг, метрики. Логи старше 30 суток архивируются и сохраняются в S3-хранилище.

Статистика (stats) — сбор статистики основываясь на данные логов, подсчёт количества преданных данных;

Компоненты

Управление

Данный компонент будет иметь веб-интерфейс и API управления услугами для клиентов. При изменении настроек будет отправляться сообщение на edge-сервера для применения конфигурации.

Обработка запросов для изменения конфигурации на edge-серверах
Схема #1: Обработка запросов для изменения конфигурации на edge-серверах

Edge-сервер

Функционал

  • Проксирование и кеширование контента с указанных ресурсов;
  • Сброс кеша;
  • Отправка логов на сервер логов;
  • Обработка трафика при помощи WAF и дополнительные инструменты отражения атак на веб-приложения.

Сервер логов

Все edge-сервера отправляют логи на сервер логов по протоколу syslog, где входящие сообщения обрабатываются и далее сообщений записываются в биллинг, метрики определённым образом. Записи, старше 30 суток, архивируются и сохраняются в хранилище S3 и в случае необходимости просмотра записей логов из архива, по запросу формируется ссылка на архив логов содержащий файлы за выбранный период времени.

Fluentd — это кроссплатформенный программный проект с открытым исходным кодом для сбора данных реализованный на языке Ruby.

Так как Fluentd реализован на языке ruby, все приложения данного компонента сети доставки контента будет реализовано также на ruby.

Сервер статистики

Принимает метрики от агента сервера логов в виде: <resource_id>,<time>,<http-statuc>,<bytes>

Записывает полученное сообщение в БД и далее может отдать авторизованному пользователю собранную статистику.

Биллинг

  • Хранит состояние баланса каждого пользователя
  • Принимает сообщения от сервера логов с количеством обработанных запросов и объёмом переданных данных
  • Списывает средства согласно выбранного плана

DNS

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

Этапы реализации

Этап #1

  • Подготовка первоначальной конфигурации edge-сервера проксирования и кеширования
  • Разработка формата логов
  • Настройка отправки логов на сервер логов

Этап #2

  • Подготовка конфигурации DNS
  • Функционал управления конфигурацией DNS
  • Логирование и сбор логов
  • Обработка логов
  • Сервис метрик
  • Биллинг

Этап #3

  • Управление услугами
  • Генерация конфигурации для серверов раздачи контента
  • Биллинг и пополнения баланса
  • Уведомлений клиентов

Итог

После беглого обзора функций нашей будущей сети доставки контента сформировалась следующая картина:

Общая предварительная схема взаимодействия компонентов системы
Схема #2: Общая предварительная схема взаимодействия компонентов системы

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

Поделиться ссылкой: