論文翻訳: Time, Clocks, and the Ordering of Events in a Distributed System
Massachusetts Computer Associates, Inc.
Abstract
分散システムにおいて、あるイベントが他のイベントより先に起こるという概念を検討し、イベントの部分順序付け (partial ordering) を定義することが示されている。分散アルゴリズムは全順序イベントに使用できる論理クロックの同期システムに対して与えられる。全順序の使用は同期問題の解決方法を用いて説明される。このアルゴリズムは物理クロックの同期に特化されており、クロックの同期がどの程度外れるかについての境界が導き出される。
Key Words and Phrases: distributed systems, computer networks, clock synchronization, multiprocess system
CR categories: 4.32, 5.29
Table of Contents
導入
時間という概念は我々の考え方の基本である。これはイベントの発生順序というより基本的な考え方から派生したものである。例えば時計が 3 時 15 分を示した後、3 時 16 分を指す前に何かが起こったとき、我々は 3 時 15 分に何かが起きたと言う。イベントの時制順序 (temporal ordering) という概念はシステムに関する我々の考え方に広く浸透している。例えば航空会社の予約システムでは、フライトが満席になる前に予約のリクエストが行われた場合、そのリクエストは許可されるべきであると規定されている。しかし、分散システムにおいてイベントを考える際にこの概念は慎重に再検討する必要があることがわかるだろう。
分散システムは、空間的に分離されメッセージを交換することによって相互に通信するプロセスの集まりで構成されている。ARPA ネットなどの相互接続されたコンピュータネットワークも分散システムである。また単一のコンピュータは中央制御装置、記憶装置、入出力チャネルが別々のプロセスである分散システムと見なすこともできる。メッセージの伝達遅延が単一プロセス内のイベント間の時間と比較して無視できない場合は分散システムである。
我々は主に空間的に分離されたコンピュータのシステムについて考察する。しかし我々の指摘の多くはより一般に適用できる。特に単一のコンピュータでのマルチプロセッシングシステムでは特定のイベントが発生する順序が予想できないため分散システムと同様の問題が発生する。
分散システムでは 2 つのイベントのどちらが先に起きたと言えないことがある。したがって "前に起きた" (happened before) という関係はシステム内のイベントの部分的な順序付けに過ぎない。人々がこの事実とその影響を完全に認識していないために問題が発生することがよくある。
この論文では "前に起きた" 関係によって定義される部分順序を議論し、それをすべてのイベントの一貫した全順序に拡張するための分散アルゴリズムを提供する。このアルゴリズムは分散システムを実装するために有用なメカニズムを提供することができる。同期問題を解決するための簡単な問題でその使用法を説明する。このアルゴリズムによって得られた順序がユーザが認識すると順序と異なる場合、予期せぬ異常挙動が発生する可能性がある。これは実際の物理クロックを導入することで回避することができる。我々はこれらのクロックを同期させる簡単な方法を説明し、それらがどの程度同期からずれるかの上限を導き出す。
部分順序
ほとんどの人々はイベント
まずこのシステムをより正確に定義することから開始する。システムはプロセスの集合で構成されていると仮定する。各プロセスは一連のイベントで構成されている。アプリケーションによってはコンピュータ上でのサブプログラムの実行が 1 つのイベントであったり、1 つの機械語命令の実行がシーケンスの 1 つになるかもしれない。ここでプロセスのイベントはシーケンスを形成すると仮定しており、このシーケンスにおいて
ここではメッセージの送受信がプロセスにおける一つのイベントであると想定している。そして "
定義. システムのイベント集合上の関係 "
" は次の 3 つの条件を満たす最小の関係である: (1) と が同じプロセスのイベントであり が より先に起きるなら である。(2) があるプロセスによるメッセージ送信であり、 が他のプロセスによる同じメッセージの受信であれば である。(3) かつ の場合、 である。2 つの異なるイベント と が かつ のとき並行 (concurrent) であると言う。
任意のイベント
この定義は Fig 1 のような "時間-空間図" で見ると分かりやすい。横方向は空間、縦方向は時間を表し、遅い時間ほど上位に位置する。ドットはイベント、縦線はプロセス、横線 (原文は波線) はメッセージを表す2。
この定義の別の見方として
この定義は、たとえば [1] や [2] の第 1 章で述べられているような特殊相対性理論の不変時空の定式化に慣れている読者にとってはごく自然に見えるだろう。相対論ではイベントの順序は送信しえた (could) メッセージの観点から定義される。しかし我々はより現実的なアプローチとして実際に送信される (be sent) メッセージのみを考慮することにした。どのようなイベントが起きえたかを知ることなく、実際に起きたイベントだけを知ることによって、システムが正しく機能したかを判断することができるはずである。
- 1何がイベントを構成するかの選択はプロセス内のイベント順序に影響する。例えばメッセージの受信はコンピュータの割り込みビットの設定や割り込みを処理するサブプログラムの実行を意味するかもしれない。割り込みは発生順に処理する必要がないため、この選択はプロセスのメッセージ受信イベントの順番に影響する。
- 2メッセージが順番通りに受信されない可能性があることに注意。複数のメッセージ送信を 1 つのイベントとすることもできるが、便宜上、1 つのメッセージ受信が他のメッセージ送信または受信と重ならないと仮定する。
論理クロック
ここでシステムにクロックを導入する。まず、クロックはイベントに数値を割り当てる方法であり、番号はイベントが発生した時刻という抽象的な観点から始める。より正確には各プロセス
ではこのようなクロックシステムが正確であるとはどういう意味か考えてみよう。物理的な時間を基準とすると物理的な時間を刻む時計を導入する必要があるため正確さの定義にはできない。そこで我々にはイベントの発生する順序に基づく定義が必要となる。もっとも強力な合理的条件はイベント
クロック条件. 任意のイベント
に対して であれば である。
条件が逆方向に成立することは期待できないことに注意。これは 2 つの並行イベントが意味的に同時に起きていると見なさなければならないためである。Fig 1 では
次の 2 つの条件が成立すればクロック条件が満たされることは "
- C1.
と がプロセス のイベントであり が よりも前に起きていれば である。 - C2.
をプロセス によるメッセージ送信とし をプロセス によるそのメッセージの受信とすると である。
このクロックを時間-空間図で考えてみよう。あるプロセスのクロックはプロセスのイベントとイベントの間ですべての通じを "刻む" (tick) と想像する。例えば
我々はこの刻み線を時空間における直交座標系の時間座標線と考えることができる。これらの座標線をまっすぐにするために Fig 2 を書き直して Fig 3 を得ることができる。Fig 3 は Fig 2 と同じイベント系を表す有効な代替手段である。システムに物理時間の概念を導入しない限り (そのためには物理クロックを導入する必要がある)、これらの図のどちらがより適切な表現かを判断する方法はない。
読者には視覚的にプロセス間の 2 次元空間ネットワークを 3 次元空間図にすると分かりやすいかも知れない。プロセスとメッセージは引き続き線で表されるが刻み線は 2 次元の面となる。
ここでプロセスはアルゴリズムであり、イベントはその実行中の特定のアクションを表すと仮定する。ここではクロック条件を満たすプロセスにクロックを導入する方法を示す。プロセス
クロックのシステムがクロック条件を満たすことを保証するために条件 C1 と C2 を満たすことを保証する。条件 C1 は簡単で次の実装ルールを守るだけで良い:
- IR1. 各プロセス
は任意の 2 つの連続するイベント間で をインクリメントする。
条件 C2 を満たすには、各メッセージ
- IR2.
- (a) イベント
がプロセス によるメッセージ の送信であれば、メッセージ にはタイムスタンプ が含まれている。 - (b) メッセージ
を受信したプロセス は を現在の値以上かつ より大きい値に設定する。
- (a) イベント
IR2 (b) ではメッセージ
イベントの完全な順序付け
クロック条件を満たすクロックシステムを用いてシステムのすべてのイベント集合に完全な順序づけを行うことができる。これはイベントを発生順序順に並べるだけである。同着を解消するためにプロセスの任意の全順序 (arbitrary total ordering)
順序関係
イベントの全順序付けができることは分散システムを実装するうえで非常に有用である。実際、正しい論理クロックのシステムを実装する理由はこのような全順序付けを得るためである。この全順序イベントの利用法を次のような相互排他問題を解くことによって説明する。単一のリソースを共有する個定数のプロセス群で構成されるシステムについて考える。リソースは一度に 1 つのプロセスのみが利用できるため、衝突を避けるためにプロセス間で同期する必要がある: (I) リソースを許可されたプロセスは他のプロセスに許可される前にリソースを開放しなければならない。 (II) リソースに対する様々な要求はそれらが成された順に許可されなければならない。 (III) リソースを許可されたすべてのプロセスが最終的に (eventually) それを開放するならばすべての要求は最終的に許可される。
リソースは最初に一つのプロセスのみに許可されていると仮定する。
これらは至極当然の条件である。これは解が正しいとはどういう意味かを正確に特定している4。この条件がイベントの順序付けにどのように関与しているかを見てみよう。条件 II は同時に発行された 2 つの要求のうちどちらが最初に許可されるべきかについては何も述べていない。
これは自明ではない問題であることを認識することが重要である。要求を受け取った順に許可する中央スケジューリングプロセスを使っても追加の仮定がない限りうまく機能しない。これを確認するために
この問題を解決するためにルール IR1 と IR2 を使用してクロックのシステムを実装し、それらを使って全イベントの全順序
問題を単純化するためにいくつかの仮定を置く。これらは必須ではないが、実装の詳細に気を取られることを避けるために導入している。まず任意の 2 つのプロセス
各プロセスは他のプロセスからは決して見えない独自の要求キュー (request queue) を保持している。最初要求キューには単一のメッセージ
次にこのアルゴリズムは以下の 5 つのルールによって定義される。便宜上、各ルールで定義されたアクションは単一のイベントを形成するものと想定する。
リソースを要求するために、プロセス
は他のすべてのプロセスに リソース要求メッセージを送信し、そのメッセージを要求キューに入れる。ここで はメッセージのタイムスタンプである。 プロセス
はメッセージ リソース要求メッセージを受信するとそれを要求キューに入れ に (タイムスタンプ付きの) 確認メッセージを送る。5 リソースを開放するために、プロセス
はその要求キューから任意の リソース要求メッセージを取り除き、他のすべてのプロセスに (タイムスタンプ付きの) リソース開放メッセージを送信する。 プロセス
が リソース開放メッセージを受信すると、その要求キューから任意の リソース要求メッセージを削除する。 プロセス
は次の 2 つの条件が満たされたときにリソースを許可される: (i) 関係 によって要求キュー内の他のどの要求よりも前に順序付けられた リソース要求メッセージがキュー内に存在する。(メッセージの関係 を定義するために我々はメッセージを送信するイベントと識別する。) (ii) は他のすべてのプロセスから より後のタイムスタンプが付けられているメッセージを受信している。6
ルール 5 の (i) と (ii) は
これらのルールによって定義されたアルゴリズムが条件 I, II, III を満たすことを検証するのは容易である。まず最初にルール 5 の条件 (ii) は、メッセージが順番に受信されるという仮定の下に
これは分散アルゴリズムである。各プロセスは独立してこれらのルールに従い、中央同期プロセスや中央ストレージは存在しない。このアプローチはこのような分散マルチプロセスシステムに対して必要な同期を実装するために一般化できる。同期は、取り得るコマンドの集合
各プロセスはすべてのプロセスが発行したコマンドを使用してステートマシンの実行を個別にシミュレートする。すべてのプロセスは (関係
この方法によって、分散システムにおける任意の形式のマルチプロセス同期を実装することができる。しかし、このアルゴリズムはすべてのプロセスの積極的な参加を必要とする。あるプロセスは他のプロセスによって発行されたすべてのコマンドを認識していなければならない。このため、あるプロセスに障害が発生すると他のプロセスがステートマシンコマンドを実行できなくなりシステムが停止する。
故障の課題は難しい問題でありこの論文で詳しく説明することはできない。ただ、故障という概念全体が物理的な時間の文脈でしか意味を持たないことを確認する。物理的な事件がなければ、故障したプロセスと、イベント間で一時停止しているだけのプロセスを区別する方法はない。ユーザはシステムが "クラッシュ" したと判断できるのは応答を待つ時間が長すぎるために他ならない。個々のプロセスや通信回線の障害があっても動作する方法は [3] で説明されている。
- 3順序付け
はプロセス間の優先順位を確立する。もし "より公平な" 方法が望まれるなら はクロック値の関数にすることができる。例えば かつ ならば、 であれば 、そうでなければ である。ここで はプロセスの総数である。 - 4"最終的に" (eventually) という用語を正確にする必要があるが本題から余りにも大きく逸脱する必要がある。
- 5
がすでに より後のタイムスタンプのメッセージを に送信している場合、この確認メッセージを送信する必要はない。 - 6
であれば は からタイムスタンプが のメッセージを受信していればよい。 - 7各プロセスが要求と解放の厳密に口語に行わなければ、解放コマンドの実行でキューから 0 個、1 個、またはそれ以上のリクエストが削除される可能性がある。
異常挙動
我々のリソーススケジューリングアルゴリズムは全順序
問題の根源をより詳しく考えてみよう。すべてのシステムイベントの集合を
このような異常挙動を回避するには 2 つの方法がある。第一の方法は順序
第二のアプローチは次の条件を満たすクロックシステムを構築することである。
強いクロック条件.
内の任意のイベント に対して: もし なら である。
これは
ここで
物理クロック
時空間図に物理的な時間座標を導入し、
クロック
PC1. すべての
に対して となるような定数 が存在する。
一般的な水晶制御のクロックでは
個々のクロックがほぼ正しい速度で動作するだけでは十分ではない。すべての
PC2. すべての
, に対して である。
Fig 2 の垂直距離を物理的な時間を表すと考えると、PC2 は 1 刻みの高さの変動が
2 つの異なるクロックが全く同じ速度で動くことはないことからそれらはますます離れてドリフトする傾向にある。したがって PC2 が常に成立するようなアルゴリズムを考案する必要がある。しかしまずは異常挙動を防ぐためには
イベント
異常挙動を避けるためには任意の
ここで PC2 が成立することを保証するためのアルゴリズムを説明する。物理時刻
ここでルール IR1 と 2 を次のように物理クロックに特化する:
IR1'. 各
について、 が物理時刻 でメッセージを受信しない場合、 は で微分可能であり である。- IR2'.
- (a)
が物理時刻 にメッセージ を送信する場合、 はタイムスタンプ を含む。 - (b) 時刻
にメッセージ を受信したプロセス は、 を最大値 に等しく設定する。9
- (a)
ルールは形式的には物理時間パラメータで指定されているが、プロセスは自分自身のクロックの読みと受信したメッセージのタイムスタンプを知るだけで良い。数学的な便宜上、各イベントは物理時間の正確な瞬間に発生し、同じプロセス内の異なるイベントは異なる時間に発生すると仮定している。これらのルールはルール IR1 と IR2 を特殊化したものであり、クロックのシステムはクロック条件を満たしている。現実のイベントが有限時間であるという事実はアルゴリズムの実装に支障を来さない。実装上の唯一の懸念は C1 が維持されるように離散的なクロック刻みが十分な頻度であることを確認することである。
ここでこのクロック同期アルゴリズムを用いて条件 PC2 を満たすことができることを示す。プロセスのシステムは有向グラフで記述され、プロセス
PC2 の確立に加えて、次の定理はシステムの初回起動時にクロックが同期までの時間の長さを制限している。
定理. IR1' および IR2' のルールに常に従い直径
を持つ強結合プロセスグラフを想定する。任意のメッセージ に対して、ある定数 に対して であり、すべての に対して (a) PC1 が成立し (b) 秒ごとに 未満の予測不可能な遅延のメッセージがすべての弧上で送信されるような定数 と が存在すると仮定する。このとき、PC2 はすべての に対して を満たす。ここで近似は を仮定している。
この定理の証明は意外と難しく付録で示す。物理クロックの同期問題については多くの研究が行われてきた。この問題の導入として [4] を参照されたい。文献に記載されている方法はメッセージ遅延
- 8ここではニュートン時空を仮定する。時計の相対運動や重力の影響が無視できない場合、
を固有時間から任意に選んだ時間座標に変換して実際の時計の読みから推定する必要がある。 - 9
考察
我々は "前に起きる" という概念が分散マルチプロセスシステムにおけるイベントの不変の部分順序を定義することを見てきた。この部分順序をいささか恣意的に全順序へ拡張するアルゴリズムについて説明し、この全順序を用いて簡単な同期問題を解決する方法を示した。今後の論文ではこのアプローチを拡張して同期問題を解決する方法を示す予定である。
このアルゴリズムで定義される全順序はやや恣意的である。システムのユーザが認識する順序と一致しない場合に異常挙動を引き起こす可能性がある。これは適切に同期された物理クロックを用いることで防ぐことができる。我々の定理はクロックがどれだけ厳密に同期できるかを示した。
分散システムではイベントの発生順序は部分順序に過ぎないことを認識することが重要である。この考え方はあらゆるマルチプロセスシステムを理解する上で有用だと考えている。それらを解決するためのメカニズムとは別に、マルチプロセッシングの基本的な問題を理解するのに役立つはずである。
付録
定理の証明
任意の
時刻
ここで
任意の 2 つのプロセス
ここで
任意の時刻
(i) の場合に
証明での関係式 (
Acknowledgements
The use of timestamps to order operations, and the concept of anomalous behavior are due to Paul Johnson and Robert Thomas.
References
- Schwartz, J.T. Relativity in Illustrations. New York U. Press, New York, 1962.
- Taylor, E.F., and Wheeler, J.A. Space-Time Physics, W.H. Freeman, San Francisco, 1966.
- Lamport, L. The implementation of reliable distributed multiprocess systems. To appear in Computer Networks.
- Ellingson, C., and Kulpinski, R.J. Dissemination of system-time. IEEE Trans. Comm. Com-23, 5 (May 1973), 605-624.
翻訳抄
論理クロック (Lamport タイムスタンプ) に関する 1978 年の論文。
- RF, L. Lamport. "Time, clocks, and the ordering of events in a distributed system." Commun. ACM 21 (1978): 558-565.


