システム間連携のアーキテクチャ、4つの基本パターンと正しい適用のポイント：徹底解説！ ITアーキテクトとは何か？（4）（2/2 ページ）
パターン3. ファイル連携
ファイル連携は、簡潔に述べると次のような処理の流れとなります。
- 連携したいデータを連携元システムがファイルに出力する
- 出力ファイルを連携先サーバーへ転送する
- 転送されたファイル内のデータを連携先システムが取り込む
この方式は、大量のデータをまとめて転送し処理するので、バッチでの連携によく利用されます。
システム間での連携において、連携先のシステムの内部仕様が年月の経過とともに変わっていくことが想定されます。このため、連携用ファイルの作成や連携ファイル取り込みについては、ユーティリティアプリケーションとして用意しておき、メインの業務処理と切り離しておくと保守が容易になります。
また、ファイルの内容を直接業務テーブルに反映するのではなく、いったん連携用テーブルに取り込むようにしておくことで、連携相手が複数存在し、ファイルフォーマットも異なるような場合に対しても、対応が取りやすくなります。
ファイルの転送には、「ftp」や「scp」などのOSが備えるコマンドを利用することも可能です。ただし、これらのコマンドでは転送エラーが検出されてもファイルの自動再送機能は用意されていません。エンタープライズシステムでは、このようなエラー発生を考慮した運用を行う必要があります。
また、ファイル連携では、ファイル転送（集信・配信） 前後に定型的な処理、例えばファイル圧縮や解凍、ファイルのバックアップ、リネーム処理などを実行したいケースがよくあります。これらの定型処理を実行するためのシェルスクリプトやユーティリティなどの準備を怠らないように注意しましょう。
ファイル連携用の商用ツールでは、通常のファイル集信・配信に加えて、エラー発生時の再送や、ファイル集配信前後のジョブ起動を実行できるものがあります。ファイルによるシステム間連携でよく使用される「HULFT」は、その一例です。このような商用ツールを利用できる環境が用意されている場合は、ツールが提供する機能を事前によく調査し活用するとよいでしょう。
パターン4. メッセージング
この処理方式では、連携元アプリケーションはメッセージキューに対してメッセージを書き込み、連携先からのレスポンスを待つことなく次の処理へ進むことが可能です。連携先アプリケーションはキュー経由でメッセージを取得して処理を進めます。
図4 メッセージングの概念各アプリケーションが非同期に処理を進められることがこの方式の大きな利点です。非同期処理とすることで、連携先アプリケーションが稼働しているかどうかの影響を受けずに処理を進めることが可能です。
連携元が連携先の処理結果を確認しながら業務処理を進める必要がある場合には、Webサービスの項でも説明したように、連携元から処理結果を知るための何らかの仕組みが必要です。ここでも、前述のコールバック方式やポーリング方式の適用が考えられます。
メッセージがキューイングされて未配送であるときに、サーバーまたはミドルウェアに障害が発生した場合、メッセージがロストする可能性があります。このようなケースでの挙動は、メッセージングを実装する製品や設定により異なりますので、事前に確認しておきましょう。また、ミドルウェアの信頼性を補完するような機能の作り込みはコストも発生します。機能を作る前に、ユーザー企業、あるいはビジネス部門にサービスレベルを確認し、合意しましょう。
メッセージングの機能はさまざまなミドルウェア製品において提供されています。以下に、主要なメッセージングミドルウェアをまとめておきます。
| 開発元 | メッセージングミドルウェア |
|---|---|
| IBM | WebSphere MQ |
| Oracle | WebLogic（JMS） |
| Pivotal | Rabbit MQ |
| Apache | ActiveMQ |
| JBoss | HornetQ (JMS) |
システム間連携において考慮すべき点
文字コード変換
連携元のシステムが出力するデータの文字コードと、連携先システムが処理可能な文字コードが異なる場合、どこかで適切な文字コードに変換しなければなりません。例えばファイル連携の場合、以下のいずれかの対応が必要です。
- 連携元システム側で連携先システムの処理可能な文字コードのファイルを用意する
- 連携元システムは連携元の文字コードのファイルを出力し、連携先システム側で文字コード変換を実施する
文字コード変換機能はさまざまなレイヤーで提供されていますので、処理方式に応じて扱いやすいものを選択するとよいでしょう。
- 変換コマンドを利用する (「nkf」や「iconv」など)
- ライブラリを利用する (例：Javaなら「java.nio.charset」を利用するなど)
- 連携製品の機能を利用する (「HULFT」や「MQ」が提供する機能を利用するなど)
ポイント
文字コード変換を行う際、変換先の文字コードに存在しない文字が含まれる場合もあります。このようなデータが出現したときの扱いをどうするか（例えば他の文字に置き換えるのか、そのような文字が見つかったらエラーとするのかなど）をあらかじめ検討しておきましょう。
メッセージキューの構成
多くのメッセージング製品において、メッセージキューごとに割り当てるリソース量を設定できるようになっています。例えば、送り先に保存可能な最大のバイト数や、最大メッセージ数、１通当たりの最大メッセージサイズなどです。
ここで割り当てられたリソース量を超えるようなメッセージをシステム間でやりとりすることがないかどうかを検討しておく必要があります。もし超えるような場合は、メッセージキューの構成を見直してみてください。
図5 メッセージキューを共有する例
図6 メッセージキューを独立させた例順序保証
システム間連携において、連携元と連携先が１対１に対応している場合は処理の順序は保証されています。しかし、複数の連携元や連携先が対応する場合は、この順序性が保証されないケースが出てきます。
例えばメッセージングにおいて連携先での処理性能を向上させるために、１つのキューに多数のコンシューマー（メッセージを受信するアプリケーション）を用意し、負荷分散させることがあります。このような場合、コンシューマー全体で見たときの処理順序がメッセージの送出順序と異なってしまう可能性があります。
他にもさまざまな場面でメッセージの送出順序とデータの処理順序が変わってしまうことがあります。データの処理順序をアプリケーションとして保証する必要がある場合は、以下のような対応を行う必要があります。
- シーケンスなど処理順保証のためのIDを用意し、アプリケーションが利用する
- ロックなど、同時実行処理を制御する方式を利用する
- MQなどメッセージング製品固有の順序性保証の機構を利用する
リカバリ
ファイル連携やメッセージ連携における連携先の処理は、連携元とは非同期に、独立して処理が行われます。この連携先の処理における障害発生時のリカバリ処理も、極力この連携先システムの中だけで完結することが望まれます。
ファイル連携におけるリカバリでは、連携されたデータを修正し、処理を再実行＝リランすることでリカバリするようにできないか検討しましょう。このためには、連携されたデータを連携先システム側で一定期間保管しておくことも必要となってきます。
メッセージ連携におけるリカバリでは、連携先の処理が必要とするデータベースなどのリソースが一時的に利用できない場合に備えて、リトライする仕組みを連携先に持たせることも考慮すべきです。アプリケーションの要求仕様に応じて適切なリトライ回数やインターバル時間などを検討します。これらのパラメーターは運用とともに値を変更する可能性が高いため、業務プログラムに埋め込まずに外部設定できるようにしておくとよいでしょう。
各連携方式の比較
今回紹介したシステム間連携の基本パターンの長所と短所を以下に示します。
| 連携方式 | 長所 | 短所 |
|---|---|---|
| リソース共有 | ・リアルタイム連携に適する ・アプリケーションにとって、共有のための仕組みが最小限で済む |
・分散データベースを共有する場合、制約が多い ・原則として、システムと共有リソースが同じLAN上に配置されている場合に利用 |
| アプリケーション連携 | ・リアルタイム連携に適する | ・障害に弱い ・作り込みが大変 |
| ファイル連携 | ・大量データ送信に適する ・結合が疎であり、連携先の影響を受けにくい |
・リアルタイム連携に不向き |
| メッセージング | ・リアルタイム連携に適する ・障害に強い |
・大量データ送信はファイル連携より非効率 ・2フェーズコミットが求められるような密な連携には不向き |
今回は以上です。各種業務プロセスを特性に応じて円滑に運用するために、システム間連携の基礎をあらためて確認してはいかがでしょうか。
著者プロフィール
熊谷 宏樹（くまがい ひろき）
コーポレート本部 戦略技術センターフェロー
大規模な証券およびカード系システムのチーフアーキテクトを経験し、生産性と品質を向上させるための開発基盤の構築・展開に従事。現在は、社内のアーキテクト育成研修のリーダーを務めるとともに、現場のプロジェクトを支援している。「システムの挙動には必ず理由がある」をモットーに、トラブルの解決にも当たっている。
Copyright © ITmedia, Inc. All Rights Reserved.
注目のテーマ
ITmediaはアイティメディア株式会社の登録商標です。