This page describes Anywhere Cache, a feature that provides an SSD-backed zonal read cache for Cloud Storage buckets. Anywhere Cache delivers on-demand cache capacity by automatically sizing the cache and available bandwidth to meet your needs. Because of its benefits, Anywhere Cache is particularly helpful for reducing the network costs associated with read-heavy workloads.
See Create and manage caches to learn how to create and manage caches in Anywhere Cache.
Overview
Anywhere Cache lets you create caches in the same zone as your workloads. When you create a cache in a zone, data read requests originating from the zone are processed by the cache instead of the bucket. Each cache serves clients within the same zone as the cache. Data will only be ingested into the cache from your bucket when that data is read by a VM that resides in the same zone as the cache. Metadata doesn't get cached and requests for object metadata are processed by the bucket instead of the cache.
When you create a cache for a bucket, the cache must be created in a
zone within the location of your bucket. For example, if your bucket is located
in the us-east1 region, you can create a cache in us-east1-b but not
us-centra1-c. If your bucket is located in the ASIA dual-region, you can
create a cache in any zones that make up the asia-east1 and asia-southeast1
regions. For a list of zones, see Regions and zones in the Compute Engine
documentation.
For each bucket, you can create one cache per zone. For example, if your bucket
is located in the US multi-region and your Compute Engine VMs are running in
the us-east1-b and us-central1-a zones, you could create a cache in
us-east1-b and another cache in us-central1-a.
Anywhere Cache is a fully managed service and always returns consistent data.
Benefits
Anywhere Cache helps you in two primary ways:
Get faster data access: Anywhere Cache places your data in high-performance storage devices near compute resources. The shorter network path and high performance devices enable your workloads to get more throughput, complete reads more quickly, and reduce time-to-first-byte latency of reads.
Avoid multi-region data transfer fees: You can use Anywhere Cache to avoid data transfer fees for other products such as Compute Engine when you use multi-region buckets to query Cloud Storage data.
When should you use Anywhere Cache?
Anywhere Cache is best used to cache data that's infrequently changed and frequently read, such as data used to train ML models or run analytics workloads.
Say you're training an AI model across many Google Kubernetes Engine nodes, all repeatedly reading data that's stored in your Cloud Storage buckets and running in the same zone. When you create a cache in the zone where your workload is running, the cache provides extra bandwidth and helps you avoid the data transfer fees associated with reading data in multi-region buckets, letting you run larger, scaled workloads more efficiently.
Supported locations
Caches can be created in specific zones as long as capacity is available. If the capacity for creating a cache is unavailable, the Anywhere Cache service continues trying to create a cache until the capacity becomes available or the creation process is aborted by the user. The capacity might remain unavailable for a long period of time.
For each bucket, you can create a maximum of one cache per zone. For example,
if a bucket is located in the us-east1 region, you could create a cache in
us-east1-b and another cache in us-east1-c. If a bucket is located in a
multi-region that encompasses us-central1 and us-east1, you could create
a cache in us-central1-a and another cache in us-east1-b.
You can use Anywhere Cache in the following zones. These zones can be used depending on the location type of your bucket.
| Geographic area | Location | ||||
|---|---|---|---|---|---|
| Zone name | Region | Dual-region | Multi-region | Custom dual-region | |
| Asia | |||||
asia-east1-a |
|||||
asia-east1-b |
|||||
asia-east1-c |
|||||
asia-northeast1-a |
|||||
asia-northeast1-b |
|||||
asia-northeast1-c |
|||||
asia-southeast1-a |
|||||
asia-southeast1-b |
|||||
asia-southeast1-c |
|||||
| Europe | |||||
europe-north1-a |
|||||
europe-north1-b |
|||||
europe-north1-c |
|||||
europe-west1-b |
|||||
europe-west1-c |
|||||
europe-west1-d |
|||||
europe-west4-a |
|||||
europe-west4-b |
|||||
europe-west4-c |
|||||
europe-west6-a |
|||||
europe-west6-b |
|||||
| United States | |||||
us-central1-a |
|||||
us-central1-b |
|||||
us-central1-c |
|||||
us-central1-f |
|||||
us-east1-a |
|||||
us-east1-b |
|||||
us-east1-c |
|||||
us-east1-d |
|||||
us-east4-a |
|||||
us-east4-b |
|||||
us-east4-c |
|||||
us-east5-a |
|||||
us-east5-b |
|||||
us-east5-c |
|||||
us-west1-a |
|||||
us-west1-b |
|||||
us-west1-c |
|||||
us-west4-a |
|||||
us-west4-b |
|||||
us-west4-c |
|||||
Anywhere Cache recommender
The Anywhere Cache recommender provides recommendations and insights for creating caches in bucket-zone pairs by analyzing your data usage and storage. For overview information and instructions on using the Anywhere Cache recommender, see Anywhere Cache recommender.
Cache operations
This section describes operations you can perform on Anywhere Cache caches. Some operations are asynchronous and return a long-running operation, while other operations are synchronous, where the operations are done immediately and return an AnywhereCache resource.
Create a cache
When you create a cache, you can configure the following properties:
The Time to live (TTL) is the longest time that a chunk of data will remain in the cache from the last read. For example, if the TTL is set to 24 hours, a chunk of data that is last read at 11am on Monday with no subsequent reads will be evicted from the cache at 11am on Tuesday.
You can set a TTL between 1 hour and 7 days. If unspecified, the TTL defaults to 24 hours.
The admission policy determines whether the cache ingests data on the first miss or on the second miss. Ingesting on second miss lets you ingest data into the cache only when the data is read a second time within the TTL you specified. Ingesting on second miss lets you reduce the cost of using Anywhere Cache by ensuring that you only cache objects that are read more than once, but also reduces the cache hit rate.
If unspecified, the admission policy defaults to ingest on first miss.
When you create a cache, the cache enters a CREATING state as it's being created, and enters a RUNNING state when it becomes actively running. Cache creation operation can take up to 48 hours, after which, the operation times out.
The AnywhereCaches Create API is asynchronous. A create operation causes a long-running operation to be returned. The long-running operation provides a status of the create operation and lets you cancel the operation before it's complete.
Update a cache
You can update the TTL or admission policy of a cache in a RUNNING state.
When a cache is in the process of being updated, the pending_update field
evaluates to true. While the pending_update field evaluates to true,
the cache cannot be updated again.
A cache in a CREATING, PAUSED, or DISABLED state cannot be updated. The AnywhereCaches Update API is asynchronous and returns a long-running operation.
When the TTL of a cache has finished updating, the new TTL immediately applies to newly ingested data, and only applies to existing data when that data is read. This means that existing data within the cache retains the old TTL until that data gets read, or is evicted due to the expiration of the TTL.
Get a cache
When you get a cache, Anywhere Cache returns the state and configuration of the cache instance. The AnywhereCaches Get API is synchronous and returns an AnywhereCache resource.
List caches
You can return a list of associated caches for a given bucket. You can return the list of caches in a paginated manner.
The AnywhereCaches List API is synchronous and returns a list of AnywhereCache resources.
Pause a cache
You can pause a cache to stop the data ingestion of a cache that's in a RUNNING state. When a cache is in a PAUSED state, you can still read existing data from the cache but you can't ingest new data into the cache. Reading existing data from the cache resets the TTL of the data in the cache.
When you resume a cache in a PAUSED state, the cache enters a RUNNING state.
The AnywhereCaches Pause API is synchronous and returns an AnywhereCache resource.
Resume a cache
You can resume caches that are in a PAUSED state or a DISABLED state, as long as the disabled cache is within the 1-hour grace period. After the 1-hour grace period, the resume operation is done at best effort, as the cache could be deleted at any point after the grace period. Once a cache has been resumed, it enters a RUNNING state.
The AnywhereCaches Resume API is synchronous and returns an AnywhereCache resource.
Disable a cache
You can disable a cache to permanently remove the cache from your bucket's configuration. When you disable a cache, it enters a DISABLED state. During this state, you can still read existing data from the cache but you can't ingest new data into the cache.
After you disable a cache, there's a 1-hour grace period during which you can cancel the disablement by resuming the cache. After this 1-hour grace period, the cache gets deleted. When the cache gets deleted, all the data within the cache gets evicted, and the cache is removed from the bucket.
During the 1-hour period before the cache gets deleted, you can revert the DISABLED state by resuming the cache, at which point the cache resumes in the RUNNING state.
The AnywhereCaches Disable API is synchronous and returns an AnywhereCache resource.
Cache size and bandwidth limit autoscaling
Anywhere Cache provides temporary cache storage and bandwidth that scale up and down according to your needs.
Cache bandwidth limit
The cache bandwidth limit applies on a per-project, per-zone basis.
This means that traffic to and from caches within the same project and zone
count towards a common cache bandwidth limit, even if the caches are created
for different buckets. For example, say Cache A is created in the
zone us-east1-a for the bucket example-bucket-1,
which is located in the project my-project. Cache B is created in
us-east1-a for example-bucket-2, which is also
located in my-project. Because Cache A and
Cache B are both located in us-east1-a and my-project,
traffic for both caches count towards the same cache bandwidth limit.
You can increase the total amount of cache bandwidth by using either of the following methods:
Increasing the amount of data stored in the cache
Increasing the number of caches by populating more zones with caches
To learn more about size limits for Anywhere Cache, see the Maximum Anywhere Cache cache size limit for buckets. To learn more about Anywhere Cache bandwidth limits, see Maximum Anywhere Cache data usage bandwidth limit per-project, per-zone.
Cost controls
The following are several tips you can utilize to minimize the costs of running a cache:
Bucket selection: you should only create caches for buckets that contain data you want to cache.
Zone selection: you should only create caches in zones where your workload will benefit from caching.
Ingest on second read: you can specify that data only gets ingested on second read as opposed to on first read, which helps ensure that the cache only stores data that's read more than once.
TTL setting: you should specify the minimal TTL you need to store data in the cache. The TTL can be changed non-disruptively.
Pausing the cache: you can pause a cache to stop data ingestion and the associated cache ingest fees. Pausing the cache has an immediate effect. You can pause a cache until all data gets evicted after the specified TTL ends. When all data gets evicted, you're no longer charged data storage fees.
Disabling the cache: you can disable a cache to permanently remove it from the service and stop all associated cache fees from accruing.
Limitations and restrictions
You cannot delete a bucket until all caches associated with the bucket have been deleted.
Anywhere Cache is not durable storage and data may be evicted from the cache in various scenarios. One scenario is when the cache gets automatically resized to ensure that sufficient resources are available for your workloads. In this scenario, some data might get evicted according to a least-recently-used (LRU) algorithm until the Anywhere Cache service has finished increasing the cache size.
In any case, your data remains safely stored in your source bucket. When data gets dropped from the cache due to reasons besides TTL expiry, the Anywhere Cache service will attempt to re-ingest the data into the cache transparently and at no cost to you. If the data cannot be transparently re-ingested or was dropped due to TTL expiry, the Anywhere Cache service will re-ingest the data upon first or second read.
Temporary resource shortages
The following sections describe Anywhere Cache behavior when a temporary resource shortage occurs, meaning there isn't enough SSD capacity or serving capacity in a specified zone to create a cache or increase the cache size.
Failure to create a new cache
Anywhere Cache can fail to create a new cache in a specific zone due either to a lack of SSD capacity or throughput serving resources, which results in a temporary shortage of resources. During this time period, Anywhere Cache attempts to create the new cache for up to 48 hours. If resources become available within the 48 hour timeframe, Anywhere Cache completes the cache creation request successfully. If resources don't become available within the 48 hour timeframe, the cache creation request fails. To avoid disruption to your caching, you can manually cancel the cache creation request and create a new cache in a different zone or region which might have capacity available.
To monitor cache creation during a temporary resource shortage, see Anywhere Cache documentation for using long-running operations.
Failure to increase cache size
Anywhere Cache can fail to complete a cache size increase due to a temporary shortage of resources in two scenarios:
When there isn't enough SSD capacity for increasing your cache size in specified zone. For more information, see Insufficient SSD capacity.
When there's a temporary shortage of throughput serving resources in a zone to scale the cache bandwidth limit. For more information, see Insufficient serving capacity
Insufficient SSD capacity
Although Anywhere Cache offers automatic cache size increases on-demand, cache size increases are contingent upon SSD capacity availability. If SSD capacity isn't available when the automatic cache size increase request is made, Anywhere Cache continues to submit the request until the temporary resource shortage ends or an increase in cache size is no longer needed.
During a temporary resource shortage, new data is ingested and existing data in the cache is evicted based on a least-recently-used basis to ensure there is enough space in the cache for new data. Caches that are large enough to store most of the hot data experience little to no impact to cache metrics. Caches with less capacity than the amount of hot data can evict data and re-ingest the same data more often than caches not affected by resource shortages. When the actual size of your cache is much smaller than the needed capacity, you might experience the following resource shortage-related behavior:
A lower cache bandwidth limit, lower cache throughput, higher data transfer bandwidth quota consumption, and a possible impact on other metrics.
Billing might be affected in the following ways:
Cache ingest fee increase
Cache storage fee decrease
Cache data transfer fee decrease
Cache data transfer operations fee decrease
Multi-region data transfer fee increase
Class B operations fee increase
For best results during a temporary resource shortage, we recommend monitoring your caches and pausing the cache or workload based on your needs.
Insufficient serving capacity
A cache bandwidth limit (CBL) shortage can occur temporarily during a cache size increase when throughput serving resources in a specific zone are insufficient to scale the cache bandwidth limit of existing caches at 20 Gbps per TiB. During a CBL shortage, Anywhere Cache doesn't allow the cache CBL to scale at 20 Gbps per TiB of data but the cache continues to serve read requests. Requests for a CBL increase are evaluated on a per-request basis. During a CBL shortage, you might see an increase in egress bandwidth consumption.
For best results during a temporary resource shortage, we recommend monitoring your caches and pausing the cache or workload based on your needs.