Логика для скрипта, запускающегося по расписанию

Загрузить и разобрать http://s3.amazonaws.com/application/?actions=loadlist .

Если текущий сервер отсутствует в списке, создать пустой файл в сегменте с ключом servers/{IP‑адрес EC2‑сервера}.

Выяснить, доступны ли остальные серверы, записанные в сегменте, проверив связь с ними, используя внутренний AWS IP адрес. Если связь установить не удается, то ключ сервера из сегмента удаляется.

Так как скрипт, запускающийся по cron, является частью виртуальной машины EC2, каждая такая машина автоматически регистрируется как доступный сервер в кластере. Клиентский код (AJAX или Flash) разбирает список ключей в сегменте, вычленяет внешнее имя AWS‑сервера и добавляет его в массив для случайного выбора при соединении, как описано выше при рассмотрении файла servers.xml.

Если виртуальная машина EC2 отказывает или выключается, то другие машины самостоятельно убирают ее запись из сегмента: в сегменте остаются только доступные серверы. Дополнительно – клиент сам выбирает другой сервер EC2 в сегменте, если ответ не был получен в течение определенного времени. Если трафик на веб‑сайт увеличивается, достаточно просто запустить больше серверов EC2. Если нагрузка уменьшается, можно часть из них отключить. Использование балансировки на стороне клиента при помощи S3 и EC2 позволяет легко создать гибкое, расширяемое и весьма надежное веб‑приложение.

5.4. Редиректы, 404‑ошибки и повторяющиеся файлы

От вопросов распределения запросов и их балансировки давайте перейдем к оптимизации самой структуры веб‑страницы и посмотрим, как в ряде случаев ее улучшение позволяет избежать существенных задержек и снизить издержки на доставку компонентов страницы конечному пользователю.