Ethernet・Wi-Fi・セルラーのフェイルオーバー：受入試験で確認すべきこと

産業用IoTゲートウェイでは、Ethernetリンク、Wi-Fi接続、セルラーネットワークへの登録が正常と表示されていても、テレメトリが宛先に届かなくなっている場合があります。そのため、有効なEthernet・Wi-Fi・セルラーのフェイルオーバー受入試験では、データの取得から合意したアプリケーションエンドポイントまで、1件のレコードを追跡します。配信できない間と、優先ネットワークが復旧したときの動作も検証します。

以下は、プロジェクト固有の受入要件を作成するための枠組みです。Obeita製品の実測性能や保証された機能を説明するものではありません。

接続を切る前に、配信に関する取り決めを定義する

対応インターフェース、優先順位、許容するセルラー使用量、切戻しを自動・手動・スケジュールのいずれで行うかを合意します。優先順位はEthernet、Wi-Fi、セルラーの順である必要はありません。共通の依存先を特定します。同じ上流ルーター、DNSサービス、バックエンドを利用する2つのインターフェースは、同時に障害が発生する可能性があります。

隔離された試験環境、承認済みの障害注入方法、復旧手順、代表的なペイロード、実際に使用するファームウェアと設定を準備します。アクセスポイントの設定、SIM/APNと通信事業者、IPバージョン、ルーティングとファイアウォールのルール、DNS設定、ブローカー設定、証明書要件を記録します。設定のエクスポートは、認証情報を含めず、機密情報を除去したものを使用します。

ゲートウェイ、ネットワーク、ブローカー、最終コンシューマーを計測できるようにします。各試験レコードに、一貫したイベント識別子、発生元タイムスタンプ、シーケンス番号を付与します。時計を同期してその不確かさを記録し、ローカルでの経過時間には単調時計を使用します。成功とはブローカーによる確認応答、データベースへの永続化、または別の観測可能な業務上の結果のいずれなのかを定義します。

リンク表示だけでなく、経路全体の健全性を試験する

ローカル接続、アドレス設定とルーティング、DNS、TCP/TLS、ブローカーへのアクセス、アプリケーション処理をそれぞれ分けて確認します。pingではDNSやブローカーは検証されません。TLSハンドシェイクの成功も、テレメトリレコードが処理されたことの証明にはなりません。

NetworkManagerを使用するゲートウェイでは、文書化されている接続性チェックは、設定されたURIにリクエストを送り、応答を評価します。この結果が示すのは、その設定されたチェックが成功したということだけであり、アプリケーションの受入試験にはなりません。接続性の監視が有効だと思い込まず、設定を確認してください。詳細はNetworkManagerの接続性に関するリファレンスを参照してください。

候補となる各経路を、想定したインターフェースとルートを通してプローブし、DNSの動作も確認します。そうしないと、正常なアクティブ接続によって待機経路の故障が隠れることがあります。特定経路の障害と、すべての経路が共有するバックエンドの停止を区別します。インターフェースを何度切り替えても、共通サービスの障害は修復できません。

切替と切戻しの判断を明確にする

プローブの対象、間隔、タイムアウト、連続失敗のしきい値、バックアップ経路の準備確認、再試行のバックオフ、最小滞在時間を指定します。優先リンクに戻る前に必要な正常プローブのしきい値、または安定継続時間を設定します。このヒステリシスにより、短時間の復旧で切替が繰り返されるのを防ぎます。

障害の種類ごとに、期待する対応を文書化します。例えば、WANのブラックホールは経路変更の理由になり得ますが、アプリケーション全体での拒否には、別のアラームと上限を設けた再試行で対応するべきです。無効な証明書はエラーとして扱い続け、検証を無効にするきっかけにしてはいけません。TLS 1.3では証明書関連のエラーアラートが定義されています。その原因は、到達性確認のタイムアウトとは区別して記録します。

接続の変化を想定し、データの復旧を検証する

アクセスネットワークを変更すると、送信元アドレスやNATマッピングが変わる場合があります。通常のTCPは両端のソケットによって接続を識別し、その仕様はRFC 9293に定められています。ルートが変わったというだけでは、既存の接続が維持されるとは判断できません。接続断の検出、TCP再接続、TLS認証、MQTT再接続を明示的に試験します。

MQTTセッションの継続性は、ネットワーク接続とは別のものです。Client ID、Clean Start、Session Expiry Interval、session-presentの処理、再サブスクライブ、送受信処理中のメッセージの動作を確認します。MQTT QoSが規定するのは、1つの送信者と1つの受信者の間の配信です。QoS 1ではメッセージが重複することがあります。QoS 2であっても、それだけで下流のデータベースや機械に「厳密に1回」の作用を保証するわけではありません。これらの適用範囲は、OASIS MQTT 5.0仕様の4.1–4.6節に基づきます。

実際のブローカーが対応する機能を確認します。例えば、AWS IoT Coreの文書ではQoS 0と1に対応し、QoS 2には対応しないことが示されています。試験計画は、採用するサービスに合わせる必要があります。

オフラインバッファリングが必要な場合は、どの時点で永続書き込みが完了したとみなすか、バイト数またはレコード数の上限、保持期間、オーバーフロー時の方針を指定します。未確認のレコードが残っている状態で電源を切り、再投入します。最終コンシューマー側でイベントIDを照合し、重複を冪等に処理できるか試験して、発生元タイムスタンプと到着時刻を別々に保持します。重複排除の対象期間は、許容される最長の再試行・リプレイ間隔をカバーできるように設定します。順序保証は発生元またはストリームごとに定義し、複数のパブリッシャーをまたぐ全体の順序を前提にしてはいけません。新規トラフィックと並行してリプレイを試験し、復旧処理が新しい測定値の処理をいつまでも妨げないことを確認します。

異なる障害モードを明らかにする障害マトリクスを使う

許可されたすべての開始インターフェースから、適用可能な各ケースを実行し、合意したペイロードのレートとサイズで遷移を繰り返します。注入した障害、期待する判断、実際の遷移、アラーム、時間情報、レコードの照合結果を記録します。

アプリケーションの復旧をルート変更とは別に測定する

障害注入、障害判定、バックアップの準備完了、最初の新規イベントの受理、滞留データのリプレイ完了に、それぞれタイムスタンプを記録します。復旧時間に加えて、観測されたアプリケーション配信の最大中断時間を報告します。ルート更新が速くても、再接続の遅延が長かったり、キューが増大したりする場合があります。

説明用の試験例であり、製品ベンチマークではありません：Ethernetを優先経路、セルラーを利用可能なバックアップに設定します。番号付きレコードを生成しながら、キャリアを落とさずにEthernetの上流トラフィックを遮断します。設定した障害しきい値を観測し、トラフィックがセルラー経由で送信されることを確認して、アプリケーション側で新規レコードとバッファ済みレコードを照合します。Ethernetをまず断続的に、次に継続的に復旧させ、合意した切戻しルールを検証します。

顧客は実行前に合否基準値を提示する必要があります。対象は、アプリケーションの最大中断時間、合意したエンドポイントにおける許容レコード損失と重複による作用、バッファ容量、リプレイ完了時間、順序保証の範囲、切替回数上限、セルラーデータの使用量上限、復旧後の安定性確認時間です。試行回数、ワークロード、ネットワーク条件を記録し、実測結果や契約上の要件を例示の数値で置き換えてはいけません。

受入チェックリスト

• トポロジー、配信先エンドポイント、障害マトリクス、測定可能な限度値を承認する。
• 遷移を試験する前に、利用条件を満たすすべてのバックアップを個別に検証する。
• インターフェースの状態だけでなく、判断理由とタイムスタンプを記録する。
• 復旧後に、欠落、重複、期限切れ、順序違反のレコードを照合する。
• 電源断、全経路停止、継続的な復旧後の切戻しを繰り返し試験する。
• 承認に備えて、設定バージョン、ログ、証跡、逸脱事項を保管する。

ゲートウェイのフェイルオーバーレビューを準備する

機密情報を除去したネットワークトポロジー、インターフェースの優先順位、受入限度値、代表的なサンプルペイロードを用意し、産業用IoTゲートウェイの要件をObeitaにご相談ください。共有前に、認証情報、非公開エンドポイント、本番環境の識別子を削除してください。これらの情報があれば、未対応の機能を前提にせずに、必要な動作と試験範囲を検討できます。

関連する統合範囲については、納入済みのマルチインターフェースIoTゲートウェイ統合プロジェクト（英語）をご覧ください。組み込みシステムの調査については、Obeitaのファームウェア・BSP診断サービスをご参照ください。プロジェクト固有の受入計画の策定は、Obeitaにお問い合わせください。