Каково максимальное время репликации Amazon S3 при загрузке файла?

Ответ 1

Обновление: этот ответ использует некоторую более старую терминологию, которую я оставил на месте, по большей части. AWS изменило дружественное название "US-Standard", чтобы более соответствовать названию других регионов, но его региональная конечная точка для IPv4 все еще имеет необычное имя s3-external-1.amazonaws.com.

В области us-east-1 S3 имеется конечная точка с двойным стеком IPv4/IPv6, которая следует стандартным соглашениям s3.dualstack.us-east-1.amazonaws.com, и если вы настроены на IPv6, эта конечная точка кажется функционально эквивалентной s3-external-1, как обсуждалось ниже.

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

Q. Не было ли в США стандартного региона?

Мы переименовали Регион США в регион США (Северная Вирджиния), чтобы он соответствовал региональным соглашениям об именах AWS.

— https://aws.amazon.com/s3/faqs/#regions

Ведра, использующие функцию ускорения передачи S3, используют конечную точку глобального стиля ${bucketname}.s3-accelerate.amazonaws.com, и пока неясно, как эта конечная точка ведет себя по отношению к нам - ведро-восток-1 и возможная согласованность, хотя разумно предположить, что другие Эта функция не должна затрагивать регионы, если она включена. Эта функция улучшает пропускную способность передачи для пользователей, которые более отдалены от ведра, путем маршрутизации запросов к тем же конечным точкам S3, но проксирует через AWS "Edge Network", ту же систему, которая поддерживает CloudFront. Это, по сути, самонастраивающийся путь через CloudFront, но без кэширования. Ускорение происходит от оптимизированных сетевых стеков и поддержания трафика в управляемой сети AWS для большей части своего пути через Интернет. Таким образом, эта функция не должна влиять на согласованность, если вы включаете и используете ее на ведре... но, как я уже упоминал, как она взаимодействует с нами, ведро-восток-1 еще не известно.

Американский стандарт (us-east-1) является самым старым и, по-видимому, самым большим, регионом S3 и играет по каким-то другим правилам, чем другие, более новые регионы.

Важным и значимым отличием является модель согласованности.

Ведра Amazon S3 в [во всех регионах, кроме US Standard] обеспечивают согласованность после записи для PUTS новых объектов и возможную согласованность для перезаписывания PUTS и DELETES. Ковши Amazon S3 в стандартном регионе США обеспечивают возможную согласованность.

http://aws.amazon.com/s3/faqs/

Вот почему я предположил, что вы используете US Standard. Поведение, которое вы описали, согласуется с этим конструктивным ограничением.

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

Есть еще один вариант, который стоит попробовать, имеет отношение к внутренним разработкам US-Standard.

Стандарт США на самом деле географически распределен между Виргинией и Орегоном, и запросы на "s3.amazonaws.com" выборочно маршрутизируются через DNS в том или ином месте. Эта маршрутизация в основном представляет собой черный ящик, но Amazon обнаружил обходное решение.

Вы можете заставить свои запросы перенаправляться только в Северную Вирджинию, изменив конечную точку с "s3.amazonaws.com" на "s3-external-1.amazonaws.com"...

http://docs.aws.amazon.com/general/latest/gr/rande.html#s3_region

... это спекуляция с моей стороны, но ваша проблема может быть усугублена географической маршрутизацией ваших запросов и принуждением их к "s3-external-1" (что, если быть понятным, -Standard), может улучшить или устранить вашу проблему.

Обновление: Совет выше официально поднялся выше спекуляций, но я оставлю его для исторической справки. Примерно через год я написал выше, Amazon действительно объявил, что US-Standard предлагает согласованность чтения после записи при создании нового объекта, но только при использовании конечной точки s3-external-1. Они объясняют это, как будто это новое поведение, и это может быть так... но это также может быть просто изменением в поведении, которое официально поддерживает платформа. В любом случае:

Начиная с [2015-06-19], стандартная область США теперь поддерживает согласованность чтения после записи для новых объектов, добавленных в Amazon S3, с использованием конечной точки Северной Вирджинии (s3-external-1.amazonaws.com). С этим изменением все регионы Amazon S3 теперь поддерживают согласованность после чтения. Консистенция после чтения позволяет вам извлекать объекты сразу после создания в Amazon S3. До этого изменения ведра Amazon S3 в стандартном регионе США обеспечивали возможную согласованность для вновь созданных объектов, а это означало, что некоторые небольшие объекты могли быть недоступны для чтения сразу после новой загрузки объекта. Эти случайные задержки могут усложнить рабочие процессы обработки данных, когда приложения должны читать объекты сразу после создания объектов. Обратите внимание, что в стандартном регионе США это изменение согласованности относится к конечной точке Северной Вирджинии (s3-external-1.amazonaws.com). Клиенты, использующие глобальную конечную точку (s3.amazonaws.com), должны переключиться на использование конечной точки Северной Вирджинии (s3-external-1.amazonaws.com), чтобы использовать преимущества этой согласованности после чтения в стандартном регионе США, _{[выделено курсивом]}

https://forums.aws.amazon.com/ann.jspa?annID=3112

Если вы загружаете большое количество файлов (сотни в секунду), вы также можете быть подавляющим механизмом S3 sharding. Для очень большого количества загрузок в секунду важно, чтобы ваши ключи ( "имена файлов" ) не были лексически последовательными.

В зависимости от того, как Amazon обрабатывает DNS, вы также можете попробовать другой альтернативный вариант обращения к вашему ведру, если ваш код сможет его обработать.

Ковши в US-Standard могут быть адресованы либо с помощью http://mybucket.s3.amazonaws.com/key... или http://s3.amazonaws.com/mybucket/key... и внутренняя реализация этих двух могла бы, по крайней мере теоретически, отличаться таким образом, чтобы изменить поведение таким образом, чтобы это было важно для вашей проблемы.

Ответ 2

Как вы отметили, в настоящее время нет гарантии или обходной последовательности возможной согласованности непосредственно с S3. В этот разговор из Netflix, оратор упоминает, что видел задержку согласования 7h (крайне редкая IMHO). Они даже создали слой согласованности поверх S3, s3mper, который является открытым исходным кодом и может помочь в вашем контексте.

Кроме того, как предложил @Michael - sqlbot, стандартные стандарты dos не обеспечивают согласованность после чтения, а наблюдаемые задержки согласования могут быть разными.