マイクロサービス アーキテクチャに基づくアプリケーション連携には、下記で説明するように多くの利点があります。
フィオラノのプラットフォーム製品は、マイクロサービス アーキテクチャに基づいており、このアーキテクチャ スタイルを包括的にサポートしています。
|
|
実行フレームワークと粗い粒度のコンポーネント
マイクロサービスは、独立したプロセスとして稼働するソフトウェア ユニットであり、他のマイクロサービスと独立してリプレースやアップグレードが可能となっています。
マイクロサービスのフレームワークは、クラシックな技術ではありますが unix のパイプに例えることができます。
- インプット ポートからデータを受信 (unix の標準入力)
- マイクロサービスに定義(記述) されたロジックでデータを処理 (unix のコマンド)
- 処理結果をアウトプット ポートから送信 (unix の標準出力)
- あるマイクロサービスのアウトプット ポートを別のマイクロサービスのインプット ポートに接続することで一連の処理を実行
(あるコマンドの標準出力を別のコマンドの標準入力に接続。unix のパイプ)
このようにマイクロサービス同士が通信し、WS-* や BPEL などの複雑で中央集権的なオーケストレーションではなく、シンプルで自治制御的/自律的なコレオグラフィとして連携します。
フィオラノのマイクロサービスは、粗い粒度のサービス コンポーネントですが、数百ものインタフェースを持つほど大きくて複雑というわけではありません。
個々のマイクロサービスは、その数に制限があるわけではありませんが、通常数個のインプットおよびアウトプット インタフェースを持つだけです。
また、デフォルトでは個々のマイクロサービスはそれぞれ独立したプロセスとして稼働しますが、複数のサービスをグループ化して単一のプロセス上で稼働させることも可能です。
アプリケーション システムは、相互に連携し合う複数のサービスから構成されます。連携のベースとなるのは、リクエスト-リプライまたはメッセージングによるコミュニケーションです。
フィオラノのプラットフォームでは、マイクロサービス間の連携に、標準規格である JMS (Java メッセージ サービス) を用いています。JMS は、リクエスト-リプライ (同期式) およびパブリッシュ-サブスクライブ (非同期式) の両方式をサポートしており、他の特殊な API を必要としません。
JMS の非同期メッセージングの特筆すべき利点は、他のマイクロサービスを停止することなく、任意のサービスだけをリプレースしたりアップグレードできることです。これによって、稼働中にその一部の機能 (サービス) を置き換えたり、変更を加えたりできるようになり、ユーザーへのサービス提供自体を停止してまう必要がありません。
|
ビジネス遂行に必要な機能を実装
個々のマイクロサービスは、主として単一の機能単位で実装されます。機能単位とは、アプリケション システムの機能を分割したもので、ビジネス遂行のための細分化された機能を指します。従来のメソッド呼び出しや RPC にみられる、非常に小さなデータ処理ロジック (例: データのソート、データの取り出し/書き込み など) とは異なります。マイクロサービスは、ビジネスロジック (業務処理ロジック) レベルを実行するものとして開発されます。
大きなシステムを開発する場合、開発者は以下の手順を踏みます。
- システム全体で実行すべき機能群を単一な機能として細分化
- 細分化された機能を個々のコンポーネントとして定義
- コンポーネントをフィオラノのマイクロサービスとして実装
マイクロサービスを設計/実装するフィオラノの開発ツールには、以下の機能が備わっています。
- フレームワークの自動生成 (コンフィグレーション設定、パラメータ指定による作成)
- インプット ポート、アウトプット ポートの生成
- ポートを介した他のマイクロサービスとのインターアクション生成
- 他のサービス (マイクロサービス化されていない外部サービス) とのインタフェース生成
- 核となるビジネス ロジックの実装 (プログラミング)
フィオラノのツールによってマイクロサービスの外枠が自動生成できるため、ユーザーはマイクロサービスの核であるビジネス機能の開発に専念できるようになります
|
独立した "プロダクト" とも言えるマイクロサービス
フィオラノのプラットフォーム上に実装されたマイクロサービスは、単体のプロダクトであるとも言えます。
ここでいうプロダクトとは、他のものからは完全に独立し、必要なものを全て含んでいるということ意味します。外部ライブラリといった他に依存するものを持たない、別のサービスとは完全に独立して開発、テストされた、あたかも単体の製品パッケージとも言えるものです。
この独立性によって、マイクロサービスに加えられた変更や追加機能が、他のサービスに対して変更や再デプロイメントといった影響を及ぼすことがありません。変更追加された新たな機能は、他のサービスからアプリケーションの新規機能として容易に利用できるようになります。
また、この独立性によって、アプリケーション全体を停止することなく任意のマイクロサービスの変更/機能追加することが可能となります。アプリケーション全体の停止を伴わない変更方法は、"プロセス セントリック" な BPEL や類似の標準規格では不可能な方法です。
|
自律的な稼働と連携基盤のトランスポート機能への特化
マイクロサービスは、他のマイクロサービスとは完全に疎結合な関係にあり、そのビジネス ロジックはすべてマイクロサービス自身によって処理管理されます。
フィオラノのプラットフォーム上におけるアプリケーションは、マイクロサービス間のコレオグラフィを定義しながら構築していきます。
コレオグラフィには、マイクロサービスの呼び出しをコントロールし、ビジネス プロセスの指揮を執る指揮者は存在しません。マイクロサービスが中央からの依頼 (リクエスト) によってロジックを実行し、その結果を依頼者 (中央) にレスポンスするという考え方は、基本的にはありません。
マイクロサービスは、コレオグラフィ定義時に定められた条件に従って自律して稼動し、条件に合致した他のサービスにデータを送ります。
フィオラノ プラットフォーム上では、基本的に、マイクロサービス間の連携に JMS プロトコルを用いています。
これは、複雑なプロトコルである WS-Choreography や BPEL とは対極にあるライトウェイトな連携プロトコルです。
なお、フィオラノの外部にあるサービスやパッケージ アプリケーションなどを考慮して多くのプロトコルもサポートしています。
- フィオラノ プラットフォームに構築されたマイクロサービス間の連携
- 外部のマイクロサービスや他のサービス/パッケージ アプリケーションなどとの連携
- ライトウェイトな標準プロトコル: JMS、REST
- その他の標準プロトコル: SOAP (WS-*)、FTP、SMTP、POP3 など
- アプリケーション独自のプロトコル (例: SAP の BAPI/IDOC)
フィオラノのプラットフォーム上のマイクロサービスには、2つのカテゴリがあります。
- アプリケーション マイクロサービス (ビジネス ロジック)
- 連携インフラ コアのマイクロサービス (連携ロジック)
|
マイクロサービスのカテゴリ
|
連携インフラ コアのマイクロサービスには、以下のような種類があります。
- ルーティング
- キャッシュ処理
- データ変換 (テキスト、XML、JSON への変換、データマッピング など)
- ビジネス ルール処理
連携インフラのマイクロサービスによって、アプリケーション マイクロサービスはそのビジネス ロジックにフォーカスすることができるようになります。
例えば、データフォーマットの変更やルーティング条件の変更などが連携先のマイクロサービスに起こっても、ビジネス ロジックを担当するマイクロサービスへの影響を最小限にとどめることができます。連携インフラのマイクロサービスが、このような変更を吸収するからです。
また、連携インフラのマイクロサービスが存在することによって、連携プラットフォーム (例: ESB など) に必要な連携機能が抑えられ、トランスポート機能に特化させることができます。これによって、連携プラットフォームは非常に小さなメッセージング サーバー (JMS サーバー) とすることが可能となります。
このようなマイクロ サーバーとも呼べるソフトウェア サーバーは、デプロイメントのコストを低くし、オンプレミスやクラウドへの配置をより柔軟なものとしてくれます。ビジネスの拡大や処理負荷の増減に合わせてリニアに、マイクロ サーバーの配置を増やしたり減らしたりすることがたい容易なものとなります。
|
マルチ言語のサポートと個別の管理
フィオラノ プラットフォーム上のマイクロサービスは他のマイクロサービスから完全に独立しています。
このため、マイクロサービスの開発言語が異なっていても、何らの問題もなく連携することができます。
フィオラノでは、次の言語をサポートしています。
- Java
- C
- C++
- C#
- スクリプト言語 (JavaScrpt, Pearl, Python など)
個々のマイクロサービスのデプロイメント、システム管理としての停止、再起動などはそれぞれ別個に実施することができ、デプロイメントなどのシステム管理を柔軟なものとしています。
|
非中央集権なデータ管理
マイクロサービスは、データを個々に保有します。マイクロサービスのビジネス ロジックを実装する際にそのロジックで必要とするデータをマイクロサービス内に保有するように設計されます。
従来のモノシリックなアプリケーションにみられる中央の単一の共有データストアというものは必要としません。
マイクロサービスが個々に自身のデータ (永続化ストレージ レイヤー) を管理します。これらのストレージは、マイクロサービス毎に異なるデータベース技術を使用する場合も、同一のデータベース技術の異なるインスタンスという場合もあります。
中央の共有データストアを連携プラットフォームが提供しないため、マイクロサービスにはグローバル変数という概念は存在しません。
情報はメッセージのペイロードとしてネットワーク上に分散しているマイクロサービスに配信されます。
複数のマイクロサービス間で永続化ストレージを共有する場合には、エラー発生時にトランザクションのコンペンセーション (保障/補正) 処理が必要となります。
マイクロサービスでは、基本的にトランザクションレスなアプリケーション連携が通常なものとなっています。トランザクション処理を行う必要がある場合には、JMS メッセージングに分散トランザクション機能を追加するか、別途トランザクション モニターなどを使用します。
(JMS の規格では分散トランザクションが必須となっておらず、製品によっては分散トランザクションをサポートしていない場合があります。)
|
インフラの自動化
フィオラノのプラットフォームでは、マイクロサービスおよびマイクロサービスの連携について以下のフェーズを設けています。
- 開発中
- QA (テスティング/デバッグ中)
- ステージング (本番待機中)
- 本番
これらのフェーズ間をボタン クリックで自由に遷移させることができるようになっています。
マイクロサービスを稼働させるプラットフォーム (マイクロサーバー) には、どのフェースのマイクロサービスを稼働させることが可能かプロファイルとして定義されています。
この機能によって、マイクロサービスのデプロイメントや起動を自動化できます。例えば、本番用マイクロサービスの起動を選択すると、本番フェーズにあるマイクロサービスが本番用プラットフォームに自動的にデプロイされ、起動されます。このためのツールはネットワークをグラフィカルに表示させた UI とスクリプトによるコマンド ライン インタフェースを有しています。
|
エラー検出、例外ハンドラー
フィオラノのマイクロサービスは基本的に JMS プロトコルでコミュニケートしています。これを利用してエラーを一括して処理する例外ハンドラーを設けています。
例外ハンドラーもまたマイクロサービスとして稼働しています。個々のマイクロサービスがエラーを検出すると、通常の連携と同じように例外ハンドラーに JMS によってエラー メッセージを送ります。これによって、エラー発生時の複雑な処理を中央で一括して行えるようにまります。個々のマイクロサービスでは、エラー発生時の処理を考慮する必要がなく、例外ハンドラーにエラー メッセージを送信するだけで良いようにしています。
また、ブラウザ ベースの監視ツールも用意されており、分散されて稼働しているマイクロサービスを任意の場所で集中すて監視および管理ができるようになっています。
|