データ集約型アプリケーションの設計 (Japanese Edition), 2nd Edition

第9章 分散システムの問題点

この作品はAIを使って翻訳されている。ご意見、ご感想をお待ちしている：[e-mail]

事故ってのは面白いものだ。起きるまでは起きないものだ。

A.A.ミルン『くまのプーさん』（1928年）

「信頼性とフォールトトレランス」で論じたように、システムを信頼性のあるものにするとは、 何か問題が起きた時（つまりフォールトが発生した時）でも、システム全体が動作を継続することを保証することを意味する。 しかし、起こりうるあらゆる障害を予測し、それらに対処するのは容易ではない。開発者としては、 正常な動作パス（結局のところ、ほとんどの場合システムは問題なく動作する！）に主眼を置き、 障害を軽視したくなる誘惑が強い。障害は多くのエッジケースを引き起こすからだ。

故障が発生してもシステムを信頼性高く保ちたいなら、考え方を根本的に変え、たとえ発生確率が低くとも何が問題になるかに焦点を当てる必要がある。百万に一つの確率であろうと関係ない。十分な規模のシステムでは、百万に一つの出来事が毎日起きる。経験豊富なシステム運用者は言うだろう、起きうる問題は 必ず起きると。

分散システムを扱うことは、単一コンピュータ上でソフトウェアを書くこととは根本的に異なる。主な違いは、新たな興味深い方法で問題が発生しうる点だ 1, 2]。 この章では、実践で生じる問題の一端を味わい、何が頼りになり何が頼りにならないかを理解する。

我々が直面する課題を理解するため、悲観論を最大限に高め、分散システムで起こりうる様々な問題を探る。ネットワーク障害や時計・タイミングの問題も含まれる。これらの問題の結果は混乱を招くため、分散システムの状態をどう捉え、発生した事象をどう推論するかも考察する。第10章では、こうした事態に直面した際に 耐障害性を実現する具体例をいくつか見る。

障害と部分的な失敗

単一のコンピュータ上でプログラミングを行う場合、通常はかなり予測可能な挙動を示す：動作するか、しないかのどちらかだ。バグのあるソフトウェアは、コンピュータが時々「調子が悪い日」を過ごしているように見えるかもしれない（再起動で直ることが多い問題だ）。しかし、それは主に、ソフトウェアの記述が不十分である結果に過ぎない。

単一コンピュータ上のソフトウェアが不安定である根本的な理由はない。ハードウェアが正常に動作している場合、同じ操作は常に同じ結果を生む（決定論的である）。ハードウェアの問題（例：メモリ破損やコネクタの緩み）があれば、通常はシステム全体の失敗（例：カーネルパニック、「ブルースクリーン」、起動不能）という結果になる。 良質なソフトウェアを搭載した個々のコンピュータは、通常、完全に機能しているか完全に故障しているかのどちらかで、その中間状態にはならない。

これはコンピュータ設計における意図的な選択だ。内部故障が発生した場合、誤った結果を返すよりは完全にクラッシュする方が好ましい。誤った結果は対処が困難で混乱を招くからだ。こうしてコンピュータは、実装基盤となる曖昧な物理的現実を隠蔽し、数学的完璧さで動作する理想化されたシステムモデルを提示する。 CPU命令は常に同じ動作をする。メモリやディスクにデータを書き込めば、そのデータは無傷で残り、ランダムに破損することはない。「ハードウェアとソフトウェアの故障」で論じた通り、これは実際には真実ではない——現実にはデータは黙って破損し、CPUも時折黙って誤った結果を返す——しかし、その発生頻度は十分に低いため、我々はそれを無視して済ませられる。 ...