AWS NLB TLS监听器对MQTT设备耗电的影响分析

背景

在将EMQX部署到EKS集群时，我们使用AWS Network Load Balancer(NLB)作为入口负载均衡器。为了优化性能,我们选择将SSL/TLS终止放在NLB层面而不是EMQX层面。这种架构可以减轻EMQX的计算负担，但也带来了一些意想不到的问题。

问题描述

在实际运行中,我们发现连接到MQTT服务器的IoT设备的电池消耗比预期要高。经过排查，发现这与AWS NLB的TLS监听器的一个特性有关。

根据AWS官方文档，当TLS监听器从客户端或目标接收TCP keepalive包时，负载均衡器会生成TCP keepalive包，并每20秒将它们发送到前端和后端连接。这个行为是固定的，无法修改。

1
客户端 <-- TCP Keepalive(每20秒) --> NLB <-- TCP Keepalive(每20秒) --> EMQX

影响分析

1. 设备耗电增加

对于IoT设备来说,频繁的网络通信会显著增加电池消耗。每20秒一次的keepalive通信意味着:

  • 设备无法进入深度休眠状态
  • 无线模块需要频繁唤醒
  • 增加了不必要的数据传输

2. 网络开销

虽然keepalive包很小,但在大规模部署场景下:

  • 产生额外的网络流量
  • 增加了带宽成本
  • 对网络设备造成额外负担

可能的解决方案

方案1: 将SSL终止移至EMQX层

优点:

  • 可以完全控制keepalive行为
  • 避免NLB的固定keepalive机制

缺点:

  • 增加EMQX的CPU负载
  • 需要在EMQX中管理证书
  • SSL/TLS解密会消耗更多资源

方案2: 使用Application Load Balancer(ALB)

优点:

  • ALB对WebSocket连接有更好的支持
  • 可以配置更灵活的空闲超时时间

缺点:

  • ALB不支持纯TCP/MQTT协议
  • 需要将MQTT over WebSocket作为主要协议

方案3: 直接暴露EMQX服务

优点:

  • 完全控制所有网络参数
  • 没有中间层的限制

缺点:

  • 失去负载均衡能力
  • 需要自行处理高可用
  • 安全性需要额外考虑

最终选择

经过评估,我们最终选择了方案1 - 将SSL终止移至EMQX层:

  1. 将SSL/TLS终止配置在EMQX集群:

    • 直接在EMQX中管理证书
    • 完全控制keepalive参数

  2. 优化配置:

    • 根据设备类型设置合理的keepalive时间
    • 调整EMQX的资源配置以应对SSL解密负载

  3. 监控措施:

    • 密切关注EMQX的CPU使用率
    • 建立SSL性能指标的监控

经验总结

  1. 在设计云原生架构时,需要充分考虑基础设施组件的特性
  2. IoT设备的能耗优化需要从整个技术栈考虑
  3. 有时候”完美”的架构方案可能带来意想不到的问题
  4. 根据实际场景做出合适的技术选择很重要

参考资料

本文基于实际运维经验总结，如有更好的解决方案欢迎讨论。