Геолокация маршрутизации в Амазонке/Облаке?

У меня есть веб-приложение, размещенное на сервере Amazon EC2. Это приложение можно получить через разные страны: США, Великобритания, Китай, Индия и т. Д.Геолокация маршрутизации в Амазонке/Облаке?

Мой вопрос - это amazon (или любой другой поставщик облачных сервисов), обеспечивающий размещение серверов в разных странах (в соответствии с EC2 по умолчанию или за дополнительную плату необходимо заплатить ), чтобы контент мог быстро обслуживаться с веб-серверов?

Например, если запрос поступает из Китая и его обслуживается сервером EC2 в Китае, это будет бит быстрее, чем если он будет обслуживаться сервером в США, так как запрос/ответ должен перескочить с национальной сети/сети в международную сеть ?

источник

2017-01-27 scott miles

Вы говорите о кросс-зоне нагрузки балансиры http://docs.aws.amazon.com/elasticloadbalancing/latest/classic/enable-disable-crosszone-lb.html Если вы хотите статического содержимого вы можете пользуйтесь сервисом amazon cloud front (делает ваш S3 CDN) –

@ DanielKrom он не говорит о балансировке нагрузки вообще. Он говорит о маршрутизации геолокации или маршрутизации на основе латентности. Кроме того, CloudFront работает с не только S3, но и больше, чем просто статическим контентом. Также он не «делает ваш S3 CDN». CloudFront - это CDN, который можно разместить перед S3, между прочим. –

@MarkByou это правильно. Cloudfront - это просто CDN, который перенаправляет запрос на лучшее местоположение края (крайнее местоположение отображает содержимое из центров обработки данных, чтобы уменьшить время ожидания), чтобы сохранить надежды запроса. Является ли это облачной областью, которая выполняет маршрутизацию геолокации? Если да, то должен ли AWS-клиент платить за это явно? Я верю Нет –

Если вы используете Route53 для DNS, вы можете использовать маршрутизацию на основе геолокации. Или, поскольку вы в основном заинтересованы в маршрутизации в самое быстрое место (сокращение латентности), вы можете маршрутизировать Route53 Latency. Различные политики маршрутизации Route53 документируются here.

Я предлагаю вам сначала изучить возможность использования Content Delivery Network, например CloudFront, который может кэшировать ответы сервера в крайних местоположениях по всему миру. Когда пользователь запрашивает что-то, что находится в кэше CDN, он получит ответ от ближайшего местоположения края CDN. Это будет быстрее и дешевле, чем управлять несколькими копиями ваших серверов по всему миру, если вы сможете эффективно использовать кеш.

источник

2017-01-27 14:12:41

Спасибо, Марк. когда вы говорите: «Если вы используете Route53 для DNS ...», разве амазонка всегда использует Route53, когда мы берем любую из облачных сервисов AWS, таких как сервер EC2? Для кэширования CDN он будет работать для статического контента, а не для динамического контента, такого как поиск, или где инвентарь динамичен правильно? –

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

@scottmiles, CloudFront все равно будет стремиться улучшить * производительность * * транспорта * неконкретированного динамического содержимого, и этот эффект наиболее заметен, когда зритель более удален от сервера. Причины этого несколько сложны для объяснения здесь, включая оптимизированные стеки TCP, keep-alives, повторное использование соединений, пиксельную пыль, управляемую транспортную инфраструктуру между регионами и автоматическую/прозрачную гео-маршрутизацию к краевому узлу CloudFront, ближайшему к браузер, но ... да, попробуй. –

Геолокация маршрутизации в Амазонке/Облаке?

ответ

Смежные вопросы