Назад | Перейти на главную страницу

AWS - как быстрее обслуживать зарубежных пользователей

У нас есть инфра, основанная на AWS в регионе us-east-1. (EC2, CloudFront, RDS, ElastiCache)

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

Некоторые подсказки после исследования:

  1. Клонировать набор инфра в регион APAC (например, JP)
    • $$ забота
    • Факт, установленный быстрым тестом: задержка между us-east-1 <---> ap-norteast-1 составляет около 160-180 мс.
    • В нашем случае это невозможно. Хотя мы можем создать реплику чтения БД в JP, веб-серверы все равно должны отправлять операции записи в США.
    • ElastiCache не поддерживает межрегиональную поддержку. т.е. US ElastiCache доступен только для американских экземпляров ec2.
  2. VPC в каждом регионе, соедините оба VPC с туннелем IPSec / VPN. JP содержит только веб-серверы, все остальные сервисы остаются в США.
    • Тем не менее, между США и Японией существует задержка.
  3. Использование оптимизатора WAN для VPN-туннеля в # 2
    • У кого-нибудь есть опыт по этому поводу? Я не смог найти много в Google для оптимизации VPC-to-VPC ...
  4. Использование Railgun от CloudFlare
    • Нам нужно только установить прослушиватель Railgun на веб-серверах США.
    • Намного проще, нам даже не нужно ничего, работающего в JP

Мои вопросы:

Любая помощь будет оценена, спасибо: D

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

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

Хорошая книга с множеством идей и источником приведенного выше графика Высокопроизводительная сеть браузера от веб-инженера Ильи Григорика.

Что наиболее экономично / оптимально зависит от ваш конкретный сценарий, ваша кодовая база и требует тщательного тестирования. Нет единственного решения волшебной инфраструктуры.

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

Интересные уроки можно найти на Блог о высокой масштабируемости

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

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

Вам нужно найти компромисс между пользовательским опытом и долларами. Во-первых, я хотел бы знать, сколько пользователей в процентном отношении приходят из Азиатско-Тихоокеанского региона. Если оно меньше, чем допустим, 10%, лучше всего подождать, чтобы увидеть, что произойдет.

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

С учетом всего сказанного, вы нашли правильный набор опций.

Мне больше всего нравится твой вариант 2. Я бы поставил как можно больше прокси / веб-серверов как можно ближе к большему количеству пользователей. Несмотря на то, что некоторый трафик всегда должен возвращаться в ваше местоположение us-east-1, завершение первого соединения в регионе приведет к гораздо лучшему взаимодействию с пользователем. Подумайте об SSL-соединениях.

Я бы также посмотрел на SPDY.

Я бы также подумал о переходе с нас-восток-1 на нас-запад-2 для вашего присутствия в США.

VPN-туннели - хорошая идея, и их не так сложно настроить.

Я бы настроил резервные туннели с использованием OpenVPN.