Какова хорошая стратегия держать мой сайт в сети, когда S3 выходит из сети?

Какова хорошая стратегия держать мой сайт в сети, когда S3 выходит из сети?

Если S3 US East 1 переходит в автономный режим, как мне настроить / структурировать мое приложение, чтобы не переводить весь сайт в автономный режим?

Каковы лучшие стратегии для диверсификации в такой ситуации?

В марте 2015 года Amazon AWS объявила о поддержке репликации S3 в разных регионах. Когда определенный регион в S3 переходит в автономный режим, вы можете обслуживать файлы с вашего зеркала в другом регионе.

^{источник: https://aws.amazon.com/blogs/aws/new-cross-region-replication-for-amazon-s3/}

Практика поддержания вашей инфраструктуры в сети путем переключения на другой регион является сложной, но S3 является относительно небольшим и простым компонентом. У Netflix есть отличная статья об их опыте с Chaos Gorilla.

Это также относится к ухудшению качества обслуживания, например, к увеличению задержки. Не только когда служба, от которой вы зависите, полностью отключена. Netflix также имеет статью на эту тему: Chaos Engineering Upgraded .

То, что вы просите, это, в основном, высокая доступность. Для обеспечения высокой доступности системы вам необходимы три вещи:

1. Устранить отдельные точки отказа
2. Механизм переключения с конечной точки на другую
3. Способ обнаружения сбоев

Устранить отдельные точки отказа

В случае S3, точка № 1 адресована, как указал Евгений, межрегиональной репликацией S3 .

Репликация, однако, не является мгновенной, и вы захотите проверить, хотите ли вы знать о репликации вашего приложения или нет. В случае сбоя, возможно, что то, что было записано в исходную корзину, еще не было (не реплицировано) в целевую корзину. Вы должны подумать, как приложение будет обрабатывать такой сценарий. Это действительно зависит от типа данных, что делается с ними и (потенциально) конечных пользователей или ожиданий руководства.

Механизм переключения с конечной точки на другую

Для S3 это означает, что в случае сбоя вы хотите, чтобы приложение прекратило чтение и запись из / в корзину A и использовало вместо нее B.

Насколько я знаю, пока это зависит от вас. Некоторые другие сервисы AWS предлагают полностью прозрачные средства отработки отказа, но в данный момент я не знаю об этом для S3.

Есть разные способы достичь этого. Одним из примеров является использование прокси, который будет направлять трафик к соответствующему сегменту. Во время сбоя вы должны обновить / изменить прокси-сервер для маршрутизации трафика в корзину, на которую не влияет сбой. Другим примером может быть динамическая конфигурация вашего приложения и сохранение ее в хранилище значений ключей. Если приложение считывает хранилище KV для обновленных свойств достаточно часто, вы можете переключаться между тем, где вы читаете и записываете (например, Spring Cloud поддерживает прослушиватель «EnvironmentChange»).

Способ обнаружения сбоев

Ну, это легко, я думаю. Просто установите цикл записи + чтения и предупредите, как только что-то не так :)

Закрытие заметок

• Если ваше приложение пишет в корзину, вы должны подумать о том, что произойдет в случае сбоя. Все ли записи сделаны до места назначения (и можете ли вы сказать)? Можете ли вы разрешить запись в целевую корзину (делая ее новой "основной")? Тщательное планирование позволит избежать разрозненных или потерянных сценариев обновлений.
• В зависимости от вашего SLA, вы можете захотеть, чтобы пункты № 2 и № 3 были автоматическими или автоматическими. Это требует дополнительного планирования, инструментария и тестирования, но хорошо написанные сценарии всегда будут реагировать быстрее и более предсказуемо, чем это может сделать человек (сбои также имеют досадную привычку происходить посреди ночи, когда вмешательство человека является чем-то опасным.
• Стоит отметить, что даже межрегиональная репликация не полностью устраняет отдельные точки отказа. Конечно, если регион падает, вы покрыты. Но что, если в США произойдет сбой AWS? У Azure был частичный, но глобальный сбой в прошлом году и один в 2014 году.