Веб-Сервисы Amazon. Какова Хорошая Стратегия Сохранения Моего Сайта В Сети, Когда S3 Отключается От Сети?

Какова хорошая стратегия сохранения моего сайта в сети, когда S3 отключается?

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

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

#amazon-web-services #amazon-s3 #высокая доступность

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

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

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

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

По сути, вы просите о высокой доступности. Чтобы обеспечить высокую доступность системы, вам нужны три вещи:

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

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

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

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

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

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

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

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

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

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

Заключительные замечания

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