Enhanced UISA：異種ノード同期の owner・boundary・復旧モデル

昇格条件（三つの検証可能な確認）：

1. 規模・閾値の暗黙の保証を除き、再現可能な retry・冪等性の制約として説明する。
2. owner → boundary → 復旧機構の最小判断木を補う。
3. 五種類の異種 node の失敗モード行列を具体的なテストで支える。

定義

本ページは UISA を四層の構成図として再説するものではない。二つの raw を総合し、汎用情報同期基盤とプラグインライフサイクル制御プレーンが接続したとき、各状態を誰が所有し、メッセージをどう同期し、失敗をどう再試行・監査し、性能と安全性のトレードオフをどこで裁定するかを示す。結論は provisional であり、ソースの規模目標を満たすデプロイメントの証明ではない。

コアメカニズム

1. Owner / boundary：状態の所有権で責務を分ける

Owner	境界内で所有する事実	所有してはならないもの
Edge Agent	ノード身元、収集、プラグイン実行、ローカルキャッシュ、バージョン	中央ポリシーの最終裁定
Secure Gateway	認証、プロトコル変換、レート制限、接続管理、オフライン転送	永続的な資産・タスクの真実
Sync Engine	スケジューリング、Diff、タスク状態機械、版の衝突、再試行	応答前の端末実行結果の推測
Durable stores	身元、資産スナップショット、タスク、時系列、監査記録	実行器を置き換える直接配信
Plugin policy	desired/current/ack/failure、能力ゲート、カナリア、ブレーカ	汎用資産同期の全ルール

この境界では、Agent の current は観測、ポリシーサービスの desired は意図、タスクストアの状態は復旧可能な制御証拠となる。Gateway はピークを吸収できるが、メモリ上の転送成功をタスク完了として扱えない。

2. 同期プロトコル：登録・ハートビート・タスク・応答で一連の流れを完結させる

最小の順序は次のとおりである。具体的な HTTP/RPC フィールドは実装側で決める。

1. 初回登録で Business ID を結び、中央が長期利用する System UUID を生成し、短期の Session Token を発行する。
2. 通常リクエストは UUID、Token、Timestamp、Nonce、署名、Payload Hash を持つ。Gateway はコア処理前に検証し、偽造、改ざん、リプレイを防ぐ。
3. Agent はメトリクス、プラグイン/資産サマリ、実行中のタスクをマージハートビートで送る。Gateway は検証とレート制限を行い、通常負荷では転送し、高負荷では MQ に書いてバッチ消費する。
4. 下りタスクは Task DB にグローバル task_id とともに先に永続化し、オンラインなら直接配信、オフラインならオフラインキューへ入れる。
5. Agent は NoChange、Diff データ、または失敗を返す。Engine は Hash/署名を検証し、版条件で資産を更新し、成功時だけ監査を書いてキューを消す。

register -> heartbeat -> persist(task_id) -> dispatch|queue
         -> ack/diff -> validate -> versioned write -> audit

3. 信頼性と冪等性：複数の制約で収束させる

制約	防ぐ問題	観測できる結果
task_id の冪等性	重複配信、リプレイ	同じタスクが二度完了しない
Version + 楽観ロック	並行上書き	更新行数 0 なら再読込して Diff を再計算
Payload Hash / 署名	改ざん、送信元偽装	Payload を拒否しセキュリティイベントを記録
有限リトライ + TTL	無限再試行、オフライン滞留	期限切れを理由付き Failed にする
監査スナップショット + Diff	再生・修復不能な変更	前後状態を追跡できる
Plugin 操作キー + カナリア/ブレーカ	危険操作の重複・全量拡散	遮断理由、実行結果の応答、失敗率を追跡できる

汎用同期の目標は、観測可能で復旧可能、かつ収束する結果整合性である。プラグインページの desired/current/ack/failure は、このタスク状態機械をドメインへ投影したもので、別の真実ではない。

4. 異種ノード：一律配信より先に能力マトリクスを置く

ノード/環境	適応すべき差	許容する方針
ECS / 物理サーバー	身元の出所、OS、アーキテクチャ、ネットワーク経路	Agent 収集 + Version/Hash 増分同期
エッジノード / ゲートウェイ	断続的接続、プロキシ転送、帯域制約	ローカルキャッシュ、オフラインキュー、復旧時の起床
コンテナ	systemd、カーネルモジュール権限、制限されたファイルシステム	プラグイン許可リスト、非対応処理を skip
root なし / 読み取り専用 / Serverless	サービスのインストールや永続書込み不可	能力フィルタ、再試行可能なインストールと誤認しない
強化環境	スクリプト実行が遮断され得る	明示的な実行器/プロトコル適応と失敗記録

統一 Agent とプロトコルアダプタは転送差を隠せるが、能力境界を消せない。各プラグインまたはタスクには前提条件を明示する必要がある。

5. 障害復旧：オフラインは例外分岐ではなくライフサイクル状態

障害	制御プレーンの動作	復旧または終了条件
ネットワーク断 / Agent オフライン	Offline としタスクをオフラインキューへ	ハートビートで起床、TTL で失敗へ
Gateway 障害	LB 切替、Token/キュー状態を永続的な外部ストアに保持	再接続後に未完了処理を継続
MQ 滞留	Consumer を増やし非コアテレメトリを縮退	バッチ消費で追いつく
Hash/署名エラー	Payload を捨てセキュリティログを書く	全量同期または手動調査
楽観ロック衝突	最新版を再読込し Diff を再計算	上限まで自動再試行
DB 書込みエラー	タスクを Pending に保ち成功と報告しない	DB 復旧後に再試行
プラグイン版の失敗率過大	ブレーカを開き後続のインストール/更新を停止	明示的解除または新しい観測期間

プラグイン状態はまず論理オフラインとし、保持期間後にバッチ削除できる。資産同期では Hash 異常、版チェーン断裂、増分失敗の反復に対して全量修復を使う。

6. Trade-offs：高信頼性に無料の選択肢はない

選択	得られるもの	支払うコスト
強同期ではなく結果整合性	オフラインとジッターへの耐性	読み手が遅延と補償を受け入れる
増分 + Hash/Diff	通常時の転送・書込みコスト低下	版チェーン管理と異常時の全量修復
実行前にタスクを永続化	復旧性と監査可能性	遅延、ストレージ、状態機械の複雑さ
マージハートビート + MQ	ピークカットとリクエスト削減	非同期処理で観測が即時でない
長接続プッシュ	軽量操作の低遅延	接続安定性に依存し複雑なインストールに不向き
スクリプトプロキシ	多段処理を監査・制御できる	経路が長く追加の実行能力が必要
カナリア + ブレーカ	不良プラグインの爆発半径を制限	リリース低速化、閾値と運用手順の増加

適用条件

• 一つの基盤で ECS、IDC 物理サーバー、エッジノード、コンテナなど異種の収集元を管理する。
• ノードがオフライン中にもタスクが発生し、復旧後に再開、期限切れ、または監査可能な失敗が必要である。
• 業務が結果整合性を許容し、タスク、監査、MQ/キャッシュ、補償基盤を運用できる。
• 端末が安定したシステム身元、短期 Token、ローカル版/キャッシュ、能力対応の実行器を保持できる。

非適用とリスク

• owner/boundary 表はそのままデプロイできる製品トポロジーではない。シャーディング、テナント分離、鍵のライフサイクル、プロトコル版管理は未裁定である。
• リアルタイム強整合、恒久的なオンライン、すべての OS/権限で同じインストール命令を要求する領域には不向きである。
• UISA raw には本番容量基準がない。百万級はプラグイン raw の説明用シナリオにだけ現れ、QPS、SLO、コストを推定できない。
• Token 有効期間、オフライン TTL、ノード別滞留数、カナリア割合、ブレーカ閾値は例示であり、実際の失敗分布で校正する必要がある。
• 増分同期は安定した資産キーと版チェーンを必要とする。Hash 不一致やチェーン断裂後の全量修復はトラフィックと競合を別途評価する。
• プラグイン制御面を汎用同期プロトコルへ接続するのは本ページの総合であり、両 raw が統一ワイヤ契約や完全な所有権実装を証明するわけではない。

最小検証

1. 一つの Business ID を二度登録し、古い Nonce をリプレイする。紐付けは一意で、期限切れ/リプレイ要求は拒否される。
2. 同じ task_id を二度送る。状態遷移と監査記録は一度だけで、重複結果を識別できる。
3. 古い版の Diff を並行送信する。楽観衝突が観測でき、最新データを上書きせず再読込・再計算する。
4. オフライン中にタスクを作り、ハートビートを復旧する。キューから起床し、期限切れは理由付き失敗になる。
5. 不正な Hash/署名と非対応能力を送る。Payload が拒否されるか処理が skip され、セキュリティ/監査の証拠が残る。
6. プラグインバージョンについて、失敗を報告する実行応答をブレーカ閾値以上にする。後続動作が遮断され、通常ハートビートで解除を迂回できない。

証拠と不確実性

• ソース事実：legacy-uisa-architecture-design は二重身元、短期 Token、署名/Hash/Nonce 検証、MQ ピークカット、Version と Diff、オフラインキュー、タスク状態機械、楽観ロック、監査、障害マトリクスを記述する。
• ソース事実：legacy-plugin-lifecycle-management はマージハートビート、プラグインの現在/目標バージョンと状態、操作重複防止、能力フィルタ、カナリア/ブレーカ、実行結果の応答による復旧を記述する。
• 本ページの総合：両ソースを owner/boundary に写像し、プラグインの安全ゲートを汎用タスク同期の上位にあるドメインポリシー層とした。Trade-offs 表は両ソースの比較である。
• 未確認：本番容量、サービス間トランザクション境界、鍵ローテーション、プロトコルバージョンのネゴシエーション、テナント分離、実際の失敗率は raw から確定できない。

関連ページ

• プラグインライフサイクル管理

出典と関連文書

• legacy-uisa-architecture-design
• legacy-plugin-lifecycle-management
• 百万端末のプラグインライフサイクル管理：状態・ハートビート・制御されたリリース