У нас есть инфра, основанная на AWS в регионе us-east-1. (EC2, CloudFront, RDS, ElastiCache)
Сейчас у нас появляется все больше и больше пользователей из Азиатско-Тихоокеанского региона. Пользователи начинают жаловаться на скорость сети на наш сайт. (обратите внимание, что мы уже используем CloudFront для обслуживания статических ресурсов)
Некоторые подсказки после исследования:
Мои вопросы:
Любая помощь будет оценена, спасибо: D
Мир является довольно большим местом, и, хотя пропускная способность сети неуклонно растет, задержка в сети между одной частью мира и противоположным концом земного шара не исчезнет в ближайшее время.
Оптимизация и настройка на нескольких уровнях могут улучшить взаимодействие с пользователем, но в конечном итоге вы достигнете уровня, на котором единственный возможный способ еще больше повысить производительность - уменьшить задержку, физически приблизив данные к конечному пользователю.
Хорошая книга с множеством идей и источником приведенного выше графика Высокопроизводительная сеть браузера от веб-инженера Ильи Григорика.
Что наиболее экономично / оптимально зависит от ваш конкретный сценарий, ваша кодовая база и требует тщательного тестирования. Нет единственного решения волшебной инфраструктуры.
Большинство приложений, нуждающихся в массовом масштабировании, проходят один или несколько редизайнов, чтобы справиться с этим. Выбор дизайна, технологии и предположения, которые казались допустимыми для X пользователей, окажутся неверными в 100 или 1000 раз больше.
Интересные уроки можно найти на Блог о высокой масштабируемости
Редизайн кода вашего приложения так динамический контент можно лучше кэшировать - это один из подходов, например взгляните на модель varnish, которая позволяет вашему веб-приложению аннулировать кэшированный динамический контент по запросу, который работает очень хорошо, когда довольно много динамического контента на самом деле не нужно полностью регенерировать для каждого запроса. Это должно позволить вам лучше использовать CDN и означает, что вы можете оставаться в пределах одного региона доступности.
Перестройка вашего приложения таким образом, чтобы оно работало в нескольких зонах доступности, также улучшит восстановление после аварии, а не только повысит производительность для международных пользователей.
Вам нужно найти компромисс между пользовательским опытом и долларами. Во-первых, я хотел бы знать, сколько пользователей в процентном отношении приходят из Азиатско-Тихоокеанского региона. Если оно меньше, чем допустим, 10%, лучше всего подождать, чтобы увидеть, что произойдет.
Вы также не можете сказать, какой тип приложения вы поддерживаете и насколько оно чувствительно к задержке. Вы бы приняли одно решение, если бы это было приложение для видеочата в реальном времени, и другое, если бы это было последовательное приложение для социальных сетей.
С учетом всего сказанного, вы нашли правильный набор опций.
Мне больше всего нравится твой вариант 2. Я бы поставил как можно больше прокси / веб-серверов как можно ближе к большему количеству пользователей. Несмотря на то, что некоторый трафик всегда должен возвращаться в ваше местоположение us-east-1, завершение первого соединения в регионе приведет к гораздо лучшему взаимодействию с пользователем. Подумайте об SSL-соединениях.
Я бы также посмотрел на SPDY.
Я бы также подумал о переходе с нас-восток-1 на нас-запад-2 для вашего присутствия в США.
VPN-туннели - хорошая идея, и их не так сложно настроить.
Я бы настроил резервные туннели с использованием OpenVPN.