要約

  • RFC 5390 の限定された UDP 例では、一つの SIP 要求が 503、代替サーバーへの再試行、トランザクション再送の組み合わせによって最大十八の要求と同数の応答に広がり得た。
  • 基本の 503 は、どの資源が過負荷なのか、どれだけ受け入れられるのか、どの対象まで信号が及ぶのかを十分に表さず、共有障害への反復、健全容量の停止、二点間の振動を生み得た。
  • 後続仕様は監視、制御判断、フィードバック、上流アクチュエーターを分離した。信号が届いた事実は、削減が実行された事実でも、実用的な処理が回復した事実でもない。

503 は仕事を消さず、宛先だけを変えた

RFC 3261 の基本動作は、局所障害には理にかなっていた。サーバーは一時的に処理できないとき 503 を返し、必要なら Retry-After で待ち時間を示す。プロキシは別のサーバーを試せる。最初の一台だけが故障し、次の一台に独立した余力があれば、この切り替えは可用性を生む。

RFC 5390 が置いたのは、候補三台がすべて過負荷という場面だった。ロードバランシングプロキシは S1 に送り、503 を受けると S2、さらに S3 へ進む。要求の意味は変わらない。各サーバーは受信、解析、スケジューリング、拒否応答の生成に資源を使う。候補リストは長いのに、新しい容量は一度も現れない。

ここで 503 は制御量ではない。ある処理経路が一件を完了しないと決めた記録にすぎない。上流が送信量を減らしたか、次の宛先が健全か、キューが短くなったか、利用者の呼が成立したかは含まれていない。それでも運用画面が「503を返せた」を「過負荷保護が効いた」と表示すれば、拒否を速く量産するほど緑に見える。

重要なのは移動前後の台帳である。どの要求がどの判断で次の宛先へ向かい、そこで新しい独立資源を得たのか。同じ仕事が同じ不足へ入り直しただけなら、フェイルオーバーではなく費用の複製である。

応答を待つ間にも仕事は増えていた

過負荷サーバーは 503 を即時に生成できるとは限らない。UDP 上の SIP クライアントは応答を待つ間に再送する。RFC 5390 の例は、クライアントからプロキシへの区間を含む四つの SIP トランザクションと、各 UDP トランザクションでタイムアウトまで最大七回の再送を数えた。その条件では、一つのクライアント要求が最大十八の要求と最大十八の応答を生む。

十八は観測された平均でも、あらゆる SIP 網に当てはまる係数でもない。三サーバーのトポロジー、UDP、再送タイマー、タイムアウトを前提にした仕様内の上限例である。前提を外して数字だけを引用すれば、証拠の精度を失う。

それでもこの数え方には強い意味がある。拒否を作るまでの遅延も、回復経路が生むコピーも、過負荷コストに含めなければならない。入口の原要求だけを数える監視では、再送増加を新しい需要と誤認し、システム自身が作った仕事を外部のせいにできてしまう。

TCP に替えれば一部の増幅は減るが、判断は直らない。同じ RFC の信頼できるトランスポート例でも、一件から三つの下流要求と四つの応答が生じる。再送がなくても、三つの候補が同じ資源不足を共有するという事実はプロキシに届かなかった。

上位プロキシは同じ地図を別の入口から歩いた

さらに一段上にプロキシを置くと、情報の閉じ込めが見える。P1 は S1、S2、S3 を試して、下流集合が過負荷だと知る。しかし、その知識が依存関係の範囲を伴う制御情報として上位へ戻らなければ、上位は P2 を選ぶ。P2 はまた同じ三台を探索する。

ノード数だけ見れば経路は冗長に見える。資源の来歴を見れば、追加されたものはない。P1 からの失敗が P1 自身の状態なのか、P1 と P2 の背後にある共有サーバー群の状態なのかを上位は判別できない。誤解を避けるため 503 の上流転送を抑えても、今度は重複探索を止める証拠が失われる。

冗長性は名前や IP の個数ではなく、成功を決める資源の独立性で評価すべきである。二つのフロントエンドが同じ停止中データベースを使うなら、その要求にとって一つの障害領域である。複数の SIP 経路が同じ PSTN 資源に収束する場合も同じだ。

したがって再試行の監査には、「別の宛先を選んだ」だけでなく「どの新しい独立資源を得る想定だったか」が要る。後者を保存しないシステムは、探索を増やすほど回復したように見せながら、実際には同じ故障へ負荷を戻す。

信号の範囲を広げすぎると健全な容量が消えた

範囲の曖昧さは、仕事を増やすだけではない。RFC 5390 は、503 が IP アドレス、ホスト名、URI のどれに適用されるかが RFC 3261 では十分明確でなかったと指摘した。一部実装がホスト名全体へ適用し、その名前が DNS SRV で複数メンバーに展開されると、一台の 503 が健全なメンバーまで避けさせる可能性があった。

この場合、ネットワークは過剰に送るのではなく、利用できる容量を自ら停止する。狭い観測が広い禁止へ変換されたためである。共有障害を別々だと思う増幅と、一台の障害を全体だと思う過少利用は、逆方向の症状に見えて同じ欠落から生まれる。

RFC 5390 の REQ 18 は、過負荷表示が IP、ホスト、URI のどれに関するものか曖昧でないことを求めた。スコープはメタデータの飾りではなく、受信者が行動してよい対象の境界である。サーバーは自分の状態を報告できるが、同じコードだけで兄弟ノードや共有サービス全体の状態を決める権限までは持たない。

運用記録には対象、時刻、有効期間、隣接相手、実際に除外または削減した対象を残す必要がある。「503受信」の一行では、障害ノードを保護したのか、健全クラスタを止めたのかを後から判定できない。

二値の待機時間が負荷を往復させた

Retry-After は滞留を解消する時間を与える。しかし基本動作は、送るか送らないかの二値だった。RFC 5390 の二サーバー例では、S1 と S2 がともに容量上限で動く。S1 が 503 と待機時間を返すと、プロキシは全トラフィックを S2 へ移す。S2 は二倍相当を受けて過負荷になり、今度は S1 側へ戻す。

各サーバーの観測は正しくてもよい。振動を作るのは、それを全量移動へ変換するアクチュエーターである。信号に、どれだけなら有用に処理できるかという段階値がない。タイマーが切れるたびに古い候補が再び全面開放され、測定と作用の遅れが次の振れを大きくする。

この例には明示的な境界がある。小さな割合ずつ送る多数の独立クライアントがいれば、その一部だけへ 503 を返すことで細かな削減に近づける。従って、Retry-After が常に振動を起こすとはいえない。RFC 5390 が必要としたトポロジーに対し、基本機構が安定した段階制御を保証しなかった、というのが正確な主張である。

REQ 7 は過負荷の程度を扱えることを、REQ 21 は提供負荷が容量以下になったときスループットが安定することを求めた。これはエラー応答の改良ではない。測定、フィードバック、作用、再測定からなる動的システムの要件である。

503 の意味が違えば、正しい次手も反対になる

実装は 503 を、自分の SIP 処理資源の過負荷以外にも使っていた。ゲートウェイの信号処理には余力があっても、特定の PSTN 経路が呼を受けられないことがある。一方、複数のフロントエンドが同じ停止中データベースに依存することもある。前者では代替経路が役立ち、後者では別フロントエンドへの再試行が同じ失敗へ戻る。

上流から見えるトークンが同じなら、再試行と抑制のどちらが正しいか決められない。REQ 6 が過負荷を他の障害から明示的に区別する信号を求めた理由である。REQ 8 と REQ 9 は、過負荷または不明な対象への反復を防ぐ一方、本当に健全な対象を利用不能にしないことを求めた。

REQ 14 は再試行方法を明確にし、とりわけ接続確立や再起動後の登録を扱う。原因、対象、削減量、時間は別の軸である。一つの一般コードへ詰め込めば、受信者が不足した政策を推測で埋めることになる。

最小限の共通仕様は、全ネットワークを支配する必要がない。下流が観測した局所状態を狭く表し、上流が自分の送信行為に責任を持つ。その権限境界を守る方が、曖昧な万能信号より強い協調になる。

後続仕様は制御ループの役割を分解した

RFC 6357 は、保護対象の SIP processor、状態を測る monitor、サンプルから判断を作る control function、feedback、送信側で働く actuator を分けた。受信側は測って伝え、上流は余分な要求が希少資源へ届く前に削減、遅延、拒否、迂回を行う。

この分離によって、失敗の位置を識別できる。監視値が正しくてもフィードバックは古いかもしれない。フィードバックが届いてもアクチュエーターが無視するかもしれない。総量の目標を守りながら、解放に有効なメッセージを落としているかもしれない。送信量が下がっても、隠れた依存障害が残れば実用処理は戻らない。

RFC 6357 は、ローカル拒否もサーバー資源を消費するため、それだけでは congestion collapse を防げないとした。最後の防護としては使えても、制御の中心は上流に置き、不要な仕事をボトルネックへ入れる前に止める必要がある。

RFC 7339 は後に、最上位 Via のパラメーターで隣接 SIP 要素間のフィードバックを運んだ。その Via は隣のクライアントによって消費されるため、情報はホップ単位の関係に結び付く。oc は既定の loss-based 方式で削減を示し、oc-validity は期限、oc-seq は順序、oc-algo は方式の種類を表す。フィールドの存在は、実装や全経路の保護、呼の成功を証明しない。

損失率とレート上限は異なる境界を作った

RFC 7339 は loss-based アルゴリズムの対応を必須とした。下流は上流クライアントに、転送する要求の割合を減らすよう求められる。軽量だが、割合は提供負荷に追従する。外からの要求が増えれば、通過する部分も増え得る。

RFC 7415 は任意の rate-based 方式を加えた。サーバーはクライアントごとの最大要求レートを示し、次の更新まで一定の上限を作る。境界は明確になるが、各クライアントに対する状態と公平性の判断が増える。

どちらも成果の約束ではない。毎秒 150 要求という上限は、150 トランザクションの完了や 150 呼の成立を意味しない。メッセージ種別ごとに処理費用が異なり、どれを枠に入れるかは上流のローカル政策に残る。標準は優先順位を世界共通にはしなかった。

だから証拠列も分ける必要がある。受信した値、期限、系列、実際に設定した制限、提供量、転送量、拒否または迂回した種別、完了トランザクション、維持できたダイアログ、利用者結果。レートを守ることと、価値ある仕事を守ることは別の検証である。

有用スループットだけが回復を閉じられる

RFC 5390 の最初の要求は、提供負荷が容量を大幅に超えても useful throughput を維持することだった。応答数を目標にしなかった点が重要である。全要求をすばやく拒否する装置は多くの応答を生成するが、利用者に一つも結果を返さないことがある。

有用性には状態の変化が要る。既存ダイアログを閉じる BYE は資源を解放し、新しい INVITE は状態を増やす可能性がある。登録更新にも別の費用と効果がある。生の要求数では、この違いを表せない。

優先順位はローカル権限として残された。運用者は緊急通信、既存セッション、契約上の義務を考慮できる。しかし、その自由は結果を記録しなくてよいという意味ではない。共通プロトコルがフィードバックを渡し、実装が選択し、その結果を運用者が引き受ける。

Lu Heng の現実層の考え方を当てれば、標準化されたパラメーター、実行中の資源、上流の決定、利用者結果は別の事実である。running code が制御を実行して初めて、仕様上の可能性が現実になる。合意済み構文は容量を創出せず、共有依存を分離せず、誤った優先順位の責任も移さない。

証拠の境界

凍結した資料が立証するのは、RFC 5390 の本文と Informational としての位置付け、記載された配備上の問題、RFC 6357、RFC 7339、RFC 7415 が示した後続アーキテクチャである。現在の通信事業者、製品、ネットワークがそれらを採用しているとは立証しない。特定障害が十八要求のモデル通りだったともいえない。

十八という数は、三サーバー、UDP トランザクション、再送、タイムアウトという前提と一緒に扱う。二サーバーの振動も、少数の大きな上流関係についての例であり、多数の小さな送信者を同じようには扱えない。実網の 503 一件だけで資源過負荷を断定することもできない。

一般化できるのは、拒否は削減ではない、という制御上の不変条件である。測定した資源、因果範囲、フィードバックの版と期限、上流作用、ローカル優先順位、有用な結果を順に示して初めて回復を主張できる。途中が欠ければ、分かるのは正しい形式のエラーが出たことまでである。