エンタープライズデータの連携方式
企業のデータは、様々なシステムと連携される。今どきのシステムは、AWSやGCP、Azure等のパブリッククラウドで動いているものが多くなり、いわゆる「クラウドネイティブ」なシステムであることが求められている。クラウドネイティブの定義は以下に詳しい。
このような技術トレンドはあるが、システム同士のデータ連携のやり方については昔からあまり変わっていない。このデータ連携の特徴をまとめてたので、急にシステム開発に関わることになった時のチートシートとして活用してほしい。主なデータ連携方式は5つあり、それぞれが、以下の6個の詳細でまとめている。
・連携するデータ量
・連携先システムへの反映速度
・連携処理時のエラー処理
・他システムとの依存度合い
・通信で使うネットワーク
・ひと言
(1)ファイル連携(ファイルの配置、ファイルの取得)
データ連携方式の基本。ファイルデータを用いて行う。ファイルに記載されているデータの区切り方の違いでCSV(Comma Separated Value)、TSV(Tab Separated Values)等のファイル形式でやりとりする。
・連携するデータ量
少量から多くまで幅広く対応でき、設計は容易。しかし、ファイルサイズの限界はあるのと、大きすぎるファイルの展開に時間がかかる為、限度は考えたい。
・連携先システムへの反映速度
対向システム(データを送信する相手先のシステム)側のデータ取り込みのタイミングに依存する為、データ送信元のシステムではコントロールできない。
・連携処理時のエラー処理
ファイルを特定のフォルダや所定の場所に置く処理である為、エラーに対する耐性が強い。しかし、対向システム側ではファイル連携にエラーが発生したかどうかは判別がつかない為、あるべきファイルが配置されていない場合の取り決めが必要となる。
・他システムとの依存度合い
単なるファイル連携のため(ファイルを置く、置かれているファイルを取得する)、システム同士の依存性は低く保つことができる。
・通信で使うネットワーク
ファイルを置く場所がネットワークのどこに存在しているのかに依るが、インターネット通信、社内ネットワーク通信どちらも可能である。
・ひと言
新しいサービスにおいて、どのようなシステムモデルが良いか考える時にまず最初に検討するべき方式である。
(2)オンライン連携(REST, SOAP等)
こちらもデータ連携方式の基本の一つ。特定の通信方法とデータレイアウトを取り決めてやりとりする。対向システム(データを送信する相手先のシステム)側で、データを受け取るための口(APIと言ったりする)を用意する。
・連携するデータ量
少量から中程度のものであることが望ましい。多量のデータを送信したい場合は、複数回の送信に分割すると良い。
・連携先システムへの反映速度
対向システム側でデータを受け取った後の処理がどのようにされるかによるが、基本的には対向システムのデータベースにも速やかに記録されるように設計される。
・連携処理時のエラー処理
対向システム側で口を用意してもらう関係上、そちら側のシステム状況に依存することを考慮する。エラー発生時にどのようにリカバリするのかによって、設計の難易度が上がる。
・他システムとの依存度合い
対向システム側で用意されている口が正常に動作している必要があり、データ送信元システムはそれに依存せざるを得ない。
・通信で使うネットワーク
対向システムがネットワークのどこに存在しているのかに依るが、インターネット通信、社内ネットワーク通信どちらも可能である。
・ひと言
データを柔軟に連携したい場合に使いやすい方式だが、エラーが発生した時にどう対応するかをよく考える必要があるが、なるべく簡便に済ませることが肝要。
(3)DB間連携(レプリケーション)
データを保存することになるデータベース同士で直接データ連携させる方式。
・連携するデータ量
少量から多くまで幅広く対応できる。データの書込・取得は、そのデータベースで標準搭載されている「レプリケーション機能」を用いるが、量の制約はそのデータベースの容量になる。
・連携先システムへの反映速度
データベース同士で直接やりとりする為、実施した処理は即時反映させることができる。
・連携処理時のエラー処理
片方のデータベースで障害が発生した場合にはレプリケーションが止まる為、「どの部分まで同期が取れているのか」を把握できるようにしておく必要がある。
・他システムとの依存度合い
データベース同士のやりとりであるため、対向システムのデータベースが障害が発生した場合の対応が複雑になりがちになる。
・通信で使うネットワーク
原則、この方式ではインターネット通信では無く、社内ネットワーク経由(もっと言えば、同一のネットワークアドレス)で行われる想定である。
・ひと言
社内システムのデータ同期の方法としては一般的と言える。双方向となるデータ同期は複雑度が上がる為、なるべく避けたい。
(4)DB直取得(SQL, Viewテーブル等)
連携する対象のデータ送信のやり方を考えるのでは無く、データが保管されているデータベースを直接対象にしてデータを書込・取得する方式。
・連携するデータ量
少量から多くまで幅広く対応できる。データの書込・取得は、SQL文(データベースを操作する言語)で行える為、設計に柔軟性が持てる。
・連携先システムへの反映速度
データベースに直接アクセスする為、実施した処理は即時反映させることができる。
・連携処理時のエラー処理
データベースに直接アクセスする為、エラー処理にやり方についてもデータベースの機能が使える。
・他システムとの依存度合い
データベースに直接アクセスして、その内部でデータ読込・書込が実施される為、対向システムのデータベースが障害が発生したり、データベースの構造(正確には対象となるテーブルスキーマ)が少しでも変更されるとエラーが発生する為、依存性が高くなる。
・通信で使うネットワーク
原則、社内ネットワーク経由(もっと言えば、同一のネットワークアドレス)で行われる為、インターネット接続を前提としたデータ連携は困難である。
・ひと言
ファイル連携やオンライン連携ではなく、直接データベースにアプローチするやり方であり分かりやすい。しかし、「システム同士の依存をなるべく減らし、なるべく疎結合にする」ことを犠牲にする為、システム同士の依存度が上がり、クイックなシステム改修がやりづらくなる。
(5)メッセージキュー連携
昔からあるシステム間連携のやり方。既出の方式と比べ、システム同士で考慮するべき取り決めもあまりない。この方式は、プログラム同士の処理連携でも使われ汎用性がある分、データ連携に特化した細やかな機能はない。
・連携するデータ量
「メッセージ」と呼ばれる要素に対して連携したいデータを格納し送信するが、格納できるデータ量に制限がある為、少量から中量のデータのやりとりに適する。
・連携先システムへの反映速度
メッセージは「キュー」と呼ばれる仕組みでコントロールされる。この仕組みは、様々なメッセージを一時的に格納しており、その処理順番は「先入れ先出し法 (first-in-first-out (FIFO))」が基本となる。その為、反映速度については管理しづらい。
・連携処理時のエラー処理
何かしらかの理由で、そのメッセージが取り込みできない場合はエラーとなるが、再試行するのか、そのまま終了とするのかは取り決めによる。
・他システムとの依存度合い
データを送信する元のシステム側は、メッセージをキューに渡して「後はよろしく。エラーになったらその後、教えてね」という軽量な依存性である。
・通信で使うネットワーク
メッセージキューの仕組みがネットワークのどこに存在しているのかに依るが、インターネット通信、社内ネットワーク通信どちらも可能である。
・ひと言
データ連携に特化した仕組みではない為、既存の仕組みがあり、この方式を採用せざるを得ない場合などの理由がなければ、敢えて選択するメリットは無い。
今回、参考にした情報ソースは以下の通り。
この記事が気に入ったらサポートをしてみませんか？