他システム連携 とか 外部システム連携 とか言いますが…要するに自システム以外のシステムとデータ連携を行う場合に気を付けておきたいことをこの記事でまとめました。
目次
- 概要
- 設計観点
- 開発に向けて
概要
他システム連携といえば以下のイメージかと思います。 この記事全体を通して基本的には 接続先側の立場 で記載します。 立場は読みづらくなりそうだから決めているだけなので、実際は接続元も接続先も同じ観点を気にする必要があります。
このようなシステム間連携の設計をするとき、気にしたい点の概要をまとめると以下のようになります。
設計…とは少しずれるかもしれませんが、実際に接続することを考えると準備が必要なこととして、以下のようなものもあります。
以下ではそれぞれの観点について詳細に見ていきます。
連携方法
連携方法と言えば、大まかには以下の3種類ではないでしょうか。 接続方法 (プロトコル) という観点で詳細を見ていきます。
リソース共有
データベースへ直接アクセスさせてデータ取得またはデータ更新を行います。
接続方法は各データベースクライアントの独自プロトコルになるかと思います。
参照のみの場合はビューを作成して公開します。更新する場合は実テーブル公開になります。 どちらにしても生データに対して直接作用されるのでリアルタイム性が高い点がメリットです。 反対にテーブル構造の変更＝インターフェース変更になるため、全く異なるベンダーとの接続だと影響が大きくなる可能性が高くなります。 また、更新を許可している場合はどのようなデータが来るか分からないので不正データが紛れたときに障害の切り分けが難しくなると思います。
ちなみに…データベース監査が入っている場合はアクセスするテーブルの許可設定が必要になる点に注意です。
【確認観点】
- 接続元IPアドレス
- 接続先IPアドレス
- 接続先ポート番号
- 接続先URL (スキーマ名含む)
- 接続時に使うユーザーID/パスワード
- 穴あけ設定
- ファイアウォール
- データベース監査
アプリケーション連携
個人的には「システム連携」と言えばこの方法が一般的な感覚です。
互いに取り決めたURLへアクセスしてもらうことで連携を行います。 通信方法としては Socket 、 WebAPI といった感じでしょうか。 Web / AP で動くアプリを開発する必要があります。 アプリ開発をするので、データベースを非公開にすることができ、接続先の内部が変更されたとしても Web / AP 上で動くアプリで変更内容を吸収することができる点がメリットです。 デメリットは追加アプリ開発の工数が必要な点でしょうか。
大量データ通信には向かない(通信中にずっと Web/AP サーバーのリソースを消費し続けるのはあまり良くない設計)ので、通信データ量が多い場合はこの次のファイル連携で圧縮含めて検討した方が良いと思います。
【確認観点】
- 接続元IPアドレス
- 接続先IPアドレス
- 接続先ポート番号
- 接続先URL
- リクエストクエリパラメーター
- リクエストボディー
- 接続時に使うユーザーID/パスワード または 証明書
- 穴あけ設定
- ファイアウォール
- Webサーバー
ファイル連携
定期的に出力するファイルで連携を行います。 アプリケーション連携と同様にデータベースを非公開にできます。 また、大量データを通信する場合は圧縮することができるので帯域使用量を減らせる効果が期待できます。 難点はリアルタイム性に欠ける点でしょうか… 定期実行されるバッチでデータ生成して連携することになるので、定期実行の頻度に依存します。
【確認観点】
- 接続元IPアドレス
- 接続先IPアドレス
- 接続先ポート番号
- 接続先URL（ファイル命名ルール含む）
- 接続時に使うユーザーID/パスワード または 証明書
- ファイル圧縮する場合
- 圧縮ファイル名
- 圧縮ファイル内のフォルダ/ファイル構造
- 穴あけ設定
- ファイアウォール
- ファイルサーバー
連携内容
接続したときやり取りするデータのうち、
DB (テーブル)
基本的にはテーブル定義書に記載する内容と同程度の内容を確認する必要があります。 具体的には以下のような観点かと思います。
【確認観点】
- テーブル物理名
- カラム物理名
- データ型
- Not NULL
- 主キー
- ユニークキー
- ER図
tar / zip
大量のデータをやり取りする場合はこの形式になるかと思います。 実態として中身はファイルなので各ファイルにおける確認観点の詳細は該当の節を確認してください。
【確認観点】
- フォルダ / ファイル構造
CSV / TSV
まとまった集計データをやり取りする連携だと CSV / TSV 形式になると思います。 集計データなので基本はファイル連携（バッチ処理による連携）となることが多いと思います。
【確認観点】
- ヘッダー有無
- カラムごとのフォーマット ( 0 や null の扱い含む )
- ダブルクォート (") 有無
XML
構造化された形式で読み取りやすいですが…ファイルサイズがすぐ大きくなってしまうのが難点です。 サーバー同士の通信で通信内容も軽量であればこの形式が適切かと思います。
【確認観点】
- DTD または XML Schema
JSON
最近だと JSON 形式も増えてきている気がします。 できることは XML と似ていますが XML に比較してファイルサイズを小さくできる点がメリットです。
【確認観点】
- JSON Schema
バイナリ
ローレベルな通信だとバイナリ形式になる気がします。 「先頭○バイトから○バイトは××を示すデータ。」といった形式です。 データ量を小さくかつ読み取りも早くできるのが特徴。 半面、実装はとても面倒…。 実装が面倒すぎて個人的にはあまり使いたくないです。。
【確認観点】
- ファイルフォーマット (バイト位置とデータの意味)
その他
上記までに含まれていないが気にした方が良いことをツラツラとあげていきます。
接続タイミング / 接続頻度
外部システム連携をどの程度利用するかも重要な決め事です。 接続で使われるサーバーリソースやネットワーク帯域が増えると既存のシステムにも影響が出てくるので、時間帯や頻度、通信量を予測しておきます。
【確認観点】
- 接続してくる時間帯
- 接続頻度
- 同時接続数
- 1回の接続レイテンシー
文字コード
やり取りするデータの文字コードは重要です。 きちんと決められていないと読み取ってもらえません。 最近は UTF-8 を使うことが多いとは思いますが、システムが古いと Shift-JIS なんとこともあります。 「こうだろう」と決めてかからず、必ず確認します。
順序保証
連続するデータ、リストデータの場合、順序保証しているかどうかを取り決めておきます。
リカバリ
どちらかというと接続元が考えることかもしれません。 接続に失敗したときどのように復帰させるかを考えます。 以下の確認観点リストの最後にもある通り「接続先が出力するデータに誤りがある」ことも考えられるので、リカバリを考えると受け取ったデータのログを残さず直接取り込むのは良くない設計かと思います。
【確認観点】
- 接続が開始できない
- 接続できたが途中で切断された
- データ受信できたが破損していた
- データ受信して取り込めたが、実はデータに間違いがあった
スタブ / ドライバ
設計が終わって開発が始まると必要になってくるのが スタブ / ドライバ です。 これだけでも1本記事がかけそうなので、ここでは簡単にだけ触れます。
スタブ
接続元側を開発するとき、接続先を仮置きで準備します。 この仮置きした接続先をスタブと呼びます。 仮置きなのであまり作りこまず単純な応答を行うものを作成します。
ドライバ
接続先側を開発するとき、接続元を仮置きで準備します。 この仮置きした接続元をドライバと呼びます。 ドライバを作るといったことはあまりないような気がします。 作らなくても直接DBをのぞいてみたり、Fiddler でリクエストを模倣したり、直接ファイルをのぞいたりはできます。
かなり長い記事になってしまいました…。 参考になったでしょうか？ 最近は単独システムで完結しなくなってきたので、他システム連携するときが必ず来ます。 そんな時にこの記事の観点が役に立てばと思います。
参考記事
- @IT - システム間連携のアーキテクチャ、4つの基本パターンと正しい適用のポイント
- Qiita - 他システムとのデータベース連携について
- IT pro - 他システムとの連携に関する要求の取りまとめ方
最後に… このブログに興味を持っていただけた方は、 ぜひ 「Facebookページ に いいね！」または 「Twitter の フォロー」 お願いします！！