Communications of the ACM
Too Big to Fail
Credit: Sfio Cracho
Dear KV,
Our project has been rolling out a well-known, distributed key/value store onto our infrastructure, and we have been surprised—more than once—when a simple increase in the number of clients has not only slowed things, but brought them to a complete halt. This then results in rollback while several of us scour the online forums to figure out if anyone else has seen the same problem. The entire reason for using this project's software is to increase the scale of a large system, so I have been surprised at how many times a small increase in load has led to a complete failure. Is there something about scaling systems that is so difficult that these systems become fragile, even at a modest scale?
Scaled Back
Dear Scaled,
If someone tells you that scaling out a distributed system is easy they are either lying or deranged—and possibly both. Anyone who has worked with distributed systems for more than a week should have this knowledge integrated into how they think, and if not, they really should start digging ditches. Not to say that ditch digging is easier but it does give you a nice, focused task that is achievable in a linear way, based on the amount of work you put into it. Distributed systems, on the other hand, react to increases in offered load in what can only politely be referred to as nondeterministic ways. If you think programming a single system is difficult, programming a distributed system is a nightmare of Orwellian proportions where you almost are forced to eat rats if you want to join the party.
Comments
R Oldehoeft
No doubt this is a problem of resource overcommitment. What resource is being overcommitted? Network capacity, node computing power or storage? Supply more of it, or use less of it to break through.
One of the most interesting lectures I ever attended was titled "Catastrophe Theory as Applied to Computer Science." Catastrophe Theory was a branch of mathematics involving multidimensional manifolds, where dropping from one surface onto another causes great systematic changes. CT is now folded into the study of dynamical systems.
Here's a CS example. Paged virtual memory systems work fine until real memory is overcommitted, resulting in a sudden large increase in OS overhead devoted to disk activity and concomitant system slowdown. A small change in memory commitment makes a huge change in performance.
Here's an example your non-CS friends can understand. Get a metal tape measure spooled in its case. Pay out the tape, and it remains horizontal for quite awhile as it gets longer. Then, suddenly, the tape end collapses to the floor. Now when retrieving the tape, the end remains on the floor until, suddenly, the tape regains its horizontal status at a shorter length than when it collapsed.
Note that, while watching the end of the tape measure on its circuit, it follows a classic hysteresis loop!
Displaying 1 comment