要約

  • RFC 5351 の RSerPool は、pool handle を Pool Element の候補へ解決し、選択ポリシーで順序を付ける。候補の順位は、宣言された入力に基づく判断であり、次のアプリ処理の成功確率そのものではない。
  • RFC 5356 では負荷の数値範囲が共通化される一方、その意味はアプリ依存で RSerPool の範囲外とされる。同じ pool の要素は同じ定義を使う必要があるが、その定義が状態鮮度や認可能力を測るとは限らない。
  • フェイルオーバーには、名前、登録、選択、到達性、アプリ互換性、旧処理の commit 境界、状態の真正性と鮮度、再試行安全性、永続化、外部結果という別々の証拠が必要になる。

数値が小さいことと余力があることは同じではない

RFC 5356 は Round Robin、Weighted Round Robin、Random、Priority、Least Used などを定義する。共有された規則があれば、ENRP と Pool User は候補集合を一貫して扱える。

ただし Load の意味はアプリケーションが決める。0 から最大値までの表現は共通でも、ある pool は同時利用者数、別の pool は CPU、さらに別の pool はメモリーを採用できる。同じ pool 内では定義を合わせなければならないが、プロトコルは何を測るべきかまでは決めない。

低い利用者数は、データベースロック、レプリケーション遅延、鍵の不足、特定シャードの過負荷を示さない。CPU が空いていても、旧セッションの状態がなければ復旧先として適切でない。

したがって「least used」は測定契約の内側でのみ意味を持つ。指標の定義、観測時刻、候補集合を消して順位だけを表示すると、選択ポリシーが持っていなかった予測能力を後から与えてしまう。

pool handle は限定された運用範囲の名前だった

RFC 5351 では pool handle は平坦な handlespace の一意なバイト列であり、運用範囲は限定される。handle の管理方法は当時の文書の対象外だった。RFC 3237 も、異なる名前空間の相互運用には別の仕組みが必要だとする。

解決成功が示すのは、問い合わせた範囲がその名前を知っていることだ。別の管理領域で同じ意味を持つこと、同じ信頼主体が運営すること、同じデータ保護条件を満たすことまでは示さない。

Pool User と Pool Element のアプリケーションプロトコルも RSerPool とは独立している。互いに対応する設定があるという前提であり、バージョン、機能、認証方式を handle が交渉するわけではない。

この小さな名前解決契約は有用である。問題は、それをサービスの同一性、現在の健康、セッション連続性まで拡張して読むときに生じる。

handlespace の同期は現在時刻を止めなかった

ENRP サーバーはメンバー変更を交換し、Presence とチェックサムで不整合を検出し、必要な範囲を同期する。障害時には Home ENRP の役割を他のサーバーが引き継ぐ。

この仕組みは名簿サービスの耐障害性を高める。一方、Pool Element は keep-alive の直後に停止できる。登録解除は伝播中かもしれない。同期されたビューも、その観測後に起きた現実を含まない。

RFC 5352 のキャッシュには stale timer がある。古いエントリーなら更新と応答を並行でき、古くなければ通常は再問い合わせしない。「stale ではない」は年齢に関するローカル判定であり、今この瞬間の応答性ではない。

監査には解決時刻、キャッシュ年齢、閾値、応答した ENRP、実接続時刻が必要だ。これらがなければ、正しく期限内だった候補と、更新されず残った候補を区別できない。

フェイルオーバーは commit の位置を知らなかった

RFC 5351 の例では、固定された主・副サーバー名の代わりに handle を使い、失敗後に次のサーバーを取得する。候補発見を各アプリが作り直す必要はなくなる。

しかし接続断だけでは、旧要求が未到達、処理中、commit 済み、または commit 後に応答だけ失われたのか分からない。新しい要素へ同じ要求を送るべきかは、その違いに依存する。

仕様自身が、アプリ状態やトランザクション状態に依存する failover はアプリ固有の知識なしには定義できないと述べる。これは不足ではなく責任境界である。

安全なサービスは、操作 ID、重複排除、commit receipt、照会または補償を持つ。GETNEXTSERVER は次の住所を返せても、旧操作の意味を決められない。

opaque cookie は状態の通路にすぎなかった

オプションの cookie では、Pool Element が状態情報を送り、Pool User は最後に受け取った一つを保持する。障害後、新しい要素へその値を返す。User から見れば構造は不透明である。

不透明性はアプリごとの形式を基盤から隔離する。しかし User は、その値が最後の commit を含むか、古い schema か、新しい要素と互換かを判断できない。「最後に受信」は「最後に生成」や「最新状態」と同義ではない。

旧要素は署名し、新要素は検証すべきだと RFC 5351 は述べる。RFC 5352 は検証詳細を範囲外に置く。署名は出所と改ざんを扱うが、鮮度、完全性、実行許可までは扱わない。

cookie や business card の対応も全役割で同じ強制条件ではない。pool に所属しているだけで状態移送能力を推定してはいけない。

business card の「次善」には評価軸が必要だった

Pool Element は障害時に使う別要素を business card で案内できる。負荷や状態鮮度を考慮して、一般的な順位より良い候補を知っている可能性がある。

それでもカードは一参加者の助言である。発行後に候補が停止することも、レプリカが遅れることもある。「next best」が低負荷を意味するのか、最新状態を意味するのかも明示しなければ分からない。

候補は再び到達性、認証、アプリ互換性、状態版を検証される必要がある。カードは探索順を改善できるが、同等性証明ではない。

UI に provenance を残すことが重要だ。「旧要素が推奨」は事実であり、「復旧先として検証済み」は追加の検査を必要とする結論である。

登録解除後にも古いセッションは残った

RFC 3237 は、Pool Element が登録解除した後も、それ以前に開始した Pool User を処理し続け、新規接続だけを別要素へ向けることを求める。これは安全な drain を支える。

その結果、handlespace にいない要素が仕事を続ける。名簿から消えたことをプロセス停止の許可にすると、継続すべきセッションを壊す。

逆に、登録直後の要素がすべてのトラフィックに ready とは限らない。キャッシュの warm-up、データ追随、ポリシー反映が残る。登録資格の上にアプリ readiness が必要だ。

新規受付と既存処理の二つの状態を別に監視すれば、登録プロトコルの意味を保ったまま運用できる。

SCTP の経路回復は別サーバーへの移動ではなかった

SCTP は multihoming と heartbeat により、同じ endpoint への経路を変更できる。RFC 9260 は RFC 4960 を置き換え、関連文書は API や再構成を定義している。

この経路切替は、別の Pool Element を選ぶこととは異なる。同じ association の相手に別経路で届く場合と、別プロセス・別状態へ移る場合では、保持される文脈が違う。

監視は path failover、association 再確立、Pool Element 再選択、状態復元を別イベントとして記録すべきだ。単一の「failover 成功」は、どの層が継続したかを隠す。

特に exactly-once を必要とする操作では、transport の復旧を application の復旧と呼ばないことが設計上の安全策になる。

認証されたメンバーでも業務操作は再認可が必要だった

RFC 5355 は偽登録、悪意ある ENRP、解決改ざん、replay、DoS を分析し、参加者間の認証・認可を要求する。単一管理領域と事前共有鍵を前提にした保護も説明される。

これは pool の地図を守る。誰がメンバーになれるか、誰が回答できるかを定める。しかし最終ユーザーがどのデータを変更できるかは別の判断だ。

新しい要素はアプリ主体を認証し、権限を再評価しなければならない。旧セッションの security context は失効またはサーバー固有かもしれない。RFC 3237 はその共有を範囲外とする。

インフラ参加権、ユーザー操作権、状態移送権を分ければ、高可用性経路が認可の抜け道になるのを防げる。

十段階の証拠で選択を位置づける

正しい作用域の handle、問い合わせたビューへの登録、既知ポリシーによる候補、現在の transport 到達性、アプリ互換性と主体認証、旧操作の commit 状態、移送状態の真正性・鮮度・完全性・互換性、再試行安全性、永続実行、外部結果。この十段階は互いに代替できない。

Least Used が担当するのは候補順位の一部だけである。その範囲を明示すると、指標を過小評価せず、過大評価もしない。

IANA の RSerPool registry は message、parameter、error、policy の番号を維持する。番号の存在は相互運用の証拠であり、導入や健康の測定ではない。

Lu Heng の最小仕様と現実層の議論は、共有記号と実行結果を分ける分析レンズとして開示する。歴史的事実は RFC と IANA が担う。