Web HighLoad - 我们如何管理数万个域的流量

DDoS-Guard 网络上的合法流量最近超过每秒一百吉比特。 目前，我们 50% 的流量是由客户端 Web 服务产生的。 这些领域有数以万计，各不相同，并且在大多数情况下需要单独的方法。

下面是我们如何管理前端节点并为数十万个站点颁发 SSL 证书。

为一个站点（即使是非常大的站点）设置前台很容易。 我们采用 nginx、haproxy 或 lighttpd，根据指南进行配置，然后就不用管它了。 如果我们需要更改某些内容，我们会重新加载并再次忘记。

当您动态处理大量流量、评估请求的合法性、压缩和缓存用户内容并同时每秒多次更改参数时，一切都会发生变化。 用户希望在更改个人帐户中的设置后立即在所有外部节点上看到结果。 用户还可以通过 API 下载数千个（有时是数万个）具有单独流量处理参数的域。 所有这一切也应该立即在美国、欧洲和亚洲发挥作用——考虑到仅在莫斯科就有几个物理上分离的过滤节点，这项任务并不是最微不足道的。

为什么全球有很多大型可靠节点？

• 客户端流量的服务质量 - 来自美国的请求需要在美国进行处理（包括攻击、解析和其他异常情况），而不是拉到莫斯科或欧洲，从而意外地增加处理延迟。

• 攻击流量必须本地化——交通运营商在攻击期间可能会降级，其流量通常超过 1Tbps。 通过跨大西洋或跨亚洲链路传输攻击流量并不是一个好主意。 我们有真实的案例，一级运营商说：“你们收到的攻击量对我们来说是危险的。” 这就是为什么我们接受尽可能接近其来源的传入流。

• 对服务连续性的严格要求 - 在我们瞬息万变的世界中，清洁中心不应相互依赖或依赖于当地事件。 您是否已将 MMTS-11 全部 9 层的电源切断一周？ - 没问题。 在此特定位置没有物理连接的任何客户端都不会受到影响，并且 Web 服务在任何情况下都不会受到影响。

如何管理这一切？

服务配置应尽快（最好是立即）分发到所有前端节点。 你不能只获取并重建文本配置并在每次更改时重新启动守护进程 - 相同的 nginx 会使进程关闭（工作进程关闭）几分钟（如果有很长的 websocket 会话，则可能需要几个小时）。

重新加载nginx配置时，出现下图是很正常的：

关于内存利用率：

老工人会吃掉内存，包括不线性依赖于连接数的内存——这是正常的。 当客户端连接关闭时，该内存将被释放。

为什么在 nginx 刚起步时这不是一个问题？ 没有 HTTP/2，没有 WebSocket，没有大量的长保持活动连接。 我们 70% 的网络流量是 HTTP/2，这意味着非常长的连接。

解决方案很简单 - 不要使用 nginx，不要基于文本文件管理前端，当然也不要通过跨太平洋通道发送压缩文本配置。 当然，这些渠道是有保证和保留的，但这并没有降低它们的跨大陆性。

我们有自己的前端服务器平衡器，我将在下面的文章中讨论其内部结构。 它能做的主要事情是每秒动态应用数千次配置更改，而无需重新启动、重新加载、内存消耗突然增加等等。 这与热代码重载非常相似，例如在 Erlang 中。 数据存储在地理分布式键值数据库中，并由前端执行器立即读取。 那些。 您通过莫斯科的 Web 界面或 API 上传 SSL 证书，几秒钟后就可以发送到我们位于洛杉矶的清洁中心。 如果突然发生世界大战，互联网在全世界消失，我们的节点将继续自主工作，并在专用通道之一洛杉矶-阿姆斯特丹-莫斯科、莫斯科-阿姆斯特丹-香港-第一时间修复裂脑- Los-Los 变为可用。洛杉矶或至少其中一个 GRE 备份覆盖。

同样的机制使我们能够立即颁发和续订 Let's Encrypt 证书。 非常简单，它的工作原理如下：

1. 一旦我们看到至少一个针对客户端域的 HTTPS 请求没有证书（或证书过期），接受该请求的外部节点就会将此情况报告给内部证书颁发机构。

   

2. 如果用户没有禁止Let's Encrypt的发行，认证机构会生成一个CSR，从LE接收一个确认令牌，并通过加密通道将其发送到所有前端。 现在任何节点都可以确认来自 LE 的验证请求。

   

3. 稍后，我们将收到正确的证书和私钥，并以相同的方式将其发送到前端。 再次，无需重新启动守护进程

   

4. 过期前7天，启动重新领取证书的程序

目前我们正在实时轮换 350k 证书，对用户完全透明。

在该系列的以下文章中，我将讨论实时处理大型 Web 流量的其他功能 - 例如，使用不完整的数据分析 RTT 以提高中转客​​户的服务质量，以及一般情况下保护中转流量免受影响太比特攻击，关于流量信息的交付和聚合，关于WAF，几乎无限的CDN以及许多用于优化内容交付的机制。

只有注册用户才能参与调查。 登录拜托

您想首先了解什么？

• 14,3%用于聚类和分析网络流量质量的算法<3

• 33,3%DDoS-Guard7 平衡器的内部结构

• 9,5%保护传输 L3/L4 流量2

• 0,0%保护网站的中转流量0

• 14,3%Web 应用程序防火墙3

• 28,6%防止解析和点击6

21 位用户投票。 6 位用户弃权。

来源： habr.com