多区域时的AWS架构

Question

我最近被介绍到AWS,我真的很喜欢它.但是,我问自己一些关于多区域架构的问题(可能是愚蠢的).

假设一个应用程序被欧洲人和亚洲人使用.我的第一个想法是在欧洲添加EC2实例,以及在欧洲保存静态数据和SQS队列以及ElastiCache的S3存储桶.对于欧洲人来说,这将是非常快的,但对亚洲人来说则要慢一些.

为了解决这个问题,我将为静态数据添加C​​loudFront,以便为亚洲人快速提供图像.但是,对服务器的请求(Ajax请求......)仍然会有一些延迟,因此解决方案是在新加坡/东京地区添加EC2实例.

然而,出现了新的问题:如果请求被分派到东京EC2实例,那么如果它需要从SQS接收存储在欧洲的消息或访问ElastiCache数据=>延迟再次+区域间转移的成本.那么我们还需要在亚洲添加SQS和ElastiCache吗？

也许我错过了一些东西,跨区域的AWS请求速度非常快,但据我所知,如果我们想要多区域的快速体验,我们基本上需要在每个区域复制所有服务(除了S3可能,如我们可以使用CloudFront,如果亚洲的SQS工作需要访问欧洲的S3资源,我想我们可以忍受延迟.

无论如何,我是否理解正确？您是否有任何关于如何针对多个区域的架构应用程序的资源？

谢谢 :)

Answer 1

这些都不是愚蠢的问题!这部分绝对正确:

Maybe I miss something, and cross-regions AWS requests are super-fast, but from
what I've understood, if we want fast experience for multi-regions, we basically
need to duplicate all services too every regions

跨区域请求将受到光速和区域之间的网络拓扑的限制.我希望亚洲的请求能够在大约1/4的往返时间内到达欧洲申请.大多数请求会更快,但您无法保证所有请求都会更快,因此您必须相应地进行设计.如果这还不够快,那么是的,您需要部署到更近的区域并将用户路由到适当的区域.需要往返的次数取决于您的应用程序的体系结构.如果您对Elasticache或SQS有很多请求,那么1/4秒将非常快速地加起来.如果您可以批量处理请求,则可能是可以容忍的.

要将用户路由到适当的区域,您需要查看Route 53,它是AWS系列的另一部分. 关于Route 53的这一公告描述了您需要的区域之间基于延迟的路由.将用户路由到相应的EC2实例后,应将您部署到的每个区域隔离.您可以使用EC2,SQS,Elasticache以及欧洲地区(eu-west-1)提供的任何其他AWS产品配置您的欧洲部署.对于您的亚洲部署,您可以将其全部托管在ap-southeast-1区域.一旦Route 53将亚洲用户连接到ap-southeast-1内的EC2实例,对SQS,Elasticache等的请求将在同一区域内,因此非常快.