Google Cloud Serverless Platform Highlights Series — Episode 9: Cloud Run Websockets Triggering

Hello Everyone,

In this episode, we will go into using websockets as a trigger of Cloud Run, the serverless container platform on Google Cloud.

Photo by CHUTTERSNAP on Unsplash

What is Cloud Run

Cloud Run is a serverless compute platform that allows you to run stateless containers that are invocable via various triggers. Cloud Run is serverless, which means that you don’t have to worry about managing servers or infrastructure. Cloud Run also scales automatically, so you don’t have to worry about provisioning or managing capacity.

Cloud Run is a great choice for a variety of workloads, including:

• Web applications: Cloud Run can be used to run web applications that are invocable via various triggers. This makes it a great choice for building APIs, microservices, and other web-based applications.
• Batch processing: Cloud Run can be used to run batch processing jobs. This makes it a great choice for processing large amounts of data or for running long-running tasks.
• Event-driven applications: Cloud Run can be used to build event-driven applications. This makes it a great choice for responding to events in real time, such as changes to data or the occurrence of an error.

Cloud Run is a powerful and versatile platform that can be used to build a wide range of applications. If you are looking for a serverless platform that is scalable, reliable, and cost-effective, then Cloud Run is a great option.

Here are some of the key features of Cloud Run:

• Serverless: Cloud Run is a serverless platform, which means that you don’t have to worry about managing servers or infrastructure.
• Invocable via triggers: Cloud Run containers are invocable via different types of triggers. This makes it easy to integrate Cloud Run with other services and applications.
• Scalable: Cloud Run automatically scales your containers up or down based on demand. This ensures that you only pay for the resources that you use.
• Reliable: Cloud Run is a reliable platform that is designed to run your containers 24/7.
• Cost-effective: Cloud Run is a cost-effective platform that only charges you for the resources that you use.

If you are looking for a serverless platform that is scalable, reliable, and cost-effective, then Cloud Run is a great option.

Websockets Triggering

WebSockets are supported on Cloud Run without any additional configuration. However, WebSocket streams are still subject to the request timeout configured for your Cloud Run service. Therefore, you must ensure that this setting works well for your use of WebSockets, such as implementing reconnects in your clients.

On Cloud Run, you can configure for session affinity as a best effort attempt for subsequent websockets request to hit the same Cloud Run instance, however as stated, it is a best effort feature and therefore subsequent requests may still end up hitting a different instance. This is an inherent limitation and you must plan for it. One way to mitigate this issue is to synchronize data between the instances, that way even if the request goes to a different instance, the data that is being transacted upon remains the same, giving you the same output.

Best Practices for WebSockets on Cloud Run

WebSockets are supported on Cloud Run without any additional configuration. However, there are some best practices to follow to ensure that your WebSockets service works as expected.

• Handle request timeouts and client reconnects. WebSockets requests are treated as long-running HTTP requests in Cloud Run and are subject to request timeouts, even if your application server does not enforce any timeouts. If a client’s WebSocket connection times out, the client will be disconnected. To prevent this, your WebSockets clients should handle reconnecting to the server if the request times out or the server disconnects.
• Be aware of billing implications. A Cloud Run instance that has any open WebSocket connection is considered active, so CPU is allocated and billed, even if no operations are being conducted. You should monitor your usage and adjust your concurrency settings as needed to avoid unexpected costs.
• Maximize concurrency. WebSockets services are typically designed to handle many connections simultaneously. Since Cloud Run supports concurrent connections (up to 1000 per container), you should increase the maximum concurrency setting for your container to a higher value than the default if your service is able to handle the load with given resources.
• Use session affinity. A single webSockets connections is stateful, so the client will stay connected to the same container on Cloud Run throughout the lifespan of the connection. This naturally offers a session stickiness within the context of a single WebSocket connection. However, subsequent websocket connections may not connect to the same instance. You can also configure your Cloud Run service to use session affinity, which can help to improve performance and reliability, but it is only best effort. You must use external data synchronization to prevent unexpected behaviors if you are relying on stateful websocket connections.
• Synchronize data between instances. Because WebSockets connections can be routed to different Cloud Run instances, it is important to synchronize data between instances to ensure that all clients see the same data. You can do this by using an external data storage system, such as a database or a message queue. Remember that Cloud Run instances do not have any CPU allocated when the container is not handling any requests, and so if you periodically poll a database for synchronization, it may be challenging. GCP recommends Redis Pub/Sub (Memorystore) or Firestore real-time updates for data synchronization as message queues allow the services to pull new data from the queue each time an instance is handling a request.

Using Redis Pub/Sub

One way to synchronize data between Cloud Run instances is to use a message queue system, such as Redis Pub/Sub (Memorystore). With Redis Pub/Sub, each Cloud Run instance establishes a long-running connection to the Redis channel that contains the received messages. Once the container instances receive a new message on the channel, they can send it to their clients over WebSockets in real-time.

Similarly, when a client emits a message using WebSockets, the instance that receives the message publishes the message to the Redis channel, and other instances that are subscribed to this channel will receive this message.

This approach can provide a reliable and scalable way to synchronize data between Cloud Run instances for WebSockets services.

Conclusion

Websockets are a powerful way to trigger your Cloud Run services and may provide what you are looking for in terms of a stateful application running on Cloud Run, assuming you have data sychronization setup so that each request, despite hitting a different Cloud Run instance, presents an unified and expected behavior to your users.