[MUSIC PLAYING]
MARTIN OMANDER: Wietse, I have a problem.
WIETSE VENEMA: What's that, Martin?
MARTIN OMANDER: My Cloud Run service displays user profiles.
And it takes a while to assemble all the data for a user profile
on the server.
I've tried caching data in a global variable
between requests.
But I notice that it's not always
there for the next request.
WIETSE VENEMA: That's because on Cloud Run,
you're not guaranteed to get the same instance every time.
But we can make things better by turning on session affinity.
Let me show you how.
[MUSIC PLAYING]
First of all, let's turn on Session Affinity in your Cloud
Run service.
Click your Cloud Run service.
Click Edit and Deploy New Revision.
Go to the Connections tab.
And check the Session Affinity checkbox.
Then scroll to the bottom and click Deploy.
MARTIN OMANDER: Done.
Now, what did that checkbox do?
Will I see a new item on my Cloud bill?
WIETSE VENEMA: No, no, it's included.
It's just another toggle.
MARTIN OMANDER: Ah.
I see.
And what kind of apps is this useful for?
WIETSE VENEMA: Well, your use case is perfect.
You're caching user-specific data that takes some time
to generate the first time.
Session affinity will make your cache more efficient,
because Cloud Run tries to route requests
from the same client to the same container instance every time.
MARTIN OMANDER: That makes sense.
WIETSE VENEMA: Another example is a game that uses WebSockets.
And you want the player to connect to the same server
if the socket is disconnected.
Because you don't want to rebuild the entire game
state of memory and introduce lag for the player.
MARTIN OMANDER: Got it.
Session affinity lets me cache data on the instance
between requests.
What about sessions?
Many web frameworks, like Express-session or PHP Symfony,
support server-side sessions.
And I've used them for shopping carts and similar in the past.
Can I use session affinity for these server-side sessions?
WIETSE VENEMA: I'm glad you asked,
because you absolutely shouldn't.
Cloud Run scales up and down.
And that means it adds and removes instances.
So the request can end up in a different instance
that doesn't have your data.
Think of this like a regular cache.
Your code will run faster if the data is in the cache.
But it shouldn't assume it's there.
MARTIN OMANDER: So how should I use server-side sessions
in Cloud Run then?
WIETSE VENEMA: Well, most people like to use Redis.
And [LAUGHS] you did a video on that,
how to port stateful web apps to Cloud Run.
MARTIN OMANDER: Ah, right.
Dina had looked into how to implement server-side sessions
in Cloud Run.
And we shot that video based on her findings.
I'll add a link to it in the show notes.
WIETSE VENEMA: Oh, by the way, did
you hear about this new feature that we added to Cloud Run?
It makes it easier to create a memory store instance
and connect your Cloud Run service to it.
MARTIN OMANDER: Yeah, I saw that in a video
from the Cloud Next conference.
So back to session affinity.
Let's say I'm not doing server-side sessions
and I'm only using session affinity
to help with local caching.
I could still use Redis for that caching, right?
WIETSE VENEMA: Yes, you can use Redis for caching.
But if you can easily recreate your data,
like you did with the user profiles,
it's cheaper and simpler to cache data in local memory
instead of storing it in memory store.
MARTIN OMANDER: Ah, I see.
Session affinity makes a cache with user-specific data
more efficient.
But Wietse, I am a developer.
I want to know how this works.
How does Cloud Run know where to send each request?
WIETSE VENEMA: Yeah.
Yeah.
I can relate with that.
I also want to know how things work.
So session affinity is implemented using cookies.
MARTIN OMANDER: That probably means
I will have to include this cookie when
I make API calls from my JavaScript web app, right?
WIETSE VENEMA: Well, usually you don't need to worry about that.
Many client-side libraries include cookies by default.
But if you are using Axios, use with credentials, which will
make Axios send the cookies.
MARTIN OMANDER: Ah.
Thank you for showing me, Wietse.
And thank you, everyone, for watching.
If you have any questions for Wietse or me,
or suggestions for future serverless topics,
please enter them in the comments below.
We read every single comment.
Until next time.
[MUSIC PLAYING]