前の章

前の章である第7章 トランザクションはこちらです。

フォールトと部分障害

分散システムは、システムが完全に動作しているか完全に壊れている単一ノード コンピューターとは異なり、分散システムでは部分的な障害が発生する可能性があるという点で単一ノード コンピューターとは異なります。

ハードウェアが正しく動作していれば、同じ処理は常に同じ結果をもたらします。これを決定的と呼びます。

部分的な障害への対処がより困難になるのは、部分的な障害が非決定的であるためです。うまくいくこともあれば、失敗することもあります。

クラウド コンピューティングとスーパーコンピューティング

高性能コンピューターまたはスーパーコンピューターには、天気予報などの計算量の多いタスクに使用される数千個の CPU が搭載されています。一般に、ジョブはその計算状態をチェックポイントし、それを時々永続的に保存します。ノードに障害が発生すると、クラスター全体がダウンします。計算状態は最後のチェックポイントから再開されます。これにより、スーパーコンピューターは単一ノード コンピューターに似たものになります。

信頼性の低いコンポーネントから信頼性の高いシステムを構築することは、分散システムに特有のアイデアではなく、他の分野でも同様に使用されています。

信頼性の低いネットワーク

ネットワークを介して相互に通信するシェアードナッシング システムに焦点を当てています。このアプローチの利点は、特別なハードウェアを必要としないため、比較的安価であることです。システムの一部として通常のマシンを多数含めることができます。

ネットワークのフォールトの実際

ネットワーク障害が発生することはまれですが、発生する可能性があるということは、ソフトウェアがそれらを処理できる必要があることを意味します。ネットワーク障害の処理は、必ずしもそれを許容することを意味するわけではありません。単純なアプローチとしては、ユーザーにエラーメッセージを表示するだけです。
ただし、ソフトウェアがネットワークの問題にどのように反応するかを把握し、システムが問題から回復できることを確認するための作業が必要です。

フォールトの検出

ネットワーク障害は障害のあるノードに関連している可能性があるため、ネットワーク障害を自動的に検出することが重要です。障害を迅速に検出することで、次のことが保証されます。

• ロード バランサーは、デッド ノードへのリクエストの送信を停止できます。

• 単一リーダーのレプリケーションでリーダーが失敗した場合、新しいフォロワーがリーダーに昇格することがあります。

ネットワークは不確実であるため、ノードが動作しているかどうかを判断するのは困難です。ただし、次のような具体的な方法があります。

• ノードが実行されているマシンに到達可能であるが、宛先ポートでリッスンしているプロセスがない場合 (プロセスがクラッシュしたなどの理由で)、OS は TCP 接続を閉じるか拒否します。ただし、リクエストの処理中にノードがクラッシュした場合、リモート ノードによって処理されたデータの量を知る方法はありません。

• データセンター内のネットワーク スイッチの管理インターフェイスにアクセスできる場合は、ネットワーク スイッチにクエリを実行して、ハードウェア レベルでリンク障害を検出できます。もちろん、インターネット経由で接続している場合、またはデータセンターにアクセスできない場合は、これは当てはまりません。

タイムアウトと限度のない遅延

タイムアウトは障害を検出するためによく使用されると述べました。ただし、タイムアウトの長さをどれくらいにすべきかという単純な答えもありません。それは単に状況に応じて異なります。

タイムアウトが長い場合、ノードが停止していると宣言されるまで待機する可能性があることを意味します。つまり、ユーザーはしばらく待つか、エラー メッセージが表示されることになります。

一方、タイムアウトが短いということは、ノードが一時的に故障しただけの場合でも (ノードまたはネットワークの負荷スパイクなどにより)、ノードが早期に停止したと宣言される可能性があることを意味します。ノードの停止を早期に宣言することには欠点があります。

同期ネットワークと非同期ネットワーク

ネットワーク遅延が一定の最大値以内に収まり、パケットドロップがないと見なせると、分散ネットワークははるかにシンプルになります。

明らかに信頼性が高く、メッセージがドロップされることはほとんどない、従来の固定電話ネットワークに注目する必要があります。

電話の回路は、ネットワークが確立されている間は他者が利用できません。TCP接続のパケットは機会があれば利用可能な帯域を利用します。

信頼性の低いクロック

クロックと時間は重要です。通信は瞬時に行われるものではないため、メッセージが届く頃には時間が進んでいます。各コンピューターは、自身の中にクロックを持っています。このクロックをある程度同期する一般的な仕組みがNTP（Network Time Protocol）です。

単調増加のクロックと時刻のクロック

現代のコンピューターは、2つの異なるクロックを持っている。1つは、時刻のクロック。もうひとつは、単調増加のクロック。

クロックの同期と正確性

時刻のクロックの同期は、NTPサーバーやそのほかの外部時刻のソースを設定する必要があります。しかし、下記のような同期の限界があります。

• クロックとNTPサーバーがずれすぎていると、同期が拒否されたり、時刻がリセットされる。アプリケーションから見ると時間がジャンプしているように見える。

• ファイアウォールの設定によってNTPサーバーと同期できない。

• NTPとの同期で、ネットワークが輻輳していると、1秒近い誤差がでることがある。

• NTPサーバーの時間が間違っている（数時間ずれている）ことがある。

• クロックが仮想化されている仮想マシンの場合、ほかのVMが動作している間数十ミリ秒一時停止する。アプリケーションからみると時間をジャンプしているように見える

ヨーロッパの金融商品市場には、UTCに対して100ミリ秒以内に同期を要求しているものもあるが、多大な労力と専門性が求められる（PTPなど）。

グローバルスナップショットの同期クロック

スナップショット分離は通常、各トランザクションに単調増加する ID を与えることによって実装されます。書き込みがスナップショットより後に発生した場合、その書き込みはスナップショット トランザクションには見えません。単一ノードのデータベースでは単純なカウンターを使用できるため、これを管理するのが簡単です。

ただし、分散データベースの場合、単調に増加するトランザクション ID を調整するのはさらに困難です。トランザクション ID は因果関係を反映している必要があります。トランザクション B がトランザクション A によって書き込まれた値を読み取る場合、一貫性を保つために、B には A よりも高いトランザクション ID が必要です。

クロックの精度について不確実性がなければ、後のトランザクションのタイムスタンプが高くなるため、同期された時刻クロックからのタイムスタンプがトランザクション ID として適しているでしょう。

ただし、Google の Spanner は、次の方法でデータセンター全体のスナップショット分離を実装します。

トランザクションのタイムスタンプが因果関係を反映していることを確認するために、Spanner は読み取り/書き込みトランザクションをコミットする前に信頼区間の長さまで待機します。これは、データを読み取るトランザクションが十分に遅い時間に行われるため、信頼区間が重複しないことを意味します。
スナップショット分離では、トランザクションは開始時にコミットされていないものを読み取ることができないことに注意が必要です。したがって、現在コミットされている読み取り/書き込みトランザクションを読み取るトランザクションは、後の時点で発生したと確信できます。

ビザンチン障害

ノードは信頼性は低いが誠実であると想定されます。応答するノードは、その知識の限りにおいて真実を語っていると想定されます。

ノードが「嘘をつく」リスクがある場合 (たとえば、破損したメッセージや誤った応答を送信するなど)、対処するのがはるかに困難な問題になります。この動作はビザンチン障害として知られており、これらの障害を処理するように設計されたシステムはビザンチンフォールトトレラントシステムと呼ばれたりします。

まとめ

以上、分散システムの問題について解説しました。

この章は少し難しい内容が多く、また、アカデミックな内容も一部含まれているので理解するのに時間がかかる可能性があります。
もし、内容が入ってこなければ、一旦次の章を読むことをオススメします。

分散システムの問題について特に重要な点を解説しました。ただし、非常に量が多いため解説していない部分が多々あります。詳細は本書を手にとってみて下さい。