このブログは、旧・はてなダイアリー「檜山正幸のキマイラ飼育記 メモ編」(http://d.hatena.ne.jp/m-hiyama-memo/)のデータを移行・保存したものであり、今後(2019年1月以降)更新の予定はありません。

今後の更新は、新しいブログ http://m-hiyama-memo.hatenablog.com/ で行います。

Tao of RPC

RPCの理想は失われた、だが…」で、

堕落と怠惰であてどなく底辺を彷徨うのはやめよう。もう一度、あの理想を思い出そうぜベイビー。

と書いた。中途半端なハイブリッド方式はもうコリゴリだ。ほんとにロクなことがない、サイテーだったわ。純粋PRCモデルに回帰する。そして、無残に退化したRPC環境を現実的に回復させる。

RPCの真髄は、手続き呼び出しの距離や方式を捨象することだ。これさえ出来れば、他は要らない。

直接呼び出しも遠隔呼び出しも区別する必要がない。距離がゼロでも2センチでも1万キロでも関係ないのだ。

しかし当然、転送レイヤーとかメッセージングインフラとか呼ばれる基盤技術に影響される。現状では、ここはHTTP一択だろう。だが、だからといってHTTPベタベタにしては時計の針が逆戻り、まったく抽象化されてないウザウザ・ドロドロの世界だ(ほんとにコリゴリだってば)。

転送/メッセージングの制約はプロトコルと呼ばれるお約束だが、プロトコルは次を決めていると思ってよい。

  1. 転送されるメッセージのフォーマット
  2. エンドポイントの識別・命名方式

メッセージのフォーマットを型システムで表現できたとして(実際表現できる)、InMsg型、OutMsg型とする。エンドポイントの識別子の全体の集合をJとする。Jは通常、文字列全体の集合stringの部分集合となる; J⊆string 。

計算モデルの圏、つまりデータ型を対象として計算可能関数(Catyではコマンド)を射とする圏をCとする。InMsgとOutMsgは圏Cの対象となる; InMsg, OutMsg∈|C|。メッセージフォーマットの制約から、ホムセット C(InMsg, OutMsg) に属する射(関数、コマンド)しか外部から呼び出せない。

外部から遠隔呼び出し可能な関数/コマンドをアクションと呼ぶ。アクションの集合は圏Cのホムセットだから、

  • Action = C(InMsg, OutMsg)

もし、Cに指数があるなら、指数型 OutMsgInMsg (上付きを避けたいときは [InMsg, OutMsg] とも書く)をActionと定義してもよい。C(InMsg, OutMsg) は圏のホムセットだが、指数型 OutMsgInMsg は圏の対象となる。ホムセットなら Action⊆C (正確には、Action⊆Morphism(C))、指数対象なら Action∈C (正確には、Action∈|C|、|C| = Object(C))。以下、指数ではなくてホムセットとして話す。

一般に、射 f:A→B in C があるとき、fを遠隔呼び出し可能とするには、fをアクション化した Act(f) が必要。Act(f)∈Action、Action = C(InMsg, OutMsg)。Cの任意の射をアクション化したいなら、Act:C→Action というアクション化写像を定義する必要がある。ソフトウェア的には、(アクション化のための)ラッパーとかアダプターと呼ばれるものを定義する。任意の射をアクション化するのが無理なら、Act:C→Action は部分写像となる。写像Actの定義域は「アクション化可能な射」の集合となる。

アクション化のラッパー/アダプターにより、メッセージフォーマットの問題は解決できる。次に、エンドポイントの識別子の問題。g:J→Action という部分写像を考える。gはgetとかlookupとか書けばよりわかりやすい。j∈J に対して g(j)∈Action、つまりgはキーjからアクションを引き当てる関数(ミスヒットがあるので部分写像だ)。(Action, J, g) は、Key-Value-Store構造を定義する。ただし、Valueがアクションだから、Key-Action-StoreとかKey-Procedure-Storeと言ったほうがいいかも。

(Action, J, g)のようにキー(識別子)からアクションを引く、そしてアプライする機構をパフォーマーと呼ぶことにする。パフォーマーはPRCサーバーと同義である。

結局、RPCを可能とするには:

  1. アクション化のラッパーを作る。
  2. パフォーマーを作る。

これらの構造は、もとの計算モデル圏Cには一切手を加えない点が重要。呼ばれる側(callee)は、自分がラッパーに包まれていることも、外部で通用する識別子(キー)で引かれたことも、また外部から呼ばれていることさえもまったく知らない、知るスベもない。これがRPCのキモだ。メッセージフォーマットに依存したラッパーと、エンドポイント命名方式に依存したパフォーマーも独立している。依存関係は最小だ。

プロトコルが具体的に与えられたからといって、これらをベタベタグチャグチャに密結合させてはダメなのだ。って、このあいだまで僕自身がベタグチャをやっていた。ベタグチャの弊害やダメさ加減を十分自覚していたとも言い難い。モヤモヤ感と不満を抱いていただけだ。「堕落と怠惰であてどなく底辺を彷徨う」とはこのことだ。

僕がヘマをやらかしただけなら、一人で反省と自戒をすればいいことだが、ほとんどの人が違和感・不満さえ抱かずにベタグチャをやっている。恐ろしい。一番恐ろしいのは、ほんの少し前の自分が(違和感・不満を感じながらも)、自分と周りに対して懐疑も批判も出来なかったことだ。なんてこった。まー、やっと厚生の道を歩み出したが…