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

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

miroservice-banner

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

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

VirtualBus
土管とコレオグラフィ

アトミック vs コンポジット –マイクロサービスの粒度–

atomic-compsite

(この記事は、Fiorano Software Global Blog *1  に投稿された “Microservices – The issue of Granularity: Atomic or Composite?” *2  の意訳です。)

マイクロサービスを開発する際には、常にその粒度について議論の対象となっています。

デベロッパ、ソリューション アーキテクト、アナリストは、サービスの最適なサイズを以下に定義するか議論を続けています。この議論は、多くの場合、次の2つの方法論に帰着します。

  • 単一レベルのサービス
  • 2段階レベルのサービス

マイクロサービス (その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 製品は、中央にブローカーと呼ぶ “ハブ” を配置し、各アプリケーションは中央のハブを経由して連携する、いわゆる “ハブ&スポーク” の形式を採っていました。

マイクロサービス (その1) – モノリシックとの対比 —

miroservice-banner

SOA の難点とマイクロサービスへの期待

クラウド、ビッグデータ、API エコノミーなどデジタル ビジネスの領域に ”マイクロサービス *2” というバズワードが現れてきました。

サービス指向アーキテクチャ (SOA) への期待が薄れる中、アプリケーション開発のアーキテクチャ スタイルとしてマイクロサービスに注目が集まっています。

2000年代の初期に登場した SOA は、大きな期待を集め、また導入に成功したプロジェクトも多くありました。それにもかかわらず、今日では、いくつかの理由によって、過剰に宣伝されたハイプ (hype) なテクノロジーとみなされるようになってきました。

SOA は、サービス間のインタフェースを定義するだけで数か月も要する複雑でコスト高なものとみなされるようになっています。SOA のプロジェクトでは、サービスの粒度を非常に大きなものとし何種類ものインタフェースを有するものとして実装されがちです。これはサービスに汎用性を持たせようという意図の結果だと思われるのですが、却って使い勝手が悪くなり、SOA のメリットの1つであるサービスの共有/再利用を阻害してしまいます。別の極端な例は、サービスを数行のコードしか持たない小さなものとして実装してしまうケースです。このような小さなサービスでは簡単で単純な業務処理を実行するのに、数十、数百のサービスを連携しなければならず、サービス間の通信だけで多大な処理時間やコンピュータ リソースを費やしてしまうことになります。

SOA の難しさの1つに、サービスの粒度決定があるといってもよいでしょう。

このクラシックな SOA が持つ欠点を解消するものとして、アプリケーション連携のアーキテクチャへのマイクロサービスの応用に期待が集まっています。

マイクロサービスの詳細を見ていく前に、モノリシックなアプリケーション アーキテクチャと対比してみましょう。

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

corp_brochure_168x203-OLD

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

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

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

1. 辞書的意味

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

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

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

API マネジメントの必要性

IoT_blog

API エコノミー

“モノのインターネット (Internet of Things: IoT)” を実現するものとして API は、今日の企業にとって最も重要な技術となっています。
API は、企業が有するデータやアプリケーションを第三者が作成した携帯アプリ、アフリエイトの Web サイトに公開することを可能とします。API によって、企業はそのビジネスを外部プラットフォームの上に拡張することができるようになるからです。

良く知られている例に、Google 社の “Google Maps” の API があります。多くの企業が自社の会社案内やアクセス マップのWeb ページに Google Maps の API を利用して地図を表示させています。
Google 社に限らず、Yahoo !、Amazon、ぐるなび、楽天、Facebook、Twitterなどが API を公開し、自社のサービスを様々な形で利用してもらう施策を実施しています。

メッセージング再入門 (後編) — イベント駆動と非同期メッセージング —

messaging

1.3 イベント駆動によるアプリケーション

1.3.1 イベント駆動と非同期メッセージング

現実世界の業務処理では、”何らかの事象 (イベント) が発生するとそれに応じた業務処理が実行される” というケースが数多くあります。例えば、イベントには次のようなものがあります。

  • 倉庫に部品が入庫した
  • 製造ラインで不良品を検出した
  • 株価が変化した
  • 新規顧客がデータベースに登録された
  • 在庫数が閾値を超えた
  • POS 端末で特定商品の売上げを検出した

今回は、イベント駆動によるアプリケーション実行とメッセージングとの関係について考察します。

12