低予算で今すぐ始めるデータ連携基盤
はじめに
地域で管理される多様なデータおよびサービスを円滑に連携させる「エリア・データ連携基盤」の整備が全国各地で進められています。しかしその整備には様々なハードルがあり、なかでも多く自治体が直面しているのが「導入・運用にかかるコストの高額さ」です。
近年では、クラウドサービスやオープンソースソフトウェア(OSS)の普及により、用途や規模に応じて適切に設計すれば、コストを抑えつつ実用的な基盤を構築することが可能になってきました。とはいえ重要なのは「クラウドサービスなどを使えば安く済む」という表面的な理解ではなく「どのような構成にするか」「どの程度のサービスレベルを求めるか」「セキュリティをどう担保するか」といった、調達に必要な、一歩踏み込んだ設計知識を持つことです。
本コラムでは、非パーソナルデータを対象にした小規模なデータ連携基盤を例に、低予算で始められるクラウド構成パターンや運用コストの目安、最低限必要なセキュリティ設計の考え方を、実務の観点から簡潔にご紹介します。
データ連携基盤の中核機能
エリア・データ連携基盤は、地域が管理する多様なサービスやデータを統合・共有するためのシステムです。このシステムの中核を担う機能は大きく2つに分類されます。
- データ流通のハブとなり、データ登録や参照用の機能(API)を提供する「データブローカー」
- サービス間の接続を管理・制御する「APIゲートウェイ」
FIWARE Orionは、非パーソナルデータ(例:防災情報、交通情報など)の管理に適したAPIを提供するデータブローカーです。Orionを利用することで、データの登録・更新・通知・公開が可能となり、特にセンサーデータのようなリアルタイムに変化する情報の収集・連携に効果を発揮します。
Orionが提供するAPIには、参照系だけでなく、データの登録や削除などの編集系機能も含まれています。データ参照は許可しても、そのデータ自体を誰もが自由に編集できるようにする運用は、現実的ではなく、編集系のAPIアクセスは、通常、関係者のみに限定されるべきです。しかし、Orion単体では細かなAPIごとのアクセス制御機能を持っていないため、それを補うためのAPIの接続制御として公開範囲の制限や利用者認証を担うことができる「API Gateway」と組み合わせが推奨されています。
Kong Gatewayは、FIWARE OrionなどのAPI公開サーバーの前段に配置し、ユーザーごとのAPIアクセス制御などを担うAPI Gatewayサーバーの一つです。FIWARE OrionとKong Gatewayの2つのモジュールを組み合わせて運用することで、シンプルかつセキュアな「最小構成」のデータ連携基盤が実現できます。
データ連携基盤の構成要素とサービスレベル
ここでは、最小構成で始められるデータ連携基盤について具体的に解説します。
最小構成に必要な4つのモジュール
推奨モジュールであるFIWARE OrionとKong Gatewayは、設定値や連携データを保存するための専用データベースサービスを必要としますので、具体的には「Kong Gateway、PostgreSQL、FIWARE Orion、MongoDB」の4つのソフトウェアを運用する必要があります。
- FIWARE Orion:データの登録・更新・取得APIを提供するデータブローカー
- MongoDB:FIWARE Orionが利用するデータストア
- Kong Gateway:APIへのアクセス制御を担うAPIゲートウェイ
- PostgreSQL:Kong Gatewayの構成情報を保存するデータベース
これらはすべてコンテナイメージが公開されており、クラウドやオンプレミス問わず容易に立ち上げることが可能です。初期段階では、これらすべてを1台の仮想マシン(VM)上で稼働させる構成にして動作検証や限定的な運用を実施させることも可能です。ただし、この構成では単一障害点となるため、安定運用を目指すにはリスクを伴います。
サービスレベルの定義とその影響
実運用においては、システムの「サービスレベル」を明確に定義し日々見直しすることが重要です。なぜならば必要なレベルに応じて、構成やコストが大きく変動するためです。検討すべき主な要素は次の通りです:
- 稼働時間帯(例:日中のみ/24時間365日)
- 障害復旧目標(RTO)(例:即時復旧/数時間以内など)
- バックアップ頻度と保管方法(例:毎日自動取得/手動対応など)
- 監視・アラート体制(例:自動監視ツール導入/人による目視など)
- スケーラビリティ(将来的な拡張に対応できる構成か)
こうした要素の定義と見積もりを疎かにすると、後からコストが膨らむリスクや、システム障害時に十分な対応ができないリスクが生じます。複数の環境が用意できる場合には、用途に応じて環境を作成し、それぞれのサービスレベルに差をつけることでコスト削減を図っているケースも存在します。
観点 | 検証環境 | 本番環境 |
可用性 | 一時的な停止を許容 | 継続的なサービス提供を前提 |
性能・拡張性 | 最低限 | 将来の負荷増加を見据え、スケーラビリティ確保 |
運用・保守性 | 手動対応 | 監視・通知・復旧などを自動化 |
セキュリティ | 限られた関係者のみ利用 | 多数のユーザー公開を想定 |
最小構成と運用コストの例
クラウドサービスを利用すれば、導入初期の負担を抑えつつ、後から柔軟に構成変更や拡張が可能です。一方で、安定稼働や長期運用を目指す場合には、冗長構成やデータ保全策が必要となり、その分コストも増加します。
ここでは、FIWARE OrionおよびKong Gatewayを使ったデータ連携基盤について、2つの構成パターンとおおよその月額コストの目安を紹介します。いずれのパターンも初期費用はなく、サービスを利用した期間分だけ費用が発生します。なお、外部ベンダーに依頼した場合の設計費や人件費は考慮していません。
パターン1:単一VMによる最小構成(開発・小規模用途)
- 構成概要:1台の仮想マシン上に、Orion、Kong、MongoDB、PostgreSQLの全サービスを同居
- 用途:機能検証、小規模な限定運用
- 可用性:単一障害点あり(サーバーが停止すると全機能が停止)
- 月額コストの目安:
- AWS:medium(2 vCPU / 4GB RAM)利用時で約40ドル
- Azure:B2s(同等スペック)利用時も同程度
この構成は求められるサービスレベルが高い場合には利用に適さない場合があります。ただし、開発・導入検証用の場合や、利用規模を小さく定めた場合には検討候補になります。
パターン2:最低限の冗長・分散構成(本番運用想定)
- 構成概要:
- Kong、Orionを冗長化しコンテナサービスで管理(例:AWS ECS Fargate)
- コンテナへの分散アクセス用にロードバランサ(例:ALB)を配置
- PostgreSQLはマネージドDB(例:Amazon RDS)
- MongoDBは専用のクラウドサービス(例:MongoDB Atlas)
- 用途:本番運用、小規模でも可用性を重視した構成
- 可用性:一部障害にも耐えられる構成(マルチインスタンス、バックアップあり)
- 月額コストの目安:最小規模でもおおよそ360ドル~
この構成では、各コンポーネントが個別に管理され、障害耐性やパフォーマンスの向上が見込めますが、パターン1と比較すると月額コストのラインは大きく増加します。
小さく始めて段階的に拡張する考え方
初期から完璧な構成を目指す必要はありません。クラウドサービスの利点を活かし、以下のように段階的にレベルアップしていく方法が現実的です:
フェーズ | 構成 | 特徴 |
ステップ1 | 単一VM構成 | 最低限の構成で立ち上げ可能。検証・実証用途に最適 |
ステップ2 | アプリ層とDB層の分離 | 性能と保守性が向上。個別スケーリング可能に |
ステップ3 | コンテナ化+冗長構成 | 本格運用を見据えた安定稼働と監視体制を構築 |
このような「スモールスタート&スケーラブル運用」は、限られた予算の中でも効果的に基盤整備を進められるアプローチです。導入初期から将来の拡張も見据えて繰り返し設計・検証を行うことが、無駄のない投資につながります。
小規模でも削れない最低限のセキュリティ設定
たとえ単一VM構成のように簡素な環境であっても、APIの公開設定やアクセス制御といったセキュリティ設計の基本は必ず実施する必要があります。最低限守るべき設計方針として、以下を推奨します。
1. Kong Gatewayを入口として一本化する
Kong Gatewayのルーティング用ポート以外は外部に公開せず、すべてのAPIアクセスをKong経由に限定することで、直接的な不正アクセスを防ぎます。
2.FIWARE OrionのGETリクエスト以外の一般公開をしない
FIWARE OrionのAPIのうち、データ参照系(例:GET /v2/entities)のみを外部公開とし、データ登録・更新・削除系APIについては、Kong側で厳格にアクセス制限を設け、関係者のみに限定します。
3.段階的に公開範囲を広げる(例:IPアドレス制限、APIキーによる制限)
システム内部での動作確認を終えたら、例えば関係者のみがアクセス可能となるようにIPアドレス制限を設ける、もしくはKongプラグインの活用によりAPIキー認証を導入するだけでも、外部からの無制限なアクセスを防止することができます。システムの公開範囲は動的に変更可能ですので、サービスの目的や運用規模感に応じて都度見直しすることが重要です。
おわりに
本記事では「エリア・データ連携基盤」の整備において直面しうる「導入・運用コストの高さ」という課題に対し、クラウドサービスを活用した、低予算で実現可能な構成例とその考え方を整理しました。基盤構築においては、最初から大型の本番構成を目指すのではなく、現時点で必要な最小限の構成で確実に立ち上げること、そして将来的な拡張や運用負荷を見据えた柔軟な設計と段階的な拡張を継続的に検討することが極めて重要です。
エリア・データ連携基盤や推奨モジュールに関する質問は以下までお問合せください。
お問合せフォーム