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構成を考える

というテーマについて整理します。