# Powered by 亚马逊云科技：Zilliz 构建企业级 AI 应用的数据底座 > **合规声明（生成式 AI 服务）**：前述特定亚马逊云科技生成式人工智能相关的服务目前在亚马逊云科技海外区域可用。亚马逊云科技中国区域相关云服务由西云数据和光环新网运营，具体信息以中国区域官网为准。 > > **完整资料：如果想了解更多内容可以访问:https://events.amazoncloud.cn/china-summit-on-demand/ > > **免责声明**：本摘要仅为便于您了解峰会内容而提供，我们不对其完整性及准确性作出任何保证，且不构成任何建议或结论。相关内容仅供参考，实际内容以峰会回放视频为准。 ## 一、基础信息 - **会议类型**：专题演讲 - **Persona**：出海实践者 - **时间信息**：6月23日 | 16:00 - 16:30 - **标题**：Powered by 亚马逊云科技：Zilliz 构建企业级 AI 应用的数据底座 - **PDF 资料**：有 - **视频回放**：有 ## 演讲人信息 ### 会议信息 - **地点**：上海世博中心（2026 亚马逊云科技中国峰会） - **日期**：2026年6月23日（Day 1） - **时间**：16:00 - 16:30 - **会议类型**：专题演讲 - **面向 Persona**：出海实践者 ### 亚马逊云科技演讲人 - **Wang Yi**：解决方案架构师 ### 客户 / 合作伙伴演讲人 - **沈亮**（Zilliz）：总监 ## 二、会议资料 PDF 转录内容 --- Page 1 --- Powered by 亚马逊云科技： Zilliz AI 构建企业级 应用的数据底座 Leo Shen Wang Yi Director of Solution Architect Solution Architect Zilliz 亚马逊云科技 --- Page 2 --- Agentic AI 时代，向量数据库角色进化 --- Page 3 --- Zilliz Cloud 产品架构概览 --- Page 4 --- Zilliz Cloud 产品形态 BYOC 自运维 全托管服务 Milvus Zilliz Cloud Zilliz Cloud BYOC AI 广受欢迎的开源向量数据库 驱动的高性能、高扩展向量检索 专为私有化场景打造 API 所有部署形态 统一，业务逻辑代码灵活复用 --- Page 5 --- Zilliz Cloud 遍布全球亚马逊云科技节点的 Overseas Amazon Region --- Page 6 --- 为什么选择亚马逊云科技作为全球化底座 ISV 全球覆盖 一致体验 生态集成 合作 30+ Region Graviton/EKS/S3 Bedrock/PrivateLink/ Partner Network Marketplace 数据本地化合规 全球一致可用 联合销售机制 更短集成路径，更低企业采用 区域先到，业务才能先到 平台能力可复制，交付才可 从技术合作走向商业共赢 门槛 规模化 --- Page 7 --- —— 基于亚马逊云科技的技术实践 计算与存储 16000 Graviton 14582 发挥 的带宽优势： QPS 14000 x86 Graviton 12000 相比传统的 架构， 芯片提供更高的 10052 Zilliz Cloud 100 9302 内存带宽。 相应地调整算法设计，以 8000 降低带宽瓶颈，实现更优的计算性能。 6000 4000 S3 2000 持久化存储： • + 0 向量索引 元数据的分层存储策略 x86 Graviton 3 Graviton 4 • 生命周期管理实现成本精细化 : Cohere 1M 768dim • 30% 数据集 : https://github.com/zilliztech/VectorDBBench 实际存储成本节降约 基准测试工具 : Zilliz Cloud 8CU-perf 主机 --- Page 8 --- —— 基于亚马逊云科技的技术实践 弹性与全球交付 Amazon Amazon --- Page 9 --- 出海合规与企业级集成 --- Page 10 --- —— AI Filevine 客户案例 北美法律 独角兽 × Me Immi Cha Dep App Layer dic grati t o al on Agent & Workflow Layer 任务拆解 策略 状态 Vector RAG & Semantic Retrieval Service Layer Database Data Foundation 案件 文档 证词 医疗 --- Page 11 --- —— 亚马逊云科技视角 性能、成本与全球化 Amazon PERSPECTIVE Graviton 从向量数据库延伸到完整 降本增效： AI + 应用基础设施 芯片架构 容器化实践 --- Page 12 --- Graviton 广泛适用于容器生态 Amazon ECS Amazon EKS Docker Swarm Kubernetes Amazon ECR Docker Hub Bottlerocket Fargate Lambda --- Page 13 --- DevOps Graviton 生态系统中的广泛 支持 混合 完全托管 / 自管理 （托管 自建） Amazon CodeBuild Jenkins Cirrus Travis CI CI argo --- Page 14 --- DevOps Jenkins in EKS with Graviton 架构： • Graviton Jenkins40% 提升了 的构建性能， Maven/Gradle 构建速度显著加快 • ARM Jenkins 架构的高效能核心设计，支持 Agent 并发执行 • Jenkins Master x86 运行在稳定的 节点， Jenkins Agent Graviton Spot 动态调度到 节 点，执行实际构建任务 • Karpenter 30 实时监控作业队列， 秒内自动 provision Graviton， 合适规格的 实例 并提供 混合架构支持 --- Page 15 --- DevOps ArgoCD can run on Graviton easily 架构： ARM64 原生 支持 • - ArgoCD ARM64 官方支持 正式支持 镜像 • - Graviton 无缝迁移 所有组件完美运行在 上 • - 30% 性能提升 同步和部署速度提升 --- Page 16 --- Graviton 迁移复杂度 易用性 工作负载 操作 Amazon RDS Amazon Aurora Amazon 、 ElastiCache Amazon OpenSearch Amazon 、 更新至最新版可使用最新功能 MemoryDB Amazon Neptune 和 无缝迁移 Amazon EMR 一般可直接使用 Graviton ISV / 基于 支持的 （开源 商业版） 根据应用而定，但通常能无缝迁移 Lambda 通常只需结合 Amazon Lambda 简单操作 托管的运行时或基础镜像 * Java (JNI) 检查 本地接口、共享对象或原生模块 Arm64 AMI Linux - 选择 并安装 解释型和即时编译型语言 一般难度的操作 Java PHP Node.js 其他操作（若容器化） （如、 ) * Java (JNI) 检查 本地接口、共享对象或原生模块 Linux - Arm64 AMI 编译型语言或依赖 选择 并编译 相对复杂的操作 C/C++ Python Go * intrinsics （如、） 移植任何 函数、汇编或原生模块 Microsoft Windows - .NET Linux + Arm64 .NET Core 多种操作，高回报 迁移至 基于 的 --- Page 17 --- Thank you ## 三、会议回放视频转录内容 好，很高兴今天能够代表 Zilliz 来给大家做一些分享 首先自我介绍一下，我叫 Leo，沈亮 我是 Zilliz 的解决方案架构师 然后今天由我来给大家去分享一下 我们 Zilliz 这么多年，我们大概成立了 9 年 在整个非结构化数据管理 包括 AI 的数据管理和向量数据库这个领域 做的一些事情 首先给大家介绍一下 Zilliz 这家公司 其实我们是一家做 AI 和技术架构的一家公司 也是一家出海的公司 我们既作为亚马逊的伙伴 是出海提供很多的一些服务 而且是服务很多中国出海的一些企业 今天我们可以看到 向量数据库已经不是像传统上 我们能够理解到的是一个非常传统的 一个简单的 RAG 的工具 或者说一个简单的单项的一个检索的一个组件 可能我在两三年前去介绍 我们公司的时候向量数据库 可能还是一个比较新的概念 可能还要花很多时间去给大家介绍向量数据库 但今天可能大家在座的每位朋友 应该都非常了解什么叫向量数据库 包括向量数据库在整个我们生态中 所做的一些贡献 今天我们可以看到在 Agentic AI 这个大的背景下向量数据库的一个转变 原来它可能是仅仅是一个作为外挂的一个存储 存储我们一些简单的上下文的一些知识 包括我们的知识库 它可能更加偏静态的一次调用 但是今天因为我们看到 很多实际的生产过程中 我们遇到了问题 并不是简单的调用一次向量数据库 或者说调用一次的记忆就能完成 而且往往整个端到端的一个效果的好坏 不仅仅取决于模型的质量 我们可以看到 可能有一些大的模型 或者海外的领先的模型 它可能效果会比较好 但是其实我们很多国产的模型 本身的效果也并不差 最大的一个差别 可能还是在于我们给它提供的一些上下文 包括我们提供的一些环境 的管理 在这个过程中 向量数据库的重要性 可能为大家越来越重视 因为大家可以看到 所有的这些持久化记忆 语义检索 包括上下文的管理 工具的调用 等等都可能涉及到 我们语义层的一些调用 所以向量数据库 如何提供一个高效的 高性能的并且稳定的 一个生产的环境 对于大家实现整体 AI 落地 还是非常重要的 所以今天可以看到 我们整个向量数据库的 使用过程中 大家面临的是 非常海量的多次调用 我们需要把整个 上下文的一些环境 包括我和所有 Agent 的一些对话 我的所有的输入 所有模型的 Output 它的一些中间的思考的过程 包括它对一些结果的判断 等等 所有这些东西 可能都会非常实时的 去写到我们向量数据库 写到我们的语义层里去 以供后续我们去调用 我们也知道 今天很多 计算成本是非常高的 如果我们把所有的这些 比如 KV Cache 保存很长时间 对我们模型的 提供商的一个成本也是非常高的 所以 更多的还是要依靠 我们把所有的这些上下文 作为一个 我们的整个 context 去保存下来 后续 如果我有 希望能够继续 这个 session 的时候 我们希望把所有 之前的那些 相关的内容全部调用出来 这个时候 向量数据库的准确性 它的性能 它的高吞吐 它的写入的性能 其实都非常重要 我们 Zilliz 的解法是什么 这个其实是我们 刚刚新发布的一个产品 我们叫 Lakebase 因为大家知道 传统我们说数据湖 数据仓库 湖仓一体 这在传统的结构化数据里面 是一个非常普遍的概念 大家已经非常接受了 但是在向量数据库这个领域 其实我们今天 还是作为比较 领先的 领先的厂家 去第一个推出 向量数据的湖仓一体 其实我们可以看到 我们把整个负载 分为三个种类 一个叫 real-time-serving 就是我们所谓的实时的 也就是我们 知道我们的 开源的 Milvus 和我们的 Zilliz Cloud 往往比较擅长的这一块 传统上我们做的 比较多的这一块 就是实时的 检索 提供实时的服务 这是第一块 第二块 我们称为 交互式的探索 有时候我们需要 有一些 可能对于 QPS 性能 要求不那么高 但是可能我们会希望 它能够实时反馈 我们的一些搜索的 一些结果 比如说我作为一个 做自动驾驶的厂商 我可能需要去 在海量的图片里面 去检索到一些 特定的 一些条件的素材 一些训练的材料 这个时候我可能希望 它能够给我一个比较快速的 去检索海量 我们的语义 向量的一个工具 往往它对 我们的整个数据量 或者说可扩展性的要求 会非常高 而且对成本相对有一些敏感 相比我们这个 线上的一个服务来说 最后一种 就是我们的 Batch Analytics 就是我们很多的场景下 我们比如说大模型厂家 他们要去做很多 语料的一些准备 这个时候他可能会去做一些 比如说去重 包括聚类 这个都是一些 向量语义空间上的计算 它强调的是一些高吞吐 我们的大规模的数据的 一些读取写入 包括它对成本也是非常敏感 往往 如果用传统的这些在线的方案 去做这样一些工作的话 它的成本会非常高 去降低成本其实也是非常重要 所以我们其实 通过了构建整个一个底座 这个底座我们会分 两大块 第一块就是我们的 底下的 S3 依托亚马逊云科技的 非常稳定可靠的对象存储 去构建我们的 Single Source of Truth 也就是我们用同一份数据 可以去 Serving 所有的 线上的服务 包括我们的 一些离线的服务 我们的一些交互式的查询 也能够实现是说 我们整个数据不用搬家 我们的数据全部是放在这个底层的 也不需要为了在线的服务 我们把数据搬来搬去 为了我们去做一个离线的挖掘 一个探索的时候 还把数据导到另外一个环境里去 所有的这份数据 全部放在我们底层的 S3 上 我们也做了一些存算分离 上面一层就是我们的计算层 计算层的话 我们分热缓存层 那就是提供我们在线服务的 在线检索的这一层 右边这个就是我们的 on-demand compute 服务我们比较偏离线的那两种应用 刚刚说的交互式的探索 和我们的批处理的应用 以实现我们的整个 我们的实例 是需要开启的时候再去启动 当我们整个任务完成的时候 可以把它马上的 归到我们的一个停止的状态 所以这样的话 能够使我们的整个成本上 能够有很大的一个优化 我们 Zilliz 的产品 也不光光是一个形态 我们今天可以看到 我们是一个全形态的产品的一个家族 首先我们有开源的产品 我们有 Milvus Lite 服务一个非常轻量化的 一个端侧的场景 很多我们的比如说 车机 我们的手机 包括我们的 IoT 的一些厂商 它都可以用我们的 Milvus Lite 去实现一个 比较偏轻量化的 向量检索的一个场景 包括我们有 Docker 的一个部署 和 Kubernetes 就是我们 Kubernetes 的一个部署 能够提供全套的 我们开源产品家族的 一个部署形态 能够满足绝大多数 用户一个探索 包括开发环境的一个部署 它整个生命周期的前半段 这样一些需求 如果步入到 一个比较生产的环境 我们推荐大家 用我们中间这个形态 就是我们 Zilliz 的一个 全托管的向量数据库服务 它不仅仅是把我们开源的环境 搬到了云上 而是做了非常多的优化 包括向量的 检索性能的优化 包括大家知道 我们今天硬件非常昂贵 不管是 CPU 内存 我们如何帮大家去节省成本 最大的一块就是体现在 如何用更少的内存 去存下来所有的这些向量存储 因为向量本身的规模是非常大的 另外一块我们也在 Zilliz 做了一个非常完善的 云管控的平台 解决了开源这边 很多用户反馈的一些 可能因为是比较难 部署 难运维 难管理的一些痛点 最右边这个形态 就是我们的 Zilliz BYOC 这是针对某一些 特别对数据敏感的 而且是对隐私 特别要求高的一些用户 提供了一套 基于公有云的 基于亚马逊云科技的一套 私有化环境 我们虽然是一个 第三方的厂商 但是我们可以把 所有的这一部分 向量数据库的基础设施 全部部署到用户 自己的 VPC 内 也就是所有的数据 数据面是不出域的 同时它和完全私有化部署 比如说我们可以把 Milvus 完全私有化部署在自己的环境里面 它最大的区别就是 我们提供全套的 Zilliz BYOC 的一个体验 也就是说我们还是会把 所有的管理的一些界面 包括我们所有的性能的一些优势 全部带到我们的 BYOC 的这个产品形态里面 并且我们可以通过一条 专属运维通道 这条运维通道本身 也是可审计的 它只有管理的一些信号 管理的一些数据 可以通过这条运维通道 去帮助用户 更好的去维护 管理好 监控好我们这一套 Zilliz 好 那今天我们跟亚马逊合作的 一个很大的一个原因 也是因为亚马逊能够在 全球提供非常多的节点 亚马逊全球有30多个区域的服务 今天我们 Zilliz 的 已经伴随着我们很多 中国的公司出海 来到了像欧洲 像北美 像亚太的 东南亚 包括澳新 包括日韩等等 都有我们的足迹 这些并不是全部 因为如果说大家有 任何的一些需求 在这个图上没有的 我们其实也可以用 非常快的速度去做部署 为什么我们要开这么多节点 因为今天出海的用户 可能很多关心的一个问题 并不仅仅是上云 而是关心的是 我出海以后 如何让数据 离我的应用更近 我有更低的访问延迟 这是非常重要的 第二个就是很多国家 都有很多的数据 合规的要求 我们需要把数据 放到本地 这是我们很多 出海的一些用户 非常敏感的一个诉求 因为大家知道 合规的成本是非常高的 所以今天我们可以跟着用户 跟着我们所有的用户的应用 去出海 到任何一个亚马逊 云科技能够部署到的一个节点 我们为什么要选择 跟亚马逊合作 还有很多的原因 刚刚已经说过了 像刚刚说的 三十多个 Region 的全球覆盖 包括我们能够在所有这些 Region 上 能够有一致性的体验 这点也是非常重要的 因为我们作为一家 软件厂商 因为我们是 不想把过多的精力 放到所有的底层的 这些 infrastructure 上 我们希望所有的这些部署 能够很快速的去做一些复制 能够有非常一致性的体验 去支持我们上面 整个数据库的这一层 所以一致的体验来说 因为我们也跟一些 其他的云厂商也有合作 我们也去做了一些横向的比较 亚马逊的一致性体验 表现优异 第三点就是生态的集成 大家知道亚马逊有很多的 像 AI 的一些基础设施 像 Bedrock 等等 能够为用户提供一个端到端的 完整的 AI 的应用的体验 因为我们毕竟只是一家 做数据库的厂商 我们不能提供整个端到端的 一些生态的集成 亚马逊很好的去补足了 我们整个生态的一个短板 包括我们也能提供很多的 像 PrivateLink 像 Marketplace 等等 生态的从前到中 到后的所有的一些 包括安全网络 包括采购等等这样一些优势 能够助力我们快速的 去拓展全球的客户 不光是我们中国出海的客户 我们现在有大量的客户 都是海外的本土客户 包括欧美的一些本土客户 最后就是我们 Partner 的 一个联合的销售的机制 因为我们也是在亚马逊 非常高等级的合作伙伴 我们也跟亚马逊的所有的销售团队 有很多的一些沟通 包括亚马逊的 PDM 销售 能够给我们去推荐很多的商机 我们可以做联合销售 同时我们也能帮亚马逊 进行去带来很多的 像刚刚说的这些生态的 AI 的一些产品 包括我们也可以进行联合结算 我们有很多的业绩 其实是对于双方的销售来说 都是会有很大的一个 目标的帮助 接下来就从技术方面 来剖析一下 为什么我们要跟亚马逊合作 我们可以从两个大的层面 第一个是计算和存储 计算和存储来说 大家知道 向量数据库本身 对硬件的要求是非常高的 我们的整个对物理内存的消耗 这个有点类似于大模型 大家知道 大模型往往它发展到后面 尤其是我们现在看到 已经进入第二阶段了 我们整个 AI 的发展 进入到推理的阶段 往往可能训练阶段 我们对 CPU 对 GPU 的要求会更高一些 但是到推理的阶段 我们可能更大的一个瓶颈 并不在 GPU 本身 可能都说 GPU 本身是有点 在闲置的 更关键的一个瓶颈 是在于内存 尤其是内存带宽 我们其实也做了很多的探索 我们跟亚马逊的一些研发团队 做了很多的测试 在亚马逊的 ARM 架构的 Graviton 芯片上 我们做了很多的内存 方向的优化 我们能够让更大的内存带宽 提供到我们的向量数据库的上层 其实大模型的计算 跟我们向量数据库检索的计算 本质上是一样的 都是大规模的向量的一些 相似度计算 或者乘法的一些计算 这个时候我们可以 更大程度的去利用 我们整个 Graviton 芯片的 一些内存带宽的优势 我们也做过一些实验 我们在这样一个 Cohere 768 维的公开数据集上 用我们一个标准的 性能评测工具 去做的这样一些对比 可能 Graviton 3 比 相比 X86 的型号的提升 还不是那么明显 可能有10% 左右 但是我们看到 Graviton 4 的一个 QPS 的性能提升是非常明显的 那也是可以看到 我们整个亚马逊的产品的 迭代 能够为我们带来一个更好的 一个成本和一个效益的一个比 另外一个点是说 我们利用了亚马逊 整个持久化的存储 S3 的存储 去做更多的一些 向量的索引 向量的元数据的一些分层存储 这样可以实现我们整个 向量数据管理的 全生命周期的一个细化 由此可以实现我们 对于大量的一些 部署的用户来说 实现一个更大的成本的节省 另一点是说 我们也可以节省 我们整个对 资源硬件资源的一个消耗 另一方面也是提高了 我们公司的一个毛利率 另外一个方向就是 我们的弹性与全球交付 这个点来说 因为我们很多的用户 用我们的 Zilliz 的商业版的产品 它其实最大的痛点就是 它不希望自己去运维一套 非常复杂的 Milvus 的一个分布式的版本 我们即使作为原厂的工程师 如果要运维好这么一套 比较复杂 Milvus 的一个开源代码 大概有200多万行 再加上我们整个管控的界面 它是一个非常庞大的 一个系统 那如何去运维好这样一套 基础架构 其实是非常复杂的一个问题 那我们其实可以通过 亚马逊很多的 一些云原生的一些 feature 包括我们的一些 CloudWatch 的一些监控 去更好的去整体运维好 我们遍布在全球的 这些 Zilliz 的一个产品 那另外一边 我们也可以实现很多 比如说用户的一些扩张 用户可能需要开一个新的区 新的 Region 的时候 那我们的 CloudFormation 等等 这样一些免费的工具 能够帮我们非常快速的去部署 可能原来我们去部一个新的区 新的 Region 可能需要数周的时间 但是现在我们有这么一个 方便的工具和方便的基础设施以后 我们可以非常快速的在天 甚至小时的级别 就完成新的区域的一个开放 这些其实都离不开 亚马逊的一个整套的工具 那另外一边我们出海的用户 其实更关心的 不仅仅是一些技术的问题 刚刚我们聊了比较多的是技术的问题 大家其实往往从技术走出来了以后 会发现我们的 CTO 我们的 CIO 我们的一些采购 我们的一些法务 可能他们更关心的是一些 安全的问题 更关心的是一些 比如说我们如何能够快速的 去做一些扩张 做一些采购 包括很多合规的问题 如何满足我们整个 当地的一些信息 安全的那些法律 这一块我们其实 借用了很多亚马逊的一些基础的组件 包括我们大家都用了非常多的 PrivateLink 让用户的数据不出域 整个能够在我们的亚马逊的内网 完成整个交互 另外我们知道 IAM 和 KMS 都是业界非常知名的 身份管理 认证的一些标杆的产品 利用这些产品 客户可以更放心的 把它的一些业务数据 把它的一些隐私数据 全部放到我们的公有云上来 另外我们也看到 亚马逊的 Marketplace 因为我们带来了很多的引流 引流的助力 我们很多的用户就是 其实我们也没有接触到用户 我们也没有能够跟 我们的销售也没有用户直接的去沟通 他们直接能够通过 Marketplace 很方便的找到我们产品 看到我们产品 然后直接订阅 直接通过他的亚马逊的账单去做支付 其实这一切的链路都是非常丝滑 还有就是我们的整个亚马逊的 刚刚联合的销售机制 等等这个刚刚已经讲过 最后一点大家都知道 我们在不同的地方 有不同的法律 在国内我们有等保 在国外比如说欧洲我们有 GDPR 在某些特殊的行业 比如说在美国 我们要去做一些医疗行业的话 有 HIPAA 等等 这样一些方向的一些 很严格的信息安全的一些制度 这些我们能够借助 亚马逊非常合规的 基础架构的一些框架 能够为用户提供一个非常合规 非常安全 非常放心的一套环境 我这部分最后就给大家介绍 一个案例 这是我们一家 北美非常大的一个客户的案例 这也是他们在前不久 刚刚进行了一个融资 他们也是一家非常大的独角兽 AI 的独角兽 融了4亿多美元 现在大概估值在20 到 30亿美元 这家公司 大家看到名字就知道 Filevine 它其实是一家做 原来在 AI 没有 这一波 GenAI 没有起来之前 它是做一些文档存储 尤其是北美那些 比如说律所 一些公司的法务 他们有非常多的一些卷宗 一些文档 一些材料 它需要把它去存储下来 所以它是做存储的软件 为主 但是 AI 起来以后 大家可以看到 它做了非常多的产品的拓展 这里我其实 有一些做了翻译 可能有一些方面大家理解 就用一些中文去表达 它其实最上面这个产品形态 有非常多 比如说 chat 它如何去跟所有的它一些材料 它的一些文档去做对话 去挖掘其中的信息 Depo 是一个证词管理 大家知道北美它的法律的体系 对证词等等管理是非常的严格的 它有各个阶段的不同的材料 如何去管理好不同阶段的 证词的一些材料 第三个就是 medical 很多的它有一些医疗的诉讼 关系到很多医疗方面的一些材料 一些数据 还有就是移民 它有一些 immigration 的一些 相关的 case 它也有相关不同领域的一些数据 它的一些材料 所有这些应用层 它映射到底下 它都会有很多的一些任务拆解 一些路由等等 最后它归到了下一层 就是我们最核心的这一层 就是 RAG 和语义搜索层 这是我们 vector database 向量数据库作为整个 AI 的 一个核心应用的一个最核心的组件 我们帮助它能够在 海量的一些数据里面 包括在不同的租户进行一个隔离 提供一个非常实时 可靠可扩展的一个 向量检索的一个基础架构 对于它整个应用的 来说是非常重要 我们也能支持下面 所有的这些数据的 一个大量的存储 包括能够帮助它去优化 整个存储的成本 好 接下来这一部分 我就有请我们的 亚马逊云科技的架构师 来帮我们介绍一下 我们刚刚提到的 Graviton 如何在一个容器化的环境里面 亚马逊做了一些工作 来优化我们的用户体验 感谢沈总的精彩分享 再次感谢 Zilliz 长期以来对亚马逊云科技的 信赖与支持 我想问一下在座的各位 各位的在实际业务当中 有使用容器和微服务的吗 请大家举手 OK 谢谢大家举手 相信我等会介绍 Graviton 容器化的一些案例 可以帮助我们企业在 整体的这种容器架构上 有所提升 其实刚才沈总介绍了 Zilliz 怎样借助亚马逊云科技 来构建全球的 向量数据库 其实构建任何一款 AI 的出海应用都不只是 上层软件的事 从底层的算力 到容器化部署 到 CI/CD 持续化部署 其实每一层的选择都非常重要 举个例子 我们作为出海的企业 要部署一款应用 肯定要部署在多个 Region 上 作为我们选择底层来讲 是非常重要的 如果我们选择错误 这样的话 我们整体的基础的成本 就会增加性能反而会下降 刚才大家也看到了 Graviton 在向量数据库检索的优势 其实 Graviton 在容器化的优势 不仅如此 这类本身就支持 容器化的相应的部署 其实容器化是大家 是非常常用的一种方式了 Graviton 在容器的这种 构建和 CI/CD 的持续化部署上 可以带来40% 性价比的一个提升 同时 Graviton 现在 亚马逊云科技超过34个 Region 以上 是可用的 用户可以根据自己的业务选择 选择相应的 Region 进行一个相应的部署 接下来我们具体看一下 Graviton 在容器化上能为我们 带来什么样的收益 首先来讲就是 经常有人问我 听起来 Graviton 很好用 它到底我现在的容器运行环境 是否能跑起来呢 答案是完全兼容的 首先作为容器编排器来讲 不管你使用 Amazon 的 EKS 还是 ECS 还是开源的 Docker Swarm 还是 Kubernetes 都是完全兼容 Graviton 的 如果你采用传统的这种部署方式 你不需要任何的代码修改 完全可以进行一个平滑的迁移 作为容器的仓库来讲 Amazon 的 ECR Docker Hub Artifactory 和 Quay 现在已经都支持多架构的 将来一个镜像存储 也就是说你只需要创建一个仓库 就可以存储 X86 包括 ARM 的架构 当你在 Graviton 中拉取镜像的时候 可以做到一个自动识别 ARM 镜像的 一个拉取 同时亚马逊云科技 亚马逊云科技针对于容器化的操作系统 也推出了一款开源的 Bottlerocket 这是 Linux 的操作系统 它的优势是它的运行速度很快 攻击面很小 当然你也可以采用 其他的这种 Linux 操作系统 比如说 Fedora 对于无服务器的应用 Fargate 和 Lambda 这里同样可以享用 ARM 的 这样的一个优势 你无需关心底层的架构 只需要关心上层代码的实现 可以带来性价比的一个提升 下面是我介绍一下 刚才我介绍了容器的运行时 下面我介绍一下 DevOps 生态中的 Graviton 的一个支持 首先我们说一下一个完全托管的模式 作为完全托管模式 Amazon CodeBuild 完全支持 Graviton 当我们在进行构建的时候 直接选择 ARM 的环境即可 CircleCI 和 Travis CI 同时也支持 ARM 的构建 GitLab 的 Runner 现在也支持了 GitLab Runner 的构建 我们再来看混合托管的一个构建的方式 GitLab 和 GitHub 它是完全支持托管的 Runner 但是它同时也支持 Self-hosted 注册的 GitLab Runner 这样一个运行的方式 我们再来看一下自管理的模式 自管理模式的 Jenkins 和 Argo 是完全可以安装在 Graviton 上的 它的运行效率相对于 X86 来讲 提升非常明显 刚才我说了一个容器运行时和 CI/CD 我们再来看一下一个具体的案例 Jenkins 运行在 EKS 通过 Graviton 来进行一个优化的案例 这个案例 Graviton 提升了 Jenkins 40% 的构建性能 Maven 和 Gradle 构建是有显著了一个加快的方式 这里我们采用一种方式 就是 Jenkins Master 由于它是一个管理整体构建的大脑 这里我们采用了传统的 X86 的一个构建方式 至于 Agent 我们采用了 Graviton 的一个方式 而且我们采用了 Spot 的一个实例 Spot 的实例大大减少了我们构建的成本 增加了整体的构建效率 这里我们还采用了一个弹性的伸缩的方式 叫 Karpenter Karpenter 实时监控我们的作业队列 能30秒内启动 provision 合适的 Graviton 的实例 并提供混合架构的这样一个支持 刚才我说了 Jenkins 40 来构建 其实构建完之后我们需要把我们相应的应用 部署在多个 EKS 集群多个 Region 这里我介绍一款工具是 Argo CD Argo CD 是一款非常流行的 GitOps 的这样一个工具 首先从官方的支持角度来看 Argo 的社区在 GitHub 已经引入了 ARM64 的架构的 Docker 镜像的支持 这就意味着我们现在可以直接使用官方的镜像 无需任何额外的构建和适配工作 Argo 的 server 和 Argo application controller 都可以完美运行在 Graviton 的实例上 不需要修改任何的代码和配置 最令人兴奋的是性能的提升 根据我们实际的测试数据 在迁移到 Graviton 之后 Argo CD 的同步和部署速度提升了30% 这就意味着我们能更快的交付周期 和更好的开发的体验 接下来我们看一下右侧的架构图 这是一个典型的多账号的 Argo CD 的部署方案 我们在中间的 DevOps account 中 部署了 Argo CD 核心的控制面 包括 Argo Server 和 Argo CD application controller 它运行在一个 EKS 集群中 然后通过 STS 跨帐号角色切换机制 Argo CD 可以安全的访问多个 Workload 的 Account 中的 EKS 集群 每个目标帐户配置了对应的 Argo Role 和 aws-auth ConfigMap 确保权限的隔离和安全的访问 最后我们来看一下整体 Graviton 迁移的复杂度 对于第一类应用来讲 就类似于 Amazon 的 RDS 和 Aurora 这些托管的数据库 可以通过云控制台向导操作完成迁移 我们只需要在控制台中 选用 Graviton 的实例类型 系统就会在下次更新中自动切换 对于第二类应用 像 Lambda 这样函数这样的无服务器应用 我们只需要做一些简单的调整 选择支持 ARM 的运行环境就可以了 这种操作通常需要几分钟就可以完成 第三类的应用 如果我们使用的是 Java, PHP 或者 Node.js 这样的编程语言 迁移工作会稍微复杂一些 这样我们需要选择 ARM64 的基础镜像 然后重新部署应用 这类通常不需要做代码的修改 第四类应用对于 C 和 C++ 或者 Go 这样的编程语言 我们需要为 ARM64 架构做新的编译代码 因为这可能涉及到一些 依赖库和兼容性的问题 这里可能需要我们更多的一个技术的投入 第五类应用就是 Windows 的.NET 应用 这里是比较有挑战的 因为需要同时进行平台的迁移 包括从 Windows 到 Linux 和架构的迁移 从 X86 到 ARM64 这通常需要我们全面的规划和测试 了解这些迁移的难度之后 我们其实可以更针对性的规划迁移的路径 优先选择那些容易迁移的项目 来选择工作负载 其实通过我刚才的介绍 大家可以体会到 Graviton 是 AI 基础设施降本增效的一个最简的路径 它的特点是兼容性好 收益快 风险低 其实今天我和沈总一起给大家展示的是 Zilliz 和亚马逊合作的一个缩影 ISV 专注于应用软件的一个创新 亚马逊云科技提供底层高效的底层基础设施 如果大家在考虑出海 在 AI 降本增效上有一些疑问的话 会后随时可以与我们联系 好 谢谢大家