6.1システム間連携

複数システムを連携させるとき、「とりあえずAPIでつなぐ」だけでは要件を満たせないことが少なくありません。システムアーキテクトは、データ量・処理のリアルタイム性・呼び出し元と呼び出し先の可用性の違いといった制約から、連携方式（REST API・ETL・EAI）と同期/非同期のどちらを採るかを判断しなければなりません。この判断を誤ると、応答遅延の連鎖や、一時的なデータ不整合への対処漏れといった障害につながります。

6.1.1REST API・ETL・EAI

• REST API＝HTTPのメソッド（GET/POST/PUT/DELETE等）とURLでリソースを表現し、システム間を疎結合に連携させる方式。呼び出し側と提供側が独立に開発・デプロイでき、Web/モバイルクライアントからも直接呼び出せる汎用性が利点だが、大量データの一括連携には1件ずつの呼び出しが非効率になりやすい。
• ETL（Extract/Transform/Load）＝複数システムのデータを抽出（Extract）→変換（Transform）→格納（Load）の順に処理し、データウェアハウスや別システムへ一括移送する方式。夜間バッチなど大量データを定期的にまとめて連携する用途に向くが、リアルタイム性は低い。
• EAI（Enterprise Application Integration）＝企業内の異種システム（会計・在庫・人事等）をハブ的な基盤で仲介し、個々のシステムがハブとだけ接続すればよい構成にする方式。システムごとに個別接続を組む（スパゲッティ状の連携）よりも接続本数を抑えられ、連携ルールの変更もハブに集約できる。

6.1.2同期連携と非同期連携の選択

• 同期連携＝呼び出し元が呼び出し先の処理完了と応答を待ってから次の処理に進む方式。処理結果をその場で使う必要がある用途（例：在庫確認後にその場で注文確定）に向くが、呼び出し先の遅延・障害がそのまま呼び出し元の遅延・障害として波及するトレードオフを伴う。
• 非同期連携＝呼び出し元がメッセージキュー等に処理を依頼したら応答を待たずに次の処理へ進み、結果は後で受け取るか問い合わせる方式。呼び出し先の一時的な遅延・停止の影響を呼び出し元から切り離せる（疎結合・耐障害性の向上）が、依頼から結果反映までの間はデータが一時的に不整合（結果整合性）になる時間帯が生じ、それを許容できるか業務要件を確認する必要がある。

あるシステムアーキテクトが、ECサイトの注文確定処理と、注文後のポイント付与処理の連携方式を設計するとします。注文確定時には在庫引当の結果をその場でユーザーに提示し、確定させるかどうかをユーザーに判断させる必要があるため、在庫システムの呼び出しは同期連携を採用します——在庫確認の結果を待たずに注文を確定させると、在庫切れの注文を受けてしまうリスクがあるためです。一方、ポイント付与処理は、ポイント計算サービスが一時的に混雑・停止していても注文確定自体を遅らせてはならないという要件があるため、注文確定後にメッセージキューへポイント付与依頼を投入する非同期連携を採用します。ポイントが画面上すぐに反映されなくても、数秒〜数分後に反映されれば業務上問題ない（結果整合性を許容できる）と業務部門から確認が取れているためです。もしここで同期連携を選んでいたら、ポイント計算サービスの遅延がそのまま注文確定処理の遅延として顧客に波及し、機会損失につながっていたはずです。さらに、既存の会計システムへの日次の売上データ連携については、大量の注文データを日次でまとめて集計・変換して会計システムへ流し込む必要があるため、個別のAPI呼び出しではなくETLを採用し、抽出・変換・格納のバッチ処理として設計します。このように、処理ごとに求められるリアルタイム性・データ量・許容できる不整合の程度を見極め、連携方式を使い分けるのが実務です。

6.1.3この節のまとめ

• REST API＝疎結合の個別連携、ETL＝抽出/変換/格納の定期一括連携、EAI＝ハブ経由で接続本数を抑制
• 同期連携＝結果をその場で使えるが遅延が波及、非同期連携＝疎結合・耐障害性は上がるが結果整合性が前提
• 連携方式はリアルタイム性・データ量・許容できる不整合の程度から逆算して選ぶ