Memorystore Redis

Memorystore is Google’s managed Redis service. ZopDay creates the instance on your VPC through private services access and stores its connection details in Secret Manager.

What does a Memorystore job create

The examples below use a job called shop.

• A new network when you choose Create new VPC: shop-network, with a private subnet, a firewall rule for internal traffic, a Cloud Router and Cloud NAT.
• Private services access on the VPC, if it is not there yet. This is a reserved /16 range named after the network (google-managed-services-shop-network) plus a service networking connection. Cloud SQL instances on the same VPC share it.
• A firewall rule, shop-datastore-allow, allowing TCP 3306, 5432 and 6379 from 10.0.0.0/8. That is the whole 10.x private block, wider than the default 10.0.0.0/16 VPC range.
• The Memorystore instance, authorised on the VPC. Its connect mode is PRIVATE_SERVICE_ACCESS, AUTH is on and transit encryption is SERVER_AUTHENTICATION.
• A Secret Manager secret, zop-ds-shop, holding the endpoint (the instance’s private host), port 6379, a username and a password.

Which Provision screen fields does Memorystore actually use

Memory / Nodes   1 by default (1 to 6); sets the memory size in GB, and 2 or more selects STANDARD_HA
Node type        BASIC or STANDARD_HA
Engine Version   REDIS_7_2, REDIS_7_0 or REDIS_6_X
Public Access    off by default

On GCP, the instance follows only the Memory / Nodes value. ZopDay does not pass the node type, engine version or public access fields to Memorystore today. As a result:

• the tier comes from Memory / Nodes;
• the Redis version is Google’s default for new instances;
• the instance has only a private endpoint.

A STANDARD_HA instance has a replica and automatic failover. To get one, set Memory / Nodes to 2 or more, which also makes the instance at least 2 GB. High Availability, Deletion Protection and Automated Backups are not offered for Redis.

Why the stored password is not the Memorystore AUTH string

The password stored in zop-ds-shop is a 32-character value that ZopDay generates. It is not the instance’s AUTH string. Memorystore generates the AUTH string itself when AUTH is on, so read it from Memorystore when you set up clients.

When you connect the instance to a cluster, ZopDay writes REDIS_HOST, REDIS_PORT, REDIS_PASSWORD and REDIS_URL into a Kubernetes secret in zop-system. These come from the same stored values. Clients must use TLS because transit encryption is on.

How do applications reach a Memorystore instance

There is no in-cluster alias. Applications reach the instance’s private host over the VPC. A cluster on a different VPC needs a VPC peering, which ZopDay creates when you connect the instance to that cluster. Both networks must be in the same project, and their address ranges must not overlap. That rules out two networks created from the Provision screen, since both use 10.0.0.0/16.

Replacing the instance changes its address, so read it from the secret instead of hard-coding it.

What does deleting a Memorystore job remove

Deleting the job removes, in order:

• the secret;
• the instance;
• every firewall rule on the network whose name ends in -datastore-allow, including rules that belong to other databases or caches;
• the network, if ZopDay created it for this job, including the private services access peering and range.

Which Redis features Memorystore jobs leave unset

ZopDay does not set persistence (RDB or AOF), maintenance windows, read replicas beyond the STANDARD_HA replica, or Redis Cluster mode. It never changes the instance’s size on its own after creation.