Soru

Zorluk: ZorApplication Caching and Session State Management

A developer is building a high-throughput mobile gaming backend deployed on Amazon Elastic Kubernetes Service (Amazon EKS). The application needs to manage real-time user session state and player matchmaking lobby tokens. Currently, session state is written to an Amazon DynamoDB table. During peak traffic periods, the application experiences database write throttling (`ProvisionedThroughputExceededException`), and players frequently lose connection and matchmaking state when EKS pods scale out or restart. The developer needs to implement a highly available caching and session management strategy that resolves the throttling and avoids data loss when EKS pods are rescheduled.

Which of the following actions should the developer take to meet these requirements? (Select TWO.)

  1. Migrate the session state storage from Amazon DynamoDB to an Amazon ElastiCache for Redis cluster with Multi-AZ replication enabled.Cevap
  2. Redesign the DynamoDB table partition key schema to use a high-entropy key, such as a combination of user ID and game session UUID, and configure the table to use on-demand capacity mode.Cevap
  3. C
    Deploy an Amazon DynamoDB Accelerator (DAX) cluster in front of the table to cache session writes and offload the write capacity requirements from the DynamoDB table.
  4. D
    Implement application-level caching by storing session tokens in EKS pod local memory using global variables to avoid network database calls.
  5. E
    Migrate the session data and player matchmaking tokens to AWS Systems Manager Parameter Store to utilize its hierarchical namespace and API caching.

Cevap

Migrate the session state storage from Amazon DynamoDB to an Amazon ElastiCache for Redis cluster with Multi-AZ replication enabled, and redesign the DynamoDB table partition key schema to use a high-entropy key, such as a combination of user ID and game session UUID, and configure the table to use on-demand capacity mode.
Migrating the session state storage from Amazon DynamoDB to an Amazon ElastiCache for Redis cluster with Multi-AZ replication enabled provides sub-millisecond, in-memory performance while ensuring that session states survive cache node failures. Redesigning the DynamoDB table partition key schema to use a high-entropy key, such as a combination of user ID and game session UUID, and configuring the table to use on-demand capacity mode eliminates hot partition issues and automatically scales table capacity to prevent write throttling during peak periods.

Adım Adım Çözüm

1
Analyze the scaling and availability constraints of the session state storage.
Identified that the current architecture suffers from two main issues: write throttling on DynamoDB and data loss due to local state dependencies when ephemeral compute (EKS pods) scales or restarts.
Resolving this requires decoupled, external, high-performance storage that persists session state across pod recycles.
2
Evaluate in-memory caching solutions suitable for stateful data.
Determined that ElastiCache for Redis with Multi-AZ replication provides low-latency key-value operations, durability, and high availability, making it an ideal choice for session and matchmaking states.
Redis supports replication and automatic failover, preventing session loss if a cache node goes down.
3
Analyze how to optimize the write pattern to DynamoDB if it continues to be used for persistent backup.
Determined that using high-entropy partition keys distributes traffic evenly across partition ranges, and enabling on-demand capacity handles sudden workload spikes.
Low-entropy keys cause 'hot partitions' that result in write throttling, even if overall table capacity seems sufficient.

Anahtar Kavram

Session state caching requires an external, durable, and highly available key-value store (like ElastiCache for Redis) to ensure sessions persist across ephemeral container restarts, and database partitions must be designed with high-entropy keys to prevent write throttling.
Tahmini Süre:2m 30s
Bu soruyu puanla