Epic Games Optimizes Fortnite Analytics on Amazon OpenSearch Service
This post details how Epic Games partnered with AWS to optimize their Amazon OpenSearch Service deployment for Fortnite analytics. By analyzing cluster behavior and identifying node hotspots, they reconfigured hardware, sharding, index mappings, and query patterns. The optimization resulted in significant improvements in query latency and resource utilization, while reducing operational costs.
- →Epic Games uses OpenSearch Service for Fortnite analytics
- →Challenge: Balancing analytics freshness and cost efficiency
- →Observations reveal underutilized system memory and node hotspots
- →Right-sizing cluster with compute-optimized instances
- →Revised sharding strategy for even load distribution
Notes (6) ›
- Epic Games uses OpenSearch Service for Fortnite analytics
Fortnite utilizes Amazon OpenSearch Service to store and analyze game event data, enabling complex queries and multi-layered aggregations to inform decision-making and enhance player experience. These insights help identify gameplay trends and understand player engagement with new content.
- Challenge: Balancing analytics freshness and cost efficiency
Epic Games faced challenges in scaling their OpenSearch Service cluster to support more frequent aggregation jobs without incurring prohibitive costs. The existing configuration struggled to maintain optimal performance and resource utilization for high-volume writes and CPU-intensive batch jobs.
- Observations reveal underutilized system memory and node hotspots
Analysis showed that despite using memory-optimized instances, system memory was not fully utilized, and node-level metrics revealed CPU hotspots. This was attributed to an uneven distribution of query execution, where primary shard counts did not match the data node count, leading to specific nodes being overutilized.
- Right-sizing cluster with compute-optimized instances
AWS recommended migrating from memory-optimized r7g instances to compute-optimized c7g instances, offering a better ratio of vCPU to RAM for CPU-intensive aggregation workloads. This change increased aggregate CPU capacity by approximately 33% and reduced costs by about 10%.
- Revised sharding strategy for even load distribution
The sharding strategy was updated to match the primary shard count to the data node count with one replica. This ensures even distribution of write loads and aggregation queries across all data nodes, eliminating previous node hotspots and improving overall cluster balance.
- Index mapping optimization reduces storage and improves query performance
Redundant text field types were removed from index mappings for fields only used in aggregation or filter contexts, reducing storage overhead. For high-cardinality string fields, the murmur3 field type was implemented to compute hashes at index time, improving query performance by avoiding expensive string hashing at query time.
https://aws.amazon.com/blogs/big-data/how-a-team-at-epic-games-tuned-amazon-opensearch-service-for-fortnite-analytics/
Related releases
- Terraform AWS Provider v6.60.0 Adds New Resources and Fixes Bugs Terraform AWS Provider Releases ·
- Amazon S3 enhances access denied errors with specific policy ARNs AWS What's New ·
- OpenAI Daybreak Red and Blue Cyber Defense Models Now on Amazon Bedrock AWS What's New ·
- AppFolio Transforms Data Streaming with Amazon MSK Express Brokers AWS Big Data Blog ·
- AWS IAM Role Manager Automates Service Role Setup AWS What's New ·
- Amazon Quick Integrates Microsoft Purview for Data Loss Prevention AWS What's New ·