ドキュメントのこの部分では、FogFlow の概念的な概要と、インスタンスの開発で FogFlow を使用する方法について説明します。 FogFlow は、動的な NGSI ベース (Next Generation Service Interface - based) のデータ処理フローをプロデューサーとコンシューマーの間でオンデマンドで調整し、タイムリーな結果を提供して迅速なアクションを実行するためのクラウドおよびエッジ環境です。コンテキストプロデューサーはセンサーベースのデバイスですが、コンシューマーは何らかのアクションを実行するコマンドを受信するアクチュエータデバイスです。

FogFlow は、分散型で自律的な方法で IoT サービスオーケストレーションの決定を実行できます。つまり、各 FogFlow エッジノードは、ローカルコンテキストビューに基づいてのみ独自の決定を行うことができます。このようにして、ワークロードの大部分は、常に中央のクラウドに依存することなく、エッジで直接処理できます。この "cloudless" アプローチにより、FogFlow は高速な応答時間を提供するだけでなく、高いスケーラビリティと信頼性を実現します。

FogFlow ベースのインスタンスを定義してトリガーするには、このドキュメントのインテントベースのプログラミングモデル (Intent based programming model) の部分を参照してください。

1. コアコンセプト¶

1.1. オペレーター (Operator)¶

FogFlow では、オペレーターは、リスニングポートを介して NGSI10 ノーティファイメッセージとして特定の入力ストリームを受信し、受信したデータを処理し、特定の結果を生成し、生成された結果を NGSI10 アップデートとして公開するタイプのデータ処理ユニットを提示します。

オペレーターの実装は、少なくとも1つの Docker イメージに関連付けられています。さまざまなハードウェアアーキテクチャ (64ビットまたは32ビットの x86 および ARM など) をサポートするために、同じオペレーターを複数の Docker イメージに関連付けることができます。

1.2. タスク(Task)¶

タスクは、サービストポロジー内の論理データ処理ユニットを表すデータ構造です。各タスクはオペレーターに関連付けられています。タスクは、次のプロパティで定義されます。

name: このタスクを表示するための一意の名前。
operator: 関連するオペレーターの名前。
groupBy: タスクインスタンスの単位を制御するための粒度。サービスオーケストレーターが作成する必要のあるタスクインスタンスの数を決定するために使用されます。
input_streams: 選択された入力ストリームのリスト。各入力ストリームはエンティティタイプによって識別されます。
output_streams: 生成された出力ストリームのリスト。各ストリームはエンティティタイプによって識別されます。

FogFlow では、各入力/出力ストリームは、NGSI コンテキストエンティティのタイプとして表されます。これらは通常、エンドポイントデバイスまたはデータ処理タスクのいずれかによって生成および更新されます。

実行時に、groupBy プロパティで定義された粒度に従って、同じタスクに対して複数のタスクインスタンスを作成できます。どの入力ストリームがどのタスクインスタンスに送られるかを決定するために、タスクの入力ストリームを指定するために次の2つのプロパティが導入されています。

Shuffling: タスクの各タイプの入力ストリームに関連付けられています。その値は、ブロードキャスト (broadcast) またはユニキャスト (unicast) のいずれかです。
- broadcast: 選択した入力ストリームは、このオペレーターのすべてのタスクインスタンスに繰り返し割り当てられる必要があります
- unicast: 選択した各入力ストリームは、特定のタスクインスタンスに1回だけ割り当てる必要があります。
Scoped: 入力ストリームを選択するために要件のジオスコープを適用する必要があるかどうかを決定します。その値は true または false のいずれかです。

1.3. タスクインスタンス (Task Instance)¶

実行時に、タスクは入力データと指定された出力タイプを使用して FogFlow によって構成され、構成されたタスクは Docker コンテナーで実行されるタスクインスタンスとして起動されます。現在、各タスクインスタンスは、クラウドまたはエッジノードのいずれかで専用の Docker コンテナーにデプロイされています。

1.4. サービステンプレート (Service Template)¶

各 IoT サービスは、サービステンプレートによって記述されます。サービステンプレートは、リンクされたオペレーターのセットを備えたサービストポロジー、または単一のオペレーターを備えたフォグファンクションです。たとえば、サービストポロジーを使用してサービステンプレートを指定すると、次の情報が含まれます。

topology name: トポロジーの一意の名前。
service description: このサービスの内容を説明するテキスト。
priority: トポロジー内のすべてのタスクの優先度レベルを定義します。これは、リソースをタスクに割り当てる方法を決定するためにエッジノードによって使用されます。
resource usage: このトポロジーのタスクがエッジノードのリソースを排他的に使用できるかどうかを定義します。つまり、他のトポロジーのタスクとリソースを共有しないことを意味します。

現在、FogFlow は、開発者が設計フレーズ中にサービストポロジーまたはフォグファンクションを簡単に定義して注釈を付けることができるグラフィカルエディタを提供しています。

1.5. 動的データフロー (Dynamic data flow )¶

要件を受け取ると、トポロジーマスターはデータフロー実行グラフを作成し、それらをクラウドとエッジにデプロイします。主な手順は、2つの主要なステップを含む次の図に示されています。

service topology から execution plan に: トポロジーマスターのタスク生成アルゴリズムによって実行されます。

生成された実行プラン (execution plan) には次のものが含まれます: 1）サービストポロジー (service topology) のどの部分がトリガーされるか。 2）トリガーされたタスクごとに作成する必要のあるインスタンスの数。 3）および各タスクインスタンスをその入力ストリームと出力ストリームでどのように構成するか。
execution plan から deployment plan に: トポロジーマスターのタスク割り当てアルゴリズムによって実行されます。

生成された展開計画 (deployment plan) は、特定の最適化の目的に従って、どのタスクインスタンスをどのワーカー (クラウド内またはエッジ) に割り当てるかを決定します。現在、FogFlow のタスク割り当ては、エッジノードに過負荷をかけることなくノード間のデータトラフィックを削減するように最適化されています。

2. FogFlow ストレージ (FogFlow Storage)¶

以前は、FogFlow はその内部データ構造を使用して、オペレーター、フォグファンクション、Docker イメージ、サービストポロジーなどの FogFlow 内部エンティティを格納していました。FogFlow は、FogFlow 内部 NGSI エンティティを格納するための永続ストレージをサポートしていませんでした。したがって、FogFlow Broker がダウンするたびに、保存されているすべての内部エンティティが失われます。したがって、この問題を解決するために、FogFlow は Dgraph という名前の永続ストレージを使用しています。

永続ストレージは、そのデバイスへの電源が遮断された後もデータを保持するデータストレージデバイスです。不揮発性ストレージと呼ばれることもあります。

Dgraph データモデルは、データセット、レコード、および属性で構成されています。ここで、レコードは Dgraph のデータの基本単位であり、属性はレコードスキーマの基本単位です。属性 (キーと値のペアとも呼ばれます) からの割り当ては、Dgraph のレコードを記述します。永続ストレージを使用したデータのフロー図は次のとおりです:

FogFlow のユーザーは、デザイナーを介して Web ブラウザーを使用して FogFlow 内部エンティティーを作成できます。
FogFlow のユーザーは、Designer を介してclient (curl) を使用して FogFlow 内部エンティティを作成できます。
Designer は、必要に応じて、作成されたエンティティを Dgraph データベースに保存して取得できます。
Designer は、Dgraph データベースから古い登録済みエンティティを取得し、Cloud Broker に登録できます。

グラフデータベースをサポートする利用可能なデータベースはたくさんあります。たとえば、Neo4j です。Dgraph はデータベースの使用率が最も高いデータベースの1つです。FogFlow は Dgraph を使用しています。Dgraph を選択した理由は次のとおりです:

Dgraph は、グラフデータの読み込みに関して Neo4j より160倍高速です。
Dgraph は、Neo4j と比較して5分の1のメモリを消費します。
Dgraph は、ジョブ (job) を遂行するために必要なほとんどの機能をサポートしています。

1. コア コンセプト¶