Future Tech Blog
フューチャー技術ブログ
Infrastructureカテゴリ

春だから学ぶシステム連携

はじめに

こんにちは、TIG真野です。春の入門連載2021の1日目です。

システム間のデータ連携は業務システムでは不可欠な要素ですが、初心者にはとっつきにくい概念です。けれどシステムとしての付加価値はデータを繋げることで生まれることが多く、非常に重要です。

本記事ではそんなデータ連携について、具体的なパターンを例に上げて説明します。

システム間のデータ連携とは

システム間のデータ連携とは、システム間である共有したいデータの受け渡しを行うことです。データ交換と言うこともありますし、システムI/F（システムアイエフ）と呼ぶことも多いです。

システムAとシステムBの連携図

この共有データのやり取りのために幾つかの取り決めが必要です。いつ・どのような項目を、どのようなプロトコルで渡すかといったことを両者で合意する必要があります。一般的にはデータを渡す側を配信（送信）、受け取る側を集信（受信、Import）と呼びます。配信と集信を合わせて集配信と呼ぶこともあります。

共有データのよく利用される形式の1つは、ファイル 形式や、何かしらのWeb APIやRPCで提供される事が多いです。

データ連携の分野では、Enterprise Integration Patternsという名著があり、共有データといった呼び方はそちらに揃えていますので、少しお高いですが興味がある人は読んで見ると一段上に上がれるかもしれません。

システムI/Fはなぜ必要か？

システム連携がなぜ必要か、ここにピンと来ない人も以外と多いです。簡単に説明します。

例えば、システムAをA社、システムBをB社の業務システムとします。

A 社と B 社は業務上取引があり、もともとは「TEL で注文を行い、請求書を郵送でやり取りすること」で取引を行っていましたが、これでは取引回数が増える度に人員を増やさないと業務が継続できそうにありません。なんせ1回で 15 分程度は、お互いの事務処理を動かす必要があります。しかも TEL なので、TEL が集中する時間とそうでない時間があり需要の見極めには長年の経験と勘が求められました

電話での発送のやり取り

電話だと大変なので、やり取りをメールに寄せ請求書や帳票をPDF添付するといったこともあるでしょう。これでもTELで同期的に処理するより属人性が減りかなり楽になりました。

メールでの発送のやり取り

しかし、システムからPDFを出力しメール添付で送信したり、メールからPDFを取り出しシステムに入力したりといった業務はなくなりません。PDFに記載されている項目のチェック作業や、万が一取引ができない場合にお断りを入れたりする業務も作業負荷としてはかなりのものです。

そのため人間を介在させること無く、システム同士でデータをやり取りさせたいという要求が生まれるわけです。どうせシステムからデータを抽出して、相手方に渡して、
相手方はそれをシステムに入力するのであれば直接システム同士でデータ連係させた方が間違いもなく確実じゃないかということです。

システム化でスッキリ

システム A に入力したデータは、B 社のシステム B に自動で連携されるので、もはや B 側ではデータの受付処理を人間が行う必要がなくなります。現実的には何か人間の意志入れが必要な場面は残るかと思いますが、大部分の業務は簡略化できました。

やや極端な例を示しましたが、なるべく人が考えなくても済む部分はシステムに任せたいという背景は理解できたと思います。

また、今回はシステムA、システムBで事業会社が異なりましたが、社内システムであっても同じような要求がでてくるので考え方は同じです。

連携パターン

さて共有データ（先程の例だと注文データ）はどのような形式で連携されるかです。

Enterprise Integration Patterns本では、ファイル・DB・RPC（Remote Procedure CAll）・メッセージングの4つで分類分けされています。大別するとシステム連携はこの4パターンのいずれかで行われているということです。それぞれの特徴を説明します。

ファイル

ファイルI/F連携

ファイル連係はその名の通り、やりとりしたい共有データをファイルによって行う方式です。

ファイル連係は見方を変えればストレージを共有するとも言い換えられます。そのため、共有するストレージが単一障害点にならないように設計する必要があります

ストレージは、AWSだとS3といったオブジェクトストレージが利用されることが多いでしょう。SFTPなども依然としてよく使われるプロトコルです。

仮にS3を利用する場合は、利用するS3バケットはどちらの所有であるべきか、などはよく議論になるポイントです。

また、処理済みの場合はオブジェクトのタグ付けで status:complete を付与してステータス管理したり、二重取り込みを禁止するために最初にリネームするなどの工夫がよく見られます。

ある程度のデータ規模になるとファイル形式が採用される事が多く、1日分の処理データや、ある断面でのマスタデータなどを連携したいときによく用いられます。

API/RPC

API連携

RPC のプロトコルとしてよく使われるのが REST-API（JSON Over HTTP）です。最近であればgRPC（Protocol Buffers over HTTP/2）も採用実績が増えています。どちらもマイクロサービシーなシステムを構築する際にもよく使われる技術でもあります。

ファイル連係に比べてよりリアルタイムな連係が可能ですが、比較的大量データの連係には不得意です。システム間連係ではある程度上限が決まっているデータの連係に用いましょう。

DB

DB連携

DB連携は、データベースを共有しあるテーブルに書き込まれているデータを共有する方法です。抽出条件は日付カラムやらステータスカラムやらを用意することが多いでしょう。
こちらもファイル連携と同じく、配信・集信のどちらかのデータベースを利用するかでパターンが分かれます。

DB連携はデータ反映の鮮度が早く確実、大量データの連携も可能ですが、依存関係が密結合になってしまうのが難点です。
昨今はマイクロサービスなど疎結合なアーキテクチャを採用することが多く、DBを共有してしまうと自システムの都合でインフラのメンテナンスを行いにくくなったり、データ連携で負荷が生じ、予期せぬ障害連鎖にも繋がりかねません。また、一度密結合になった連携を、疎結合に戻すのは一般的に難しいためできるなら避けたい法式です。

メッセージング

メッセージングで連携

RPC と異なり、配信側はメッセージを送信した後、集信側の処理結果を待たずに配信を完了とする方式です。パブリッシュ・サブスクライブ（Publish-Subscribe）方式が代表的で、配信：集信＝１：N の場合には有効な手法です。プロダクトとしては、Apache Active MQ や ZeroMQ、Apache Kafka などが有名です

まとめ

  • システムのデータ連携は、糊付けの部分でかなり地味。されどできる便利だしユーザ目線からすると超重要です
  • 連携法式は大分類で捉えると理解しやすい
    • 静止点がとれ、ある一定のデータ量になるデータ交換を目的とするシステム I/F ではまずファイル連携の利用を検討しましょう
    • リアルタイム性を求められるなど要件が出てきた段階で RPC やメッセージングの利用を検討しましょう
    • 逆に、イベントの通知を目的とする場合はファイル連携ではなく、RPC やメッセージングの利用を検討しましょう