データ連携基盤 基盤間連携の実践
はじめに
地域のデータを集約し、行政や民間サービスにデータを仲介する「エリアデータ連携基盤」の共同利用検討が全国の都道府県で推進されています[1]。共同利用は、特に基盤整備の効率化に対して有効ですが、サービスが対象とする地域課題は、都道府県や自治体の枠を超えて広がると予想されます。例えば防災や気象、交通といった広域的な課題では、データの発生源が自治体や地域をまたいで存在するため単一基盤のデータ利活用よりも、複数基盤のデータを組み合わせることでより魅力的なサービス提供が実現できる可能性が広がると考えられます。そのため、主に基盤整備の効率化を目的とした「共同利用」の推進に加えて、複数の基盤を相互につなぎ、広域的にデータを利活用できる「基盤間連携」のしくみも把握した上で地域サービスを検討できることが望ましいです。
本コラムでは、非パーソナルデータ向けの推奨モジュールを備えたエリアデータ連携基盤を題材に、基盤間連携の実践例を紹介します。
[1] https://www.digital.go.jp/policies/digital_garden_city_nation/area-data-coordination-platform#share
FIWARE Orionが提供するAPIを用いた基盤間連携のしくみ
FIWARE Orionは、エンティティデータの管理に特化したコンポーネントで、主に3つのAPI機能（蓄積、通知、所在管理）を提供します。このうち「所在管理」は、他のOrionにあるデータの場所（URLやメタデータ）だけを記録し、必要に応じてその場所に問い合わせるしくみです。データ全文が登録されていなくても「どこにあるか」を知っていることで、利用者にとっては一箇所に集約されているかのようにデータを参照できます。基盤間連携で鍵となるのがこの所在管理機能です。
| 機能名 | 内容 |
| 蓄積 | データを登録、更新、削除でき、リクエストに応じてデータが参照できる機能 |
| 通知 | データの更新状況をモニタリングし、条件に合致したデータを登録した通知先に配信する機能 |
| 所在管理 | データ所在情報を登録、更新、削除でき、リクエストに応じてデータが参照できる機能 |
地域A内に1つのKongと、2つのOrionA、OrionBが稼働していたとします。また、Kongの転送設定には、OrionAだけが設定されていて、KongとOrionBは直接の通信が発生しない構成であるとします。この時、クライアントがKong経由でOrionAに対してOrionAとOrionBのデータ取得を要求すると、OrionAは登録された所在情報を参照して、OrionBへのデータ取得を要求します。OrionBがその要求に応じて結果を返却し、OrionAは自身のデータ取得を含めた結果を返却し、最終的にクライアントは、OrionAとOrionBの結果が得られます。
Orionの所在管理機能を利用すると、クライアントは複数のOrionに点在したデータを一箇所から入手することができ利便性が向上する可能性があります。また、データ管理面でもデータの分散管理が実現でき、IoTデバイスの種類や、データ分野別にOrionを分けた管理が可能になるなど運用上のメリットになる場合があると考えられます。
FIWARE Orionのデータ所在管理機能を用いた場合の課題とその解決策
FIWARE Orionのデータ所在機能は非常にシンプルで、複雑なユースケースには対応できないという課題があります。具体的には登録したデータ所在(URL)に対して固定のデータ取得要求しか実施することができず、エリアデータ連携基盤で広く用いられているようなAPI Gatewayによる認証(例えばAPIキー認証)に対応することができない点です。
地域Aと地域Bでそれぞれ推奨モジュールのKong GatewayとFIWARE Orionが運用されているケースを考えます。地域AのOrionに対して地域Bの所在情報を登録したとします。クライアントが地域Aに対して地域Aのデータと地域Bのデータ取得をまとめて依頼したとすると、Kong経由で転送された地域AのOrionは、地域BのKongへデータ取得を要求します。しかし、地域BのKongが指定のAPIキーを設定したリクエストしか認めていない場合、地域BのKongはこのリクエストを拒否し、結果としてクライアントも地域Bのデータを取得することができず、地域Aの結果だけが返却されます。
この課題を解決する方法の一つとして、地域内のAPI Gatewayをアダプターとして活用する方法が挙げられます。地域Aと地域BにそれぞれKongとOrionがあるケースを考えてみましょう。見た目は1つ前の処理フローと似ていますが、処理が一部追加されています。
前の図と同様に、クライアントが地域Aに対して地域Aのデータと地域Bのデータ取得をまとめて依頼したとします。Kong経由で転送された地域AのOrionは、地域BのKongへデータ取得を要求しますがこの時、地域Bに直接リクエストするのではなく、地域AのKongをデータ所在URLとして登録します。Kongには地域B宛のリクエスト用エンドポイントを予め追加しておき、さらにこのエンドポイントに来たリクエストには地域Bで利用されるAPIキー認証の情報を付与させるように設定します。このように設定することで、Kongが地域間のOrionをつなぐアダプターとして機能し、地域Bのデータが取得できるようになります。
API Gatewayを地域間リクエストのアダプターとして利用する設定は、多くのAPIゲートウェイ製品で標準的な機能のみで実装できます。推奨モジュールであるKong Gatewayを例に挙げると、該当のルートに対して”Request Transformer”プラグインを適用しリクエストヘッダーにAPIキーを追加する設定を加えること、加えて該当のルートはOrion以外が利用できないようにプライベートIPアドレス等でリクエスト元を制限すること、この2点の設定で実現が可能です。なお、しくみが同じであるため詳細は割愛しますが、異なるFIWARE Serviceが指定されたOrion間でのデータ所在管理でも同じようにAPI Gatewayをアダプターにしたリクエストの修正を行うことでサービス間の連携が可能ですので、基盤間連携だけでなく共同利用基盤内においても利用される場合がある処理フローです。
まとめ
本記事では、非パーソナルデータ向けのデータ連携基盤を題材に、推奨モジュールであるKongとOrionを用いた基盤間連携を実装方法の具体例を紹介しました。特に「API Gatewayをシステム間通信のアダプターにする」というテクニックは、基盤間連携を含むシステム構成検討/サービス検討において役に立つ可能性があり覚えておいて損はありません。
地域が必要とするサービスからデータ連携基盤に求められる要件をトップダウンで検討する際には、推奨モジュールで実際に「何ができるのか」というボトムアップの理解も欠かせません。こうした両面の視点を持つことは、開発委託ベンダーとの調整を円滑に進めるうえでも重要です。データ連携がどんなしくみで機能しているかについても、ぜひ注目してみてください。
エリア・データ連携基盤や推奨モジュールに関する質問は以下までお問合せください。
お問合せフォーム