[MUSIC PLAYING]
KARTHI THYAGARAJAN: Hello, everyone.
My name is Karthi Thyagarajan.
I'm a solutions architect with Google Cloud Platform.
So I'm going to talk about Cloud MemoryStore for Redis,
as well as OpenCensus today.
First, Cloud MemoryStore for Redis.
It provides a fully managed in-memory Datastore service
that's built on scalable, secure, and highly
available infrastructure that's managed by Google.
Now, caching capability, as most of you know,
is extremely important for most production applications,
and latency goes hand-in-hand with caching.
The way most people reduce latency is using caching.
Now, tracing this latency in an end-to-end fashion
for your application is the role of observability.
And it helps you design your application faster,
and it will also help you diagnose issues faster.
Now, I should point out that Cloud MemoryStore for Redis
already has powerful monitoring capabilities built in,
but this is entirely on the server side.
In this video, what we'll look at
is how you can build observability of attributes,
like end-to-end latency, directly
into your applications with something called OpenCensus.
OpenCensus is a vendor agnostic set
of libraries that provides metric collection
as well as tracing capabilities.
So before we get to our demo, let's
look at the application architecture.
Our application is a simple three-tier application,
and it's hosted on Google Kubernetes engine.
At its core, it consists of a simple Java Spring Boot
application, and users interact with this application via GCPs,
https Load Balancer.
And for the database here, our application
uses Cloud SQL, specifically the MySQL engine in Cloud SQL.
When the user issues a query against our application,
the results returned from the database
are cached using Cloud MemoryStore for Redis.
With that context, let's see the demo in action.
So in this application, what we'll do
is we will look for our employees in our directory
by typing in part of their name.
In this case, we'll type in Mel, and we
see that a whole bunch of results are returned.
In addition to those results, we also
see that the application tells us how long that query took,
248 milliseconds in this case.
Now, let's try that query again.
Type in Mel again, and as you can see now,
it only took one millisecond.
That's because the results were cached
in Cloud MemoryStore for Redis.
Let's dive a little deeper into it
by looking at what OpenCensus tracing tells us.
We've configured OpenCensus to perform trace logging
into Cloud Trace, which is a service offered by Google Cloud
Platform.
Navigating to Cloud Trace, we can
see that our trace logs are easily identifiable by the name
of the function that we used.
And in this case, it also tells us
how long the overall function took, 248 milliseconds
approximately.
OpenCensus tracing also lets us dive deeper
into our overall function call.
You can see here that our application attempted to get
the results from the cache--
in this case, Cloud MemoryStore for Redis
did not find it in the cache, hence the request to MySQL.
Down below, you can see that MySQL took approximately 244
milliseconds, about twice the order of magnitude
that it would take to fetch the data from Redis.
We can also see here that we have
annotated cache misses to help us better trace
our application.
Diving a little deeper into what happens after our results are
fetched from MySQL, you can see that our application
added the results to the cache using addToCache.
What about the second time the query is issued?
We expect the results to be fetched from the cache,
and that's what we see using OpenCensus tracing.
We can see that this query took a lot less time,
around one millisecond.
Because the results were found in the cache,
it did not have to access the database,
and we saved approximately 240 milliseconds.
That's quite a bit of time.
So that was the happy path.
You can see how we also have library level tracing here.
Now, let's see how OpenCensus can help
us diagnose issues that occur.
What we'll do here is we'll simulate a network issue where
we cannot reach our Redis host.
And we'll type in the name Mel again.
While we expect this to take a lot less time because we expect
the results to be in the cache, we
see that it actually takes 240 milliseconds or so,
so there's something wrong with our application.
There's too much latency.
So let's go back to OpenCensus tracing
and look for the most recent request.
Diving deeper into it, we see that there was a cache miss,
and the reason for the cache miss
is that our application was unable to connect to Redis.
Now, in production, we would have to chase this error down,
and it would be a lot more difficult to find
the error without this tracing capability.
Now, we know that it's a network issue or some kind
of connectivity issue getting to Cloud MemoryStore for Redis,
and we know where to focus our efforts.
So that can save us a lot of time during diagnosis.
Hopefully, that gives you an idea
of how you can use OpenCensus for both improving performance
as well as diagnosing issues.
To summarize, we've looked at how
you can use Cloud MemoryStore for Redis
to significantly reduce latency in your application.
Following that, we also saw how you
can build in end-to-end observability
directly in your application using OpenCensus.
If you're interested in using OpenCensus in your application,
please visit opencensus.io.
So thank you for watching.
If you enjoyed this video, please click the Like button
and subscribe to this channel.
[MUSIC PLAYING]