データ連携基盤共同利用の実践

はじめに

全国の地方自治体で導入が推進されているデータ連携基盤は、他の行政システムと同様に、これまで各々が独立に開発・運用が推進されてきました。しかし限られた予算内で専門的なシステム基盤を導入することは難しいと判断される場合が多く、データ連携基盤の普及展開においてハードルの一つになっていることが明らかになっています。
他の基幹システムと同様に、データ連携基盤も複数自治体での共同利用検討が推進されています。デジタル庁の共同利用ガイドブックによれば、基盤の共同利用によって導入・構築コストは1/2程度、運用コストは1/5程度削減できる可能性が示唆されており、データ連携による地域横断的なサービス創出に向けたシステム導入促進の起爆剤となる可能性があります。
共同利用ガイドブックでは、共同利用の実現に向けたプロセスやビジョン策定の方式が詳しく説明されている一方、具体的なシステムの構築方式は言及が限定的となっています。本コラムでは、構築イメージや導入の進め方をつかんでいただくことを目的として、非パーソナルデータを対象とした共同利用の実践例を紹介します。

共同利用に適したシステムアーキテクチャとは

「テナント」概念とその重要性

システム基盤の共同利用を検討する際に重要となるのが、どのようなシステム構成でサービスや機器を複数自治体に提供するかという点です。「テナント」とは、クラウドや共通のシステム基盤上に構築された”利用者ごとの論理的な区画”を示す言葉で、ビルなどの建物におけるテナントビルと同様、ひとつの基盤やサーバの上に複数の自治体や団体がそれぞれの専用スペースをもってサービスを利用する状態を意味します。このテナントの考え方が、複数の組織が同じシステムを共同で使う際の独立性を保つ基本単位として多くの場面で利用されています。

シングルテナント方式とマルチテナント方式の違い

テナントの構成には大きく分けて、「シングルテナント方式」と「マルチテナント方式」の2種類があります。

シングルテナント方式は、利用者がそれぞれ専用のシステムリソースを持つ方式で、サーバやデータベースを他の利用者とは物理的にも論理的に分離されて利用されている状態です。利用者は他の利用者の影響を受けないため、柔軟にシステム設定をカスタマイズすることが可能です。

他方、マルチテナント方式は、基礎となるシステムリソースを複数のテナントで共有する方式です。サーバやデータベースを他の利用者と共同で利用する構成であるため、運用管理の効率性やコスト面でメリットがある反面、テナントごとの高度な設定や障害発生時の影響が広範囲に渡るなどのデメリットがあり、一般的に利用者が節度を保って利用することが必須条件となっています。

テナント方式別のメリット・デメリット比較

マルチテナントはシングルテナントと比べてメリットもありますが、デメリットもあります。テナントの利用者は、これらマルチテナントのデメリットを理解し、合意の上で利用することが求められます。

項目	シングルテナント	マルチテナント
環境分離	完全分離	論理分離
コスト効率	低い	高い
性能保証	個別の最適化が可能	利用者全体での最適化検討が必要
障害影響	他利用者への影響なし	1利用者の障害が全体に波及する可能性がある
運用調整	個別対応	共通メンテナンススケジュールの合意が必須

マルチテナントを支える技術要件とは

マルチテナント方式を採用するためには、商用ビルが貸テナントを提供できるよう設計されていることと同じように、アプリケーションやサービス自体がマルチテナント方式に対応した設計がなされていることが前提となります。具体的には、利用者ごとのアクセス制御やデータの分離を行う仕組みが、アプリケーション側に備わっている必要があります。
データ連携基盤のコア機能である、API Gatewayやデータブローカーモジュール、およびこれらに各種データベースサービスは、いずれもマルチテナント運用に対応した機能を標準で備えています。例えばデータブローカーの推奨モジュールの一つであるFIWARE Orionは、FIWARE Serviceと呼ばれるテナント設定を区切ることで論理的にデータベースを独立させることができます。

【実践例】X県における3自治体の共同利用モデル

ここでは具体例としてX県でA市、B市、C町の3団体が非パーソナルデータのデータ連携基盤を共同利用する事例を考えてみます。API GatewayとしてKong Gateway、データブローカーとしてFIWARE Orionを利用し、前回の記事で紹介したVMインスタンス1台を用いて小規模なシステムを構築したと仮定します。

Kongでは、ドメイン(例:a_city.example.com)やパス(例:/disaster)を設定することで複数のAPIを設定することが可能です。1台のKong上に3つの独立したAPIを設定し、それぞれ異なるバックエンドAPIに転送します。Kongの裏側では1台のOrionを起動させ、テナントごとに異なる3種類のAPIを設定します。Orionで設定した３つのFIWARE Serviceは、Orionと連動するMongoDB内のデータベースを論理的に分けて設定する仕様のため、APIごとにデータも分けて管理することが可能です。

発展的なケース、例えばミッションクリティカルなシステムである場合や、テナント数が増大しさらなる柔軟性が求められた場合は、より高度な仮想化技術やオーケストレーションツールの導入を検討する必要があります。API Gatewayやデータブローカーは、いずれもコンテナベースの利活用が可能であるため、リアーキテクチャの検討も比較的しやすいと考えられますが、システム移行などの運用を都度考慮する必要があります。

マルチテナント特有の課題もあります。例えばテナントの1つがシステム負荷の高いAPIを全体公開してしまい、かつそのAPIが悪用されてコンピューティングリソースに対する負荷攻撃を受けてしまった場合、すべてのテナントがその影響を受けてしまいます。この防止策としては、WAFなどのセキュリティ対策の導入に加えて、各テナントが運用するAPIの仕様をテナント内で公開することを義務づけ「脆弱なAPIを外部公開させない」ための仕組みを実装する運用などが考えられます。総じて、各テナント利用者は基盤提供者に運用を丸投げするのではなく、マンションの住民が共用施設を大切に使うことと同じように、粗雑な運用をしないよう気を付ける必要があります。

テナント横断機能を活用した情報収集

マルチテナント運用では、テナントごとに独立した機能を提供すると同時に、すべてのテナントで共通の機能を実装することも可能です。例えばテナントの基盤使用量に応じて利用料金を各団体に請求したいという要件が発生する場合があります。この要件を先ほど示した構成例で実現したい場合は、KongとMongoDBにて共通機能を追加/利用します。

KongではAPIの利用回数をアクセスログとして記録することが可能です。Kong上で、すべてのテナントのAPIに対してアクセスログを必ず記録する設定にすることで「どのAPIが何回利用されたか」を集計することが可能です。またOrionがデータを蓄積するMongoDBでは、データベースごとのデータサイズを動的に収集することが可能です。そのため、「APIの利用回数」と「データの保存量」の2点を根拠に、データ連携基盤の利用料をテナントの数で按分させることが可能です。

この他にも、「同じ認証設定を活用する」ことや「同じタイミングでサービスを停止させる」など主にKong Gatewayのプラグインを活用することで様々な要件に対応することが可能です。また、KongとOrionの機能を組み合わせることで、個別認証で制御された他データ連携基盤とのデータ仲介機能の実装も可能ですが、こちらはかなり発展的な事項であるため本記事では割愛します。DSAの推奨モジュール問合せ窓口に個別ご質問いただければ詳細をご説明いたします。

まとめ

本記事では、データ連携基盤を自治体間で共同利用するための技術的ポイントを紹介しました。限られた予算でのデータ連携基盤導入を支える手段としては、マルチテナント方式による共同利用が有効だと考えられます。データ連携基盤の推奨モジュールであるKongとOrionを活用してデータ連携基盤の構築にぜひトライしてみてください。

エリア・データ連携基盤や推奨モジュールに関する質問は以下までお問合せください。
お問合せフォーム

データ連携基盤 共同利用の実践