Edge / Cloudの信頼性設計は何を改善するのか？ ― Freeze対策・再送・監視を運用指標から整理する
はじめに
これまで、医療向けのEdge / Cloud環境において、24時間365日の無人運用を前提とした安定化に取り組んできました。
具体的には、以下のような対策です。
- Edge PCのFreeze対策
- DriverやSoftware構成の最小化
- WindowsからLinuxへの移行
- Azure IoT EdgeのVersion管理
- AMQP over WebSocketへの変更
- Cloud切断時のStore-and-Forward
- 通信断のMonitoring
- Modality → Edge PC間の再送設計
これらは、それぞれ異なる技術課題への対策です。
しかし、個別の技術対策だけを見ていると、最終的に何を改善したかったのかが見えにくくなります。
例えば、
Edge PCのFreezeを減らすことは、単にOSを安定させるだけが目的ではありません。
データ送信の停止を減らし、障害調査や現地対応の負担を減らすことにもつながります。
今回は、これまで取り組んできた技術対策を振り返りながら、
技術的な改善を、どのような運用指標で評価できるのか
という視点で整理します。
1. Edge PCのFreeze対策はDowntimeの削減につながる
Edge PCのFreezeに対して、これまで以下のような対策を行ってきました。
- 不要なDriverの削減
- GPU Driverの切り分け
- 不要なDeviceの無効化
- OSの変更
- KernelやSoftware Versionの管理
- Maintenance処理の分散
技術的には、OSやDriver、Hardwareに起因する障害を切り分け、安定稼働を目指す取り組みです。
しかし、実際の運用では、Edge PCの停止が引き起こす影響はPC単体にとどまりません。
Edge PCがFreeze
↓
Data送信が停止
↓
顧客またはSupportが異常に気付く
↓
状態確認
↓
原因調査
↓
必要に応じて現地対応
↓
復旧
一つの障害に対して、顧客、代理店、Support、Engineeringなど、複数の関係者が対応する可能性があります。
そのため、Freeze対策の効果を評価するときは、単に「PCが止まらなくなったか」だけでは不十分です。
例えば、以下の指標が考えられます。
| 評価指標 | 確認したいこと |
|---|---|
| Freeze発生回数 | 停止頻度が減ったか |
| 稼働率 | 正常にサービスを提供できる時間が増えたか |
| MTTR（平均復旧時間） | 障害からの復旧が早くなったか |
| 現地対応回数 | 現地へ行く必要が減ったか |
| 障害対応工数 | SupportやEngineeringの負担が減ったか |
特に、端末が多数の施設に展開される場合、1台あたりの障害頻度や対応時間の削減が、全体の運用負荷に大きく影響します。
つまり、
Edge PCの安定化は、OSの技術課題であると同時に、System全体の可用性や保守性を改善する取り組み
だと考えられます。
なお、Freeze回数の減少だけでサービス稼働率の改善を判断することはできません。アプリケーション停止や通信断など、ほかの停止要因も含めて評価する必要があります。
2. Store-and-Forwardは「再送できる」だけでは評価できない
Cloudとの通信が切断された場合に備えて、Store-and-Forwardを設計してきました。
基本的な流れは以下です。
Edge PC
↓
Cloudとの通信断
↓
Edge側にDataを保持
↓
通信復旧
↓
保持Dataを再送
↓
Backlog解消
技術的な目的は、通信断によるData Lossの防止です。
ただし、Store-and-Forwardを実装しただけで、必ずData Lossを防げるわけではありません。
例えば、以下のような条件も考える必要があります。
- 何時間分のDataを保持できるか
- Storage容量を超えた場合にどうするか
- 再起動後もDataが保持されるか
- 通信復旧後にBacklogを解消できるか
- 重複送信が発生した場合にどう処理するか
また、System全体を見ると、通信経路は以下のようになります。
Modality
↓
Edge PC
↓
Cloud
Edge PC → Cloud間でDataを保持できても、Modality → Edge PC間でDataが失われれば、End-to-EndのData Lossは防げません。
そのため、再送設計を評価するときは、以下のような指標が必要になります。
| 評価指標 | 確認したいこと |
|---|---|
| Data欠損件数 | 送信元からCloudまでDataが届いているか |
| Data重複件数 | 再送による重複が発生していないか |
| 最大保持可能時間 | 何時間の通信断に耐えられるか |
| Backlog解消時間 | 復旧後、通常状態に戻るまでの時間 |
| 再送成功率 | 保持Dataを正常に送信できたか |
例えば、Cloudへの通信が2時間停止してもDataを保持できたとして、通信復旧後にBacklogを解消するまで10時間かかるのであれば、運用要件によっては十分とはいえません。
逆に、通信断が発生してもDataを失わず、復旧後に許容時間内でBacklogを解消できれば、通信障害による業務影響を小さくできます。
重要なのは、Store-and-Forwardという機能の有無ではなく、どのような障害条件までDataを守れるのかを確認することです。
3. Network設計は接続性だけでなく導入負荷にも影響する
Cloud接続を実装するとき、最初に確認するのは通信が成立するかどうかです。
しかし、実際に複数の施設へ展開する場合、通信できることだけでは十分ではありません。
例えば、
- 施設ごとにNetwork Policyが異なる
- 特定のPortがBlockされる
- Proxyを経由する必要がある
- DNSやFirewallの設定が異なる
- Network変更に施設側の承認が必要になる
といった問題があります。
以前、Azure IoT Edgeの通信方式を、
AMQP
↓
AMQP over WebSocket
へ変更しました。
AMQP over WebSocketでは、一般的なHTTPSと同じTCP 443を利用できます。
そのため、AMQPの直接接続に必要なPortがBlockされている環境でも、接続できる可能性があります。
ただし、TCP 443を利用すれば必ず通信できるわけではありません。
ProxyやTLS Inspection、通信先FQDNの制限など、施設側のNetwork Policyに依存します。
この変更の目的は、単純なProtocol変更ではなく、
施設ごとのNetwork環境の違いをできるだけ吸収すること
でした。
これを運用面から評価すると、以下のような指標が考えられます。
| 評価指標 | 確認したいこと |
|---|---|
| 初回接続成功率 | 標準構成で接続できる施設の割合 |
| 導入所要時間 | Network設定から接続完了までの時間 |
| Network調整件数 | 施設側との調整が何回発生したか |
| 接続障害件数 | 導入後に通信問題がどれだけ発生するか |
例えば、Network構成の見直しによって施設側のFirewall変更が不要になるケースが増えれば、導入時の調整工数を削減できる可能性があります。
ただし、接続性だけを優先してSecurity要件を緩めるべきではありません。
必要なSecurity、Reliability、導入性、運用性を満たしたうえで、構成を選択することが重要です。
4. Remote Monitoringは障害の検知時間と対応時間を改善する
Remote Monitoringでは、Edge PCやCloudの状態を遠隔から確認します。
例えば、以下の情報です。
Edge PC
├─ OS稼働状態
├─ Application稼働状態
├─ Network接続状態
├─ CPU / Memory / Storage
└─ Software Version
Cloud
├─ 最終Data受信時刻
├─ 通信状態
├─ Data受信件数
└─ Error情報
これらを取得できれば、障害発生時の切り分けに利用できます。
例えば、Cloud側でDataの未受信を検知したとします。
未受信という情報だけでは、以下のどれが原因か分かりません。
Edge PCが停止した
Applicationが停止した
施設Networkが切断された
Cloudへの送信だけが失敗した
Modality側からDataが送られていない
そのため、Edge PC内部のTelemetryや、外部監視端末によるHeartbeatなど、複数の情報を組み合わせる必要があります。
Remote Monitoringの評価では、以下の指標が有効です。
| 評価指標 | 確認したいこと |
|---|---|
| MTTD（平均検知時間） | 障害を検知するまでの時間 |
| MTTR（平均復旧時間） | 障害から復旧するまでの時間 |
| 障害切り分け時間 | 原因の候補を絞り込むまでの時間 |
| 現地対応率 | 全障害のうち現地対応が必要だった割合 |
| 自動復旧率 | 人手を介さず復旧できた割合 |
Remote Monitoringがない場合、
障害発生
↓
顧客が異常に気付く
↓
問い合わせ
↓
Supportが調査
という流れになりがちです。
Monitoringを導入すると、
障害発生
↓
Systemが異常を検知
↓
SupportがRemoteで状態を確認
↓
必要な対応を判断
という運用に変えられる可能性があります。
ただし、監視を導入しただけでMTTRが短くなるとは限りません。
検知後の通知先、対応手順、復旧方法まで設計する必要があります。
監視の目的は情報を集めることではなく、障害に早く気付き、必要な対応を早く判断できるようにすることです。
5. Field DataはProduct品質の改善にも利用できる
Cloudへ送るDataは、現在のDeviceの状態を把握するためだけのものではありません。
例えば、以下の情報を継続して取得できれば、長期的な分析にも利用できます。
- 稼働時間
- Fault発生件数
- Software Version
- 通信障害の発生状況
- 部品交換履歴
- Maintenance履歴
これらを分析することで、以下のような傾向を把握できる可能性があります。
特定Software VersionでFaultが増える
一定の稼働時間を超えると
特定部品の交換が増える
特定のNetwork環境で
通信障害が多く発生する
こうした情報をProduct改善につなげる場合、以下のような流れになります。
Field Dataを収集
↓
傾向を分析
↓
原因を調査
↓
改善策を検討
↓
Productへ反映
↓
改善効果を確認
ただし、単純なFault件数だけで品質を判断するのは適切ではありません。
例えば、Software VersionごとのFault発生件数を比較するときは、対象Deviceの台数や稼働時間を考慮する必要があります。
Fault発生率
=
Fault発生件数 ÷ 総稼働時間
といった指標を利用すれば、異なる条件のDevice群を比較しやすくなります。
また、医療向けSystemでは、収集するDataについても注意が必要です。
障害解析に不要な患者情報などを収集しない設計や、アクセス権限、保存期間、通信・保存時の保護などを考慮する必要があります。
Cloud接続によって得られる価値の一つは、Fieldで発生している問題を可視化し、次の改善へつなげられることです。
6. 技術対策と運用指標を対応させる
これまでの内容を整理すると、以下のようになります。
| 技術対策 | Engineering上の目的 | 運用上の改善目標 | 評価指標の例 |
|---|---|---|---|
| Freeze対策 | Device安定化 | Downtime削減 | 停止回数、稼働率 |
| Driver最小化 | 不具合要因削減 | 長期安定運用 | 障害発生率 |
| Version管理 | Change Risk低減 | 更新起因の障害抑制 | 更新失敗率、変更後の障害件数 |
| Store-and-Forward | Data Loss防止 | 通信断時のData保持 | 欠損件数、保持可能時間 |
| 再送制御 | End-to-End Reliability | Data欠損・重複の削減 | 再送成功率、欠損・重複件数 |
| 通信断Monitoring | 障害検知 | 異常の早期把握 | MTTD |
| Firewall設計 | 不要通信の制御 | Security Risk低減 | 許可通信の棚卸し結果、設定逸脱件数 |
| Network構成見直し | 接続性向上 | 導入負荷削減 | 接続成功率、導入時間 |
| Remote Monitoring | 状態把握 | Support効率改善 | 切り分け時間、現地対応率 |
| Field Data分析 | 障害傾向の把握 | Product品質改善 | Fault発生率、再発率 |
ここで重要なのは、技術対策の実施と、運用上の改善効果を分けて考えることです。
例えば、
技術対策：
Store-and-Forwardを実装した
確認：
通信断中のDataを保持できた
運用上の評価：
想定する通信断時間に耐え、
復旧後に欠損なくDataを再送できたか
というように整理します。
同様に、Remote Monitoringなら、
技術対策：
Cloud側で通信断検知を実装した
確認：
Data未受信を検知できた
運用上の評価：
従来より早く異常を把握し、
障害切り分け時間を短縮できたか
となります。
単に機能が動いたことと、その機能によって運用が改善したことは別です。
可能であれば、対策導入前後で同じ指標を記録し、比較する必要があります。
また、障害発生率などを比較するときは、端末台数や観測期間、運用環境の違いも考慮することが重要です。
まとめ
これまでのEdge / Cloud環境では、以下のような技術課題に取り組んできました。
Freeze対策
↓
Deviceの安定化
↓
Downtime削減
Store-and-Forward
↓
通信断時のData保持
↓
Data欠損リスクの低減
Remote Monitoring
↓
障害の早期検知・切り分け
↓
対応時間・現地作業の削減
これらの対策は、それぞれ技術的な目的を持っています。
しかし、実運用では、その技術が何を改善したのかまで確認する必要があります。
特に、24時間365日の無人運用を前提としたEdge / Cloud Systemでは、
- 安定して動き続けられるか
- 通信障害が発生してもDataを守れるか
- 異常を早く検知できるか
- Remoteで原因を切り分けられるか
- 現地対応の負担を減らせるか
といった点が重要になります。
Reliability、Security、Monitoringは、それ自体が最終目的ではなく、Systemの運用要件を満たすための手段です。
そして、それぞれの対策に対して評価指標を設定することで、技術的な改善を運用上の効果として確認しやすくなります。
これまでの取り組みを振り返ると、技術選定や設計の段階から「何を改善したいのか」を明確にしておくことが重要だと感じています。
次回は、その考え方をもう一歩進めて、
CloudやEdge PCを先に決めるのではなく、必要な価値や運用要件からSystem構成を考える
というテーマについて整理します。