[MUSIC PLAYING] GOPAL ASHOK: Welcome to
Cloud OnAir, Live Webinars from Google Cloud. We are hosting
webinars every Tuesday. My name is Gopal Ashok, product
manager in Google Cloud. Today, I'll be talking about
getting started with Redis on Google Cloud Platform. You can ask questions
anytime on the platform, and we have Googlers on
standby to answer them. Let's get started. When you look at
what's happening today with businesses, most
of the businesses are moving to your
public cloud platforms. Most of you attending
this webinar probably are using
Google Cloud today or some other public
cloud platform or are interested in moving
to a public cloud platform. When we look at
the various reasons why customers want to move
to a public cloud platform, there are various reasons. One is to reduce
infrastructure costs. Secondly, they move
to the public cloud to gain more insights from
data, to use the services in public cloud, and
analyze the data, and get more insights from it. And thirdly, they want to
properly build applications so that they can deliver
services to their customers. So regardless of
the reasons that you want to move to
the public cloud, with Google Cloud Platform,
we provide a number of services that allows you to
basically build applications for your various needs. So if you look at the
different types of services that we provide in
Google Cloud Platform, you have the compute services. So for example, we have
the Google Compute Engine, where you can provide
infrastructure as a service. You have the Container
Engine, so if you want to deploy
applications in Kubernetes, we have a managed
Kubernetes service for that. Or if you want to do like
serverless application, so there's App Engine
and Cloud Functions. And then if you want
big data services like Cloud Data Flow
for string processing or Cloud Data Prompt
for managed Hadoop, there are a number of
services that allows you to provide big data solutions. So there are-- and
there are more. Like if you look at the
security and identity management services like Cloud IAM, so
the bottom line is regardless of the kind of
applications and services that you want to provide,
in Google Cloud Platform, we provide a large number of
services to help you do that. But underlying all these
applications and services that you want to provide, one of
the key services that you need is a database and
storage service. So depending on the
application that you build, you may want to have
a relational database, or you may want to
have a NoSQL database, or you may want to have
something like Data Warehouse. So when you look at the managed
database and storage services that Google Cloud provides,
we provide a wide variety of these services. So for example, if you
want a relational database, we provide Cloud Spanner. So Cloud Spanner,
as you know, is a globally distributed
transactionally consistent database. Or if you want to
have a document store, you have Cloud Datastore. Or if you want to have a
managed data warehouse, you have BigQuery. So as you can see, there's
a wide variety of services that you can choose from. And these are all
managed services so that you don't have
to worry about managing the databases yourself. So one of the key things
that Google has focused on is, like, for example, if
you look at Cloud Spanner, Cloud Spanner is one of the
really large scale database that Google uses internally
to provide their services. So in this particular case,
we provide those services in Google Cloud
Platform so that you can leverage the
power of Cloud Spanner and build your app
[? by distributed ?] applications on top of that. So apart from providing the
services that I just described, one of the other
key focus that we have is to make Google Cloud
Platform an open platform. So what do I mean by that? So most of the customers today
prefer to build applications on open source products. One of the key
reasons you want to do that is because you want
to be able to [? pull ?] your applications
anywhere you want. So for example, if you're
building an application using PostgreS, for
example, you want to be able to either do that
on prem, or if you move it to another cloud provider, you
want to be able to use PostgreS in any of the cloud providers. So in Google, we are
very much focused on providing open
source services. So for example, if you look
at the popular open source databases that are
currently available, and if you look at the
DB engine's ranking, for example, MySQL, PostgreSQL,
Elasticsearch, Redis, et cetera, are very
popular databases that customers are using
today to build applications. Now if you want to use those
databases in Google Cloud Platform, those databases
are available as services that Google provides, or
there are partner services that you can use to
leverage those databases. For example, if you are using
PostgreS, CloudSQL for PostgreS provides you a managed
PostgreS service. And with managed services,
one of the key benefits that you get, of course,
is that you don't have to manage the service. You just have to focus on
building the application. Same thing with MySQL-- so if you have MySQL, you
can use CloudSQL for MySQL. If you're using
HBase, for example, we have HBase-compatible
APIs both on top of the cloud [? Bigtable. ?] So open source is
a big focus for us. Now talking about
open source databases, Redis, which is the topic
of today's conversation, is one of the most
popular open source databases available today. Now why is Redis such
a popular database? So from my perspective,
the way I look at Redis is that Redis is a very
versatile in-memory database. So when I talk about
versatility of Redis, Redis actually can be used to
solve a number of different use cases. For example, Redis-- a lot
of customers in, for example, in Google Cloud today use
Redis for simple caching. So when I talk about
caching, it could be as simple as caching
some database queries, or it could be caching
some API results. The other use cases
for Redis are typically our session management,
where you just want to store a session token. So when customers first start
off with Redis, for example, they typically use
it as a simple cache. But the versatility of
Redis comes from the fact that it is actually a
data structure server. What I mean by that is
Redis provides a number of powerful data
structures that allows you to solve much bigger use
cases than simple caching. A very good example is
gaming leaderboards, so with sorted sets in
Redis, it is very easy to build leaderboards
for gaming applications. Similarly, for stream
processing or if you're building IoT services, Redis
provides a number of great data structures in order to do that. So if you look at how-- an example of how
Redis gets used, one of the examples
that we commonly see is stream processing. So in Google Cloud,
we see customers using stream processing
for solving quite a number of different use cases. This is a very typical
example that we see where customers use
Cloud Pub/Sub for basically ingesting events that
they want to process. So a very good
example is that if you want to process credit
card transactions, and you want to be able
to make decisions on that, you can use Cloud Pub/Sub,
which essentially is basically an event streaming engine that
allows you to ingest events pretty quickly. And then you can use
Cloud Data Flow in order to process these events
very, very quickly. One of the key use
cases for Redis that we see in this
particular architecture is that customers use Redis
to basically store states that they want to look
up really quickly, or if they want to store some
aggregate data that they really want to retrieve for
their processing. So this is a very good
example of how Redis gets used for stream processing use case. So one of the key
things that customers have been asking from
Google Cloud Platform is that they want to be able to
have a managed Redis service. So until now, customers have
been deploying their own Redis instance, and they've been
managing it themselves. What I'm happy to say is that
we now have Cloud Memorystore. Cloud Memorystore, which
is currently in beta, is a fully managed in-memory
datastore service for Redis. So what I want to do for
the rest of the presentation is to walk you through
Cloud Memorystore and walk you through the
capabilities that we provide. Like I mentioned, this
service is currently in beta. So let's take a look at what
Cloud Memorystore provides. So one of the key
principles that'd be followed for
Cloud Memorystore is to make sure that the
service is fast, scalable, highly available, and secure. And more importantly,
we wanted to make sure that you are focused on
building applications, and we can take care of
just managing Redis for you. And that's essentially
what we are doing with Cloud Memorystore. So with the Memorystore, it's
a fully managed Redis service. One of the key things that we
provide is high availability. So typically, when you
look at caching services, you normally don't SLAs
associated with it. With Cloud Memorystore, we
provide three nines of SLAs for one of the tiers. And finally, the
Memorystore is obviously built on Google's
scalable infrastructure. We provide a high
level of security based on both the
networking infrastructure and also using role-based
access control. So I'll talk more about
these features in detail as we move forward. But I just want to
quickly point out that with Cloud Memorystore
available in beta, it's going to be very
easy to use Redis to [INAUDIBLE] your
application, because now you don't have to manage your own
Redis in Google Cloud Platform. So let's take a look at
some of the features that are available with
Cloud Memorystore today. The first thing I
want to touch upon is how we expose a service. So Cloud Memorystore provides
two tiers of service-- a basic tier and
a standard tier. So what is a basic tier? So basic tier, basically,
is a single Redis instance. Where we see customers
use basic tier is when customers want to
use Redis as a simple cache. In this particular
case, application can tolerate the Redis
instance losing the data, and they simply want
to have a cache that is actually cheaper in cost. The key thing about
the basic tier is that we do the
instance monitoring. So what that means is
that if something happens to the instance, we have
health monitoring in place that will basically take care
of restarting the instance and recovering the
instance from failure. When you recover the
instance from failure, obviously, the IP
address is maintained so that the
applications can simply reconnect without any changes
on the application side. One of the key things
about the basic tier that I want to point out is
that we don't provide an SLA for the basic tier. So the standard
tier is essentially what you want to use if you
rely on Redis as a key component in your application,
and you want high availability for Redis. So what do we do in
the standard tier? We provide a replicated
instance of Redis. We provide one
secondary replica, which is deployed at cross-zones. So what that means is that
if there is a zonal failure, then your applications
are unaffected, because we automatically
failover the Redis instance over to the other zone. The other thing that we
provide is a seamless scale-up of capacity. This is also available
in basic tier, but the key difference here
is that in standard tier, when we do the scaling up the
instance up and down, we provide high availability
for the instance. And I'll talk more about
it when I show the demo. And lastly, like I mentioned,
with standard tier, you get three nines
of availability. I want to note that the
availability SLA is applicable when we go GA. It's not applicable in
the current beta release. OK, so the other thing
that I want to touch upon is apart from the
tiers, we also provide what we call capacity tiers. So the way we expose
the servers is the more memory you provision,
the more throughput you get. So as it can see in the
table, if you provision up to 35 gigabytes on Redis, you
get about three bits per second in terms of network throughput. And if you provision greater
than 100 gigabytes of Redis, you get 12 gigabits per
second network throughput. So the key thing to note here
is that when you plan your Redis deployment using
Memorystore, you want to consider what your
application throughput characteristics are. And depending on that,
slice your Redis instance appropriately. One of the key
aspects of Redis is that Redis is single threaded,
so you always will have-- in most cases, you
have sufficient CPU for these instances. The key thing that
you want to note is how much network
throughput you want to have before the
application saturates a Redis server. So the capacity tier basically
tells you the network performance that you get. It also determines the
pricing of the Redis instance. So the way we have
priced Memorystore is by dollar per gigabyte hour. So what does that mean? So if you're provisioning one
to four gigabytes of Redis, so anything less than or
equal to four gigabytes, you will be charged at
4.9 cents per gigabyte. Or similarly, as you go higher
up in the capacity range, obviously, your gigabyte
[? hour ?] pricing is actually going to be lower. Standard tier
instance, similarly, are priced using the
same capacity ranges, but the pricing is going to be
more compared to the basic tier instance. Like I said, Cloud Memorystore
is a managed service, so we make this provisioning
extremely simple. We allow you to provision
Memorystore Redis using Cloud Console
or Command Line or using Google
Client Libraries. And the other key
thing that we have done is we have integrated
with Terraform, so if you are managing
your infrastructure as infrastructure
as code, you can use Terraform to provision
the Redis instance. One key thing I
want to point out is that we are supporting
Redis version 3.2.11. We will be looking at
supporting more versions later, but currently in beta, what
is available is 3.2.11. Just want to quickly
touch on high availability and what we do there. So the key thing I
want to point out here about high availability
architecture or when you deploy a
standard tier instance is that you are
connecting to a single IP, and, basically, we take
care of the redirection of the application
connections to the right VMs if a failover happens. The other thing is that we
provide automatic failovers, so we have our
own health monitor that monitors the instance. We monitor the health
of the processes, and if anything goes wrong,
we automatically failover. And the failover time is
actually very, very fast. It's actually in the
order of seconds. So in terms of
application availability, you get pretty good
at high availability with a standard tier instance. And finally, security--
the key thing that we try to do
with Cloud Memorystore is to protect the instance
from external attacks. So when we provision
the instance, we provision it
using private IP. So when you provision a
Cloud Memorystore instance, it's not accessible
from the internet, because it is provisioned
using a private IP address. The other key
thing you can do is to limit the access of the
instance using Virtual Private Network. And we also support Cloud
Identity and Management roles, so we have granular
IAM roles that allows you to control
access to the Redis instance based on your
organizational rules. And the other key thing
that I want to point out, which actually became
relevant very recently, is critical patch management. So Redis recently
announced a critical patch. We actually applied the
patch even before it was publicly announced, so
one thing you can be sure of is that your Redis instances
or Cloud Memorystore instances are always
secure, because we take care of the
patching, and you don't have to worry about it. And finally, I want to touch
upon some of the other features and capabilities. I talked about
scaling seamlessly. So we allow scaling of
the Memorystore instance at both basic and standard tier. You can scale your
memory up and down. With basic tier,
obviously, you will have your cache [INAUDIBLE],,
because its a single instance. But the standard tier of
scaling is a highly available operation. We have integration
with Stackdriver, and I'll talk more
about it in the demo. And we also will be
providing the capability to back up your data
using RDB snapshots, which will be coming soon. The RDB snapshots is
not currently available in beta today, but we plan to
make it available pretty soon. And lastly, because we are
built on open source Redis, we are protocol-compatible. So what that means is that if
you're running your own Redis instance today, you can switch
over to Memorystore instance with very little or
actually no code change, and everything should just work. OK, so that's kind of the
summary of the capabilities that we provide with
Cloud Memorystore. So let me quickly
switch over to the demo and show you how easy it
is to deploy and manage Cloud Memorystore. So to get started, you go
to the Google Cloud Console, and Memorystore is a storage
and database service. So if you click on
Cloud Memorystore, it'll take you to the
Memorystore landing page. One of the key things I
want to point out here is that if you're provisioning
Memorystore for the first time, we automatically
enable the API for you. And once the API is
enabled, you can start provisioning for instance. In this particular case, I have
provisioned instances already. But let's go ahead
and create an instance and see how easy
it is to do this. So when you provision
an instance, the first thing that you want to
do is give it an instance name. I'm just going to give it-- let's say, Demo Instance
2, as I mentioned. The Redis version
that we provide is 3.2, so you
don't have an option to select a version
in the beta release, but we will be providing support
for more versions later on. And the next choice
that you want to make is whether it's a basic or
a standard tier instance. Like I mentioned earlier,
basic tier is a standalone, and standard tier is
a replicated instance. In this particular
case, I'm going to choose standard,
because I want to deploy a highly available instance. And the next thing I want
to do is select the region where you want to
deploy the instance. So the key thing I
want to point out here is that if you
choose zone as any, we automatically pick
the zones for you for both the master
and the replica. But if you want to specify the
zone where the master is going to be deployed at
the time of creation, then you can go ahead and
select a specific zone where you want to deploy
the master instance. But even if you select
a zone for the master, we will automatically
select a zone for the replica, which is
different from the zone that you selected. In this particular case, I'm
just going to leave it at any. And over here, this
is where you select the size of the Redis instance. As I mentioned, if you change
the size of the instance, you basically get different
network throughput. So you want to be able to
determine what is the network throughput that you want to
get out of your Redis instance, and size the
instance accordingly. And lastly, you want
to pick the network that this Redis
instance is going to be authorized to connect,
so what that means is that VMs connected
to the VPC network where the Redis
instance is provisioned can actually access this
particular Redis instance. So let's go ahead and
create the instance. So as you can see, it
is actually very simple to go ahead and create this
instance-- create the Redis instance in using Memorystore. One quick thing I
do want to point out is that I talked about scaling. So I already provisioned
a basic instance here, and it is currently
one gigabyte. Now I want to go ahead and
change that to, let's say, 10 gigabytes. As you can see, it's super easy. All I have to do is
go to Edit Instance and change the size of the
instance, and then click Save, and we automatically
do the scaling for you. As I mentioned earlier, when
you scale a basic tier instance, we recreate the instance, so
it's a full flush of the cache, but we preserve the IP address
so that applications can retry and connect back to
the same IP address. OK, so now I talked about
Redis getting provisioned on a private IP address. As you can see, the IP that
we currently use for the demo instance is 10.0.0.4. So from a connectivity
perspective, there are a few things
to keep in mind. One is you can only connect to
the Memorystore Redis instance from within the
same region where you have deployed the instance. So that means you can
connect-- your application has to be running in
US [? Central ?] 1 to be able to connect to this
particular Redis instance. Secondly, you cannot access
the Redis instance outside of the region, obviously. So for example, if you're
connecting from your laptop or trying to connect from your
laptop to the Redis instance, you may not be able
to do that directly. So let's look at connecting
to the Redis instance. Like I said, Redis is
protocol-compatible. So I'm just going to run a
quick standard Redis benchmark and see if that works. And as you can see, the
use open source Redis, so any of the tools that you
use with open source Redis works great. In this particular
case, I'm just running a Redis
benchmark that basically does a get set
[? push and a pop. ?] As you can see, we get pretty
good performance when you are using a Memorystore instance. Now the interesting
question is, how do you monitor the instance? As I mentioned earlier,
we have integrated with Stackdriver monitoring. So to go get to
Stackdriver, let me quickly show you how to do that. So if you want to get to
Stackdriver and see the Redis instance, you basically just
have to go onto Stackdriver and click on monitoring. And if you launched
Stackdriver monitoring, you can get to the
Redis dashboard. So when you look at the
dashboard, as you can see, we expose a whole
bunch of metrics that makes it very, very easy
for you to monitor your Redis instance. So in this particular case,
you can see the average network throughput. You can see the CPU utilization. You can see the average
commands per second. You can see the [INAUDIBLE]
percentile latency. So there's a lot of
things that we actually expose as part of Stackdriver. So let's take a look at what all
the metrics are that we expose. So to see the metrics, what
you can do is go to Resources, and go to Metrics Explorer, and
just type in, redis.googleapis. And you will see the
list of all the metrics that are currently published
for you to monitor the Redis instance. So as I showed
you, it's very easy to go deploy a Redis instance. It's protocol-compatible, so
that means any of the tools will work that you're
currently using. So if you're currently using
a [? self-deport ?] Redis instance, and your applications
are using Redis for whatever reason, it is very, very easy
to switch to a Memorystore instance. And finally, I touched
upon some of the features around monitoring. So if you want to be able to
manage the Redis instance, it's very, very
easy to manage it, because we automatically
provide the monitoring for you so that you don't have to
integrate with any third party tools to do the monitoring. Like I mentioned, we take care
of the management of the Redis instance so that you
don't have to worry about patch management, et cetera. All you have to worry about is
just writing your application and using Redis for
what it is meant for. So that's pretty much the
Cloud Memorystore product. It's currently in beta. We are planning to
go GA pretty soon. But if you are interested
in testing the product, you can do that using
free credits that are available with the
Google Cloud Platform. And if you want to have more
information about Memorystore, you can also go to
Google.com/memorystore, where we have the documentation
and more information about the service. Thank you very much. Now we are going
to take the Q&A. OK, so we already got a few
questions from the audience. I'm just going to
quickly address some of the questions
that are showing up here. So the first
question is, will you be providing support
for Redis 4.0? Yes. Like I mentioned,
currently in beta, we are only supporting
3.2, but we plan to provide support for
Redis 4.0 pretty soon. We don't have exact timeline,
but soon after GA, we expect to be able to provide
support for Redis 4.0. The other question is, I see
that the current limit is 300 GB. My application requires close
to a terabyte of Redis data. What are my options? That's a very good question. So like I mentioned, the
basic and standard tier are essentially
single instance Redis. So what that means is that
there is only one master, and it does not scale out
Redis cluster solution. So in this particular
case, one option is to basically deploy
multiple instances of Redis and do a client-side sharding. That's one way to do it. The other thing that
we are working on is obviously Redis cluster. Again, this is in our
roadmap, and we are actually working towards providing
a Redis cluster. But until then, the limit
is going to be 300 GB. Is persistence supported
in the current release? Very good question. So this is something that
currently is not supported. So let me clarify what we-- let me clarify
persistence a little bit. So there is both-- there is RDB,
and then there is AOF, at least in 3.2. So we plan to provide RDB
snapshots very quickly, where you can take RDB
backups to a GCS bucket. AOF is something that
we are working on, and we should have
that pretty soon. But currently, neither
basic or standard tier provides AOF [? persistence. ?] And finally, when is
the product going GA? We expect the product to go
GA by September of this year. So we are actively
working towards that, and we hope to have that
released in September. So that's all the
questions that I have. Thank you very much. Thank you for
attending the webinar. Have a great day. [MUSIC PLAYING]
