← Справочные архитектуры / reference-architecture / diagrams / storage
Миграция данных объектного хранилища по запросу
Введение
Перенос данных между поставщиками облачного объектного хранения может быть сложным и затратным. Необходимо убедиться, что ни один объект не потерян, особенно если новые данные поступают уже во время миграции. Кроме того, стоит учитывать значительную единовременную плату за передачу данных.
Чтобы решить эти проблемы, Cloudflare разработала два инструмента миграции: Sippy и Super Slurper. Sippy представляет собой сервис миграции данных по запросу, и именно на нем сосредоточена данная диаграмма референсной архитектуры. Super Slurper, напротив, предназначен для крупномасштабных единовременных миграций в глобальный сервис объектного хранения Cloudflare, R2. Перенос всех данных сразу может не подойти для вашего сценария, и здесь может помочь Sippy.
Sippy позволяет переносить данные от других облачных провайдеров в Cloudflare R2 по мере поступления запросов на эти данные. Такой подход отлично подходит, когда нужно избежать крупных единовременных расходов на передачу данных и переносить их выборочно, по мере обращения к ним.
Расходы на исходящий трафик, связанные именно с миграцией при использовании облачного хранилища других поставщиков, снижаются за счёт использования запросов в рамках обычного потока вашего приложения, где вы уже платите за исходящий трафик, одновременно копируя объекты в R2.
Используйте Sippy для миграции часто запрашиваемых объектов данных и сразу начните экономить на плате за исходящий трафик. Затем используйте Super Sluper для переноса оставшихся данных.
Вот как работает Sippy: сначала он пытается получить объект из хранилища R2. Если объекта нет в R2, он получает его из исходного облачного хранилища объектов. Одновременно объект добавляется в R2 для доступа в будущем, что обеспечивает плавный и эффективный процесс миграции данных.
Миграция данных объектного хранилища по требованию с помощью Sippy
- Клиент запрашивает объект из R2 с помощью Workers ↗, S3 API ↗, или публичный бакет ↗.
- Если объект найден в вашем R2 bucket, он передается клиенту.
- Если объект не найден в R2, он одновременно возвращается из исходного bucket хранилища и копируется в R2. Обратите внимание: для копирования некоторых крупных объектов в R2 может потребоваться несколько запросов, поскольку они копируются частями (multipart upload). С точки зрения клиента он все равно получает запрошенный файл.
После копирования объектов последующие запросы будут обслуживаться из R2, и вы сразу начнёте экономить на комиссиях за исходящий трафик.