要約

  • RFC 3528は、登録を受け入れたmesh-enhanced Directory Agentが、他のDirectory Agentへの非同期転送より先にService AgentへSrvAckを返すことを認める。この返答はローカル処理の完了であり、分散コミットではない。
  • 受領権限、accept ID、version timestamp、peer別転送、anti-entropyの範囲、検索結果、残存寿命、削除状態、到達性、アプリケーション結果を別々に残さなければ、最初の成功表示が後続工程を不当に代表する。

分散ディレクトリには、同じ出来事を表す一つの時計があるわけではない。書き手は登録内容の版を進める。受入ノードは自分の流れに順番を付ける。読み手はさらに後の瞬間に、選んだノードの状態を見る。

2003年4月にExperimentalプロトコルとして公開されたRFC 3528は、SLPv2にscope単位のDAフルメッシュ、直接転送、anti-entropyを加える。標準化したのは瞬間的一致ではなく、差分を運び直す方法である。

最初に閉じるのは書き手との交換である

Service AgentはDirectory Agentへ登録を送る。更新を受け入れたDAがaccept DAとなり、mSLP対応であれば、共通scopeを持つpeerへ状態を転送する。

直接転送は非同期である。accept MDAは別のMDAへSrv(De)Regを送る前に、MSAへSrvAckを返せる。つまり書き手の待機は終わっても、peerへの作業は始まったばかりかもしれない。

これは受領確認が偽物だという話ではない。確認対象が限定されている。特定DAが特定の更新を受け入れた事実は示せるが、他のDAが受領したこと、検索に出ること、サービスが動くことは観測していない。

全peerを待たずに返すことで、一つの遅いノードがすべての書き込みを止める事態を避けられる。その可用性上の選択を守るには、表示側も「ここで受け入れた」と明記し、メッシュ全体の言葉を使わないことが必要である。

受領記録にはaccept DA、認証済みMSA、scope、payload digest、認可方針、version timestamp、accept ID、SrvAckの因果種別を結ぶ。単一のsuccessフィールドでは後から境界を復元できない。

順序保証は未来の配送を完了させない

peer DA同士は、共有するすべてのscopeについて持続的で信頼性のある順序付き接続を使う。生きている接続上で更新順序を維持できることは、回復を考えるうえで大きな利点である。

しかし、信頼性は時間を飛び越えない。まだ送っていない更新を配達済みにはできず、切断中の差分を自動的に検索可能にもできない。障害後にはanti-entropyが必要になる。

初期同期後、新しい更新はaccept DAから該当peerへ直接送られる。一跳の設計であり、受信peerが同じ更新を際限なく再配布するものではない。

peer接続が配送を保証するため、peerから受けた個々のSrv(De)Regへ毎回SrvAckを返す必要はない。だからこそ、MSA向けの確認をpeer全員の確認と読むことはできない。

証跡は、期待peer、認証済み接続、共有scope、送信位置、結果、回復後のfrontierをpeerごとに持つべきである。「接続中」という集合状態だけでは対象更新が渡ったか分からない。

三つの時計は三つの問いに答える

accept IDはaccept DAのURLと、そのDAが単調増加させるaccept timestampからなる。同じDAが受け入れた更新はこの順序で伝播される。

別のaccept DAには別の流れがある。異なるDAで受け入れた更新同士は任意の順序で伝わり得る。二つの数字を比較しても、メッシュ全体の前後関係にはならない。

登録内容にはMSAが与えるversion timestampもある。同じ登録の新旧を決めるための値で、peerへの到着時刻では代替できない。古い更新が遅れて新しい更新の後に到着し得るからである。

version timestampは「どの内容が新しいか」、accept IDは「どの入口がどの順番で受けたか」、検索時刻は「その読者が何を見たか」に答える。一つの更新日時へ統合すると、障害解析に必要な関係が消える。

RFCは一つの登録を一つのSAが更新すると仮定する。複数の書き手を許す実装は、独自の権限と競合解決を設計しなければならない。

summary vectorは受領位置の一覧である

anti-entropyでは、既知のaccept DAごとに最後に受け取ったaccept timestampをsummary vectorへ入れる。複数の起点流について、どこまで受けたかを小さく表現できる。

相手は各frontierより後の状態を要求する。complete要求なら、要求に現れないaccept DAの状態も対象になる。selective要求なら、列挙したaccept IDsだけが対象である。

従って「同期成功」には修飾が必要だ。selectiveな交換が正しく完了しても、省略された起点は一切検査されない。要求集合を失った成功記録は範囲を証明できない。

提供側は要求状態をaccept ID順に送り、処理後にSrvAckを返す。このackは最初の登録ackと名前が同じでも、anti-entropy要求の完了を示す別の受領書である。

summary vectorが揃っても、サービスの健全性は分からない。期限切れ、誤った内容、別scope、到達不能なendpointであっても、更新履歴だけは完全に同期できる。

削除は直ちに無ではなくなる

回復時に送られる登録は、元の残存lifetimeを引き継ぐ。同期のたびに満額の寿命へ戻してはならない。そうしなければ古い広告が回復処理だけで生き続ける。

登録解除はdeleted registrationとして保持される。遅れて届いた古い登録が削除済み状態を復活させるのを防ぐtombstoneである。元の登録が期限に達すると削除状態をpurgeできる。

解除を受け入れた時刻、peerがtombstoneを受けた時刻、物理削除した時刻、検索から消えた時刻は別である。「削除済み」という一語では観測点を失う。

登録ID、version、accept ID、削除フラグ、残存時間、同期経路、検索観測を残せば、遅延更新が現れたときに復活を防いだ理由まで説明できる。

scopeは誰が同じ地図を見るかを決める

同じscopeを提供するMDAはフルメッシュを形成する。一つの接続は複数の共通scopeを運べる。MSAは自分のscope集合を覆うだけのMDAへ登録し、残りを伝播に任せられる。

そのため、受入scopeは成果の範囲そのものである。scope外のDAに同じ結果を要求できない。User Agentが別のscopeや別のDAを選べば、別の検索結果になり得る。

RFCはフルメッシュを単純性と信頼性のために採用し、一般には数十MDA以下を想定する。無制限の規模向けではない。この記述は設計上の目安であり、現行配備の計測ではない。

親scopeを二つの子scopeへ分けると、以前は一度で済んだ登録が両方に必要になる場合がある。分類変更は管理画面上の名前変更ではなく、発見可能性の契約変更である。

認証されていない入口からも状態は広がる

mSLPはSLPv2認証を使う。MDAはpeering前に他のMDAを、更新の受入・転送前にMSAを認証すべきであり、MSAも利用するMDAを認証すべきだとされる。

順序付きTCP接続は正規メンバーシップを証明しない。有効な署名だけでも、その鍵がこのscopeのサービスを更新できるとは限らない。認可方針は別に必要である。

一つのMDAが侵害されると、伝播によってメッシュ全体へ影響し得る。可用性のためのfan-outは、誤った入口判断の範囲も拡大する。

SLPv2は、事前の安全設定がないbootstrapでは一定のblind faithが必要になる場合も説明する。鍵配布と検証方針はプロトコル名だけでは生まれない。

IANAはMesh-enhancementをSLPv2 extension ID 0x0006として登録しRFC 3528を参照する。登録番号は意味の衝突を防ぐが、実装、設定、認証、収束、結果を保証しない。

検索一致はサービス利用の入口にすぎない

書き込みはSAからDAへ、読み取りはUAから選択されたDAへ進む。可視性を証明するには、対象DA、認証済みidentity、scope、検索predicate、response digest、version、残存lifetime、観測時刻を記録する。

ディレクトリ応答は、サービス所在地についての登録を返しただけである。endpointへ接続せず、アプリケーションプロトコルを確認せず、利用者の権限も最終処理も保証しない。

目的が利用可能性なら、名前やaddress解決、network reachability、handshake、サービス固有health、application outcomeまで別のreceiptを続ける必要がある。

時計を消さない証拠鎖

最初にプロトコルidentityとstatus、scope定義、MSA identity、credential、trust policy、認可結果を保存し、payload digest、version timestamp、accept DA、accept IDへ結ぶ。

MSA向けSrvAckはローカルreceiptのまま固定する。その後のpeer転送、summary frontier、anti-entropyは別eventとしてimmutable identifierで関連付ける。後から知った全体状態を初期receiptへ上書きしない。

最後にquery observation、endpoint reachability、service health、application resultを追加する。Directory、security、service、applicationの各ownerが、自分の観測範囲だけへ署名する構造が必要である。

証拠の境界

本稿は特定の実装、vendor、operator、mesh、agent、service、endpoint、registration、deployment、incident、outage、attack、customer resultを指さない。採用率、規模、伝播時間、検索成功率、到達性を測定していない。

RFC 3528は2003年4月のExperimentalプロトコルとして扱い、Internet Standardとは呼ばない。keepalive 200秒、timeout 300秒は文書上のdefaultで、現場設定や検知時間の証拠ではない。

registryとmetadataは文書identityやassigned valueを示すが、running codeを証明しない。

Heng Luのauthorityとrunning codeに関するノートは、receiptの権限を問う編集上の視点として明示する。IETFの意図や配備事実をそこから導かない。

結論は限定的である。ローカル受入、mesh伝播、query visibility、service reachability、application outcomeは別々に真偽が変わる。

出典