2
3

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

Fiware Orion Context Brokerに関する6つの誤解

Last updated at Posted at 2023-12-24

インフォ・ラウンジAdbent Calendarの最終日を任されてしまったので、イブの夜に泣きながら書いてます!

背景

本業で自治体や国の機関向けにデータ基盤の導入なんかを支援しています。最近、都市OSやデータ連携基盤について聞かれる事が多くなってきたのですが、データ連携基盤=Fiwareみたいな感じで言われることが多くて、ざっくりは合っているんだけど、エンジニアとしてはモヤモヤするなぁと思って、今現在自分が考えていることを書いてみました。これから都市OSやデータ連携基盤を導入しようと考えている行政の担当者などがいたら、参考にしてもらえればと思います。(宣伝要素多めです)

一応、一エンジニアとしての乏しい知識で書いているので、内容に誤りがあれば指摘もらえるとありがたいです。

誤解その1: FIWAREってソフトウェアの名前?

いえ、FIWAREというソフトウェアがあるわけではありません。FIWAREはFuture Internet Wareの略だそうですが、欧州連合(EU)の次世代インターネット官民連携プログラム(FI-PPP)というプロジェクトで構成された概念で、多くのOSS(オープンソース・ソフトウェア)のモジュールから構成されています。Fiware Foundationという組織があって、そこで認定されたソフトウェアをFIWARE GEs (Generice Enablers)と呼びます。いうなれば、Powerd by FIWAREっていう感じの概念ですね。FIWARE GEsのカタログはここにあります。
https://www.fiware.org/catalogue/

ただし、これがないとFIWAREって言ってはいけませんというモジュールが一つだけあります。それがContext Brokerです。Context Brokerって何?って話は後でします。FIWARE GEsに記載されているContext Brokerにはいくつか種類がありますが、現在のところOrionというモジュールが使われることが多いと思います。

では、GEsに記載されているソフトウェア(モジュール)がFIWAREのために作られたものかというと、必ずしもそういうわけではなく(そうでない方が多い?)、例えばAPIゲートウェイ機能であるKongは、FIWARE発足前からイタリアで開発されていたソフトウェアのようです。

では、Context Brokerと接続すればなんでもGEsになれるかというとそういう話ではなく、「オープンソース・ソフトウェアである」というのが必須の条件のようです。FIWAREプロジェクトは欧州におけるGAFAMへの対抗政策という位置づけが強く、米国がプロプライエタリでガンガンいくなら、こっちはオープンで対抗しよう(意訳)みたいな感じなのだと思います。しらんけど。

誤解その2: データ連携基盤にはFIWARE Orionを使わないといけない?

データ連携基盤では、FIWARE Orionを使わなければならないと思われていることが多いですが、全くそんなことないと思います。もちろん、データ基盤同士は相互に接続できなければいけないので、そのインターフェースには一定のルールが必要です。FIWAREでは共通インターフェースとしてNGSI (Next Generation Service Interface)を提唱しているので、当面これに乗っかっていくのが良いと思います。

現在主に使われているのは、NGSI v2という規格。といっても、こんなデータモデルが規定されているだけ、中身は何のことない、エンジニアにはおなじみの普通のJSONベースのREST APIです。

image.png

Entity (実体) というのが、例えば「山田さんの車」だったりすると、そのidが「車体番号」で、typeが「車」だったりします。で、その車はAttributes (属性) をいくつか持っています。例えば、色という属性であれば、nameが「色」で、typeが「テキスト」、valueが「赤」だったりします。色の他には、車高とか定員とかいう属性があるんですかね。詳しくは説明しませんが、Metadataはさらにその属性に関する追加情報です。

そういう意味では、NGSIはとっても「ゆるい」仕様です。何にでも使える代わりに何者でもないというやつです。

誤解その3: NGSIを使えば相互運用性が担保できる?

上に書いたとおり、NGSIの縛りはとてもゆるいので、typeとidさえあれば何でも食うダボハゼです。つまり何にもコントロールしなければ、Orionにはゴミがたまっていくだけです。Typeに応じてきちんとデータスキーマを定義するなり、バリデーションをかけるなりしなければなりません。

とはいえ、FIWAREもその状況を放置しているわけではなく、スマートデータモデルというデータモデルのスキーマを公開して、それを使うよう推奨しています。
https://www.fiware.org/smart-data-models/

例えば都市に設置されているカメラのデータモデルはこんな感じです。どこに設置されているか(address)、カメラの名前(cameraName)、緯度経度(location)などの情報が定義されています。
https://github.com/smart-data-models/dataModel.Device/blob/master/Camera/doc/spec.md

実際にOrionにデータを投入する際には、このモデルの中から一番近いタイプのものを探してきて、それに既存のセンサーなどが持っている情報を当てはめていく訳なのですが、これがなかなか難しい。

まず、スマートデータモデルに登録されているタイプはまだまだ少ないので、投入しようとしているデータに一番マッチしそうなモデルを選択するのに一苦労。選択したモデルのフィールド名と、投入したいデータの値をマッチさせていくのに一苦労。マッチするフィールドがない場合には独自の拡張をするわけですが、ここでも出来るだけ標準的な語彙(タイプ)を使わないといけないので、スマートデータモデルなんかよりももっと標準的なSchema.orgなどから、最適な語彙を引き出してきて、スマートデータモデルと繋ぎ混みます。ここまでできるのはかなりの強者です。1

仮に、Aさんが登録したデータが綺麗になっていても、Bさんが登録したデータはオレオレモデルになっているとすると、それはもう「つながらないデータ連携基盤」(データ非連携基盤?)になってしまいますね。しらんけど。

誤解その4: どんな種類のデータでも連携できる?

半分正解です。前にも書いたように、NGSIはゆるい仕様なので、どんな種類のデータでもOrionに投入することはできますし、力業でやれば何でも連携できます。しかし、何事にもコストと効率性というものがあります。ぶっちゃけ不向きなデータというのは何でしょう?

ズバリ「静的データ」ってやつです。世の中のデータは主に、「静的データ」と「動的データ」に分けられます。ざっくりとこんな特徴があります。

種類 変更頻度 利用目的 管理の複雑さ
静的データ 低い (月・年) 主に基本的な情報提供、参照、文書化 比較的簡単、定期的メンテナンス 避難所情報、施設情報
動的データ 頻繁 (リアルタイム) 監視、実時間の意思決定、動的プロセスの管理 高度な管理システムが必要、流通が継続的であるため複雑 河川水位、バス運行情報

一言でいえば、リアルタイム性の違いです。避難所情報や施設情報がリアルタイムに変わったら困ります。役所に行こうと思ったら、次の瞬間に戸籍課がワープしてたとかいうのは困ります。時々移転するかもしれませんが、移転して1秒後に通知もらわなくても誰も困りません。対して、バスが遅れてますってのは、1時間後に通知されても困ります。前者のようなデータを「静的データ」、後者のようなデータを「動的データ」って言います。Orionはどうぞ「動的データ」のために使ってください。

ちょっとややこしい話ですが、OrionがContext Broker (状況の仲介人) と呼ばれる所以を説明してみたいと思います。

B1xOlzOIp.png

Orionには常時、何百、何千というセンサーからリアルタイムで情報が送られてきます。そのうちの一つである、温度センサーを「センサーA」として、その情報をほしがっている人を「受信者」と仮定します。もし、Orionがセンサーから受け取った情報をムーディーに右から左に流していたとすれば、受信者は早晩精神を病んでしまうことでしょう。そんなときのOrionさんです。

受信者は、予めOrionさんに対して「センサーAの温度が50度以上になったら教えてね」ってそっと伝えておく(サブクスリプション登録する)だけで良いんです。センサーAから「30度になったよ」「40度になったよ」ってどれだけ言われても、Orionさんは我慢強く待ちます。そして「55度になったよ」っていう通知が来た瞬間に「超えたー!」って受信者さんをたたき起こすわけです。

こんな処理を、何百、何千というセンサーと、同じく何百、何千という受信者とサブスクリプションに対して、超高速にさばくのが、仲介人たるOrion Context Brokerの役割なわけです。しらんけど。

誤解その5: データAPIを公開するにはOrionが必要?

静的データをCSVとして公開するだけならデータカタログ(CKANとか)で良いけど、APIとして公開するならばやっぱりOrionが必要だよね?というのもだいぶ誤解です。例えば施設情報のような静的データでもCSVが置いてあるだけよりは、APIがあった方が便利です。ExcelからAPI叩いて、施設の情報をまるっともって来れたら便利だし、仕事もはかどります。

ところで、API (Application Programming Interface)って何?って話ですが、要はプログラム(機械)が他のシステムからデータを取ってくるときに使われるインターフェースです。例えば、施設番号xxxxxxxxの施設の情報をまるっと(住所やら、緯度経度やら、設備情報やら何やらかんやら)欲しいと問い合わせれば、その情報が一定の決められたフォーマット(形式)で戻ってくる機械さま向けの便利な窓口です。

これって、欲しいときに問い合わせたら、必要な結果だけ返ってくれば良いですよね?いちいち戸籍課が引っ越したー!ってプッシュ通知くれなくても良いですよね。こういうのをPull型APIっていいます。ほしいときに引き出すっていうイメージですね。さっき説明したセンサーの例は、勝手に送ってくるのでPush型APIっていいます。

細かい話を省くと、静的データはPull型が向いていて、動的データはPush型が向いています(例外はあります)。この違いを意識しておくと理解が早いと思います。そして、Pull型APIを整備する方が簡単で、コストもかかりません。はい、ここテスト出ますね。

噂によると、CKANにCSVを上げておけば勝手にAPIを作ってくれるサービスもあるようです。2

誤解その6: Cotext Broker的なものを作るにはFIWAREが必要?

Context Brokerという言い方はFIWRE以外であまり耳にしないのですが、同等の機能を持つサービスは大手のクラウドサービスではたいがい用意されています。AWS IoT Coreなんてのもその一つです。さっき言った、「FIWAREってのは、もともとGAFAM対抗を意識してるんよ」っていう話をちらっと思い出してもらえると、ストンと腹落ちするかもしれません。しらんけど。

どっちを使っても、NGSIのインターフェースだけ揃えておけば、技術的にはつながります。意味的につなげるには、さっき言ったデータモデルの話もね。

ぶっちゃけエンジニア視点から言えば、整備されてるクラウドサービス使った方がずっと楽ですし、コストも安くてメンテナンスも手間がかからないと思います。とはいえ、日本はどうやら欧州路線で行くみたいなので、どうしてもFIWARE導入したくなったら、こんなSaaSを使ってみるのも良いと思います!3

おわりに

データ連携基盤はFIWAREを導入すれば何でもつながる的な誤解はとても多いんですが、実際はそんなに簡単なものではないというのが現実かと。ここに書いたもの以外には、認証の話(これも奥が深い)もあるし、連携基盤同士のコンフリクトの問題とかもあると思います。N対Nの連携とかとホントに成立するのかなぁなんて気もします。しらんけど。

  1. データモデルの作成にお困りの際は当社までお問い合わせください。

  2. 都知事杯オープンデータハッカソンでファイナリストになったみたいです。
    https://www.youtube.com/watch?v=LbPL9odzQYg&t=3675s

  3. https://www.code4japan.org/activity/moc

2
3
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
2
3

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?