AWS – 如何更快地向海外用户提供服务

我们在美国东部地区拥有依靠AWS的基础设施。 (EC2,CloudFront,RDS,ElastiCache)

我们现在有越来越多的亚太地区用户。 用户开始抱怨networking速度到我们的网站。 (请注意,我们已经在使用CloudFront来提供静态资产)

研究后的一些线索:

  1. 克隆亚太地区的一系列基础设施(如JP)
    • $$关心
    • 一个快速testing发现的事实:我们之间的等待时间约为160-180ms。
    • 在我们的情况下不是真的可行。 虽然我们可以在JP中创build数据库只读副本,但是Web服务器仍然必须向美国发送写入操作。
    • ElastiCache不支持跨区域。 即。 美国的ElastiCache只能由美国的ec2实例访问。
  2. 每个区域内的VPC将VPC与IPSec / VPN隧道互连。 JP只包含Web服务器,其他所有服务都保留在美国。
    • 不过,美国和日本之间还有延迟
  3. 在#2中使用WAN优化器作为VPN隧道
    • 任何人都有这方面的经验? 在VPC-to-VPC优化中,我找不到在google中的很多…
  4. 使用CloudFlare的Railgun
    • 我们只需要在美国networking服务器上安装Railgun监听器
    • 太简单了,我们甚至不需要在JP中运行任何东西

我的问题:

  • 什么是最好的方式/行业最佳实践? 扩大到另一个地区? 我知道一些公司只在一个地区拥有自己的基础设施,但是他们如何确保海外用户的速度?
  • 对于#2,永久隧道的帮助吗?
  • 对于#2 /#3,假设区域之间的延迟和networking速度可以被优化,是否真的有必要在JP中有Web服务器? 如何在JP中只有代理服务器向美国Web服务器发送代理请求?

任何帮助将不胜感激,谢谢:D

世界是一个相当大的地方,虽然networking带宽正在稳步增长,世界的一部分和世界的另一端之间的networking延迟不会很快消失。

在多个级别进行优化和调优可以改善用户体验,但是最终你会达到提高性能的唯一可行方法,通过让数据距离最终用户更近,从而减less延迟。

http://chimera.labs.oreilly.com/books/1230000000545/ch10.html#MORE_BANDWIDTH_DOESNT_MATTER_MUCH

Web性能工程师Ilya Grigorik的高性能浏览器networking ( High Performance Browser Networking)是一本有很多见解和上面图表来源的好书。

什么是最经济/最优的取决于您的具体情况,您的代码库,需要仔细的testing。 没有神奇的基础设施解决scheme。

大多数需要大规模扩展的应用程序需要经过一次或多次重新devise才能解决这个问题。 devise的select,技术和假设,似乎有效的X用户量将被certificate是错误的100或1000倍。

有趣的经验教训可以在高可扩展性博客上find

重新devise你的应用程序代码,以便更好地cachingdynamic内容是一种方法,例如,看看varnish模型,它允许你的web应用程序无效caching的dynamic内容点播,当很多dynamic内容实际上并不需要为每个请求完全重新生成。 这应该允许您更好地使用CDN,并且意味着您可以保持在单个可用区域内。

重新devise您的应用程序,使其能够在多个可用区域上工作,也将改善灾难恢复,不仅可以提高国际用户的性能。

您必须在用户体验和美元之间进行权衡。 首先,我想知道亚太地区有多less用户来自亚太地区。 如果这个数字低于10%,那么你最好采取的行动就是等待看看会发生什么。

你也不会说你支持哪种types的应用程序,以及它对延迟的敏感程度。 如果是实时video聊天应用程序,则会做出一个决定,如果这是最终一致的社交媒体应用程序,则会做出决定。

所有这一切,你已经find了正确的select。

我最喜欢你的select2。 我尽可能多地将代理/ Web服务放在尽可能接近大多数用户的位置。 尽pipe有些stream量总是要返回到您的位置,但第一个连接终止在区域内会带来更好的用户体验。 思考SSL往返。

我也看看SPDY 。

我也想为你们的美国存在而从我们东1转到美西2。

VPN隧道是一个好主意,不难设置。

我会设置使用OpenVPN的冗余隧道 。