Rapsberry Pi

EdgeX Foundry: Geneva から Hanoi へ

はじめに

本ブログでもちょこちょこ話題にしてきた EdgeX Foundry ですが、最後のエントリからもう半年以上経過してしまいました。

EdgeX Foundry は、半年に一度のペースで新しいバージョンがリリースされます。ぼくが 日本語のハンズオンラボガイド を最初に公開した 4 月時点ではまだ Fuji(1.1) が最新でしたが、5 月に Geneva(1.2)がリリースされ、11 月には Hanoi(1.3)がリリースされています。

というわけで、リリースノートを中心に、Geneva をいまさらおさらいした後、Hanoi の更新情報も見ていきましょう。

Geneva

2020 年 5 月 13 日にリリースされました。リリースノートは公式 Wiki で公開されています。また、LF Edge のブログでも紹介があります。

新機能系をざっくり見ていきます。

Dynamic Device Provisioning の追加

これは、デバイスサービスが定期的(または REST API のでトリガを契機)にデバイスのスキャン(Device Discovery)を実行し、応答があったデバイスを動的に EdgeX Foundry 配下に登録できる機能です。Dynamic Device Discovery、Automatic Provisioning などとも表記されます。

Geneva では、これを実装するためのフレームワークが SDK に追加されました。SDK に含まれるサンプルデバイスサービス(device-simple)でごく簡単な実装例が示されています。

自分でも 5 月末くらいに既成の MQTT デバイスサービスに機能を追加で実装して試してみていました。Slack の DM で質問も来たので、ついでとばかりにガイドを書いて公開済みです。

けっこうおもしろいデモができそうな感じでした。

エクスポートのバッチ処理の追加

アプリケーションサービスのエクスポートをバッチ処理できるようになりました。具体的には、SDK への機能追加と併せて、パイプラインで使える組み込みのファンクションが追加されています。

データのエクスポートを、データの到着都度ではなく、一定の時間やデータ個数ごとにまとめて行えるようになり、オフライン環境や通信の安定しない環境でもエクスポートしやすくなるとされています。

ただし、このバッチでのデータの溜め込みはメモリ内で行われるため、データ量やバッチの間隔によっては使用メモリの肥大化やパフォーマンス劣化を招く可能性があります。利用の際は、実環境でテストしたうえでパラメータを調整するなど、ある程度のチューニングは必要になるかもしれません。

これも動作は確認済みです。

MQTTS や HTTPS でのエクスポート機能の追加

生の MQTT や HTTPS ではこれまでもエクスポートできましたが、アプリケーションサービスで、それぞれ MQTTS、HTTPS でのエクスポートがサポートされました。

実際に試した範囲では、Geneva の段階だと バグ があり、動作させるには Vault なしにはひと工夫必要 でしたが、クライアント証明書を使ったセキュアなエクスポートができるようになっています。

一部機能の廃止や変更

MongoDB が非推奨になり、標準のデータベースが Redis に変更されました。非推奨なだけなので利用は可能で、Geneva では MongoDB を使う Compose ファイルも用意はされていますが、次の Hanoi ではなくなっています。

また、サポートサービス層の要素のひとつ、ロギングサービスも非推奨になりました。これも Geneva ではまだ利用は可能ですが、MongoDB 同様、Hanoi では Compose ファイルからは除かれています。一般論としてコンテナのログは標準出力に吐くべきものであり、標準出力に吐かれたログの扱いはコンテナプラットフォーム側の責任といえるので、その考え方に寄せた(独自で実装するべきものではないと判断された)ということでしょう。

さらに、ルールエンジンが Java で記述された従来の Drools ベースのものからサードパーティの Kuiper に変更されています。EdgeX Foundry 独自のカスタマイズなしにネイティブの Kuiper と連携できるようで、疎結合でよいですね。

このほか、エクスポートサービス層(今ではアプリケーションサービス層ですが)に存在していた Export Client サービスと Export Distro サービスも廃止になっています。

その他

比較的大きめの(とぼくが思った)ものをピックアップします。

  • コアサービスとアプリケーションサービスの間のメッセージングにはこれまで ZeroMQ が使われていましたが、MQTT と Redis Streams のサポートが追加されました。
  • REST デバイスサービス、ONVIF 対応カメラ用のデバイスサービス、C 言語版の BACnet デバイスサービスが追加されました。
  • デバイスサービスやコアサービスで扱えるデータとして、配列がサポートされました。複数のセンサの値をまとめて扱えるようになります。
  • Reading オブジェクトにデータ型を表すフィールドが追加されました。Value Descriptor なしである程度はデータを適切にハンドリングできるようになります。
  • 各種サービスに起動時用の設定ファイルを配置する役割のシーディングサービスが廃止されました。各サービスは起動に必要な処理をそれぞれ自分自身で行うようになります。
  • アプリケーションサービスのパイプラインに JsonLogic ベースのルールを表記できるようになりました。ごく簡単なルールエンジンとして利用できます。
  • デフォルトでは、API ゲートウェイ(Kong)以外はポートをホストの外部に公開せず、127.0.0.1 のみで待ち受けるようになりました。
  • アプリケーションサービスが任意の秘密情報を Vault に追加できるようになりました。また、すべてのサービスが秘密情報を Vault から取得できるようになりました。
  • アプリケーションサービスの実装例が追加で公開されました(一部は GA 前です)。
  • API のドキュメントが Swagger Hub での公開に変更されました。
  • UI の機能が強化されました(ただし UI そのものは開発者向けです)。

これらの純粋な機能面での変更だけでなく、開発プロセスや品質保証面でも様々な変更や改善、強化が行われているようです。

Hanoi

Hanoi は出たてほやほやで、2020 年 11 月 20 日にリリースされました。1.x 系の最後のマイナリリースになるようです。

こちらも新機能系をざっくり見ていきます。

CLI のリリース

開発が進められていた CLI が GA になりました。cURL や Postman などで REST API コールを手作りしなくても、デバイスの追加などに必要な操作はおおむね実行できるようになっています。

ただし、EdgeX Foundry が動作しているホスト上での利用が想定されており、リモートインスタンスへの操作はサポートされていません。

エクスポートデータのタグ付けのサポート

EdgeX Foundry が集めたデータは、アプリケーションサービスを使ってさらに上位の分析基盤やクラウドサービスなどにエクスポートできます。Hanoi では、複数の EdgeX Foundry インスタンスがあるときに、データのエクスポート元のインスタンスをエクスポート先が判断できるようにするために、タグ付けがサポートされたようです。

具体的には、アプリケーションサービスのパイプラインで使える組み込みのファンクションにタグ付け用のものが追加されています。

Compose ファイルの編集性の向上

これまでのリリースでは、デバイスサービスやアプリケーションサービスにカスタマイズが必要な場合、Docker Compose で利用する巨大な Compose ファイルの手動編集が避けられませんでした。

Hanoi では、Compose ファイルは make コマンドでビルドする方式に変更されています。コアサービス群、デバイスサービスごと、セキュリティサービス群、など部品化された Compose ファイルが用意されており、make コマンドの引数で組み合わせやアーキテクチャを指定する形です。

個人的には、確かに長大なファイルをいじくりまわす必要性を減らせたメリットはあるものの、触った感触として、なにかをカスタマイズしたいときに編集すべきファイルの判断や make に渡すべき引数の検討など考えるべきことが逆に増えてしまっている部分もあるので、デメリットもある感触です。

デバイスサービスの分散デプロイの実現

これまでは、EdgeX Foundry を構成するすべてのマイクロサービスがひとつのホストの中にある状態でした(正確には複数ホストでも分散はできたものの、通信の秘匿などの面で懸念が残る状態でした)が、Hanoi ではデバイスサービスをリモートホストに配置する構成を取りやすくなっています。

具体的には、コアサービスが動作するホストとデバイスサービスが動作するホストの間で SSH トンネルを構成するための手法が公開されています。また、Docker Swarm でオーバレイネットワークを構成して疎通させる PoC も公開されました。

自動パフォーマンステストの追加

EdgeX Foundry のインスタンスに対して、管理下に配置できるデバイス数など、自動的にパフォーマンスをテストできる仕組みが用意されました。

現状ではまだ Modbus デバイスサービスのみですが、今後、デバイス種別も範囲も強化されていくことが予想されます。

V2 API の実験的リリース

正式には次の Ireland で採用される予定のため、Hanoi ではベータ扱いですが、V2 API が含まれています。各種機能追加が図られているようです。

その他

このほか、比較的大きめの(とぼくが思った)ものをピックアップします。

  • 同じ LF Edge 傘下で、主に産業向け IoT のプラットフォームである Fledge に対して、EdgeX Foundry からエクスポートするサンプルが提供されました。次のリリースでは、逆に EdgeX Foundry に Fledge からデータを取り込む手段が提供されるようです。
  • シークレットストア(Vault)のマスターキーをハードウェア(TPM など)の支援の下で保護できるようになりました(参考)。
  • GPIO や UART、LLRP、CoAP など新しいデバイスサービスが公開されました。
  • Snap 用の実装の維持管理が Canonical に移譲されました。
  • コアデータサービスをバイパスして、メッセージバスを利用してデバイスサービスからアプリケーションサービスに直接データを送れるようになりました。
  • 実装例を集める edgex-examples リポジトリができました。

Ireland

来年の春にリリースされる予定の Ireland は、メジャリリースす。つまり、Edinburgh(1.0)から続いていた 1.x 系が終わり、Ireland は 2.0 になる予定です。

API も V2 に置き換えられ、デバイスサービスなどの認定プログラムも開始されるようです。

おわりに

Geneva と Hanoi をざっくり振り返りました。だんだん個人で追いかけるのも限度が出てきますね。引き続き趣味の範囲でゆるゆるとやっていきます。

EdgeX Foundry 関連エントリ

@kurokobo

くろいです。ギターアンサンブルやら音響やらがフィールドの IT やさんなアルトギター弾き。たまこう 48 期ぎたさん、SFC '07 おんぞう、新日本ギターアンサンブル、Rubinetto。今は野良気味。

コメントを残す

メールアドレスが公開されることはありません。 が付いている欄は必須項目です