Live data from Hacker News

Building Facebook's Service Encryption Infastructure

code.fb.com

21–30 of 48 posts

Re: Building Facebook's Service Encryption Infastructure

#21

Earlier quoted context omitted.

Isn't Istio implemented mostly as a sidecar container(Envoy Proxy) though? The article mentions they are running containers via their Tupperware orchestrator. If they are largely running containerized where is the scaling issue with adding sidecars to implement the service mesh? I don't have any experience with Istio but I'm genuinely curious along which axis it(or Connect, Linkerd etc) doesn't scale.

Envoy is so slow that deployment at this scale would be too costly, or if you could afford it would immediately present itself as a huge opportunity for cost reduction. People who are measuring their tail latency in microseconds aren't going to tolerate Envoy's marginal latency, which will be milliseconds even at the median.

Indeed, Istio is very CPU heavy and probably not great for cloud use on a truly large scale just due to cost concerns. Shopify found it uses 50% more CPU then an alternative like Linkerd [1]. Istio also incurs much larger latency and lower throughput then Linkerd [2]. (To be clear, I don't have a dog in this Istio vs Linkerd fight, those are just some recent benchmarks I'm aware of)

[1] https://medium.com/@michael_87395/benchmarking-istio-linkerd...

[2] https://medium.com/@ihcsim/linkerd-2-0-and-istio-performance...

Re: Building Facebook's Service Encryption Infastructure

#22
post #19

Earlier quoted context omitted.

Borg != Kubernetes k8s is based on Borg, but they are quite different. Companies at this scale have integrations between all different levels and layers of the 'stack' that make the use of off the shelf software difficult or impossible.

yes I know they are different, but the lessons learnt/dev in both products probably end up influencing each other. My point was encryption of services is built into K8s/service mesh and wondering how it fares compared to FB's approach.

This would make a great comparison. I'm not certain whether or not K8's mutual auth supports session ticket resumptions and distribution of short lived ticket keys. The ticket rotation design would probably make a great addition to K8. There are a lot of intricate details in design which can make a major difference in not only performance but also whether or not the system wakes you up at night.

Re: Building Facebook's Service Encryption Infastructure

#23

Earlier quoted context omitted.

At a previous organization I worked at that operated at this kind of scale, I came up with a couple of maxims: 1. If you're only 99% automated, you're dead. 2. Anything you can easily imagine going wrong is probably going wrong right now. 3. Everything else that can possibly go wrong will go wrong at some point in the not distant future. Some of the problems we ran into were pretty fun and challenging. The longest su…

Can you share the problem that took a couple of years to figure out?

Sure. I didn't figure this out, but was relatively close to the investigation. My team provided a lot of data that ended up being used to come to root cause.

My team and extended teams managed almost 200,000 network devices, spread all over the world, most of which were Cisco, and most of which were installed in stores. And most of the switch ports were connected to customer facing Point Of Sale devices. Among these are employee facing registers and customer facing card scanners. That is, the devices you interact with whenever scan your card to pay for something.

With that many devices in that many locations in a largely unmanaged environment (the switches would be installed all over the store, often in the ceiling, and many of them experienced extreme temperatures), there were a constant stream of failures. The process to manage these failures was optimized, streamlined and largely automated.

However, it was discovered that switches were failing far more frequently in the northern Midwestern US than elsewhere, and then only in the winter.

So this wasn't a really big operational issue, but it had a substantial cost impact, and the rate was high enough that a lot of the affected stores did notice and were complaining.

Right. Very strange, very mysterious.

So, briefly, the root cause:

Apparently, people in the upper Midwest wear wool to stay warm far more frequently than other cold places, specifically the US northeast. And much of the time, the humidity is quite low. So, you have a lot of people wearing a lot of wool in low humidity air. These people generated a lot of static, which they would all too often discharge while interacting with the customer facing point of sale device. And, all too frequently, that pulse of static would end up flowing all the way back to the switch, often killing it.

I didn't follow the subsequent remediation efforts, so I don't know what if anything was done about that.

Re: Building Facebook's Service Encryption Infastructure

#24
post #9

> After several days, we finally narrowed down the issue to a bad Advanced Vector Extensions (AVX) instruction on a single CPU in our fleet This isn't even the first time I've heard of an issue at FB being caused by a single bad CPU instruction. Working at a scale where "Problem X is a one-in-a-million edge case" and "Problem X happens several times per day" are synonymous is weird...

If you are interested in something like that, i would recommend you to listen to this podcast [0]. One of the stories from what i remember is that someone had run a `delete table` command but it turned out that processor had a bit off which mapped `create table` command to `delete table`. It's really really interesting.

[0] https://softwareengineeringdaily.com/2017/06/16/google-early...

Re: Building Facebook's Service Encryption Infastructure

#25

Earlier quoted context omitted.

Envoy is so slow that deployment at this scale would be too costly, or if you could afford it would immediately present itself as a huge opportunity for cost reduction. People who are measuring their tail latency in microseconds aren't going to tolerate Envoy's marginal latency, which will be milliseconds even at the median.

Indeed, Istio is very CPU heavy and probably not great for cloud use on a truly large scale just due to cost concerns. Shopify found it uses 50% more CPU then an alternative like Linkerd [1]. Istio also incurs much larger latency and lower throughput then Linkerd [2]. (To be clear, I don't have a dog in this Istio vs Linkerd fight, those are just some recent benchmarks I'm aware of) [1] https://medium.com/@michael_87…

[deleted]

Re: Building Facebook's Service Encryption Infastructure

#26

Earlier quoted context omitted.

Isn't Istio implemented mostly as a sidecar container(Envoy Proxy) though? The article mentions they are running containers via their Tupperware orchestrator. If they are largely running containerized where is the scaling issue with adding sidecars to implement the service mesh? I don't have any experience with Istio but I'm genuinely curious along which axis it(or Connect, Linkerd etc) doesn't scale.

Envoy is so slow that deployment at this scale would be too costly, or if you could afford it would immediately present itself as a huge opportunity for cost reduction. People who are measuring their tail latency in microseconds aren't going to tolerate Envoy's marginal latency, which will be milliseconds even at the median.

Interesting, I wasn't aware that Istio has such performance issues. Isn't Google using this though as well or at least an internal version of it? Surely they are on the same scale as FB.

I'm curious at to what the cause of the latency is. TLS handshakes?

Re: Building Facebook's Service Encryption Infastructure

#27

Earlier quoted context omitted.

Envoy is so slow that deployment at this scale would be too costly, or if you could afford it would immediately present itself as a huge opportunity for cost reduction. People who are measuring their tail latency in microseconds aren't going to tolerate Envoy's marginal latency, which will be milliseconds even at the median.

Interesting, I wasn't aware that Istio has such performance issues. Isn't Google using this though as well or at least an internal version of it? Surely they are on the same scale as FB. I'm curious at to what the cause of the latency is. TLS handshakes?

To be fair, most software projects have performance issues at FB's scale.

Re: Building Facebook's Service Encryption Infastructure

#28

Earlier quoted context omitted.

Can you share the problem that took a couple of years to figure out?

Sure. I didn't figure this out, but was relatively close to the investigation. My team provided a lot of data that ended up being used to come to root cause. My team and extended teams managed almost 200,000 network devices, spread all over the world, most of which were Cisco, and most of which were installed in stores. And most of the switch ports were connected to customer facing Point Of Sale devices. Among these…

One of the great stories right here. Thank you for sharing.

Re: Building Facebook's Service Encryption Infastructure

#29

Earlier quoted context omitted.

Can you share the problem that took a couple of years to figure out?

Sure. I didn't figure this out, but was relatively close to the investigation. My team provided a lot of data that ended up being used to come to root cause. My team and extended teams managed almost 200,000 network devices, spread all over the world, most of which were Cisco, and most of which were installed in stores. And most of the switch ports were connected to customer facing Point Of Sale devices. Among these…

Wow, that’s one helluva edge case I’d never think of!

Re: Building Facebook's Service Encryption Infastructure

#30

Earlier quoted context omitted.

Can you share the problem that took a couple of years to figure out?

Sure. I didn't figure this out, but was relatively close to the investigation. My team provided a lot of data that ended up being used to come to root cause. My team and extended teams managed almost 200,000 network devices, spread all over the world, most of which were Cisco, and most of which were installed in stores. And most of the switch ports were connected to customer facing Point Of Sale devices. Among these…

That’s a fantastic anecdote. I would have loved to have been a fly on the wall when the results were reported to management.
Post reply on HN