国外合法性直播软件,国外合法性直播软件有哪些?

twitch是世界上最大的个人流媒体直播平台,客户端观看Twitch的方式有很多,包括桌面浏览器、移动设备、游戏机和电视应用程序。客户端交付平台团队拥有向用户交付Twitch客户端的基础设施。去年,我们为我们的一个关键微服务设计了下一代高可用性防御措施,将可用性从99.9%(3个9)提高到99.99%(4个9)。

在这篇文章中,我将分享我们的设计、指导原则和结果。

每当你为一个服务设计高可用性时,你都应该考虑到常见的考虑因素(适用于任何云服务)以及你的服务的特定机会。云计算高可用性的基础知识是众所周知的,比如使用冗余来避免单点故障。我们将讨论我们在基础知识之外所做的事情。

指导原则

我们制定了以下高可用性原则。

  • 像对待安全一样对待可用性。
  • 实行深度防御。
  • 将你的内容交付网络(CDN)作为一个完整的合作伙伴来保护你的服务。
  • 为服务的不可用性设计故障转移机制。
  • 将超额配置作为一项长期防御措施。
  • 准备好在你需要时迅速增加容量。
  • 使用比例配置来平衡超额配置和成本。
  • 定期分析负载并调整服务分配。
  • 考虑可用性决定对其他领域的影响,如延迟。
  • 对警报进行投资,并避免错误警报和不知情的极端情况。
  • 不要依赖常设防御:对攻击作出反应。
  • 优化你的服务以获得最大的效率。
  • 致力于持续创新和不断改进。

交付网络平台

通常一天有3000万人访问www.twitch.tv。作为回应,Twitch网络平台是一个单页应用程序,由一个名为Sage的微服务与CDN合作向浏览器提供。Sage的工作是提供index.html。这听起来很简单,但Sage还支持金丝雀发布、A/B测试、政策执行和搜索引擎元数据检索。如果Sage不能完成它的工作,用户就不能到达Twitch,也就不能享受Twitch提供的实时视频、聊天和其他一切。一旦网络平台被加载,Sage就不在了,其他服务支持观看体验。因此,我们关心Sage的高可用性,因为你只有一次机会,给人留下第一印象。

让我们来定义一些指标。我们正在衡量可用性,即Sage服务负载平衡器的无错误率,每周报告一次。一个相关的指标是交付率,即从CDN到浏览器的无差错率。可用性衡量的是服务,而交付能力衡量的是实际的客户体验。

Sage在全球十几个AWS数据中心运行,由数百个CDN存在点支撑。它一直是高度超额配置的,作为对拒绝服务攻击和活动波动的一种保障。Sage是一个你永远不必担心的可靠服务,直到有一天我们担心了。去年,我们注意到Sage的可用性在3月的一天略低于99.9%。3个9的可用性是对所有关键Twitch服务的最低期望。当这种情况第二次发生时,我们采取了短期行动,将受影响地区的服务器增加了三倍,同时我们进行了深入分析,并决定在长期基础上做什么。

威胁建模:像对待安全一样对待可用性

对Sage的DDOS攻击是是正常负载的数倍的突发请求,突然爆发通常可以轻松处理,但如果超过了容量,一些用户将开始收到5xx错误。分布式拒绝服务(DDOS)攻击同时袭击多个地区。它们通常在几分钟的时间内就结束了,但有时也会延长。由于一个热门事件引起的浪涌可能持续数小时甚至数天。

并非所有的可用性威胁都是敌对的。流量的增加可能是出于完全无辜的原因,比如增长,或者是在一个意料之外的、疯狂的、流行的事件中激增。无论意图如何,对可用性的挑战就意味着战争

中世纪的城堡是可视化可用性防御的一个很好的比喻,所以我们将把我们的原则与城堡防御联系起来。虽然这似乎更适合于安全讨论,但你不能把可用性与安全分开,许多安全设计的工具同样适用于可用性。其中最主要的是威胁建模。我们首先从服务中断开始倒推,确定什么会导致或促成故障的发生。然后,我们为这些漏洞设计缓解措施。

深入防御;多层防御

城堡实行纵深防御,即分层防御的技术,以削弱和打击攻击者的士气。一些防御措施是显而易见的,如高而厚的石墙。其他的则是隐藏的,在需要时才会保密。当攻击者越过一个可怕的防御,他们就会遇到另一个。

攻入城堡意味着要克服大量的防御措施,包括自然特征、周围的城镇、护城河、吊桥、门闩、弓箭手、垛口、谋杀洞、外墙、内墙和守卫塔。

深度防御在中世纪是很有效的,今天它仍然是一种受人尊敬的防御策略。

深度防御对可用性至关重要,因为我们不能依靠任何一种机制来完全保护我们。我们利用多个冗余的防御层来提供卓越的保护。当攻击者穿透一个防御层时,后面还有另一个防御层–削弱攻击者的决心和资源,使进一步攻击变得不值得。我们的每一个防御机制都是深度防御马赛克的一部分。

从头到尾思考:CDN防御系统

在攻击者到达城堡之前,他们必须首先越过外围的防御设施。城堡利用了周围地区的自然特征,如悬崖和河流。位于山丘或山脉上的城堡更容易发现入侵者,而敌人也更难将士兵和武器转移到位置上。周围的城镇是防御系统的一个组成部分。镇民们被期望既能保卫城堡,又能对入侵者发出警报。城堡周围充满水的护城河阻止了隧道的建设。

CDN是我们认识敌对交通并对其采取行动的第一个机会。对于Sage来说,CDN可以识别和过滤已知的不需要的机器人,同时传递友好的机器人,如搜索引擎爬虫。在长时间的攻击中,如果我们能够识别攻击者流量的显著特征,我们可以配置CDN来拦截它。

当一座城堡被围攻时,攻击者会隔离城堡,切断其食物和水的供应。供应充足的城堡有足够的储备来等待漫长的围困。1226年对凯尼沃斯城堡的围攻持续了6个月,直到占领者耗尽了食物而投降。城市可以拖得更久:1648-1669年对坎迪亚的围攻持续了21年!

服务所有者同样必须考虑当资源匮乏时该怎么办。我们的高级系统工程师James Hartshorn设计了一个设施,我们称之为Sage Origin Backup。Sage和CDN通常不缓存index.html,因为新版本的发布很频繁。然而,我们确实缓存了最新版本的index.html,用于故障转移。当Sage不可用并以5xx错误响应请求时,CDN会介入并提供一个过时的index.html来代替它。用户完全没有意识到服务的中断,也没有受到影响。虽然绕过Sage意味着没有服务的业务逻辑,但这只是短暂的,而且保留了提供index.html这一重要的任务。

为了衡量这种做法的有效性,我们跟踪了一个名为 "送达率 "的指标,它告诉我们客户从CDN收到200个响应与5xx个错误的频率。由于这一明显有效的机制,大多数星期我们都达到了5个9的送达率。

外墙:过度校验是你的常设防御

城堡防御最明显的一层是其厚厚的石墙,也叫幕墙。每个人都知道城堡墙的重要性。它是你的常备防御,是保护你的基础。在视觉上具有威慑力,墙是不断提醒可能的攻击者城堡的完整性。

城堡墙的服务相当于我们的供应水平,即每个区域的容量大小。当攻击突然到来时,在没有任何警告的情况下,我们的常备防御需要足够。我们不是为标准负荷而是为标准攻击负荷分配容量。

传统上,Sage一直在全球十几个AWS数据中心的数百台服务器上运行,所有这些服务器都被高度超额配置,以防范拒绝服务攻击。每个地区都有相同的容量。虽然这种安排多年来一直运行良好,但随着时间的推移,有些事情已经发生了变化。Twitch的流量增加了:我们是否仍然有足够的供应?世界各地的负载差异有多大?我们甚至在正确的地区吗?

我们试图更好地了解我们的流量和负载。分析显示,地区负载差异很大:我们最繁忙的地区的流量是最不繁忙的地区的24倍!此外,有些地区更容易出现问题。此外,一些地区比其他地区更容易受到拒绝服务攻击。这意味着我们的 "厚墙 "保护并不像我们认为的那样厚。

所有流量的45%只通过两个数据中心,这也是令人不舒服的:虽然没有容量的问题,但一个完整的区域中断可能会影响到我们很大一部分用户。

我们研究了我们的流量频率分布,以了解每个区域所承受的峰值负荷。由此产生的各地区每小时请求的堆积图使我们能够对每个地区的负载进行分析。我们还研究了每分钟的请求,以了解激增的强度。

有了这些洞察力,我们将Sage从一个固定的供应模式转移到一个按比例的供应模式。我们根据测量的负载,乘以超额配置系数来调整我们的区域分配。我们还在欧洲增加了更多的区域来分配负载。因此,Sage现在有非常不同的区域分配,但每个区域的保护量是相等的。我们的比例配置方法确保每个地区都得到充分的保护,同时又不浪费。尽管增加了新的地区,但每月的费用只增加了1.5%,因为这种重新分配供应的方式减少了许多地区的分配。

内墙:增加容量

1300年代后,一个防御良好的城堡有两道墙。如果入侵者突破了外墙,还有另一道更高的墙要对付。守卫者会把箭和热焦油射向攻击者,他们被夹在墙之间的狭窄区域。

如果常设供应是你的外墙,那么增加的能力就是你的内墙。无论你的配置有多好,超过这个水平所需要的只是一个足够的流量。你增加的容量可以来自于自动扩展,手动增加容量,或者当你预测到负载变化时计划增加容量。你很容易认为自动扩展是你需要的全部,但这有其局限性。自动扩展可以在几分钟内建立新的实例,但DDOS攻击可能在这段时间内完全结束,并扰乱你的可用性。对于长期的负载挑战,如流量的意外增加或负载的季节性变化,自动扩展仍然是非常有用的。

Twitch上的一个热门活动可以吸引一百万或更多的观众。我们经常会收到关于这类事件的提前扩展通知,如果我们认为有必要,可以增加容量。然而,有些流量的增加是意外的,我们必须做好准备。对于Sage来说,我们对我们的供应水平和服务效率有信心,以应对短期的负载激增。在长期的负载挑战中,一旦达到一定的服务错误阈值,我们会临时增加容量。在新容量上线之前发生的任何服务错误都会被CDN的Sage Origin备份功能所覆盖,不会影响到客户。

更高的效率意味着更多的能力和更低的成本

效率在中世纪的战争中发挥了重要作用。长弓的到来在百年战争中发挥了巨大的作用,因为它射得更快,穿得更远,同时制造起来也更容易,成本更低。

Sage是一个在Linux上运行的C#.NET核心服务,一直被认为是一个高效的服务。

我们的高级软件工程师Felix Kastner看到了通过消除多余的软件层和分块应用响应压缩来获得进一步效率的机会。他推测这些优化将使性能至少提高100%。实际的性能改进是5000%。这种恒定的50倍的性能提高意味着我们可以在降低成本的同时提高Sage的容量:由于每个实例能够承载更多的负载,因此需要的数量更少。

创新和持续改进是关键

中世纪的战争比人们所描述的更为复杂,它需要不断的创新来跟上时代的变化。像长弓和大炮这样的新武器具有高度的破坏性,必须用新的防御和战略来应对。城邦雇佣了最好的人来设计武器和防御措施。达芬奇被聘为军事建筑师和工程师,他为威尼斯和切萨雷-博尔吉亚发明了战争机器和防御措施。

服务的可用性需要同样的创新承诺。攻击者不会停滞不前,你的防御系统也不能。前面描述的Sage Origin Backup的创新使5个9的交付率成为可能。赛捷的优化创新使我们能够在降低成本的同时提高容量。我们每周审查运营活动,问自己哪些方面需要改进。当一个破坏性的事件发生时,我们会充分分析错误的原因,以及为避免再次发生需要做的事情。

我们在一起:战略性可用性决策

当Sage最初被配置时,可供选择的AWS地区少得多。在我们的分析和按比例配置工作中,我们有机会在欧洲增加地区。我们增加新地区的主要动机是减少我们最繁忙地区的负担,但由于我们有新地区的选择,我们战略性地选择了它们,希望能看到延迟的改善。我们在AWS巴黎增加了Sage的存在,以改善法国的观众体验,众所周知,法国的内部连接良好,但与其他国家的连接较差。我们在AWS斯德哥尔摩增加了办事处,以便更接近俄罗斯,一个拥有大量Twitch观众的国家。这些变化的延迟影响很大:欧洲的延迟减少了27%,俄罗斯的延迟减少了52%。

这说明了共同考虑可用性、延迟和安全性等领域的价值,而不是把它们当作孤立的主题。

经验之谈

像对待安全一样对待高可用性,允许你使用威胁建模和其他安全工具来识别漏洞和设计防御措施。实行深度防御,以达到卓越的可用性覆盖。

充分利用你的CDN来过滤恶意流量并建立故障转移机制。也要准备好一个替代的CDN。测试你的故障转移机制,以便你知道它们的工作。

超额配置作为一个长期的防御,并准备在你需要时增加更多的容量。定期分析负载并调整你的分配。使用比例配置来平衡分配水平和成本。优化你的服务,以较低的成本增加容量。

测量可用性指标并投资于警报。调整你的警报,以避免错误的警报和不知情的情况。不要依赖你的常设防御系统:准备好自动和手动反应。

即使有良好的保护措施,也不要对可用性感到自满。致力于持续的创新和改进。审查操作,在事件发生后发明改进措施,并重复进行。

原文链接在:https://www.jdon.com/59281

本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容, 请发送邮件至 313694832@qq.com 举报,一经查实,本站将立刻删除。
如若转载,请注明出处:https://www.zhangfen6.com/28003.html