News for hackers. Stuff that matters.
Re:Migrating Millions of Concurrent WebSockets to Envoy by jeffbee on Wednesday March 17, 2021 @02:28PM (#26495043)
When you control both client and server it seems like hot restart is just a complicated stunt you don’t need. Isn’t it fine to just stop accepting connections, tell all your clients to reconnect, and do a normal restart? The frontend load balancer that stands between you and Gmail doesn’t know how to restart hot but you probably never noticed.
Re:Migrating Millions of Concurrent WebSockets to Envoy by mbyio on Wednesday March 17, 2021 @02:57PM (#26495389)
I think Slack is different than Gmail because people are actively having conversations, so if you disconnect, it is much more likely to be noticeable and annoying.

Reading between the lines, I think what they would need is a way to tell clients to move to a new websocket connection at the proxy layer. I don't think there is an easy built-in way to do this in the websocket protocol, so they would have to implement something custom in their application layer. This would also require triggering custom code in the client to make a new websocket connection, start using it, and then close the old connection.

I feel like it would have been simpler to just have the client do a graceful reconnect every 5 minutes. But they probably decided to use envoy so they could have the other advantages too.

Re:Migrating Millions of Concurrent WebSockets to Envoy by zemo on Wednesday March 17, 2021 @05:03PM (#26496747)
maybe it could work, but in practice it's often not as easy as you'd like it to be. disconnecting everyone at or around the same time simultaneously can easily create a thundering herd or a TCP global synchronization problem, so "just ask everyone to reconnect" has its own set of complications.
Re:Migrating Millions of Concurrent WebSockets to Envoy by toast0 on Wednesday March 17, 2021 @07:16PM (#26497984)
Depending on where the load balancer is in the protocol stack, it might be hard to signal the client to please reconnect. I've tended to run/use load balancers in tcp mode or direct server return mode; in both cases, the load balancer can't signal the client or server (except by killing connections, which isn't ideal).

If you do restart with reconnect, many clients will need to reconnect multiple times, as it they get kicked off early, they'll tend to connect to another old server, and have to get kicked off again later. This isn't great because connection startup is usually expensive; also a (hopefully) small minority of clients may have difficculty connecting because of network issues and it may take them a substantial time to get reconnected.

If you have a working hotload path, you get clients to new server server code faster using less resources.

Load balancing software is also often behind some other layer of load balancing/availability (DNS or ECMP or BGP or CARP), and a hot load means you don't need to churn that layer, which can avoid any issues with changes in that layer.

Re:Migrating Millions of Concurrent WebSockets to Envoy by jsiepkes on Wednesday March 17, 2021 @02:48PM (#26495293)
> Isn’t it fine to just stop accepting connections, tell all your clients to reconnect, and do a normal restart?

Dependents on how many config changes you need (per day).

Besides Envoy supports it and I would call it a bonus if you can reload your configuration without client interruption. As for complicating things the implementation for hot reload isn't terribly complicated in Envoy.

Re:Migrating Millions of Concurrent WebSockets to Envoy by jeffbee on Wednesday March 17, 2021 @02:53PM (#26495359)
I'm mentally separating the hot restart part from the reloadable configs part, even though they are together in the article. To me, not having reloadable configs is too crazy to even imagine.
Re:Migrating Millions of Concurrent WebSockets to Envoy by hermanradtke on Wednesday March 17, 2021 @02:43PM (#26495240)
> stop accepting connections, tell all your clients to reconnect

This "drain" pattern is great for maintenance, upgrades, etc too.

The only caveat is that the clients need to be given time to migrate. How long that is depends on how well the clients behave. A hot restart may be much faster.

Re:Migrating Millions of Concurrent WebSockets to Envoy by paxys on Wednesday March 17, 2021 @08:20PM (#26498444)
It is normal to have production deploys continuously throughout the day. If your client disconnected and reconnected every time a Slack engineer decided to push some code, it would get annoying pretty quick.
Re:Migrating Millions of Concurrent WebSockets to Envoy by jeffbee on Wednesday March 17, 2021 @08:30PM (#26498511)
I don't see why even an endless series of connection interruptions would ever need to come to my attention.
Re:Migrating Millions of Concurrent WebSockets to Envoy by jayd16 on Wednesday March 17, 2021 @02:42PM (#26495224)
The Gmail load balancer has to do a cold restart to add or remove an instance? That's the requirement they placed on themselves because they do not trust the runtime HAProxy api.
Re:Migrating Millions of Concurrent WebSockets to Envoy by jfrunyon on Wednesday March 17, 2021 @08:46PM (#26498603)
Are you saying that Slack don't trust it? Or Google? If the former, it's actually because they don't trust their code that used the HAProxy API. https://slack.engineering/a-terrible-horrible-no-good-very-b...

> Consul-template renders a new version of the host list, and a separate program developed at Slack, haproxy-server-state-management, reads that host list and uses the HAProxy Runtime API to update the HAProxy state. ... However, over the course of the day, a problem developed. The program which synced the host list generated by consul template with the HAProxy server state had a bug.

Re:Migrating Millions of Concurrent WebSockets to Envoy by theflyinghorse on Wednesday March 17, 2021 @02:51PM (#26495329)
If they do not trust HAProxy runtime API then why are they using HAProxy at all?
Re:Migrating Millions of Concurrent WebSockets to Envoy by vad_ on Wednesday March 17, 2021 @03:32PM (#26495832)
Haproxy itself is a solid piece of software. The runtime API is something they added on top of it because of competitors (envoy).