これは、FIWARE FogFlow の入門チュートリアルであり、ユーザがエッジで処理フローを動的に調整できるようにします。分散または単一ノード・システムで FogFlow を有効にし、ユーザ定義のワークロード・パターンを登録し、実行中のタスクの形でエッジでそれらを調整する方法を説明します。理解を深めるために、チュートリアルに例が含まれています。

クラウド-エッジ・コンピューティング (Cloud-Edge Computing)¶

チュートリアルの目的は、IoT センサ・デバイスがコンテキスト・データを FogFlow に送信する方法、FogFlow がアクチュエータ・デバイスを介して環境を変更する処理フローをいつ、どこで開始するかをユーザに教えることです。以下の図は、シナリオの概要を示しています。センサ、アクチュエータ、動的処理フローについては、このチュートリアルの後続のセクションで説明します。これらのセクションは、以下の図に関連しています。

ユーザがシナリオを FogFlow に提供します。これには、何をすべきか、いつすべきかが含まれます。FogFlow はどこを行うべきかを理解します
センサは定期的にコンテキスト・データを FogFlow に送信します。データには、温度、ビデオ・ストリーミング、写真などの環境データが含まれる場合があります
FogFlow は、エッジでの処理フローをすぐに調整します。これらの処理フローは、アクチュエータの状態を変更したり、一部のデータを FogFlow にパブリッシュしたりする可能性があります。それはすべて、ユーザが実行したいことに関するものです。

アーキテクチャ ¶

FogFlow フレームワークは、クラウド・ノード、エッジ・ノード、IoT デバイスを含む、地理的に分散した階層型の異種 ICT インフラストラクチャで動作します。次の図は、3つの論理層にわたる FogFlow とその主要コンポーネントのシステム・アーキテクチャを示しています。

レイヤード・アーキテクチャ (Layered Architecture)¶

論理的には、FogFlow は次の3つのレイヤーで構成されています。

サービス管理: サービス要件を具体的な実行プランに変換し、生成された実行プランをクラウドとエッジに展開します。タスク・デザイナ、トポロジ・マスタ、および Docker レジストリ・サービスは、サービス管理レイヤーを構成します
コンテキスト管理: すべてのコンテキスト情報を管理し、柔軟なクエリおよびサブスクライブ・インターフェイスを介してそれらを検出およびアクセス可能にします。このレイヤーは、Context Brokers と IoT Discovery で構成されています
データ処理: データ処理タスクを起動し、コンテキスト管理レイヤによって提供される pub/sub インターフェースを介してタスク間のデータ・フローを確立します。エッジ・ワーカ (そして、もちろんクラウド・ワーカ) はこのレイヤーの下にあります

FogFlow クラウド・ノードの起動 ¶

クラウド・ノードを起動するための前提条件は次のとおりです :

Docker: インストールについては、こちらを参照してください。必要なバージョン > 18.03.1-ce;
Docker-Compose: インストールについては、こちらを参照してください。必要なバージョン > 2.4.2;

重要: また、ユーザが sudo なしで Docker コマンドを実行できるようにしてください。

FogFlow クラウド・サービスのインストールを開始するには、次の操作を行います :

現在の環境に応じて、config.json の次の IP アドレスを変更します
- my_hostip: FogFlow クラウド・ノードのパブリック IP アドレス
- site_id: FogFlow システムのノードを識別するための一意の文字列ベースの ID
- physical_location: ノードの地理的位置
- worker.capacity: これは、FogFlow ノードが呼び出すことができる Docker コンテナの最大数を意味します。デフォルトでは、その値は "8" です

{
    "my_hostip": "10.156.0.9",
    "physical_location": {
        "longitude": 139.709059,
        "latitude": 35.692221
    },
    "site_id": "001",
    "worker": {
        "container_autoremove": false,
        "start_actual_task": true,
        "capacity": 8
    }
}

重要 !¶

my_hostip の IP アドレスとして "127.0.0.1" を使用しないでください。これは、 Docker コンテナ内で実行中のタスクにのみアクセスできるためです。

ファイアウォール・ルール: FogFlow Web ポータルにアクセスできるようにするには、TCP 経由でポート 80 および 5672 を開く必要があります。

Mac ユーザ: Macbook で FogFlow をテストする場合は、Docker デスクトップをインストールし、構成ファイルの my_hostip として "host.docker.internal" も使用してください。

ポート番号を変更する必要がある場合は、変更がこれら3つの構成ファイルすべてで一貫していることを確認してください。

FogFlow コンポーネントの Docker イメージをプルして起動します

git clone https://github.com/FIWARE/tutorials.Edge-Computing.git
cd tutorials.Edge-Computing
git checkout NGSI-v2

docker-compose pull
docker-compose up -d

次の2つの方法のいずれかで FogFlow クラウド・ノードのセットアップを検証します
docker ps -a を使用して、すべてのコンテナが稼働していることを確認します

docker ps -a

CONTAINER ID   IMAGE                   COMMAND                  CREATED         STATUS         PORTS                                                                                            NAMES
e412877b4862   nginx:latest            "/docker-entrypoint.…"   2 minutes ago   Up 2 minutes   0.0.0.0:80->80/tcp                                                                               tutorialsedgecomputing_nginx_1
29ea8555685d   fogflow/master:3.2      "/master"                2 minutes ago   Up 2 minutes   0.0.0.0:1060->1060/tcp                                                                           tutorialsedgecomputing_master_1
aaa2f29959e7   fogflow/worker:3.2      "/worker"                2 minutes ago   Up 2 minutes                                                                                                    tutorialsedgecomputing_cloud_worker_1
1298fe46bf1e   fogflow/designer:3.2    "node main.js"           2 minutes ago   Up 2 minutes   0.0.0.0:1030->1030/tcp, 0.0.0.0:8080->8080/tcp                                                   tutorialsedgecomputing_designer_1
644333fa6215   fogflow/broker:3.2      "/broker"                2 minutes ago   Up 2 minutes   0.0.0.0:8070->8070/tcp                                                                           tutorialsedgecomputing_cloud_broker_1
acd974d6c040   fogflow/discovery:3.2   "/discovery"             2 minutes ago   Up 2 minutes   0.0.0.0:8090->8090/tcp                                                                           tutorialsedgecomputing_discovery_1
cce2c64503d9   dgraph/standalone       "/run.sh"                2 minutes ago   Up 2 minutes   0.0.0.0:6080->6080/tcp, 0.0.0.0:8000->8000/tcp, 0.0.0.0:8082->8080/tcp, 0.0.0.0:9082->9080/tcp   tutorialsedgecomputing_dgraph_1
925d1deb343f   rabbitmq:3              "docker-entrypoint.s…"   2 minutes ago   Up 2 minutes   4369/tcp, 5671/tcp, 15691-15692/tcp, 25672/tcp, 0.0.0.0:5672->5672/tcp                           tutorialsedgecomputing_rabbitmq_1

http://<coreservice_ip>/index.html にある FogFlow ダッシュボードからシステム・ステータスを確認します。表示される Web ページは下図のとおりです

FogFlow エッジ・ノードの起動 ¶

エッジ・ノードを起動するための前提条件は次のとおりです :

Docker: Raspberry Piに Docker CE をインストールする方法を参照してください。

インストールを開始するには、次のようにします。

クラウド・ノードと同様に構成ファイルを変更しますが、coreservice_ip はクラウド・ノードの IP アドレスであるため、統一されたままになります。my_hostip はエッジ・ノードのパブリック IP アドレスに変更されます。

{
    "coreservice_ip": "10.156.0.9",
    "my_hostip": "172.17.0.1",
    "physical_location": {
        "longitude": 138.709059,
        "latitude": 36.692221
    },
    "site_id": "002",

    "worker": {
        "container_autoremove": false,
        "start_actual_task": true,
        "capacity": 4
    }
}

Edge IoT Broker と FogFlow Worker の両方を起動します。エッジ・ノードが ARM ベースの場合は、コマンド・パラメータとして arm を追加します。

  ./start.sh

Edge IoT Broker と FogFlow Worker の両方を停止します :

  ./stop.sh

IoT デバイスを FogFlow に接続 ¶

センサ・デバイスからブローカーに向かうデータ・フローはノースバウンド・フローと呼ばれ、ブローカーからアクチュエータ・デバイスにデータ・フローが流れる場合はサウスバウンド・フローと呼ばれます。FogFlow は、この双方向のデータ・フローに依存して、その背後にある実際のアイデアを実現します。

センサ・デバイスからデータを受信するには、 [センサ・デバイスに接続する]((https://fogflow.readthedocs.io/en/latest/integration.html#northbound-integration) を参照してください。チュートリアルには、NGSI デバイスと非 NGSI デバイスの両方の例が含まれています。

FogFlow は、動的な処理フローを通じて、ドアのロック、ランプのスイッチのオン、シールドのオン/オフなど、接続されているアクチュエータ・デバイスの状態を変更できます。アクチュエータ・デバイスに接続するには、アクチュエータ・デバイスと FogFlow の統合を参照してください。このチュートリアルには、NGSI デバイスと非 NGSI デバイス (特に、UltraLight デバイスと MQTT デバイス) の例も含まれています。

サウスバウンドが実際に FIWARE のコンテキストでどのように機能するかについての基本的なアイデアを得るには、このチュートリアルを参照してください。

FogFlow を使用したエッジでの動的オーケストレーション ¶

先に進む前に、ユーザは以下を確認する必要があります :

Fog ファンクションを定義してトリガー ¶

FogFlow はサーバーレス・エッジ・コンピューティングを可能にします。つまり、開発者は処理ロジック (またはオペレータ) とともに Fog ファンクションを定義および送信でき、残りは FogFlow によって自動的に実行されます :

入力データが利用可能になったときに送信された Fog ファンクションをトリガーします
定義された粒度 (granularity) に従って作成されるインスタンスの数を決定します
作成されたインスタンスまたは処理フローをデプロイする場所を決定します

タスク・オペレータを登録 ¶

FogFlow を使用すると、開発者は登録済みオペレータ内で独自のファンクション・コードを指定できます。いくつかの例とチュートリアルをチェックして、カスタマイズされたオペレータの作成方法を確認してください。

オペレータを作成するための Python, Java, JavaScript テンプレートはこちらにあります。

現在のチュートリアルについては、以下の手順を参照してください:

FogFlow にオペレータを登録するには、次の手順が必要です。

オペレータの登録とは、オペレータの名前と必要な入力パラメータを定義することを意味します。

オペレータを登録するには、FogFlow ダッシュボードを開きます。水平バーから "Operator Registry" タブを選択し、左側のメニューから "Operator Registry" を選択して、"Register" ボタンをクリックします。ワークスペースを右クリックし、ドロップ・ダウン・リストからオペレータを選択して、詳細を入力し、最後に送信をクリックします。

注:

ユーザはオペレータにパラメータを追加できます。オペレータ・アプリケーションのポートを定義するには、"service_port" を使用し、その値として有効なポート番号を指定します。アプリケーションは、このポートを介して外部からアクセスできます。

Docker イメージを登録し、オペレータを選択して、Docker イメージを定義し、すでに登録されているオペレータを関連付けます。次の図は、登録済みの Docker イメージのリストと各イメージの重要な情報を示しています。

"register" ボタンをクリックして必要事項を入力し、"register" ボタンをクリックして登録を完了します。

フォームは次のように説明されます。

Image: オペレータの Docker イメージの名前。[Docker Hub] に公開するものと一致している必要があります
Tag: オペレータの Docker イメージの公開に使用したタグ。デフォルトでは "latest" です
Hardware Type: x86 または ARM (Raspberry Pi など) を含む、Docker イメージがサポートするハードウェア・タイプ
OS Type: Docker イメージがサポートするオペレーティング・システム・タイプ。現在、これは Linux に限定されています
Operator: オペレータ名。一意である必要があり、サービス・トポロジを定義するときに使用されます
Prefetched: これがチェックされている場合、すべてのエッジ・ノードがこの Docker イメージを事前にフェッチし始めます。それ以外の場合、エッジ・ノードがこのオペレータに関連付けられたスケジュールされたタスクを実行する必要がある場合にのみ、オペレータの Docker イメージがオンデマンドでフェッチされます

"dummy" Fog ファンクションを定義 ¶

タスク・デザイン・ボード内を右クリックすると、次のようなメニューが表示されます :

Task: Fog ファンクション名と処理ロジック (またはオペレータ) を定義するために使用されます。タスクには入力ストリームと出力ストリームがあります
EntityStream: 入力データストリームとして Fog ファンクション・タスクとリンクできる入力データ要素です

"Task" を選択すると、以下に示すように、タスク・エレメントがデザイン・ボードに配置されます。

次の図に示すように、タスク要素の右上隅にある設定ボタン (configuration button) をクリックします。タスクの名前を指定し、いくつかの事前登録されたオペレータのリストからオペレータを選択します。

ポップアップ・メニューからデザイン・ボードに "EntityStream" を追加します。

次のフィールドが含まれます :

Selected Type: は、その可用性が Fog ファンクションをトリガーする入力ストリームのエンティティ・タイプを定義するために使用されます
Selected Attributes: は、選択されたエンティティ・タイプに対して、Fog ファンクションに必要なエンティティ属性。 "all" は、すべてのエンティティ属性を取得することを意味します
Group By: は、選択されたエンティティ属性の1つである必要があります。これは、この Fog ファンクションの粒度、つまり、この Fog ファンクションのインスタンスの数を定義します。この例では、粒度は "id" で定義されています。つまり、 FogFlow は個々のエンティティ ID ごとに新しいタスク・インスタンスを作成します
Scoped: は、エンティティ・データが場所固有 (location-specific) かどうかを示します。True は、場所固有のデータがエンティティに記録され、ブロードキャスト・データの場合は False が使用されることを示します。たとえば、特定の場所ではなく、すべての場所に true を保持するルールまたはしきい値データがあります。

以下に示すように、設定ボタンをクリックして EntityStream を構成します。ここでは例として、"Temperature" を示していますが、 "dummy" Fog ファンクションの入力データのエンティティ・タイプも同様です。

タスクには複数の EntityStream が存在する可能性があり、それらは以下に示すようにタスクに接続されている必要があります。

Fog ファンクションを送信します。

"dummy" Fog ファンクションをトリガー ¶

定義された "dummy" フォグ機能は、必要な入力データが利用可能な場合にのみトリガーされます。

1つの方法は、以下に示すように "Temperature" センサ・デバイスを登録することです。

System Status タブの Device メニューに移動します。以下の情報を提供します。

Device ID: 一意のエンティティ ID を指定します
Device Type: エンティティ・タイプとして "Temperature" を使用します
Location: 地図上に場所 (a location) を配置します

デバイス・プロファイルが登録されると、新しい "Temperature" センサ・エンティティが作成され、"dummy" Fog ファンクションが自動的にトリガーされます。

Fog ファンクションをトリガーするもう1つの方法は、POST リクエストの形式で NGSI エンティティの更新を FogFlow broker に送信して、"Temperature" センサ・エンティティを作成することです。

1 リクエスト:¶

curl -iX POST \
  'http://localhost:8080/ngsi10/updateContext' \
  -H 'Content-Type: application/json' \
  -d '{
    "contextElements": [
        {
            "entityId": {
                "id": "Device.temp001", "type": "Temperature", "isPattern": false
            },
            "attributes": [
                {
                  "name": "temp", "type": "integer", "value": 10
                }
            ],
            "domainMetadata": [
            {
                "name": "location", "type": "point",
                "value": {
                    "latitude": 49.406393,
                    "longitude": 8.684208
                }
            }
            ]
        }
    ],
    "updateAction": "UPDATE"
}'

次の方法で Fog ファンクションがトリガーされているかどうかを確認します。

次の図に示すように、この Fog ファンクションのタスク・インスタンスを確認します

次の図に示すように、実行中のタスク・インスタンスによって生成された結果を確認します

サービス・トポロジを定義してトリガー ¶

サービス・トポロジは、いくつかのオペレータのグラフとして定義されます。サービス・トポロジの各オペレータには、入力と出力の注釈が付けられています。これは、同じトポロジの他のタスクへの依存関係を示しています。

Fog ファンクションとは異なり、サービス・トポロジはオンデマンドでカスタマイズされた "intent" オブジェクトによってトリガーされます。

簡単な異常検出の使用事例の調査は、開発者がサービス・トポロジを定義およびテストするのに役立ちます。

この使用事例は、小売店が異常なエネルギー消費をリアルタイムで検出するためのものです。次の図に示すように、小売企業にはさまざまな場所に多数のショップが分散しています。ショップごとに、Raspberry Pi デバイス (エッジ・ノード) が展開され、ショップ内のすべての電源パネルからの電力消費を監視します。店舗 (またはエッジ) での異常な電力使用を検出すると、店舗のアラーム・メカニズムがトリガーされ、店舗の所有者に通知します。さらに、検出されたイベントは情報集約のためにクラウドに報告されます。集約された情報は、ダッシュボード・サービスを介してシステム・オペレータに提示されます。さらに、システム・オペレータは異常検出のルールを動的に更新できます。

オペレータ・ファンクションを実装 ¶

この特定の使用例では、FogFlow にすでに登録されている anomaly と counter の2つのオペレータが使用されています。コード・リポジトリで提供されている例を参照してください。

Anomaly Detector オペレータは、小売店の電源パネルから収集されたデータに基づいて異常イベントを検出します。2つのタイプの入力があります
- 検出ルールは、オペレータによって提供および更新されます。検出ルールの入力ストリーム・タイプは broadcast に関連付けられています。つまり、このオペレータのすべてのタスク・インスタンスでルールが必要です。このオペレータの粒度は shopID に基づいています。つまり、専用のタスク・インスタンスが各ショップに対して作成および構成されます
- センサ・データは電源パネルから提供されます
Counter オペレータは、各都市のすべての店舗の異常イベントの総数をカウントします。したがって、そのタスクの粒度は "都市" によるものです。その入力ストリーム・タイプは、前のオペレータ (Anomaly Detector) の出力ストリームタイプです

結果コンシューマ (result consumers) には2つのタイプがあります :

クラウド内のダッシュボード・サービス。グローバル・スコープの Counter オペレータによって生成された最終的な集計結果にサブスクライブします
各店舗のアラーム。小売店のローカル・エッジ・ノードの Anomaly Detector タスクによって生成された異常イベントにサブスクライブします

サービス・トポロジを指定 ¶

サービス・トポロジで使用されるタスクが実装および登録されていると仮定し、FogFlow トポロジ・エディタを使用して次の方法でサービス・トポロジを指定します。

図のように、次の重要な情報を提供する必要があります。

以下を含むトポロジ・プロファイルを定義します。
- topology name: トポロジの一意の名前
- service description: このサービスについて説明するテキスト
サービス・トポロジ内のデータ処理フローのグラフをデザイン・ボードのどこかで右クリックして描画し、タスクまたは入力ストリームまたはシャッフルを選択して、考えている設計に従ってデータ処理フローを定義します
それぞれの設定ボタンを使用して、以下を含むデータ・フローの各要素のプロファイルを定義します
- Task プロファイルは、名前、オペレータ、エンティティ・タイプを指定して定義できます
- EntityStream プロファイルは SelectedType, SelectedAttributes, Groupby, Scoped fields で更新されます
- Shuffle 要素は2つのタスク間のコネクタとして機能し、タスクの出力は Shuffle 要素の入力であり、同じ要素は Shuffle によって別のタスク (複数可) に入力として転送されます

インテントを送信してサービス・トポロジをトリガー ¶

サービス・トポロジは、次の2つのステップでトリガーできます :

サービス・トポロジを個別のタスクに分割する高レベルのインテント・オブジェクトを送信します
そのサービス・トポロジのタスクに入力ストリームを提供します

インテント・オブジェクトは、次のプロパティを持つ FogFlowダッシュボードを使用して送信されます。

Topology: インテント・オブジェクトが対象とするトポロジを指定します
Priority: トポロジ内のすべてのタスクの優先度レベルを定義します。これは、リソースをタスクに割り当てる方法を決定するためにエッジ・ノードによって利用されます
Resource Usage: トポロジがエッジ・ノードのリソースを使用する方法を定義します。排他的な方法での共有は、トポロジが他のトポロジのタスクとリソースを共有しないことを意味します。もう1つは包括的な方法です
Objective: 最大スループット、最小待ち時間、および最小コストを、ワーカーでのタスク割り当てに設定できます。ただし、この機能はまだ完全にはサポートされていないため、現時点では "None" に設定できます
Geoscope: は、入力ストリームを選択する必要がある定義済みの地理的エリアです。グローバルおよびカスタムのジオスコープを設定できます

インテント・オブジェクトのスコープ内にあるコンテキスト・データを受信するとすぐに、最も近いワーカーでタスクが起動されます。

Anomaly-Detector の使用例の入力ストリームを送信するための Curl の例を次に示します。PowerPanel とルール・データが必要です。

注: ユーザは、シミュレートされた PowerPanel デバイスを使用して、PowerPanel データを送信することもできます。

Curl のケースでは、クラウド IoT Broker がポート 8070 の localhost で実行されていると想定しています。

2 リクエスト:¶

curl -iX POST \
  'http://localhost:8070/ngsi10/updateContext' \
-H 'Content-Type: application/json' \
-d '
    {
    "contextElements": [
        {
            "entityId":{
                "id":"Device.PowerPanel.01", "type":"PowerPanel"
            },
           "attributes":[
                {
                    "name":"usage", "type":"integer", "value":4
                },
                {
                    "name":"shop", "type":"string", "value":"01"
                },
                {
                    "name":"iconURL", "type":"string", "value":"/img/shop.png"
                }
           ],
           "domainMetadata":[                                                                                           {
                    "name":"location", "type":"point",                                                                      "value": {                                                                                                  "latitude":35.7,
                        "longitude":138                                                                                     }
                },                                                                                                      {
                    "name":"shop", "type":"string", "value":"01"
                }
           ]
        }
    ],
    "updateAction": "UPDATE"
}'

サービス・トポロジの出力はブローカーに公開され、データをサブスクライブするアプリケーションは通知を受け取ります。アクチュエータ・デバイスは、ブローカーからの入力としてこれらのストリームを受信することもできます。結果のストリームは、 FogFlow ダッシュボードの Streams メニューにも表示されます。

他のチュートリアルを読むことで見つけることができます

クラウド-エッジ・コンピューティング (Cloud-Edge Computing)¶

重要 !¶

1 リクエスト:¶

2 リクエスト:¶

License¶