Гео-сбалансированный (статический) хостинг сайтов

Question

Аннотация

Я перестраиваю свой сайт, и на этот раз я решил использовать статический генератор сайтов (jekyll ,ulpin.io и т.д.). Частично в качестве упражнения, я хочу, чтобы этот сайт размещался на глобально сбалансированном хостинге для скорости. (Таким образом, американские зрители должны получить сайт с американского сервера.)

Итак, моя цель - создать максимально быстрый сайт. Потому что я надеюсь, что могу.

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

Вопрос в том, как мне это сделать? Вот что я попробовал:

Использование CDN

Я мог бы получить случайный статический веб-хост и поместить CDN перед всей страницей. Хотя это будет работать достаточно хорошо, CDN отбрасывает мало использованных ресурсов из кэша и требует их повторного извлечения при необходимости, что увеличивает время загрузки.

Статический хостинг Amazon AWS

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

Amazon Route53/EC2

Хотя моя собственная операционная система менее оптимальна (слишком много работы, высокие затраты), это вариант. Тем более, что Puppet упрощает автоматизацию.

Для этой установки потребуется экземпляр EC2 в каждом регионе, один Elastic Load Balancer, настроенный перед ним, и Route53 для маршрутизации трафика в географически локальные ELB.

Построй сам

Размещая VPS или корневые серверы в каждом регионе, я могу запустить свою собственную ОС и установить nginx. В любом другом случае это будет очень похоже на настройку AWS.

Резюме

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

Answer 1

Я склонен начать с того, что скажу: «Выберите любые два».

Этот вариант железного треугольника, по сути, говорит, что вы не можете иметь все три. Если мы предполагаем, что вам нужны хорошие (производительность, надежность), быстрые (простое развертывание) и дешевые (плата за услуги и обслуживание) ... вашим лучшим вариантом может быть предложение «два из трех», для которого не так много волшебных моментов. ,

Я склонен не согласиться с предпосылкой, что подход CDN не будет достаточно быстрым, так как объект не должен быть безумно популярным, чтобы быть достаточно популярным, и случайное короткое ожидание меньшинства объектов на скважине Разработанная страница может остаться незамеченной. CDN, такой как CloudFront, обладает дополнительным преимуществом, заключающимся в том, что ваши запросы к исходному серверу в значительной степени пересекают собственную сеть Amazon, а не общедоступный Интернет, удаляя некоторые переменные глобальной передачи данных.

Но есть гибридный подход, объединяющий практически все элементы, которые вы упомянули:

Первая линия - это CDN. Мы скажем CloudFront, который использует DNS для автоматической маршрутизации запросов от браузеров к наиболее оптимальному местоположению.

Исходный сервер, к которому CDN подключается на задней стороне, на самом деле является несколькими серверами, гео / задержка маршрутизируется с использованием маршрута 53, поэтому край CDN подключается к ближайшему исходному серверу в соседнем регионе AWS.

Эти цели с гео / латентной маршрутизацией - источники, где CDN обновляет любые не кэшированные объекты - являются экземплярами EC2, но вместо полноценных веб-серверов они используют прокси-серверы, один или несколько в каждом регионе, с S3 в качестве хранилища данных вместо жестких дисков. Поскольку прокси-серверы могут переписывать исходные заголовки хоста на пути к S3, имена ваших сегментов больше не должны совпадать, поэтому вы можете разместить их в каждом регионе. Вы можете достичь существенной пропускной способности в очень маленьких экземплярах с помощью прокси-сервера, такого как HAProxy (у меня есть машины t2.micro, обслуживающие 2 миллиона запросов в день при поддержании постоянной загрузки ЦП около 3%). Поскольку прокси находятся в том же регионе, что и корзины, плата за передачу данных не взимается. Вам не нужен ELB, поскольку проверки работоспособности Route 53 могут удалить неработающий прокси-сервер из пула, из которого будет выбран CDN. Если корзина S3 по какой-либо причине становится недоступной для прокси-сервера, прокси-сервер намеренно провалит проверку работоспособности, в результате чего он будет удален из выбора.

Если вы хотите получить абсолютно менее миллисекунды, вы можете использовать Varnish в качестве прокси на машинах EC2 и кэшировать содержимое из S3 внутри EC2, так что вы потенциально уже получили бы его, если бы CDN требовалась свежая копия.

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

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