В настоящее время я внедряю архитектуру хранения изображений для своего сервиса.
Как я читал в одной статье, неплохо было бы переместить целое
изображение для загрузки и загрузки трафика c во внешнее облачное хранилище объектов.
https://medium.com/@jgefroh / Software-Architecture-Image-uploading-67997101a034
Как я заметил, есть много поставщиков облачных хранилищ объектов:
- Amazon S3
- Облачное хранилище Google
- Microsoft Azure Хранилище BLOB-объектов
- Хранилище объектов Alibaba
- Oracle Хранилище объектов
- Хранилище объектов IBM
- Объект Backblaze B2
- Хранилище внеклассных объектов
- Хранилище объектов Aruba
- Хранилище объектов OVH
- DreamHost DreamObjects
- Файлы Rackspace Cloud
- Цифровые океанские пространства
- Хранение горячих предметов Васаби
M Первый выбор был Amazon S3, потому что
почти вся моя системная инфраструктура расположена на AWS.
Однако я вижу много проблем с этим хранилищем объектов.
(Пожалуйста, исправьте меня, если я ошибаюсь в любой точке ниже)
1 ) Дорогая доставка журналов
AWS взимает плату за все оперативные запросы. Если мне придется оплачивать все запросы, я бы хотел видеть все журналы запросов. и я хотел бы получить эти журналы как можно быстрее. AWS S3 обеспечивает доставку журналов, но с большой задержкой, и каждый журнал предоставляется как отдельный файл в другом сегменте S3, поэтому каждый журнал представляет собой отдельный запрос записи S3. Запросы на запись стоят дороже, они стоят примерно 5 $ за 1 млн запросов. Существует еще одна опция для запуска AWS лямбда при каждом запросе, но это также дополнительные расходы 0,2 $ за 1M лямбда-вызовов. Подводя итог, я считаю, что доставка журналов запросов S3 является дорогой дорогой.
2) Невозможно глобально настроить максимальную длину содержимого объекта для всей корзины.
Я не нашел возможности настроить ограничение максимального размера объекта (длина содержимого) для всей корзины. Короче говоря - я хочу иметь возможность блокировать загрузку файлов больше указанного лимита для выбранного сегмента. Я знаю, что можно указать длину содержимого загружаемого файла в предварительно назначенных URL-адресах PUT, однако я думаю, что это должно быть доступно для глобальной настройки для всего сегмента.
3) Невозможно настроить ограничение скорости запросов для каждого числового IP-адреса в минуту непосредственно в сегменте.
Поскольку все запросы S3 являются платными, я хотел бы иметь возможность ограничить лимит запросов, который будет быть сделаны на моем ведре с одного номера IP. Я хочу предотвратить массовую загрузку и загрузку с одного IP-номера, и я хочу, чтобы он был настраиваемым для целого сегмента. Я знаю, что эта функция может быть использована AWS WAF, подключенным к Cloudfront, однако такие запросы, проверенные WAF, стоят дорого! Вы должны платить 0,60 $ за каждый 1M проверенных запросов. Прямые запросы Amazon S3 стоят 0,4 $ за 1M запросов, поэтому в этом нет никакого смысла, и совершенно не выгодно использовать AWS WAF в качестве опции ограничения скорости для запросов S3 в качестве «защиты кошелька» для атак DOS.
4) Невозможно создать предварительно назначенный URL-адрес «один раз - загрузить».
Созданные предварительно назначенные URL-адреса можно использовать несколько раз, пока не истек срок действия. Это означает, что вы можете загрузить один файл много раз, используя один и тот же предварительно заданный URL. Было бы замечательно, если бы AWS S3 API предоставил возможность создавать предварительно назначенные URL-адреса для "однократной загрузки". Я знаю, что могу сам реализовать такую функцию «однократной загрузки».
Например, см. Эту ссылку https://serverless.com/blog/s3-one-time-signed-url/
Однако, по моему мнению, такая функциональность должна предоставляться напрямую через S3 API.
5) Каждый запрос к S3 является платным!
Допустим, вы создали приватное ведро. Однако никто не может получить доступ к данным в нем .... Любой из inte rnet может выполнять массовые запросы в вашем ведре ... и Amazon будет взимать плату за все эти запрещенные 403 запроса !!! Не очень удобно, что кто-то может «истощить мой кошелек» в любое время, зная только имя моего ведра! Это далеко не безопасно !, особенно если вы дадите кому-то прямой S3-адрес с заданным адресом. Каждый, кто знает, как называется ведро, может выполнить 403 запроса и слить мой кошелек !!! Кто-то уже задавал этот вопрос здесь, и я думаю, что это все еще проблема
https://forums.aws.amazon.com/message.jspa?messageID=58518
По моему мнению, запрещенные 403 запроса вообще не должны быть платными!
6) Невозможно заблокировать сетевой трафик c к S3 через правила NaCL
Поскольку каждый запрос к S3 платный. Я хотел бы иметь возможность полностью блокировать сетевой трафик c для моего сегмента S3 на нижнем сетевом уровне. Поскольку корзины S3 не могут быть размещены в частном VPC, я не могу блокировать трафик c с определенного IP-номера с помощью правил NaCl. По моему мнению, AWS должен предоставить такие правила NaCl для сегментов S3 (и я имею в виду правила NaCL, а не ACL, которые блокируют только прикладной уровень)
Из-за всех этих проблем я Я рассматриваю возможность использования nginx
в качестве прокси для всех запросов, сделанных в мои частные корзины S3
Преимущества этого решения:
- Я могу ограничить количество запросов до S3 бесплатно, однако я хочу
- Я могу кэшировать изображения на моем nginx бесплатно - меньше запросов на S3
- Я могу добавить дополнительный уровень безопасности с помощью Lua Resty WAF (https://github.com/p0pr0ck5/lua-resty-waf)
- Я могу быстро обрезать запросы с телом запроса больше указанного
- Я могу предоставить дополнительную аутентификацию запроса с использованием openresty
(пользовательский код lua может быть выполнен при каждом запросе)
- Я могу легко и быстро получить все журналы доступа с моего компьютера EC2 nginx и переслать их в облачный сервис, используя cloud-watch-agent.
Недостатки этого решения:
Я должен перенести все трафики c на S3 через мои машины EC2 и масштабировать мои машины EC2 nginx с использованием группы автоматического масштабирования.
прямой трафик c на S3 bucket все еще возможно из inte rnet для всех, кто знает мое имя bucket!
(нет возможности скрыть корзину S3 в частной сети)
МОИ ВОПРОСЫ
Считаете ли вы, что такой подход с обратным прокси-сервером nginx перед хранилищем объектов хорош?
Или, может быть, лучше просто найти альтернативного поставщика хранилища облачных объектов, а не запросы на хранение прокси-объектов вообще?
Буду очень благодарен за рекомендации альтернативных провайдеров хранения.
Такая информация о данной рекомендации будет предпочтительнее.
Имя поставщика хранилища объектов
A. Сколько стоит трафик INGRESS c?
B. Какова цена траффика EGRESS c?
C. Какова цена ЗАПРОСОВ?
D. Какие варианты оплаты доступны?
E. Существуют ли какие-либо долгосрочные соглашения?
F. Где расположены центры обработки данных?
G. Предоставляет ли он S3 совместимый API?
H. Предоставляет ли он полный доступ ко всем журналам запросов?
I. Предоставляет ли он настраиваемое ограничение скорости для IP-номера в минуту для сегмента?
J. Позволяет ли скрыть хранилище объектов в частной сети или разрешить сетевой трафик c только с определенного IP-номера?
По моему мнению, ИДЕАЛЬНЫЙ поставщик хранилища облачных объектов должен:
1) Предоставление журналов доступа ко всем запросам, сделанным в сегменте (номер IP, код ответа, длина содержимого и т. Д. c.)
2) Предоставление возможности оценивать количество запросов на ограничение по сегментам на номер IP в минуту
3). Предоставить возможность отключать трафик c от вредоносных IP-номеров на сетевом уровне
4) Предоставлять возможность скрывать хранилища объектов в частной сети или предоставлять доступ только для указанных IP-номеров
5) Не взимать плату за запрещенные 403 запросы
Буду очень признателен за все ответы, комментарии и рекомендации
С уважением