当云原生成为一种显学,对象存储和数据湖如何顺势而为
前言:
已经成为数字化时代显学的云原生并非单项技术,而是一种重塑了软件开发和和业务运行应用的设计思想,是一套技术体系和方法论。云原生“Cloud Native”的Cloud 是指云平台,Native则表示应用程序从设计之初即使用云环境、天生为云而设计,充分利用和发挥云平台的弹性+分布式优势。据相关机构(Gartner)预测,部署在云原生平台上的数字工作负载将由 2021 年的 30%增长至 2025 年的 95%。对象存储作为最早的云服务,已广泛支持各种云业务,在数据湖领域更是成为统一存储的不二之选。
一、何为云原生
1.1 云原生定义
随着技术发展,云原生定义也在不断演进,如下是云原生计算基金会 (CNCF,Cloud Native Computing Foundation)目前的云原生定义:
“云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中,构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式API。
此描述的前一句阐述云原生的应用场景和目标,后一句则介绍云原生会使用到的相关技术。目前,以容器、微服务、DevOps 为代表的云原生技术已在金融、电信、互联网等多个行业得到实践和验证,为企业提供了具有弹性、韧性及拓展性的用户体验。
1.2 云原生技术特征
根据云原生的技术架构,它可以广泛部署到公共云、私有云、混合云等云环境。
通过CI/CD持续集成实现敏捷应用开发。
采用容器的轻量化运行环境降低资源开销、优化成本,基于服务网格(例如Istio)来管控应用的各模块、实现灵活调度,通过微服务架构理念将应用切分多个模块化服务,基于分而治之的方法让多团队快速迭代开发。
不可变基础设施,则是通过容器镜像(Docker Images)来交付软件,将软件和运行环境打包发布,减少环境适配的复杂度;而提供软件包,再到客户环境部署、调试、运行的方案,则需要考虑各种兼容情况,非常复杂。某些场景下,基于镜像的部署时间只有基于软件包部署时间的1/10,极大优化软件交付。
声明式API,类似 K8S(Kubernetes)只需提交定义好的 API 接口来“声明”,表示所期望的最终状态,一次调用就可完成。而软件包部署方式下,需要通过执行命令实现一步一步交互,最终完成发布,这种“命令式API”相较于K8S的“声明式API”效率低下。所以,通过“声明式API”可以让系统之间的交付更加简单,无需关注过程细节。
1.3 云原生对存储的需求
在上述的云原生技术架构下,对存储提出了诸多需求,包括:
- 容器的安全性
不管是CI/CD,还是容器、微服务,通常都运行在虚拟网络(VPC)环境中,如何实现VPC容器下的安全数据访问是基础要求。
- 微服务的隔离性
基于服务网格、微服务架构,应用需要划分为众多的子服务,降低子服务间的干扰、实现子服务间的数据访问隔离至关重要。
- 弹性扩展能力
微服务架构中的子服务模块会引入突发流量,例如10,000+的容器并发访问数据将会带来访问洪峰。而不可变基础设施的容器镜像批量启动风暴,也会带来集中的瞬时流量,因此需要存储提供弹性扩展能力。
- 高可用、高可靠
微服务架构会产生大量的子服务,它们都需要高可用、高可靠的底层存储,从而实现企业级应用要求的5个9可用性。
- 单位存储密度的性能,可预期的带宽、时延、OPS
容器化的细粒度运行环境,在公共云上实现了秒级计费能力,比弹性计算服务器的小时级更精细。所以,存储提供单位密度的带宽规格(每TB的Gbps带宽能力)、稳定的请求时延和OPS(99.99%的请求在指定时间T内完成),可以有效地帮助微服务评估使用存储的时长,从而可以按需释放容器,获得最合适的性价比。
二、对象存储如何支持云原生
2.1 对象存储符合云原生定义
对象存储作为数据存放的平台,天然支持构建和运行可弹性扩展的应用。而且容器、服务网格、微服务在设计开发的早期就使用对象存储来存放数据,容器镜像数据存放的常用技术也是对象存储。对象存储的Restful API完全匹配声明式API要求,因此对象存储是云原生数据存储的理想之地。
2.2 云原生给对象存储带来的挑战
对象存储应用到云原生,是典型的存算分离架构;同时对象存储作为数据底座,它的高可靠、高可用以及弹性扩展能力,已在云上得到广泛认可。
云原生应用正在引领各个应用领域实现云原生化的同时,也在深刻改变着应用服务的方方面面。对象存储作为应用运行的基石,在服务云原生化过程中遇到了更多的挑战。安全性、隔离性、单位密度的性能,都是对象存储的面临的新挑战,需要集中解决。
2.3 对象存储该做些什么
- 加强针对VPC环境的容器访问对象存储安全性
实现VPC运行环境和对象存储桶的安全访问绑定能力。限定在VPC内只能访问指定的对象存储桶,避免“内鬼”从企业VPC将企业的对象存储数据拷贝到个人的对象数据桶,这需要对象存储提供VPC Endpoint功能;也需要限定对象存储桶只能被指定的VPC访问能力,避免外部黑客盗取密钥后导致数据泄漏,需要对象存储提供Bucket Policy功能。
- 微服务的PoD级访问对象存储桶的灵活权限
类似云计算服务器绑定访问存储的Access Token,需要为PoD绑定访问存储的Access Token,通过Token的临时性,避免Access Key这样的长期密钥被盗取,从而带来影响巨大的安全风险。
- 面向微服务的隔离性
访问隔离。应用的不同子服务,可以使用同一个数据存储桶,但需要为每个子服务提供不同的访问域名,并绑定不同的访问策略,控制访问路径、权限,实现访问隔离,需要对象存储提供Access Point功能。
- 流控隔离
为应用的子服务,提供用户级、子用户级、对象存储桶级的流量控制能力,限制子服务能使用的带宽,避免应用被异常流量冲垮。
- 提供单位存储密度性能的规格
通过不同存储类型,提供差异化的单位存储密度性能。例如高性能存储类型,为每TB容量提供不同带宽能力,带宽性能规格越强,价格越高。从而能够根据实际性能需求,为应用选择不同的存储类型。
- 保证稳定可预期的时延和OPS
存储的数据访问时延存在波动,即使大部分时候都是低时延,但少量的长尾高时延,也足以让云原生应用的运行时长不可预期,只能按照最坏的长尾高时延设计。所以,对象存储的各种存储类型都应该提供稳定的时延和QPS,而不是一味追求极致低时延。
- 热点数据性能加速
容器批量启动风暴和并行计算框架,都会带来大量热点数据的重复读。提供靠近容器可用区(AZ)部署的对象存储热点数据加速器,可以提高容器加载速度和快速完成并行计算任务。
三、如何做好云原生下的数据湖
数据湖是解决大数据存储与利用的有效手段。如下图所示,为了更好地适配云原生应用,数据湖除了更强的高可靠性、高可用、弹性扩展需求外,还需要在安全性、隔离性、支持计算引擎的接口和功能上提供更强的功能。为了更好的利用云原生容器的细粒度运行环境,还需要单位存储密度的性能,实现可预期的带宽、时延和OPS,以及性能加速能力,从而让微服务的数据访问时长可建模计算,使得应用可以精确申请和释放容器,达到成本优化。
除了这些变化外,还需要关注如下的点:
- 数据湖支撑云原生计算的接口适配
云原生理念被广泛接受,基于云原生架构构建的数据分析计算引擎遍地开花。而基于对象存储的数据湖,要支持丰富的计算引擎,包括存量的历史引擎(如Hadoop生态)、以及新的引擎(如Spark、Iceberg、Hudi、Delta Lake等)。数据湖要支持额这些引擎,就必须要适配数据访问接口,特别是历史的Hadoop生态访问的HDFS接口。
- 可观测的运维
由于云原生采用微服务架构,应用通常由多个微服务组成,它简化了部署难度,但随着数据链路增加,也增大了排查问题、分析性能、度量系统的运维难度。因此云原生需要架构相关模块提供可观测的运维,对象存储作为数据存储也需要提供可观测运维的Log/Metric/Trace能力,被云原生应用集成。
- 可编排和调度的资源
云原生通过编排和调度实现应用的灵活部署和管理,对象存储需要提供编排和调度的接口,并整合到云原生平台中,从而让存储资源按需快速可用。
云原生充分释放了云计算的红利,未来将有更多的业务应用生于云,长于云。因此,随着云原生架构的应用拓展到更多的领域,新需求将如雨后春笋般涌现,在这样的背景下,数据湖将会不断演进,进而更好满足业务的实际需求。
原文链接
本文为阿里云原创内容,未经允许不得转载。