SLA と高可用性の境界

このドキュメントは、3 台のアプリケーション / Swarm ノード、2 台の PostgreSQL HA ノード、1 台の witness ノードで構成される 6 VM 完全オフラインデプロイに適用されます。

アーキテクチャ基準

レイヤー	現在の設計	高可用性の境界
アプリケーションランタイム	Enterprise New compose は固定の tier0_app_active_node 上で実行されます。	backend、redis、EMQX、SourceFlow、EventFlow、Marimo、OPC UA Server はまだ自動マルチレプリカサービスではありません。
HTTP 入口	3 台のアプリケーションノードで keepalived APP VIP + HAProxy を実行します。	VIP は浮動できます。HAProxy はアクティブノードの 8088/TCP に転送し、/healthz を確認します。
MQTT / OPC UA	EMQX は 1883/8883/8083/8084、OPC UA は 4840 を使用します。	これらはアクティブノードへ直接接続します。TCP VIP プロキシには含まれないため、プロトコル入口の HA は保証されません。
データベース	PostgreSQL / TimescaleDB ストリーミングレプリケーション + repmgr + witness + DB VIP。	primary 障害時に standby を自動昇格できます。非同期レプリケーションは厳密なゼロ RPO を保証できません。
バックアップと復元	backup-db.sh / restore-db.sh。	復旧性を提供しますが、オンライン HA と同じではありません。

推奨 SLA

サービス対象	推奨表現	制約
プラットフォーム HTTP 入口	月間可用性 99.5% から開始します。	VIP フェイルオーバーはアクティブアプリケーションノードの自動移行と同じではありません。
データベースアクセス	運用目標：RTO <= 2 minutes。	RPO はレプリケーション遅延に依存します。同じアーキテクチャでの過去フェイルオーバーテストは約 59-64 秒でした。
MQTT / OPC UA	現在の設計では HA SLA を約束しません。	先に HAProxy TCP proxy、専用 VIP、またはサービスクラスタリングを追加する必要があります。
バックアップと復元	毎日バックアップ。大きな変更前は必須。	復元時間はデータ量と現地 I/O に依存します。

99.9% 以上を主張する前に、アプリケーションの自動移行またはマルチレプリカデプロイ、プロトコル入口の HA、監視アラート、復旧訓練を完了してください。計画中の機能を納品済み機能として記述しないでください。

受け入れ条件

各デプロイまたはアップグレードでは、少なくとも以下を満たす必要があります。

• verify-materials.sh が成功し、デリバリーパッケージの SHA256 チェックが通る。
• 3 台の Swarm ノードが Ready である。
• APP VIP /healthz と /readyz が 200 を返し、ホームページと /uns にアクセスできる。
• アクティブノード上の 7 つの compose サービスが実行中である。
• DB VIP:5432 にアクセスでき、primary、standby、witness の topology が正常である。
• デフォルトアカウントで実際にログインできる。ポート、コンテナ、HTTP 200 応答だけで IAM 初期化成功を判断しない。
• HTTP、EMQX ポート、WebSocket/WSS、OPC UA TCP の smoke check が通る。

点検とアラート

毎日以下を実行します。

./bin/verify.sh --site config/site.conf
./bin/smoke-business-emqx.sh --site config/site.conf

少なくとも以下のアラートを設定します。

• APP VIP /healthz または /readyz の失敗。
• DB VIP 到達不可、primary 不在、split-brain リスク、レプリケーション中断、またはしきい値超過の遅延。
• keepalived、HAProxy、PostgreSQL、repmgrd の異常状態。
• backend、redis、EMQX などの重要コンテナの終了または頻繁な再起動。
• データディスク使用率が 80% / 90% を超過。
• 最新バックアップが失敗、または生成されていない。

訓練要件

訓練	頻度	検証基準
APP VIP failover	デリバリー前および四半期ごと。	現在の VIP ノードで keepalived を停止した後、/healthz と /readyz が復旧する。
DB primary 障害	デリバリー前および半年ごと。	standby が昇格し、DB VIP が復旧し、旧 primary が standby として再構築される。
データベース復元	毎月のサンプル確認、および大きな変更前。	バックアップが復元可能であること。復元後に verify、スモークチェック、ログイン検証が通過すること。
資材検証	すべてのパッケージビルド。	source material、package SHA、展開検証が通る。

インシデント対応原則

1. まず影響範囲を確認します。HTTP、MQTT、OPC UA、database、単一ノード影響を確認します。
2. VIP、HAProxy、アクティブアプリケーション、database primary の復旧を優先します。
3. ログ、データディレクトリ、バックアップを保全します。インシデント現場を直接削除または上書きしないでください。
4. データベースインシデントでは、まず現在の primary を特定し、その後フェイルオーバー、再参加、復元のいずれを行うか判断します。
5. 復旧後、verify、smoke check、実ログイン検証を実行します。

高 SLA 向け強化項目

• アプリケーションを multi-replica 化するか、アクティブノードの検証可能な自動移行プロセスを確立します。
• EMQX をクラスタ化するか、専用 VIP と HAProxy TCP / TLS でルーティングします。
• HAProxy TCP、専用 VIP、またはサービスクラスタリングで OPC UA の高可用入口を提供します。
• PostgreSQL 同期レプリケーションを使用するか、許容できる replication lag と RPO を明確に定義します。
• バックアップスケジュール、オフサイトレプリケーション、定期復元訓練を自動化します。
• コンテナ、ホスト、データベース、ログ、black-box probe を統一アラートに接続します。

関連手順: 運用 Runbook と 標準ポート一覧。