前回 (その4) は、機能性の低いパイプ (Dumb pipe: 土管) のアーキテクチャとして、仮想的なバスを提示しました。
今回は、“smart endpoints and dumb pipes (賢いエンドポイントと機能性の低いパイプ)” の一方である “smart endpoint (賢いエンドポイント)” について考察してみたいと思います。
ビジネス ロジックを複数のマイクロサービスからなるコレオグラフィとして実現し、マイクロサービス間の通信はライトウェイトなメッセージング サーバーで構成される仮想的なバス (Dumb pipe: 土管) によって支えるアーキテクチャが良いと説明しました。
このアーキテクチャによって、オンプレミスやクラウド上に分散されて配置されるマイクサービスを連携し、１つのビジネス ロジックとして実行することが可能になります。
(この記事は、Fiorano Software Global Blog *1 に投稿された “Microservices – The issue of Granularity: Atomic or Composite?” *2 の意訳です。)
マイクロサービスを開発する際には、常にその粒度について議論の対象となっています。
デベロッパ、ソリューション アーキテクト、アナリストは、サービスの最適なサイズを以下に定義するか議論を続けています。この議論は、多くの場合、次の２つの方法論に帰着します。
前回は “smart endpoints and dumb pipes (賢いエンドポイントと機能性の低いパイプ)” の意味することにについて考察しました。
今回は、マイクロサービス間の連携を支えるこの “smart endpoints and dumb pipes” の具体的なアーキテクチャについて考えてみます。
マイクロサービスとは、複数のマイクロサービスが連携して業務処理を実現するアプリケーション アーキテクチャです。
単一の機能にしぼった小さな (マイクロな) サービスを連携させることで、大きな処理を実現するアプローチは、UNIX シェルのパイプのエッセンスを有しています。
前回は、マイクロサービスについてUNIX のパイプ機能をアナロジーとして取り上げ説明しました。
今回は、マイクロサービス間の連携を支える “マイクロサービスにおけるパイプ機能” について考察してみたいと思います。
マイクロサービスを提唱したJames Lewis氏が Martin Fowler氏と共に著した『Microservices』*1という記事の中で、「Smart endpoints and dumb pipes」*1というセクションを設けて、マイクロサービス間の連携について説明しています。
このセクションではまず、対極にある smart pipe を説明しています。smart pipe の例として ESB (エンタープライズ サービス バス) などのアプリケーション連携製品をあげています。
前回 (その1) は、マイクロサービス アーキテクチャについてモノリシックなアプリケーションと比較して概説しました。今回は、マイクロサービス間のコミュニケーションに焦点をあててマイクロサービス アーキテクチャを掘り下げていきます。
マイクロサービス アーキテクチャは、クラシックな技術ではありますが UNIX のパイプ機能になぞらえることができます。
UNIX のパイプ機能は、最初のシェルが作られた 1970 年代に誕生しています。このブログを読まれている方の中には、UNIX のシェルを直接使用してコマンド実行をしたことがない人もいるかもしれません。簡単に説明してみます。
クラウド、ビッグデータ、API エコノミーなどデジタル ビジネスの領域に ”マイクロサービス *2” というバズワードが現れてきました。
サービス指向アーキテクチャ (SOA) への期待が薄れる中、アプリケーション開発のアーキテクチャ スタイルとしてマイクロサービスに注目が集まっています。
2000年代の初期に登場した SOA は、大きな期待を集め、また導入に成功したプロジェクトも多くありました。それにもかかわらず、今日では、いくつかの理由によって、過剰に宣伝されたハイプ (hype) なテクノロジーとみなされるようになってきました。
SOA は、サービス間のインタフェースを定義するだけで数か月も要する複雑でコスト高なものとみなされるようになっています。SOA のプロジェクトでは、サービスの粒度を非常に大きなものとし何種類ものインタフェースを有するものとして実装されがちです。これはサービスに汎用性を持たせようという意図の結果だと思われるのですが、却って使い勝手が悪くなり、SOA のメリットの１つであるサービスの共有/再利用を阻害してしまいます。別の極端な例は、サービスを数行のコードしか持たない小さなものとして実装してしまうケースです。このような小さなサービスでは簡単で単純な業務処理を実行するのに、数十、数百のサービスを連携しなければならず、サービス間の通信だけで多大な処理時間やコンピュータ リソースを費やしてしまうことになります。
SOA の難しさの１つに、サービスの粒度決定があるといってもよいでしょう。
このクラシックな SOA が持つ欠点を解消するものとして、アプリケーション連携のアーキテクチャへのマイクロサービスの応用に期待が集まっています。
マイクロサービスの詳細を見ていく前に、モノリシックなアプリケーション アーキテクチャと対比してみましょう。
Twitter