AWS Re:Invent 从AWS CTO演讲的教训看AI云基础设施架构

AWS Re:Invent CTO专场 ^[1] , Werner Vogels博士并没有发布任何新的产品, 而是把他入职亚马逊20年的宝贵的经验和教训分享出来, 当复杂性是不可避免时, 告诉大家拥抱简单性(Simplexity), 这些经验在我们构建新的AI云基础设施时是尤为重要的.

Simplexity, 拥抱简单

Werner博士引用了Tesler's Law

提醒了参会者:“复杂性既不能被创造也不能被摧毁，它只能转移到其他地方。”

举个例子吧, 例如RoCE网络中的PFC/ECN, 你以为自己很简单的解决了复杂性, 其实把问题转移到了其它地方, 如同下面这个矩阵转置的笑话.

复杂性告警通常有如下几个标志: 软件特性迭代降速, 频繁升级, 调试耗时, 代码库增长过多, 模式不一致, 无处不在的依赖等

对于如何把复杂性(Complexity)变为Simplexity(简单性), werner博士剧了一个很形象的例子: 自行车

独轮车虽然组件最少, 看起来最简单, 却在实际操作运维中很困难, 需要很高的技术能力的团队努力才能实现. 而三轮车虽然组件多, 稳定性更好, 但是灵活度上却带来的一定的限制, 例如转弯不方便.

而普通两轮的自行车介于两者之间, 提供了最佳的平衡, 既灵活又易于控制. 其设计到到了功能和体验的最佳平衡, 因此也成了最简单易用的交通工具.

对于简单性(Simplexity)的几个教训:

1. 未雨绸缪(Make evolvability a requirement), 构建可演进性架构对复杂性进行可预期管理
2. 化繁为简(Break complexity into pieces), 把复杂性分解成多个高内聚和良好API定义的构建块
3. 组织和架构对齐(Align organization to architecture), 建立小团队, 挑战现状, 鼓励主人翁意识
4. 单元化(Organize into cells), 在复杂系统中,通过单元化缩小影响范围
5. 设计可预期系统(Design Predicatable System), 降低不确定性的影响.
6. 自动化(Automate Complexity), 对于不需要高判断力的事情全部自动化.

详细内容可以参考 《Werner Vogels：20年架构设计，仅道六句箴言！》 ^[2] 我们接下来主要谈一下可演进架构, 这也是AWS一直在Well-Architected框架中提到6大支柱: 弹性/安全/性能/稳定/成本/可持续性.

未雨绸缪

对于一个系统, 随着时间的推移都会发生变化, 因此在设计之初, 就需要确保架构能够去适应新的需求.可演进性是一个系统的基础, 是对复杂性进行可预期管理的先决条件.

公司应该构建能够随着时间推移以可预期方式发展的基础设施, 而不是急于推出1.0产品, 迫使团队接下来几年里将新功能添加到日益不稳定的技术栈上. 其实很多技术架构上的灾难往往都开始于Time-To-Market的赶工, 弄出一个人和代码总有一个能跑的框架...

对于一个可演进的系统, 通常包含如下几个维度:

它需要以商业概念作为模型, 隐藏内部的细节, 提供细粒度的接口, 构建智能的端点并且去中心化, 同时要求可独立部署, 能够很好的进行自动化,符合云原生设计原则, 满足故障隔离, 提供很好的可观测能力以及支持多种范式.

werner博士以S3为例, 最初是一个简单, 耐用且高性价比的云存储服务. 到后来随着客户数量的增加, S3都会对其技术和架构进行改进, 但从不影响现有服务的稳定性. 好比开着飞机换引擎.  这得益于在系统设计时就考虑到了未来升级的需求, 设计了灵活可扩展的架构.

它的演进也很好的诠释了AWS对于云计算的价值主张: 一直都是: 弹性,安全, 性能, 成本,可靠性和可持续性.

Werner博士也提到了Nitro System , 虽然很遗憾今年没有新的Nitro v6发布, 但我接下来会对Nitro做一些更详细的阐述.

从可演进架构上来看, Nitro支持多种范式的部署. Nitro除了在通用计算节点上使用外. 在存储上也通过Nitro+4块盘构建了可解耦的存储小系统

在网络设备上, 例如Trn2使用的交换机上有Nitro

在Trn2上还两个Trainium2芯片配置了8颗Nitro

即便是在Nvidia的GB200上, 宁愿抛弃800Gbps的CX8, 也要选择采用6块200Gbps的Nitro

甚至是在高精度时钟分发上也采用了Nitro

而这背后的本质就是可演进架构的抽象, 就像前面自行车那个例子, 独轮车成本最低但运维难, 而三轮车成本高稳定, 但是不灵活. 最后权衡下的选择就是两轮自行车.

而Nitro vs CX8的定位也是如此, 为什么要坚持使用Nitro接入AWS? 对于云选择何种技术的问题, 还是要回到:弹性/安全/稳定/性能/成本/可持续性

从弹性的角度 , Nitro隐藏了基础设施中的大量的复杂性, 让所有的资源都能 对等 的接入到整个Fabric中, 无论是存储/CPU/GPU等资源, 都可以按照用户的需求进行组织和构建. 这一点非常关键, 在第一天Peter的演讲中也有详细的讲解,根据负载的动态可伸缩的架构.

Nitro把中间的网络/存储的资源动态配置和物理拓扑的复杂性全部隐藏了, 也就是Werner博士讲的, 将这些真正复杂的东西转移到了基础设施这一层, 让用户能够更加专注于业务, 并以业务的需求来使用资源.