Проблема: медиатрафик душит origin
Когда фото товаров, hero-видео, PDF и пользовательские загрузки находятся на том же сервере, что рендерит ваши страницы, каждый запрос изображения конкурирует за CPU, дисковый I/O и трафик с реальной работой приложения. Одна популярная страница с тридцатью изображениями умножает трафик на origin в тридцать раз, а всплеск трафика или загрузка большого видео могут лишить приложение ресурсов, нужных для ответа вообще. Хранилище на сервере приложения также трудно масштабировать: рано или поздно закончится диск, а резервное копирование раздутой файловой системы становится медленным и хрупким. Отделение байт от логики — первое структурное решение, и именно его обеспечивает этот сценарий.
Как cdn.com.tr это решает: бакеты плюс edge-кэш
Вы храните каждый ресурс в S3-совместимом бакете Object Storage, что даёт вам практически эластичную ёмкость и эндпоинт, с которым ваши приложения общаются стандартными S3-инструментами. Перед этим бакетом вы размещаете CDN cdn.com.tr, так что реальная доставка браузерам происходит из edge-локаций, а не из бакета и никогда не с сервера приложения. Первый запрос к файлу заполняет edge-кэш; каждый последующий запрос к этому файлу отдаётся с edge, больше не обращаясь к Object Storage. В результате ваш origin обрабатывает почти никакого байтового трафика, ваш уровень хранения масштабируется независимо от вычислений, а пользователи получают ресурсы с ближайшего edge-узла вместо единственного удалённого сервера.
Ключи доступа, публичные ресурсы и приватные файлы
Каждый бакет контролируется парами access key и secret, которые вы создаёте, ротируете и отзываете из панели. Для публичного медиа, например изображений каталога, вы доставляете через домен CDN и держите сырой эндпоинт бакета вне вашей разметки. Для приватных материалов, например платных загрузок или внутренних резервных копий, вы держите объекты непубличными и выдаёте короткоживущие подписанные URL, сгенерированные с помощью access key, так что ссылка истекает, а не живёт вечно. Поскольку каждая интеграция получает собственный ключ, скомпрометированный загрузчик или уходящий подрядчик — это отзыв в один клик, а не сброс пароля по всей платформе.
Cache-control и purge без самостоятельного отравления кэша
Кэш настолько хорош, насколько хороши заголовки, которые вы задаёте своим объектам. Давайте долгоживущим версионированным ресурсам далёкий-future Cache-Control с immutable, а действительно часто меняющимся вещам — более короткий TTL. Самый чистый паттерн — имена файлов с хэшем содержимого: когда изображение меняется, меняется его URL, так что edge естественным образом отдаёт новый файл, и вам никогда не приходится бороться с устаревшим кэшем. Когда нужно перезаписать файл по тому же URL — замена логотипа, исправленный PDF, — точечный purge из панели или cdnctl сбрасывает этот объект с каждой edge-локации, так что следующий запрос повторно забирает его из бакета. Это делает инвалидации редкими, точными и безопасными.
Масштабирование от нескольких изображений до полной медиатеки
Та же настройка, что отдаёт горстку логотипов, масштабируется до каталога сотен тысяч фото товаров, библиотеки видео по запросу или скользящего архива ночных резервных копий, потому что Object Storage растёт без того, чтобы вы разворачивали диски, а edge поглощает трафик чтения. Медиатяжёлые сайты видят самый резкий выигрыш: страницы становятся легче и быстрее по мере того, как изображения текут с ближних edge, а трафик origin — часто самый дорогой и хрупкий ресурс — резко падает. Резервные копии тоже получают чистый дом, изолированный в собственном приватном бакете со своим ключом доступа, вдали от публичного пути доставки.
Как это сочетается с остальной платформой
Этот сценарий намеренно сфокусирован на хранении и доставке, но он сочетается со всем остальным в аккаунте. Приложение на WordPress или PHP может вынести свой каталог загрузок в бакет, продолжая отдавать сайт через тот же edge. Контейнерное приложение может привязать бакет как переменные окружения и читать или писать объекты напрямую. DNS и Auto SSL обрабатывают домен доставки, а purge, логи и статус дают операционную видимость, чтобы подтвердить, что ресурсы текут из кэша, а не молча промахиваются в origin при каждом запросе.
Как настроить, шаг за шагом
Создайте бакет
В панели откройте Object Storage и создайте бакет для вашего медиа (например media-prod). Вы получаете S3-совместимый эндпоинт, регион и имя бакета. Держите отдельные бакеты для публичных ресурсов и приватных резервных копий, чтобы их политики доступа никогда не пересекались.
Сгенерируйте ограниченный по правам ключ доступа
Создайте пару access key / secret для бакета и вставьте её в свой загрузчик, CMS или SDK для S3. Используйте один ключ на приложение, чтобы можно было ротировать или отзывать одну интеграцию, не ломая остальные. Ключи можно ротировать из панели в любой момент, если один утёк.
Загружайте с правильными заголовками
Отправляйте ресурсы через существующий S3-клиент, aws-cli или плагин, задавая Content-Type и долгий Cache-Control (например max-age=31536000, immutable) для файлов, которые никогда не меняются. Используйте имена файлов с хэшем содержимого вроде logo.a1b2c3.png, чтобы новая версия была новым URL и никогда не требовала инвалидации.
Поставьте CDN впереди
Подключите домен доставки (например cdn.example.com) к CDN и направьте его origin на эндпоинт бакета. Теперь запросы сначала попадают на edge, кэшируются по локациям и промахиваются к Object Storage только на первый запрос каждого ресурса. Auto SSL автоматически выпускает сертификат для домена доставки.
Проверьте поведение кэша
Загрузите ресурс дважды и проверьте заголовки ответа на HIT при втором запросе. Убедитесь, что ваш Cache-Control учитывается и что MIME-типы изображений и видео корректны, чтобы браузеры и edge правильно их кэшировали.
Настройте purge
Когда вы перезаписываете файл по тому же URL, выполните purge из панели или через cdnctl, чтобы edge сбросил устаревшую копию. Для ресурсов, версионируемых по имени файла, это редко нужно — именно поэтому для высокооборотного медиа рекомендуются имена с хэшем содержимого.
Примеры сценариев
Тысячи фото товаров живут в бакете и транслируются с edge, так что страницы списка и деталей остаются быстрыми во время кампаний, не нагружая сервер приложения магазина.
Видео по запросу и файлы установщиков хранятся один раз и доставляются из кэша, удерживая трафик origin ровным, даже когда файл внезапно становится вирусным.
Ночные резервные копии базы данных и файлов идут в приватный бакет с выделенным ключом доступа, полностью вне публичного пути доставки и ротируемые по требованию.
Часто задаваемые вопросы
Действительно ли хранилище S3-совместимо с моими существующими инструментами?
Да. Бакеты предоставляют S3-совместимый эндпоинт, так что aws-cli, s3cmd, rclone и AWS SDK работают, если направить их на эндпоинт с вашим access key и secret. Большинство плагинов загрузки CMS и фреймворков, поддерживающих S3, работают точно так же.
Пользователи обращаются напрямую к бакету или к CDN?
Для публичной доставки вы направляете домен CDN на эндпоинт бакета и публикуете этот домен в своей разметке, так что пользователи всегда попадают на edge-кэш. Сырой эндпоинт бакета остаётся за CDN, и именно на него ваши страницы не ссылаются.
Как отдавать приватные файлы, не делая бакет публичным?
Держите объекты приватными и генерируйте короткоживущие подписанные URL с помощью вашего access key. Ссылка даёт доступ на ограниченное время, а затем истекает, что является правильным паттерном для платных загрузок, счетов или всего, что не должно быть публичным навсегда.
Если я заменяю изображение под тем же именем файла, почему всё ещё показывается старое?
Потому что edge закэшировал предыдущую версию под этим URL. Выполните purge для этого объекта из панели или cdnctl, либо примите имена файлов с хэшем содержимого, чтобы каждая новая версия имела новый URL и никогда не требовала purge.
Какой Cache-Control задавать для медиа?
Долгоживущие версионированные ресурсы должны использовать далёкий-future max-age с immutable; часто меняющиеся файлы — более короткий TTL. Задание заголовка во время загрузки — это то, что позволяет edge держать файл, а не забирать его повторно из бакета.
Могу ли я отозвать доступ, если ключ утёк?
Да. Ключи доступа ротируются и отзываются из панели по интеграциям. Поскольку вы выпускаете один ключ на приложение, отзыв утёкшего ключа затрагивает только эту интеграцию, а не каждый сервис, читающий бакет.