我正在尝试在AWS云上设计具有一定级别的SLA(例如99.99)的系统。 我的体系结构的要素之一是CloudFront,目前,我正在努力了解是否有可能通过引入冗余来提高其可用性。通常,它可以正常工作,例如ECS容器或EC2实例或RDS,但对于Cloudfront是不可能的(据我所知)。
到目前为止我所拥有的:
here它表示SLA从99到99.9
and here它说我可以增加具有多个Origins(CDN)的可用性,但是对我来说,似乎我会增加CDN的可用性,而不是CloudFront服务本身,对吗?< / p>
有人可以纠正我的理解是否正确或/并解释为CloudFront服务增加SLA的正确方法吗?
答案 0 :(得分:2)
在疯狂尝试设计高级SLA系统之前,请仔细考虑。以适中的成本实现99.9%的正常运行时间相当容易。超出这一范围,您的成本就会迅速上升。对于每个添加项9,请考虑将成本增加10倍至100倍。该成本包括云基础架构,管理,监视和警报软件以及人员成本。您将花费大量时间来管理SLA大于3个9(99.9%)的系统。
99.99%的utime意味着每周仅停机1分钟。这包括您需要花费时间来修补操作系统,更新软件,备份等。您每周可以在1分钟内完成所有这些工作吗?如果没有,您将不会达到4个9(99.99%)。犯了一个错误,您的4个9球目标将变成2个9球。
Amazon CloudFront可提供99.9%的正常运行时间。很好要想走得更高,您需要提供多个来源(CloudFront缓存并交付给最终用户的数据源)。您的原点成本只是价格的两倍,还不包括使两个原点之间保持全天候24x7同步的工作量。任何停机时间或您的来历和4个9的问题都没有出现。
答案 1 :(得分:0)
正如其他人提到的那样,这将带来更多的成本和复杂性,所以我的主意如下:
您可以借助Route53(SLA为100%)提高可用性。
首先,我将拥有在Cloudfront上通过其他服务(例如EC2)服务的对象的副本(请参阅复杂性如何开始增长)。
然后,您需要设置故障转移路由策略。基本上Route53会检查您的Cloudfront分发的运行状况,如果运行状况不正常,则流量将故障转移到EC2。
现在您的SLA将提高到99.89%(99.99%EC2 * 99.9%Cloudfront)
答案 2 :(得分:0)
将 CloudFront 视为 CDN(类似于 Akamai 和其他 CDN)。 IE。它是静态内容的缓存,可以驻留在 S3 或其他来源上。即使 CloudFront 出现故障,您的系统仍然有 99.99% 可用(如果这样设计),因为您的系统边界是 VPC 边缘,而不是 CloudFront、Route53、S3 等(这些被您的系统视为外部接口并且在公共区域除非您与他们建立私人联系)。