亚马逊AWS官方博客

Amazon GameTech 架构最佳实践系列 —— MOBA/FPS数据分析篇

不同规模的游戏公司对数据分析的需求各不相同。对于中小型游戏公司,其团队的运维能力通常有限,更倾向于以托管服务解决运维的人力、成本和技术问题,同时还开始有一些数据分析的考虑,开始关注和分析游戏相关指标。对于大型游戏公司, 这些客户更加关注产品的最佳实践、性能(如产品的性能瓶颈)以及在大型场景下的数据分析解决方案,例如哪些托管产品能够提供更高的性能和更低的成本与风险。

游戏中数据分析的需求种类也纷繁复杂,涉及近实时处理和批量处理、结构化数据和非结构化数据、低频冷数据查询和高频热数据查询、不定期查询和周期性报表等。AWS 提供覆盖范围广泛、托管简单高效、组合灵活多样的数据分析服务,能够最大程度地满足各种游戏场景的数据分析需求。并且 AWS 的客户案例中不乏 Supercell、Zynga、Pokémon 等一线游戏厂商,这进一步说明,在数据分析服务的成熟度、稳定性、功能等方面,AWS 都是游戏厂商的不二之选。

典型应用场景

游戏服务器日志分析——游戏服务器稳定而高效的运行是优化用户体验的基石。对于每天大量产生的性能指标及日志数据,采用合适的日志数据分析工具进行处理,能够快速发现运维风险,降低故障发生概率,提升运维效率。

业务需求

  • 返回监控应用的状态;
  • 收集游戏服日志,并进行分析和统计;
  • 通过日志分析和统计得到游戏的访问统计、异常统计、业务统计;
  • 具有分析和处理大规模日志数据的能力,易于扩展;
  • 能够制定告警规则,根据条件触发告警,将应用异常情况实时推送到运维、开发或业务人员的通信工具或值班系统;
  • 配有可定制的看板,可以直观显示各种实时统计数据或报表。

AWS的价值

  • 易于使用——分钟级别部署经行业内无数客户验证的托管集群以及云原生监控方案,通过提供蓝绿部署等机制将升级影响降至最低;
  • 开源支持——完美支持业内最广泛使用的 ELK/EFK 组合;
  • 高度扩展——通过托管服务使集群的规模扩展对业务无感知;
  • 安全——以 AWS IAM 及 AWS KMS 深度集成与 AWS CloudTrail 深度审计,提供企业级安全管控;
  • 高可用——通过托管服务提供最小运维成本,将底层基础设施交给更专业的云服务商;

基础日志收集

由于 FPS 类型的游戏通常会使用专用游戏战斗服务器,根据用户规模来弹性扩展进行服务,在战斗会话结束后服务器就会进行释放。因此需要通过中心化的流式日志解决方案,才能避免日志丢失,集中收集各个战斗服务器上的日志,并进行分类汇总和分析。

上图提供的是一个最简单的日志收集架构。首先在游戏的战斗服务器上,需要安装日志收集组件进行游戏运行日志、会话日志、错误日志等日志收集。这里常用的实现方式是游戏战斗服务器打印日志进行输出,并保存到指定的本地目录上,通过开源的 FluentD 或 FluentBit 等日志收集工具对目录进行监听,从而实时地把增量日志上传到流式管道中进行后续处理。FluentD 是一款全功能的数据收集器,功能完善、强大,甚至还可以做一些ETL的功能,而 FluentBit 的定位是一个轻量级的数据转发器,更方便的进行安装部署,同时消耗资源更少。

流式管道服务可以有多种方案可以选择,Amazon Kinesis 可让您轻松收集、处理和分析实时流数据,以便您及时获得见解并对新信息快速做出响应。Amazon Kinesis Data Firehose (KDF) 是将流数据可靠地加载到数据湖、数据存储和分析服务中的最简单方式。该服务可以捕获和转换流数据并将其传输给 Amazon S3、Amazon Redshift、Amazon OpenSearch Service(Amazon Elasticsearch Service的后继者),还可以传输到标准的 HTTP 终端节点和第三方服务提供商(如 Datadog、New Relic、MongoDB 和 Splunk)。这是一项完全托管的服务,会自动扩展以匹配数据吞吐量,并且无需持续管理。该服务还可以在加载数据前对其进行批处理、压缩、转换和加密,从而最大程度地减少存储量,同时提高安全性。Amazon Kinesis Data Firehose 按需使用,无最低消费和设置费用。

如果您习惯使用 Apache Kafka 进行实时摄取和处理流数据,可以直接使用开箱即用、完全兼容的托管服务 Amazon Managed Streaming for Apache Kafka (Amazon MSK),让处理变得更简单。您还可以使用Amazon MSK Connect,实现无服务器和自动扩展的Kafka Connect工作负载,把数据导入到 Amazon S3、Amazon OpenSearch Service 等数据存储和分析服务中。

无论是哪种流式管道服务,都可以轻松地把数据导入到 Amazon OpenSearch Service (Amazon Elasticsearch Service的后继者) 中。Amazon OpenSearch Service 是一款开源的分布式搜索和分析套件,衍生自 Elasticsearch。使用 OpenSearch 可以对 PB 级文本和非结构化数据进行搜索、可视化和分析。OpenSearch 支持19个版本的 ElasticSearch (从1.5到7.10), 并且可以使用OpenSearch Dashboard 和 Kibana 进行可视化的数据分析。

Amazon OpenSearch Service提供了三层存储,用于在大规模数据存储情况下提供性能与成本的平衡。OpenSearch 标准的数据节点使用“热”存储,也就是数据节点上的实例存储或者挂载的EBS,“热”存储会提供最强的索引和搜索性能。

UltraWarm 节点是 Opensearch的“温”存储,底层使用S3和高级缓存解决方案,对于查询频率较低的数据,UltraWarm 使每GiB数据的成本显著降低。查询“温”存储上的数据与查询其他数据一样,都使用相同的API,也可以在OpenSearch Dashboard/Kibana中进行可视化。OpenSearch也提供“冷“存储层,可以把大量不频繁访问的历史数据放在“冷”存储,Cold Storage不需要计算节点,因此只有存储的成本。当需要查询“冷“存储中的数据时,只需要调用API把冷数据迁移到UltraWarm即可,由于只有MetaData的操作,冷存储到UltraWarm的迁移非常迅速,之后就可以对数据进行查询和使用OpenSearch Dashboard/Kibana 进行可视化访问。当然,数据在三层存储间的流转,Amazon OpenSearch Service 可以通过设置生命周期策略完全自动化进行。

游戏日志分析的场景下,通常都会对分析系统的使用者进行权限的管控。Amazon OpenSearch Service支持细粒度的权限控制, 可以针对Index, Document和 Filed 级别进行角色的访问控制。Amazon OpenSearch Service也包含一些更高级的功能,比如使用机器学习 (ML) 实时检测异常、自动根据运行指标优化集群性能,并提供跨集群搜索的功能。

多种日志处理

很多客户对游戏日志处理还有进一步的需求,FPS 游戏因为在客户端会产生很多的交互,这些交互日志可以在游戏客户端进行上传,用于实时的统计和分析,也可以用于回放等不同场景的需求,可以对不同种类的日志进行过滤和汇总,还希望进行低成本的日志数据存储。

要在游戏客户端进行流式日志上传,可以使用 AWS SDK 进行处理,日志可以实时上传到 Amazon Kinesis 上。常用的游戏开发框架(例如:Unity、Unreal等)都能方便集成。服务器端日志收集,除了使用开源的日志收集组件 Fluentd 或 Fluent Bit 等外,也可以使用官方提供的 Amazon Kinesis Agent 收集程序,实现服务器日志的上传收集。

客户端日志收集不建议直接使用 Apache Kafka 进行收集,一方面是集群较难扩展以应对海量的用户日志上传,另一方面安全性是需要考虑的问题。Amazon Kinesis Data Streams (KDS) 是一种可大规模扩展且持久的实时数据流服务。KDS 可以从每小时数 MB 扩展到数 TB,并且 PUT 记录可以从每秒数千个扩展到数百万个,您可以随时根据您的输入数据量动态调节数据流的吞吐量。《堡垒之夜》就使用了这样的方案收集日志。收集的数据以毫秒为单位,以实现实时分析用例,如实时仪表板、实时异常检测、动态定价等。KDS 可以支持多种权限验证的方式,非常适合在客户端和服务器间安全传输数据,通过加密 KDS 中的敏感数据,并通过 Amazon Virtual Private Cloud (VPC) 访问您的数据,以满足法规和合规性需求。如果对流中的数据有较高的消费需求,还可以使用增强型扇出功能,每个增强型扇出的数据吞吐量高达每分片 2 MB/秒。

日志注入到KDS之后,可以使用Amazon Kinesis Data Analytics (KDA) 进行数据的简单处理。KDA 是使用无服务器的完全托管式的流式数据处理服务,可以运行Flink程序,或者也可以使用简单的SQL语法对数据进行流式数据的分析和处理。比如KDA可以根据原始数据的格式,使用Flink程序或者简单的SQL进行处理,对原始数据扇出到不同的Kinesis Firehose,最终数据可以加载到不同的OpenSearch集群中。

还可以通过 KDF 直接保存到 Amazon S3 中,进行低成本的海量日志永久保存,或设置自动的生命周期策略,实现自动清理过期数据,或自动移动到极低成本的Amazon S3 Glacier Flexible Retrieval和 Amazon S3 Glacier Deep Archive中进行数据归档存储,以实现备份和审计需求。

近实时处理和批量处理的数据分析架构

如果业务需要秒级的实时数据大盘展现和异常告警,KDS 可以从成千上万个来源中以每秒数GB的速度持续捕获数据,KDA 消费KDS 里的数据,把结果写入到常见的数据源中,如RDS MySQL。BI分析可以从RDS中获取数据并进行大盘的展现。对于异常的数据, Amazon Lookout for Metrics可以连接常见的数据源(如Amazon S3, Amazon Redshift, Amazon RDS),自动检测指标异常并确定其根本原因,从而轻松诊断检测到的异常。

当我们需要更多的模块来消费数据的时候,我们还可以使用多个 KDA 应用程序对流进行消费,一个 KDA 应用程序也可以实现同时多个输出处理,例如把数据流导入到新的 KDS 中,或通过 KDF 进行数据导出。

Kinesis Firehose 可以把数据输出到多个目标,还可以通过 Lambda 函数进行简单的 ETL 处理。其中S3提供低成本的海量存储,也是实施智能湖仓的基础。智能湖仓将数据湖,数据仓库和专用的数据库无缝集成,从而对这些数据进行分析,或提供给机器学习任务进行处理。在智能湖仓的架构中,数据可以自内向外流动,自外向内流动,或者在各个专用的数据库或数据分析产品之间流动。比如可以使用Amazon Athena直接查询S3中的海量数据,而无需提前预置计算资源,或者在预置的计算资源不足时,负责处理额外的数据查询请求。也可以由外向内,把专用数据仓库中的数据复制到数据湖中,并在机器学习任务中使用湖中的数据产生推荐算法。专用的数据仓库也可以直接对RDS数据库中的数据进行联合查询,从而将实时数据与批量数据进行整合产生统一的分析报告。

相关参考:

https://docs.thinkwithwp.com/kinesis/

https://github.com/aws-samples/aws-sdk-unity-samples

https://thinkwithwp.com/cn/kinesis/data-streams/resources/

https://docs.thinkwithwp.com/zh_cn/streams/latest/dev/enhanced-consumers.html

https://docs.thinkwithwp.com/zh_cn/opensearch-service/latest/developerguide/what-is.html

https://docs.thinkwithwp.com/zh_cn/redshift/

本篇作者

秦镜高

亚马逊云科技解决方案架构师,负责基于亚马逊云科技云计算方案的咨询与架构设计,同时致力于亚马逊云科技云服务在游戏与互联网行业的应用和推广。加入亚马逊云科技之前,有10多年丰富的游戏开发和架构设计实践经验。

汤力嘉

亚马逊云科技高级解决方案架构师,负责基于亚马逊云科技的云计算方案的架构设计,在游戏 , 多媒体方向有丰富部署实践经验。