前回 (その4) は、機能性の低いパイプ (Dumb pipe: 土管) のアーキテクチャとして、仮想的なバスを提示しました。
今回は、“smart endpoints and dumb pipes (賢いエンドポイントと機能性の低いパイプ)” の一方である “smart endpoint (賢いエンドポイント)” について考察してみたいと思います。
ビジネス ロジックを複数のマイクロサービスからなるコレオグラフィとして実現し、マイクロサービス間の通信はライトウェイトなメッセージング サーバーで構成される仮想的なバス (Dumb pipe: 土管) によって支えるアーキテクチャが良いと説明しました。
このアーキテクチャによって、オンプレミスやクラウド上に分散されて配置されるマイクサービスを連携し、１つのビジネス ロジックとして実行することが可能になります。
個々のマイクロサービスは、それが有する機能特性/機能ドメインによって下記の稼働環境を他マイクロサービスとは非依存に選択でき、これがマイクロサービスの利点ともなっています。
- 開発言語
- 稼働プラットフォーム (マシン/OS)
- 配置場所 (オンプレミス/クラウド、他組織の IT 環境、デバイスなど)
また、データは個々のマイクロサービスの中に隠蔽され、マイクロサービス間でデータを共有することはできる限り避けるように設計実装されます。こうすることで、他マイクロサービスを含む外部の変化変更からの影響を最小化できるからです。
メディエーション機能 *1
前述のようにマイクロサービス間の非依存性/疎結合性を高めると、マイクロサービスが通信する際にデータ形式などの違いを吸収するなど、本来のビジネスロジックではないメディエーション機能が必要となってきます。
メディエーションとは、日本語に訳すと “調停” や “仲介” という意味で、マイクロサービス間のデータ スキーマなどの違いを調整し、両者がうまくコミュニケーションできるようにする機能です。代表的なメディエーション機能を下の表にまとめました。
| メディエーション機能 | |
データ変換
|
|
| データ暗号化、圧縮 | |
フローコントロール (データのルーティング)
|
これらのメディエーション機能を如何に実現するかが、マクロサービスによるアプリケーション構築における課題の一つです。
ビジネス ロジックを実行するマイクロサービスの中にこれらのメディエーション機能をも持たせることは、マイクロサービスの利点を失わせるものです。モノリスなアプリケーションに近づいてしまう方法です。
フィオラノ ソフトウェアでは、メディエーション機能もマイクロサービスとして実装する方法を推進しています。フィオラノので製品では、上記の表に示したメディエーション機能毎にマイクロサービスを用意し、製品にバンドルしています。これらのマイクロサービスは、ユーザー独自のビジネス ロジックを実行するマイクロサービスと通信できるようにあらかじめプリビルトされています。細かな動作はパラメータ指定で選択できるようにしており、プログラミングすることなくビジネス ロジック間にメディエーション機能を組み込むことができるようになっています。
アダプター
マイクロサービスによるアプリケーション開発あるいはアプリケーション連携において課題となってくるのが、既存のアプリケーションです。コストや困難度を無視すれば、マイクロサービス アーキテクチャに基づくものへと再構築するということも可能です。しかしながら、製品ベンダーなどから提供されているパッケージ ソフトの場合には、作り変えることは不可能です。
レガシーなアプリケーションやパッケージ製品などは、マイクロサービスとするのではなく、今ある姿のまま稼働させることがベターな方法です。ただし、マイクロサーサービスからこれらの非マイクサービスなアプリケーションへのアクセス手段を用意しておく必要があります。これによって、既存ロジックをマイクロサービスによる新しいアプリケーションの中でも利用/再利用できるようになるからです。
アクセス手段は、いわゆるアダプターとしての機能を持ったマイクロサービスがベストです。
アダプターはアクセス先がサポートしているプロトコルに応じて、下の表に示す種類毎にマイクロサービスとして用意します。
| アダプター (代表的なもの) | |
| SAP アダプター | Salesforce アダプター |
| DBMS (JDBC) アダプター | JMS / MOM 用各種アダプター |
| Web サービス (SOAP) アダプター | HTTP アダプター |
| REST アダプター | FTP アダプター |
| SMTP アダプター | POP3 アダプター |
| SMS アダプター | HL7 アダプター |
| FIX アダプター | SWIFT アダプター |
| EDI 用各種アダプター | EJB アダプター |
| ファイル 読み書き用アダプター | |
マイクロサービスのレイヤー
マイクロサービスは次の３種のタイプに分けて考えるのが、現実のアプリケーション開発やアプリケーション連携には妥当な方法論のように思います。
- アプリケーション本来の機能を実装したマイクロサービス
ビジネス ロジックを実装。他のアプリケーションでもビジネス ロジックとして再利用可能。 - サポート機能を実装したマイクロサービス
その都度開発するのではなく、マイクロサービスの部品としてコンテナに格納しておく。あるいはマイクロサービスをサポートするプラットフォーム製品ベンダーのバンドルを利用する。
- メディエーション マイクロ サービス
データ変換などのメディエーション機能を果たす - アダプター マイクロサービス
マイクロサービス形態ではないビジネス ロジックにアクセスするための機能を果たす
これらのマイクロサービスのタイプは下図のようにレイヤー構造として図式化することができます。
“賢いエンドポイント” を実現するための現実的な解は、上図のようにマイクロサービスをタイプ分けしておくことだと思います。
参考 (資料、文献、Webサイトなど)
1. メディエーション機能
メディエーション機能の詳細については、筆者の ThinkIT での連載記事を参照してください。
1) ESB におけるデータ変換 (前篇)
http://thinkit.co.jp/free/article/0703/7/3/
2) ESB におけるデータ変換 (後編)
http://thinkit.co.jp/free/article/0703/7/4/
Twitter