フィオラノ ソフトウェア ジャパン ブログ
    Twitter
  • Facebook
  • Google+

マイクロサービス (その5) –賢さをどこに求めるか–

miroservice-banner

前回 (その4) は、機能性の低いパイプ (Dumb pipe: 土管) のアーキテクチャとして、仮想的なバスを提示しました。

今回は、“smart endpoints and dumb pipes (賢いエンドポイントと機能性の低いパイプ)” の一方である “smart endpoint (賢いエンドポイント)” について考察してみたいと思います。
ビジネス ロジックを複数のマイクロサービスからなるコレオグラフィとして実現し、マイクロサービス間の通信はライトウェイトなメッセージング サーバーで構成される仮想的なバス (Dumb pipe: 土管) によって支えるアーキテクチャが良いと説明しました。
このアーキテクチャによって、オンプレミスやクラウド上に分散されて配置されるマイクサービスを連携し、1つのビジネス ロジックとして実行することが可能になります。

VirtualBus
土管とコレオグラフィ

マイクロサービス (その4) — 仮想バス アーキテクチャ —

miroservice-banner

前回は “smart endpoints and dumb pipes (賢いエンドポイントと機能性の低いパイプ)” の意味することにについて考察しました。

今回は、マイクロサービス間の連携を支えるこの “smart endpoints and dumb pipes” の具体的なアーキテクチャについて考えてみます。

 

マイクロサービスとは、複数のマイクロサービスが連携して業務処理を実現するアプリケーション アーキテクチャです。
単一の機能にしぼった小さな (マイクロな) サービスを連携させることで、大きな処理を実現するアプローチは、UNIX シェルのパイプのエッセンスを有しています。

マイクロサービス (その3) — 土管 (Dumb pipe) の意味 —

miroservice-banner

前回は、マイクロサービスについてUNIX のパイプ機能をアナロジーとして取り上げ説明しました。
今回は、マイクロサービス間の連携を支える “マイクロサービスにおけるパイプ機能” について考察してみたいと思います。

Dumb Pipe (土管) ?

マイクロサービスを提唱したJames Lewis氏が Martin Fowler氏と共に著した『Microservices』*1という記事の中で、「Smart endpoints and dumb pipes」*1というセクションを設けて、マイクロサービス間の連携について説明しています。

このセクションではまず、対極にある smart pipe を説明しています。smart pipe の例として ESB (エンタープライズ サービス バス) などのアプリケーション連携製品をあげています。

マイクロサービス (その2) – パイプライン —

miroservice-banner

前回 (その1) は、マイクロサービス アーキテクチャについてモノリシックなアプリケーションと比較して概説しました。今回は、マイクロサービス間のコミュニケーションに焦点をあててマイクロサービス アーキテクチャを掘り下げていきます。

UNIX のパイプ

マイクロサービス アーキテクチャは、クラシックな技術ではありますが UNIX のパイプ機能になぞらえることができます。

UNIX のパイプ機能は、最初のシェルが作られた 1970 年代に誕生しています。このブログを読まれている方の中には、UNIX のシェルを直接使用してコマンド実行をしたことがない人もいるかもしれません。簡単に説明してみます。

ハブ&スポークの問題点 –バス トポロジーとの対比 —

hubSpoke_jp2

1.EAI 製品の登場

過去、企業の IT インフラは複雑化の一途をたどるスパイラル状態にありました。既存のレガシー システムに数多くのパッケージ アプリケーションを加えていき、メンテナンスの困難な情報サイロを作り出してしまっていたのです。
このような状況では、ビジネス データもまた各アプリケーションに分散され、情報のサイロ化をも生じています。ビジネス データがこのような状況に陥ると、意思決定に必要な情報をタイムリーに得ることが非常に難しくなります。
1990 年代に登場した EAI (エンタープライズ アプリケーション統合) 製品は、上述の状況を改善することを目的としたものでした。この当時の EAI 製品は、中央にブローカーと呼ぶ “ハブ” を配置し、各アプリケーションは中央のハブを経由して連携する、いわゆる “ハブ&スポーク” の形式を採っていました。

コレオグラフィ vs オーケストレーション

corp_brochure_168x203-OLD

SOA や BPM の世界では、ビジネス プロセスの構築や実行制御を指すものとして、コレオグラフィ と オーケストレーション という 2 つの用語が使われています。

Fiorano Software では、ビジネス プロセスの構築/実行を指す言葉として コレオグラフィ を意図的に用いています。

これは、コレオグラフィとオーケストレーションという言葉が意味するものが、ビジネス プロセスの構築/実行においてそれぞれ異なるからです。

1. 辞書的意味

コレ1. オグラフィ (choreography) とオーケストレーション (orchestration) の辞書などに掲載されている意味合いは、次のようになっています。

  • コレオグラフィ (choreography)
    バレーや舞踏などの振り付け
  • オーケストレーション (orchestration)
    オーケストラによる演奏方法

バレーとオーケストラとの間の大きな違いは、実演中に指揮者が存在するか否かという点にあります。
これを、ビジネス プロセスの構築/実行に当てはめて説明してみましょう。