ElastiCache
The most common performance bottleneck for webscale applications is the database. It’s really a reflection of the laws of physics — queries against databases end up reading data from a spinning disk, which imposes delays because of disk rotation speeds and data transfer speeds, not to mention the overhead of relational database queries. Some tricks can be applied to address this issue; for example, you can set up a master/slave database configuration or set up more slave database servers. At a certain point, however, the overhead of updating all those slave database servers outweighs the performance gains they provide.
Amazon offers some solutions that can be used to mitigate database performance issues. You can use the high-performance instances — the ones that have solid-state storage rather than disks. You can also switch to using the DynamoDB service, which offers a high-performance, key-value database that runs on solid-state storage instances. But what if you want to stick with therelational database model but need better performance than you can get with master/slave-based systems?
The answer is caching — placing data in high-performance memory so that frequent queries are served without having to go out to a spinning disk to be retrieved. You may have seen the use of caching earlier in this chapter, in my discussion of CloudFront. Database caching uses the same technique to solve a different problem; whereas CDNs are designed to address the issue of accessing data in widely dispersed locations, database caching is used to address the issue of accessing data in centralized locations that require a solution beyond hard drives.
What’s the secret to memcached? Essentially, rather than repeatedly query a database to provide the same information to a specific user or to multiple users who want the same data (a list of today’s blog entries on an industry news site, for example), you use memcached to store data that’s repeatedly accessed in a set of servers that are configured to store the data in memory. (That’s the mem part of memcached.) After the initial retrieval of the data from the database, subsequent queries go to memcached to retrieve the data, thereby achieving much higher levels of performance.
Memcached is widely used in many applications to improve performance. Amazon rolled out a serviceit calls ElastiCache, designed to make using memcached easier. ElastiCache is protocol-compliant with memcached — it supports the same commands as memcached, and existing language libraries that work with memcached also work with ElastiCache. This benefit is important because it means an application can be migrated to ElastiCache without modification. Perhaps a good way to think about ElastiCache is that it’s similar to RDS: an Amazon-managed, operations-simplified service to make services commonly required by many applications both easy and inexpensive to use.
ElastiCache offloads the administrative overhead of running a caching service by
✓ Creating the server pool based on commands issued via the AWS Management Console or API: The server pool can be arbitrarily large, composed of servers ranging from micro-instances (213MB of memory per node) to High-Memory Quadruple Extra Large instances (68GB of memory per node). The number of nodes is limited to 20 per AWS account, but more can be requested if needed.
✓ Managing the pool to ensure caching server availability: If a server crashes or becomes unavailable, it automatically starts another to replace the failed server. . (Note that this service is available only with caches contained in a single AZ; spreading a cache geographically is not supported).
✓ Automatically patching servers with necessary software changes and migrating your data from an unpatched version to a new, patched version: This occurs at infrequent intervals, although at a time and weekday you define, which should be during a low-load period. During this maintenance window downtime, your application retrieves all data directly from the database instead of from ElastiCache.
✓ Allowing you to grow or shrink the pool with a simple command: It rebalances your data across the larger or smaller number of servers, all without interrupting service.
Using ElastiCache
ElastiCache is straightforward to use. Using either the AWS Management Console or API, you define the initial ElastiCache configuration, choosing the type of servers you want (in terms of memory capacity) and the number of servers you want in the ElastiCache pool. You then have to associate an ElastiCache security group with one that’s associated with your account. After you finish this configuration work, Amazon returns an endpoint identifier— a resource name that your applications use to interact with your ElastiCache pool. Using this endpoint identifier, you can then create and retrieve ElastiCache records using key-value techniques.
Why do you have to create an ElastiCache security group and associate itwith an account security group? ElastiCache is a service that’s separate and distinct from the account used by your applications. It has to be configured to accept traffic from your account, which is why it has its own security group that must be associated with a security group from your account — and preventing your ElastiCache pool from being accessed by anyone else.
ElastiCache scope
ElastiCache is available in all AWS regions.
ElastiCache cost
ElastiCache imposes a cost per server for each server within an ElastiCache pool, ranging from $.022 per hour (micro-instance type) to $2.02 per hour (Quadruple Extra Large type — 64GB memory). Prices vary somewhat byregion. In addition to the server charges, you face network traffic charges for traffic between an EC2 instance in one AZ and an ElastiCache pool in another AZ.The charge is $.01 per gigabyte of data transferred. Each account can transfer 15GB of traffic per month at no charge.