Документы S3: «один параллельный запрос на 85–90 МБ / с требуемой пропускной способности сети» - почему?

Question

На странице, указанной ниже, я нашел следующее утверждение:

Сделайте один параллельный запрос на каждые 85–90 МБ / с требуемой пропускной способности сети. Для насыщения сетевой карты 10 Гбит / с (NI C) вы можете использовать около 15 одновременных запросов через отдельные соединения. Можно увеличить количество одновременных запросов по большему количеству подключений, чтобы насыщать более быстрые сетевые карты, например сетевые адаптеры 25 Гбит / с или 100 Гбит / с.

Шаблоны проектирования производительности для Amazon S3 - горизонтальное масштабирование и Запрос распараллеливания для высокой пропускной способности

Каково происхождение этих чисел? Я не могу найти другую документацию, которая оправдывает это. Я предполагаю, что это ограничение больше говорит об ограничениях NI C на экземпляре EC2, а не S3. Тем не менее, есть ли другой источник, который объясняет, откуда взялись эти цифры?

Для ясности, это не вопрос о том, как оптимизировать пропускную способность S3 - я знаю об альтернативах. Это вопрос самой документации AWS S3.

Answer 1

Единственные люди, которые могут ответить на этот вопрос однозначно, это те, кто работает над внутренними компонентами S3. И они почти наверняка покрыты NDA. Так что я сейчас напишу полные предположения.

Мы знаем, что S3 распределен и избыточен: каждый объект хранится на нескольких физических дисках в нескольких зонах доступности.

Мы можем сделать вывод из того факта, что S3 доступен как сетевой сервис, существует некоторая форма сетевого интерфейса между томом S3 и внешним миром. Очевидно, что да, но если этот сетевой интерфейс ограничен 1 Гбит / с c, он сможет достичь приблизительно 85-90 МБ / с c устойчивой пропускной способности.

Также важно помнить, что AWS использует программно-определяемую сеть: поэтому, хотя служба S3 может фактически иметь сетевой интерфейс, поддерживающий 10 Гбит / с c, AWS может ограничивать полосу пропускания, доступную для любого данного соединения.

Гораздо интереснее для меня эта цитата из той же ссылки:

мы предлагаем делать параллельные запросы для диапазонов байтов объекта с гранулярностью 8–16 МБ

Это означает, что избыточность управляется на уровне подобъектов, так что большой объект разбивается на несколько частей, возможно, по 64 МБ, и эти части распределяются по отдельности. Как HDFS управляет большими файлами , так что это не гигантский скачок.

Что касается вашего предположения, что это ограничение EC2, а не S3, я думаю, что предложение использовать несколько правил подключения это из Хотя вполне возможно, что EC2 ограничивает одно соединение ограничением 1 Гбит / с c, я ожидаю, что разработчики S3 будут более обеспокоены нагрузкой на свою систему. Вы всегда можете проверить это, открыв одно соединение между двумя экземплярами EC2 с сетью с высокой пропускной способностью, и посмотрите, не подавлено ли оно.