5. 可用性¶

IoT Connectivity Engineの可用性の考え方について説明します。

プロセス

ICE Backend一般

ICEではICE Backend の各サービスについて、外部のプロセス監視によって制御されることを想定しています。すなわち、各サービスが何らかの原因でダウンした際、ICE自身によるサービス再起動は行わず、外部のプロセス監視とリカバリ機能によって速やかにサービス再起動がなされる事を想定しています。
ICE Core

ICE外部のプロセス監視やウォッチドッグタイマで再起動されることを想定しています。
Privileged Application、Edge Application、Device Adapter

これらはICE Coreによってプロセス監視され、停止を検出すれば速やかに再起動されます。

End To End のメッセージング

非同期処理

ICEを流れる全てのデータは非同期で通信が行われます。
送達保証

ICEによるメッセージの送達保証は、データの流れる方向により異なります。
- ICE Core から ICE Backend
  
  ICE Coreでデバイスから収集したセンサデータは、ICE Backendへの送達確認ができるまで ICE Coreプロセス内の有限の送信バッファに保存され、送達確認できるまで再送されます。
  
  ICE CoreとICE Backend間のネットワーク障害などにより、このバッファが溢れた場合はあふれた分のデータ(デフォルトでは古いデータ)が破棄されます。
  
  通信の障害が発生したタイミングによっては、再送処理により ICE Backendに同じデータが複数送信されることがあります。 (再送の制御は、ICE CoreからMQTT/MQTTSプロトコルによる通信を選択した場合に有効です)
  
  また、ICE Backend内でData Storeに異常が発生しMessage Routerによる書き込みが失敗すると、Message Routerが定期的にリトライします。その間に到着したデータはMessage Broker内にバッファリングされ、上限に達するとICE CoreからMessage Brokerに対する送信が失敗します。その結果、ICE Core側の送信バッファにも滞留し始めます。
  
  【OP-Addon】
  
  データの送信成功/失敗をアプリケーションに通知します。バッファが溢れてデータ削除されたことを検知できるようになります。
- ICE Backend から ICE Core
  
  ICE Backend から ICE Coreに対するメッセージの送信に対する送達保証はありません。 ICE Core停止時や、ネットワーク障害などの影響でICE Backendからの指示がICE Coreに届かないケースがあり得ます。
  
  また、ICE Backend API、MongoDB、FileServer、RabbitMQ これらのサービスの停止中にクライアントから ICE Backend API に HTTPリクエストを行うとエラーが返却されます。エラーレスポンスを受け取った各クライアントはリトライすることでサービス復旧後にリクエストを完遂することができます。
順序保証

ICEはメッセージに対する順序制御はありません。

障害が発生していないほとんどのケースでは、送信された順序で通信が行われますが、再送処理中には再送データと新規データの送信が並行で実行されるため、新旧のデータが混在してICE Backendに到着することがあります。

【OP-Addon】

再送処理時にもデータ送信順序が保証されるようになり、通信障害が発生した場合でもデータ投入順通りにデータを送信します。
優先度制御

ICEはメッセージに対する優先度制御はありません。