☰

AWS - 如何处理全球“往返时间”？

tag-icon • tag-icon amazon-web-services hosting infrastructure
AWS - 如何处理全球“往返时间”？

嘿 serverfault 的朋友们，

想象一下一家提供在 AWS 上运行服务的通用“软件即服务”公司（嘿，这就是我们）。这不需要什么火箭科学，标准的 Web 应用程序照常运行，最终用户智能手机应用程序也是如此。由于客户来自欧洲，自然而然，AWS eu-central-1 区域包含多个租户的所有内容。

现在销售成功赢得了一位客户澳大利亚- 到目前为止一切都很好，因为 Web 应用程序已经可以处理不同的时区、货币和地区。但是：澳大利亚是距离欧洲最远的地方（至少在地球上），因此现在需要相当长的往返时间。每个请求每个方向确实会多出大约 300 毫秒 - 400 毫秒（编辑：在评论中指出 RTT 时这是错误的，我们确实看到了 2x400ms = 800ms 的额外时间HTTPS要求）。

对于上述客户用于管理目的的 Web 应用程序，这完全没问题。渲染的 HTML 稍晚一些，但多亏了 CDN（CloudFront），资产不是问题。

但最终用户智能手机应用程序会受到影响，因为它执行的 JSON 请求较少，但数量较多。它感觉还算“还行”，但绝对不够敏捷。

现在的问题是：如何从最终用户的角度改善时间安排？ 我们已经考虑了一些选择：

  1. 克隆完整软件并将其托管在 AWS ap-southeast-2 中

    好处：性能卓越，易于设置，CI/CD 允许在欧盟和澳大利亚同时部署相同的代码。

    缺点：我们必须维护并支付两套相同的基础设施，数据不能轻易共享，各方面都存在大量重复。

  2. 仅将计算实例移动到 AWS ap-southeast-2

    不可以，因为数据库或 redis 查询会受到往返时间的更大影响，所以不会起作用。

  3. 在 AWS ap-southeast-2 中有一个只读副本，并在 eu-central-1 中执行写入

    比选项 2 更好，但会增加代码的复杂性，而且写入的次数通常也不是那么少。

  4. 在 AWS ap-southeast-2 中启动负载均衡器，并与 VPC 对等连接

    想法：用户连接到 AU 端点，流量通过强大的连接传输到 EU 实例。但是，这显然不会缩短距离，我们不确定潜在的改进（如果有的话？）

有没有人遇到过类似的问题并愿意分享一些见解？

更新：似乎只有第一个 HTTPS 请求非常慢。在深入研究 AWS 负载均衡器选项时，我还注意到AWS 全球加速器可能会有帮助，所以我们做了一些测试。

从本地系统（在欧盟）：

curl -w "dns_resolution: %{time_namelookup}, tcp_established: %{time_connect}, ssl_handshake_done: %{time_appconnect}, TTFB: %{time_starttransfer}\n" -o /dev/null -s "https://saas.example.com/ping" "https://saas.example.com/ping"
dns_resolution: 0,019074, tcp_established: 0,041330, ssl_handshake_done: 0,081763, TTFB: 0,103270
dns_resolution: 0,000071, tcp_established: 0,000075, ssl_handshake_done: 0,000075, TTFB: 0,017285

从 AU（EC2 实例）：

curl -w "dns_resolution: %{time_namelookup}, tcp_established: %{time_connect}, ssl_handshake_done: %{time_appconnect}, TTFB: %{time_starttransfer}\n" -o /dev/null -s "https://saas.example.com/ping" "https://saas.example.com/ping"
dns_resolution: 0,004180, tcp_established: 0,288959, ssl_handshake_done: 0,867298, TTFB: 1,161823
dns_resolution: 0,000030, tcp_established: 0,000032, ssl_handshake_done: 0,000033, TTFB: 0,296621

从 AU 到 AWS Global Accelerator（EC2 实例）：

curl -w "dns_resolution: %{time_namelookup}, tcp_established: %{time_connect}, ssl_handshake_done: %{time_appconnect}, TTFB: %{time_starttransfer}\n" -o /dev/null -s "https://saas-with-global-accelerator.example.com/ping" "https://saas-with-global-accelerator.example.com/ping"
dns_resolution: 0,004176, tcp_established: 0,004913, ssl_handshake_done: 0,869347, TTFB: 1,163484
dns_resolution: 0,000025, tcp_established: 0,000027, ssl_handshake_done: 0,000028, TTFB: 0,294524

简而言之：TLS 握手似乎造成了最大的初始延迟。但是，如果可以重复使用，AU 到 EU 的额外时间似乎实际上“仅”约为 277 毫秒（0.294524 秒 - 0.017285 秒）的首字节时间。

问候！

相关内容