У меня есть 2 VPC, один в us-east-1, а другой в ap-northeast-1, с туннелем OpenVPN между ними.
Согласно моему тесту ping, задержка между двумя регионами составляет ~ 160-180 мс. Предполагая, что все службы (БД, кеширование, очередь / рабочие и т. Д.) Должны оставаться в США, в то время как в JP будут развернуты только веб-серверы. Доступ к этим сервисам в США для веб-серверов JP будет огромной.
На торговой площадке AWS есть продукты для оптимизации / ускорения WAN. Но я не могу найти много информации в Google.
У кого-нибудь есть опыт оптимизации WAN-канала между VPC? Я не уверен, что я на правильном пути, есть ли другие способы добиться того же (уменьшить задержку и обеспечить достаточно хорошую скорость сети между регионами)?
Предполагая, что ваш туннель OpenVPN не увеличивает значительно время приема-передачи (RTT) ссылки по сравнению с RTT между сайтами без OpenVPN, нет технологии, которая действительно может уменьшить фактический RTT ниже, чем у базовых ссылок. .
Вы ограничены законами физики (задержка распространения сигналов по проводам и оптоволоконным кабелям и, возможно, к спутнику и обратно, хотя последнее кажется маловероятным, иначе RTT будет еще хуже) и скоростью, с которой промежуточные маршрутизаторы внутри и между регионами могут переключать пакеты.
Используя чрезвычайно круглые числа (7000 миль x 2, при 2/3 скорости света в вакууме), я бы сказал, что ~ 113 мс вашей задержки - это просто лучший случай, когда свет перемещается из одного места в другое и обратно. очередной раз. Ничто не может этого устранить.
Сжатие, аналогично упаковке большего количества пассажиров в самолет или полет на больших самолетах, позволяет получать больше данных по каналу связи заданной пропускной способности в единицу времени, но ни один пассажир не тратит меньше времени в пути.
Кэширование в его различных формах также может создавать удобную иллюзию более быстрого извлечения данных, но некэшированные данные не могут поступать быстрее, чем обычно.
Если OpenVPN не добавляет заметной дополнительной задержки (а, по моему опыту, этого не должно быть), вы не найдете волшебного решения.
Архитектура вашего приложения, вероятно, должна будет адаптироваться, чтобы приспособиться к этой существенной задержке, включая реплики чтения базы данных, локальные очереди (возможно, даже для обработки возможного выполнения некритических записей в базу данных) и более эффективный доступ к базе данных.
Все продукты для оптимизации WAN - это кеши. Зная это, почему бы просто не развернуть стандартные кеши, такие как подчиненные серверы memcached, mysql / percona, nginix / varnish, в VPC Японии? Я бы действительно заглянул за кулисы в продукты оптимизации WAN, которые вы развертывали, они, вероятно, просто используют эти типы кешей в красивом пакете.