複数台で動かす：active / standby と設定の同期

[max3584]

rproxy を複数台（VM など）で動かし、1 台が止まっても転送が続くようにする。まだ実装はしない。形（設定・API・DB）を決めてから、次のマイナー（v0.4.0）でまとめて入れる。

オーナーの要望

• active / standby などの役割を持たせる
• 設定は全台で同期する
• 転送（クライアントの受け付けと転送先への送信）は基本的に active だけが行う

設計の案（たたき台）

1. どの台が active か（リーダーの決め方）

案	仕組み	利点	注意
A. DB のリース	共有の MariaDB に「active の台と期限」の行を置き、active が数秒ごとに延長する。期限切れなら standby が取る	追加のソフトが要らない（DB は既にある）	DB が止まると役割を決められない（その間は今の active を続ける）
B. 台どうしの合意（Raft など）	3 台以上で多数決	DB に依存しない	3 台以上が要る。実装が重い
C. 外部に任せる	keepalived（VRRP）や Kubernetes の Lease が決め、rproxy は通知を受けて役割を切り替える	実績のある仕組みを使える	keepalived などの設定が別に要る

2. クライアントを active に向ける方法

案	仕組み	注意
a. 仮想 IP（VIP）	active だけが VIP を持つ（ip addr add と gratuitous ARP / 非請求の NA）。rproxy が自分で付け外しするか、keepalived に任せる	同じ L2 のセグメントが要る。IPv6（GUA）も対応が要る
b. BGP / 上流のルータ	active だけが経路を広告する	ルータ側の設定が要る
c. DNS	active の IP を返す	切り替えに TTL の分だけ時間がかかる

• standby は、待ち受けを閉じておくか、IP_FREEBIND で VIP に先に bind しておき、受け付けを始めないだけにする（切り替えを速くするため）
• 転送先への送信（ヘルスチェック・CrowdSec の LAPI・DNS の再解決を含む）を active だけにするか、standby もヘルスチェックだけはするかを決める

3. 設定の同期

• 設定ファイル（RPROXY_CONFIG）：全台に同じファイルを配る（今の再読み込みで反映）。rproxy 自身で配るかは要検討
• API・UI で作ったルール（DB）：今は起動時にしか DB を読まないので、変更を全台に反映する仕組みが要る
  • 案：DB の変更の履歴（forward_rules_log）を各台が追いかける／active が standby に API で送る
• UI はどの台に話しかけるか：active（VIP）か、全台に送るか
• global（CrowdSec・trusted_proxies など）とトークン・証明書のファイルの扱い

4. 切り替えのとき

• 開いている TCP の接続は切れる（ユーザー空間のプロキシなので、接続を引き継げない）。UDP のセッション・rate_limit の数・CrowdSec の判定は作り直し
• 両方が active になる（split-brain）のを防ぐ方法（リースの期限・フェンシング）
• 状態の見え方：GET /cluster（台・役割・最後の同期）、ログ event=cluster.role、UI の表示

決めること

1. active の決め方（A / B / C）
2. クライアントを向ける方法（VIP / BGP / DNS）と、IPv4・IPv6 の両方で要るか
3. 台数（2 台か、3 台以上もあるか）
4. standby が転送先へのヘルスチェックなどを行ってよいか（「基本 active から送信」の範囲）
5. Kubernetes（将来の本命）での動かし方との関係（Deployment + Lease で C に寄せるか）

[max3584]

オーナーと決めた方針（2026-09-28）

1. 役割（act / stb）は API だけで扱う。 rproxy は自分の役割の状態を持ち、API で読み書きする（例 GET /role・PUT /role、/capabilities か /healthz にも出す）。rproxy は DB に書かない（DB に書くのは UI だけ）。リーダー選出（DB のリース・Raft）は持たない。
2. VIP は keepalived（VRRP）に任せる。 keepalived の notify のスクリプトから rproxy の API で役割を切り替える。track_script で rproxy の /healthz を見て、rproxy が止まったら VIP を移す。
3. 設定の同期は UI が行う。 rproxy は受け身の API のまま（台どうしの通信は持たない）。どの台に何を送るかは UI が決める（UI の L7: 認証（ForwardAuth と Keycloak / OIDC） #59）。
4. 切り替えは role の状態で把握する。 act→stb は設定の同期、stb→act は rebase（昇格した台の設定を基準にする）。同期する前なら、元の act に戻すことで設定の切り戻しができる（standby で試してから本番に出せる）。※解釈はオーナーに確認中
5. VIP の制御は rproxy の中に持たない。 VM は keepalived、Kubernetes は K8s の仕組みに頼る。

rproxy 側でやること（案）

• 役割の状態と API（act / stb、変更のログ event=cluster.role、/metrics）
• standby で VIP を持っていなくても待ち受けを開けるように、待ち受けに IP_FREEBIND / IPV6_FREEBIND を付ける設定（ルール、または extra_listen_addrs のアドレスごと）。ホストの ip_nonlocal_bind でも代わりになる
• stb のときの動き：VIP の外（台自身の IP）の待ち受けは動かす（設定を試すため）。転送先へのヘルスチェックなどを stb で止めるかは要検討
• keepalived の設定の例（notify・track_script）と docs

[max3584]

4 の解釈はオーナーに確認済み：stb→act（rebase）で昇格した台の設定を基準にし、act→stb の台には基準の設定を同期する。同期する前なら、元の act に戻して設定を切り戻せる。

[max3584]

standby でも、転送先へのヘルスチェックと CrowdSec の LAPI（判定の取り込み）は行う（オーナーと決定）。昇格した直後から、宛先の生死と CrowdSec の判定がそろった状態で振り分けられるようにするため。クライアントの転送（VIP での受け付けと転送先への送信）は act だけ。

[max3584]

UI 側の設計を max3584/TCP-UDP-rproxy-ui#98 にまとめました。act/stb は UI のグループとして扱い、rproxy-api は変えません（起動時の復元は、ノードごとの DB のビューで自分の行だけを読ませる）。

[max3584]

UI 側（TCP-UDP-rproxy-ui の #98・#59・#109）で、rproxy-api を変えずに act/stb と設定の同期・昇格の前に揃える仕組み・keepalived の例（UI の contrib/keepalived）まで入ったので閉じます。最初の案の FREEBIND（stb が VIP を持たずに待ち受ける）は作っていません。要れば別の issue にします。