要約
- Argus の guardian はプロセス、オブジェクト、回復責任を包み、atomic action は参加する回復可能オブジェクトの変更を直列化可能かつ全か無かの結果にした。
- commit は、外部装置や人の作業、管理外 I/O の完了を証明しない。handler 呼び出しの背後にいる人物や、より広い業務目的の正当性も証明しない。
commit は成功した。それでも装置は動かない
ある handler が永続的な制御オブジェクトを書き換え、その後で Argus の外側にある装置へ動作を要求するとする。topaction は合意に達し、参加する guardian はすべて承認し、stable object の新しい版が記録され、呼び出し元には成功が返る。
それでも装置が動かないことはあり得る。
これは取引結果との矛盾ではない。Argus は action に参加した回復可能オブジェクトについて強い約束をする一方、参加していない装置には約束をしていないからだ。「commit」という語には全工程の終結を思わせる響きがある。しかし Barbara Liskov が率いた Argus 研究では、終結とは組織全体への宣言ではなく、言語とランタイムが定めた範囲内の性質だった。
1983 年の Guardians and Actions は Liskov と Robert Scheifler の共著である。guardian は、分散プログラムがあるノードで所有する資源、オブジェクト、プロセスを回復単位にまとめる。action は、直列に見えるべき操作をまとめ、すべて反映するか、関連する回復可能状態を以前の版へ戻す。二つの抽象によって、障害処理はアプリケーションごとの場当たり的な規約から、推論できる仕組みへ移った。
同時に、証拠の境界も生まれた。commit は参加者集合の内側で強い。その外側では、別の受領証が要る。
guardian は回復領域であり、世界全体の監視者ではない
guardian は一つのプロセスより長く存続するモジュールに近い。オブジェクトを保持し、プロセスを走らせ、他の guardian から呼ばれる handler を公開する。ノード障害後には回復可能状態を復元し、volatile な状態は初期化し直す。これにより、どのデータをどの単位が回復するかが明示された。
名称から万能のセキュリティ監視装置を想像してはいけない。guardian が包むのはプログラム資源と回復責任であり、組織が接触するファイル、機器、人物、外部サービスのすべてではない。
保存モデルにもその境界がある。stable 変数は resilient object を回復するための根になる。topaction が commit する前に、変更された stable object の新しい状態は stable storage へ書かれる。volatile 変数は回復時に初期化される。stable 変数から参照したというだけで、非 resilient な対象が取引的に永続化されるわけではない。保証はオブジェクトの型と回復実装に依存する。
したがって「Argus は分散プログラムを信頼できるものにした」という言い方だけでは粗い。正確には、定義された障害条件の下で、定義された状態の集合を回復可能にしたのである。
handler 呼び出しは action の木を作る
Argus の遠隔処理は取引から見えない脇道ではない。他の guardian の handler を呼ぶと、呼び出し側には call action、相手側には activation action が生まれる。引数と結果は値として guardian 境界を越え、返答経路も subaction の終了方法に関わる。
通常の return や signal は handler activation を commit させる。abort return と abort signal はそれを abort させる。ここで重要なのは、例外と取引失敗が同義ではないことだ。ある例外なら外側の action も commit すべきでないと判断するプログラムは、適切な action 境界で例外を捕捉しなければならない。
subaction は局所的な失敗封じ込めを可能にした。一つが abort しても親が必ず失敗するとは限らない。ただし subaction が commit すると、暫定版とロックは親へ引き継がれ、その結果は親、最終的には topaction の成否に従う。「subaction が commit した」は「呼び出し元から独立して永久化した」という意味ではない。
topaction は木の根である。分散した決定では commit 時に二相コミットを使い、action と commit 済みの子孫が変更した stable object の新しい版を記録する。topaction が abort すれば、取引管理下の状態は以前の版へ戻る。
この階層は三つの過剰解釈を防ぐ。handler activation の成功は topaction の commit ではない。subaction の commit は独立永続化ではない。topaction の commit は非参加者の完了証明ではない。
orphan は「返答がすべてではない」と示した
分散呼び出しの失敗は曖昧になりやすい。あるノードが消えても、別の場所の処理は走り続けるかもしれない。返答経路だけが失われ、遠隔 activation が停止したか分からないこともある。Argus は、祖先が死亡した、または結果を祖先へ届けられなくなった action を orphan と呼んだ。
orphan の仕組みは単なるタイムアウトではない。孤立した action を最終的に abort させ、正当な祖先を失った後に不整合な atomic data を観測させないことを狙う。マニュアルには、呼び出し元が unavailable を受け取った時点でも、遠隔活動が orphan として動いている場合があると記されている。
ここから二つの注意が導かれる。結果が届かないからといって何も実行されなかったとは限らない。action 内で強制 abort できても、管理外の外部効果まで取り消されたとは限らない。orphan 保証は action が atomic data を介して通信することに依存する。すでに発したモーター信号、印刷済みの紙、外部メールサーバーへ渡した通知、人へ伝えた指示は、祖先 action が消えただけでは巻き戻らない。
Argus は制御できる状態を定義して難問を解いた。世界全体を取引化したふりはしなかった。
open nesting は意図された例外だった
通常の subaction は commit 後も親に従属する。一方、Argus の nested topaction は独立して commit でき、外側の action が後に abort しても結果を残せる。これは open nesting である。
親が失敗しても残すべき調整記録などには有用だが、証明内容は変わる。独立効果が安全であり、必要な直列化条件を満たすことをプログラマが保証しなければならない。親の abort 後に結果が残るのは atomicity の漏れではなく、明示的に選んだ rollback 例外である。
現代の outbox、saga の一工程、独立監査ログにも似た構造がある。名前が変わっても原則は同じだ。独立 commit は明示し、「親操作は痕跡なく戻った」という報告に紛れ込ませてはならない。
commit が確定するのは状態であって、身元や目的ではない
Argus の action identity は並行制御と回復処理を結び付けるためのもので、自然人を認証する仕組みではない。handler は引数、結果、action の系譜を知っても、どの社員や利用者が業務上の権限を与えたかは分からない。
直列化可能性も目的制限ではない。オブジェクトのインターフェース上は同じく有効な二つの要求のうち、一方だけに承認済み変更票があることは普通だ。全か無かの更新が内部不変条件を守っても、決済網、物理工程、組織権限を横断する規則に反することはある。これは action モデルの欠陥ではなく、モデルが答えると約束していない問いを投げないための注意である。
運用証拠は層に分けるべきだ。取引記録は参加 guardian と回復可能オブジェクト、subaction の終端、最終決定、stable storage への反映を示す。身元記録は実行主体と必要な承認者を示す。外部受領証は他サービス、装置、人の工程の完了を示す。広い不変条件には、関係するすべての領域からの観測が必要だ。
研究の功績にも境界がある
Liskov は研究計画を率い、1988 年の成熟した概説を書いたため、自然な入口である。しかし Argus は共同研究だった。Guardians and Actions の著者は Barbara Liskov と Robert Scheifler で、Argus 設計グループ、特に Maurice Herlihy、Paul Johnson、William Weihl の貢献を明記する。1987 年のマニュアルには Liskov、Mark Day、Herlihy、Johnson、Gary Leavens、Scheifler、Weihl が並ぶ。実装論文は Liskov、Dorothy Curtis、Johnson、Scheifler の共著である。
名前を残すことは儀礼ではない。言語の発想、回復プロトコル、マニュアル、動く実装の境界そのものが技術史だからだ。一つの commit が世界全体を代表できないのと同じく、一人の著名な研究者がシステム全体の仕事を代表してはいけない。
出典
会員向け解説
プロフィールの詳細
適切な会員レベルでログインすると、解説全文と出典メモをご覧いただけます。
Strategic Circle 限定
Strategic Circle
すべての読者に公開されています。参加してログインすると プロフィール解説 を閲覧できます。
Strategic Circle に参加Leadership Alliance 会員限定
Leadership Alliance
対象となる IP 資産の所有者・管理者向けです。ログインすると Leadership Alliance の解説を閲覧できます。
Leadership Alliance に参加
