Azure IoT EdgeのStore-and-Forwardは何時間耐えられる？TTL・Disk容量・再送時間を確認する
Azure IoT EdgeのStore-and-Forwardを設定すると、Cloudとの通信が切れても、edgeHubが未送信Messageをローカルに保持できます。
しかし、24時間365日の無人運用を考えると、
Store-and-Forwardが有効になっているだけでは不十分
です。
実運用では、少なくとも次を確認する必要があります。
・何時間Messageを保持できるのか
・Disk容量は足りるのか
・TTLは十分なのか
・RestartしてもDataは残るのか
・Cloud復旧後、何分で再送が終わるのか
・Data欠落や重複が発生しないか
この記事では、Azure IoT EdgeのStore-and-Forwardを、
設定できている
ではなく、
Cloud断に何時間耐えられるか
という視点で確認します。
結論
最初に結論です。
Store-and-Forwardで実際に保持できる時間は、大まかには、
TTLで許可された保持時間
と
Disk容量から計算した保持可能時間
の短い方
で決まります。
つまり、
実質的な保持可能時間
=
min(TTL, Storageから計算した保持時間)
です。
さらに、Cloudが復旧したあとも、
Cloud Connected
=
完全復旧
ではありません。
通信断中に蓄積したDataがすべて再送され、
Backlog = 0
になるところまで確認する必要があります。
1. まず「何時間のCloud断に耐えたいか」を決める
最初に決めるのはDisk容量ではありません。
まず、
最大何時間のCloud通信断までDataを失わず保持したいか
を決めます。
例えば、
30分
2時間
6時間
24時間
72時間
では、必要なStorage容量もTTLも大きく変わります。
例えば要件が、
最大24時間のCloud Disconnectまで
Dataを保持したい
であれば、少なくとも24時間分のDataをEdge PC側へ保存できる必要があります。
実際には限界ぎりぎりではなく、
想定最大通信断
+
Safety Margin
で設計します。
2. Disk容量から「何時間持つか」を計算する
例えば、1時間に発生するData量が、
50 MB/hour
だったとします。
10時間通信が切れると、
50 MB × 10時間
=
500 MB
24時間なら、
50 MB × 24時間
=
1.2 GB
必要です。
基本的には、
必要容量
=
1時間あたりのData量
×
想定通信断時間
で概算できます。
逆に、Storage容量から、
あと何時間保持できるか
も計算できます。
例えば、Store-and-Forwardで安全に使用できる領域が、
3.5 GB
Data増加量が、
50 MB/hour
であれば、
3500 MB
÷
50 MB/hour
=
約70時間
です。
この考え方を使うと、
Disk残量 3.5GB
よりも、
現在のData量なら
あと約70時間保持できる
と表示できます。
障害対応では、この方が判断しやすくなります。
3. Data量は想像ではなく実測する
重要なのは、
50 MB/hour
のような値を想像だけで決めないことです。
実際にSystemを動かして、
1時間
3時間
24時間
などの単位でStorage使用量を測ります。
例えば、
試験開始時
10.00 GB
1時間後
10.12 GB
なら、
約120 MB/hour
増加しています。
Edge PC全体のDisk容量は、
df -h
で確認できます。
ただし、同じDiskには、
OS Log
Docker Log
Application Log
Temporary File
なども書き込まれます。
Store-and-Forward単体の増加量を確認するなら、edgeHubが使用しているStorage領域を個別に確認した方が分かりやすいです。
Host側へPersistent Storageを割り当てている場合は、
sudo du -sh <edgeHubのHost Storage Path>
などで確認できます。
Mount設定は、
docker inspect edgeHub
でも確認できます。
4. Diskが大きくてもTTLが短ければ保持できない
Store-and-Forwardでは、Disk容量だけでなく、
timeToLiveSecs
も確認する必要があります。
timeToLiveSecsは、edgeHubが未送信Messageを保持する時間です。
Microsoft Learn上の既定値は、
7200秒
=
2時間
です。
そのため、
Disk容量
100時間分
TTL
2時間
という構成では、100時間保持できるわけではありません。
TTL側が先にLimitになります。
逆に、
TTL
72時間
Disk容量
20時間分
なら、Disk側が先にLimitになります。
したがって、
実質的な保持可能時間
=
TTLによる保持時間
と
Disk容量による保持時間
の短い方
と考えます。
5. Cloud復旧後にはBacklogが残る
次に見落としやすいのが、Cloud復旧後です。
例えば、
02:00
Cloud Disconnect
08:00
Cloud Reconnect
だったとします。
08:00にIoT HubとのConnectionが復旧しても、Edge PCには6時間分の未送信Dataが残っています。
この未送信Dataを、ここでは、
Backlog
とします。
例えば通常、
100 MB/hour
のDataが発生するSystemで6時間通信が停止すると、
100 MB × 6時間
=
600 MB
のBacklogが発生します。
Cloud復旧後は、
過去6時間分のData
+
現在発生しているData
を同時に送る必要があります。
6. 再送速度が通常Data量と同じでは追いつかない
例えば通常のData発生量が、
100 MB/hour
だったとします。
Cloud復旧後の送信能力も、
100 MB/hour
しかなければ、
新規Data発生
100 MB/hour
送信
100 MB/hour
となります。
これでは、新しいDataを送るだけで送信能力をすべて使ってしまいます。
通信断中に溜まったBacklogは減りません。
したがって、
送信可能量
>
通常のData発生量
である必要があります。
7. 「何時間で追いつくか」を計算する
例えば、
通常Data発生量
100 MB/hour
Cloud復旧後の送信能力
300 MB/hour
だったとします。
新しく発生するDataへ、
100 MB/hour
必要なので、Backlog解消に使用できるのは、
300 - 100
=
200 MB/hour
です。
6時間の通信断で、
600 MB
溜まっている場合、
600 MB
÷
200 MB/hour
=
3時間
となります。
つまり、
08:00
Cloud Reconnect
↓
11:00頃
Backlog Clear
です。
このため、
何時間Offlineに耐えられるか
と、
Cloud復旧後、何時間で追いつけるか
は別の指標として確認した方がよいです。
8. 「Connected」だけで復旧判定しない
Monitoring側でも、復旧を1段階にしない方が分かりやすくなります。
例えば、
NORMAL
↓
CLOUD DISCONNECTED
↓
BUFFERING
↓
CLOUD RECONNECTED
↓
RESENDING
↓
BACKLOG CLEARED
↓
NORMAL
という状態管理です。
CloudとのConnectionが復旧しても、
6時間分のDataを再送中
なのであれば、まだ完全なNormalとは言えません。
Cloud Reconnected
≠
System Recovered
です。
9. 欠落を確認するためMessage IDやSequenceを持たせる
障害試験では、
通信断中に発生したDataが本当にすべてCloudへ届いたか
を確認する必要があります。
そのため、可能であればDataへ、
Message ID
Sequence Number
Timestamp
Device ID
などを持たせます。
例えば、
10001
10002
10003
10004
10005
まで送信されている状態で通信を切断し、
10006
10007
10008
10009
がOffline中に発生したとします。
復旧後、Cloud側で、
10001
10002
10003
10004
10005
10006
10007
10008
10009
まで確認できれば、Sequence上の欠落はありません。
10. Duplicateも確認する
確認するのは欠落だけではありません。
IoT EdgeのMessage Routingは、少なくとも1回の配信を保証する仕組みなので、受信側ではDuplicateの可能性も考慮します。
例えば、
10001
10002
10003
10003
10004
となっていれば、
10003
が重複しています。
そのためCloud側でも、
Message ID
Sequence Number
などを使って、
Missing
Duplicate
を確認できるようにしておくと障害試験がしやすくなります。
11. 実際にやっておきたい障害試験
Store-and-Forwardは設定だけを見るのではなく、実際に通信を切って確認します。
Test 1：短時間のCloud Disconnect
まずは5分程度です。
正常通信
↓
Cloud通信を遮断
↓
Dataを発生
↓
Cloud通信を復旧
通信断中に、
Application Moduleが停止しない
edgeHubが動作している
Dataが保持される
Storage使用量が増える
ことを確認します。
復旧後は、保存されたDataがIoT Hubへ送信されることを確認します。
Test 2：長時間のDisconnect
次に、
30分
1時間
3時間
6時間
などへ延ばします。
それぞれについて、
Disconnect Duration
Generated Messages
Storage Increase
Reconnect Time
Backlog Clear Time
Missing
Duplicate
を記録します。
例えば、
Disconnect:
3 hours
Generated:
10,800 messages
Recovered:
10,800 messages
Missing:
0
Duplicate:
0
Backlog Clear:
18 minutes
のように数字で残します。
Test 3：Cloud断中にIoT EdgeをRestart
さらに、
Cloud Disconnect
↓
Data蓄積
↓
IoT Edge Restart
↓
CloudはまだDisconnect
↓
Data発生継続
↓
Cloud Restore
を試します。
ここで確認したいのは、
Restart前に保持していたDataが残っているか
です。
Production環境では、edgeHubやedgeAgentの状態をContainer内部だけへ依存させず、Host側のPersistent Storageへ保存する構成が重要になります。
Test 4：Cloud断中にOSをReboot
24時間365日の無人Edge PCでは、OS Rebootも現実的なFailureとして考えます。
Cloud Disconnect
↓
Data蓄積
↓
OS Reboot
↓
Ubuntu起動
↓
IoT Edge起動
↓
CloudはまだDisconnect
↓
Cloud Restore
通信断単体だけでなく、
通信断
+
Restart
でもDataが保持できることを確認します。
Test 5：Backlogが0になるまで確認
最後に、
Cloud Restore
だけを確認して終わらせないようにします。
Cloud Restore
↓
Backlog送信開始
↓
Queue減少
↓
Backlog Clear
↓
通常Dataのみ
まで確認します。
記録する時刻も、
Reconnect Time
Backlog Clear Time
の2つを分けます。
12. 試験中に確認するコマンド
Moduleの状態は、
iotedge list
で確認できます。
edgeHubのLogは、
iotedge logs edgeHub --since 30m
で確認できます。
通信やMessage関連に絞るなら、
iotedge logs edgeHub --since 30m 2>&1 | \
grep -Ei 'cloud|connect|disconnect|message|store|queue'
のように確認できます。
Disk全体は、
df -h
Persistent Storageを割り当てている場合は、
sudo du -sh <edgeHubのHost Storage Path>
も確認します。
つまり、障害試験では、
Network
edgeHub
Application
Message
Storage
Cloud
を同時に見ます。
13. 「Disk 80%」だけではなく「あと何時間」を監視する
通常のDisk Monitoringでは、
70%
80%
90%
のようなThresholdを設定します。
もちろんこれも必要ですが、Store-and-Forwardでは、
Remaining Buffer Time
という考え方も有効です。
例えば、
Store-and-Forward用空き容量
3 GB
現在のData増加量
150 MB/hour
なら、
3000
÷
150
=
約20時間
です。
つまり、
Disk Usage: 75%
だけではなく、
Remaining Buffer Time:
約20時間
と判断できます。
Cloud通信断が発生している時に、
通信断開始
02:00
現在
08:00
経過
6時間
残り保持可能時間
約18時間
と分かれば、
今すぐ現地対応が必要か
Network復旧を待てるか
Data保持Limitが近いか
を判断しやすくなります。
14. 最終的には試験結果を数字で残す
例えば、次のように結果を残します。
Cloud Disconnect Test
Disconnect Duration:
6 hours
Generated Messages:
21,600
Recovered Messages:
21,600
Missing:
0
Duplicate:
0
Storage Increase:
1.4 GB
Disk Remaining:
42 GB
Reconnect:
08:00
Backlog Cleared:
08:37
Recovery Time:
37 minutes
単に、
Store-and-Forward OK
と記録するよりも、
6時間のCloud DisconnectでもData欠落がなく、Cloud復旧後37分でBacklogが解消した
と説明できる方が、SystemのReliabilityを判断しやすくなります。
まとめ
Azure IoT EdgeのStore-and-Forwardを24時間365日の無人運用で使用するなら、
Store-and-Forwardが有効
だけではなく、
何時間Dataを保持できるか
Diskはどれくらい必要か
TTLは十分か
RestartしてもDataが残るか
Cloud復旧後に何分で追いつくか
Missingがないか
Duplicateがないか
まで確認しておく必要があります。
特に重要なのは、
Cloud Reconnected
≠
完全復旧
という点です。
Cloud Disconnect
↓
Buffering
↓
Cloud Reconnect
↓
Resending
↓
Backlog Clear
↓
Normal
まで確認して、初めて復旧と判断できます。
またDisk容量も、
あと何GBあるか
だけではなく、
現在のData量なら
あと何時間保持できるか
へ変換すると、障害時の判断材料として使いやすくなります。
Store-and-Forwardを単なるAzure IoT Edgeの機能としてではなく、
「何時間の通信断に耐えられるのか」を数字で説明できる運用設計
として扱うことがポイントです。