インフォ・ラウンジ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です。
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 (状況の仲介人) と呼ばれる所以を説明してみたいと思います。
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の連携とかとホントに成立するのかなぁなんて気もします。しらんけど。
-
都知事杯オープンデータハッカソンでファイナリストになったみたいです。
https://www.youtube.com/watch?v=LbPL9odzQYg&t=3675s ↩