我有 2 个 VPC，一个在 us-east-1，另一个在 ap-northeast-1，它们之间有一个 OpenVPN 隧道。
根据我的 ping 测试，两个地区之间的延迟约为 160-180 毫秒。假设所有服务（数据库、缓存、队列/工作器等）必须保留在美国，而只有 Web 服务器将部署到日本。通过日本 Web 服务器访问美国的这些服务将产生巨大的延迟。
AWS 市场上有“WAN 优化/加速”产品。但我似乎无法从 Google 上找到太多信息。
- 银峰
- 接受条款后，我被迫“享受” 30 天的免费试用期。我在美国启动了一个，在日本启动了另一个，然后尝试将它们连接到隧道中……然后它抱怨许可证密钥重复，因为两个实例中的试用密钥是相同的……
- 云优化
- 在两个地区启动后完全不知道该如何设置。用户界面和知识库都很糟糕。
- 云桥
- 我认为这会好得多，因为它来自一个大牌。但是在“入门向导”的第一步中，它只是一直说我的 AWS 凭证不正确并且不让我通过。
有谁有优化 VPC 之间 WAN 链路的经验？我不确定我的做法是否正确，还有其他方法可以实现同样的效果吗（减少延迟并确保区域之间的网络速度足够好）？
答案1
假设您的 OpenVPN 隧道与没有 OpenVPN 的站点之间的 RTT 相比不会显著增加链接的往返时间 (RTT)，那么没有任何技术可以真正将实际 RTT 降低到底层链接的 RTT 以下。
您受到物理定律（信号通过电线和光纤电缆的传播延迟，以及可能到卫星和返回的传播延迟，尽管后者似乎不太可能，或者 RTT 会更糟）以及区域内和区域之间的中间路由器交换数据包的速度的限制。
使用非常近似的数字（7,000 英里 x 2，真空中光速的 2/3），我会说延迟的 ~113ms 只是光从一个地方传播到另一个地方并返回的最佳时间。没有什么可以消除这一点。
压缩类似于在飞机上搭载更多乘客或驾驶更大的飞机，在单位时间内通过给定容量的链路传输更多数据，但没有单个乘客在运输过程中花费的时间会减少。
各种形式的缓存也可以给人一种数据检索速度更快的便利错觉，但未缓存的数据并不能比正常情况更快地到达。
如果 OpenVPN 没有增加任何明显的额外延迟（根据我的经验，它不应该这样），那么您就找不到灵丹妙药的解决方案。
您的应用程序架构可能必须适应这种本质上基本的延迟，包括数据库读取副本、本地队列（甚至可能用于处理非关键数据库写入的最终执行）以及更高效的数据库访问。
答案2
所有 WAN 优化产品都是缓存。知道为什么不直接将标准缓存（如 memcached、mysql/percona 从属服务器、nginix/varnish）部署到日本 VPC？我会真正深入了解您正在部署的 WAN 优化产品，它们可能只是在一个漂亮的包中利用了这种类型的缓存。