Mule Runtime のアーキテクチャコンセプト紹介

Copyright (C) 2018 OGIS-RI All rights reserved.
株式会社オージス総研
齋藤伸也
Mule Runtime のアーキテクチャコンセプト紹介
～EIP、Conversation Patterns、SEDA、Non-blocking～

ご注意
本スライドの記述は MuleSoft, Inc. の公
式見解ではありません。
2

自己紹介
• 齋藤伸也 (Saito_Shinya@ogis-ri.co.jp)
• 株式会社オージス総研
– クラウドインテグレーションサービス部所属
• インテグレーションアーキテクト / APIテクニカルコンサルタント
• Mule 2.x 時代(約10年前)からMuleを利用したシステム連携や
API構築プロジェクトに参画

今日の話
• システム連携のパターン
– Enterprise Integration Patterns
– Conversation Patterns
• Mule engine の処理モデル
– Muleのスレッドモデル(Mule3)とNon-blocking IO(Mule4)
– Muleのチューニング(Mule3)とセルフチューニング(Mule4)

システム連携は簡単？
システムA システムB
システム連携は線で
結べばOK

システム連携は簡単・・・じゃない
• 同期/非同期、リアルタイム/バッチ、1:1/N:1/N:N
• データサイズ、連携頻度
• プロトコル、データ形式
• 経路の信頼性、エラー処理
• ・・・・などなど
システムA システムB

Enterprise Integration Patterns
• 著者：Gregor Hohpe氏 and Bobby Woolf氏. 2005
• 企業におけるシステム連携のパターンを65種類網羅
したパターン本
• Mule、Camel、Spring Integrationなど様々な連携ミドルウェアがリ
ファレンスしている
• メリット
– システム連携の共通言語、連携アーキテクチャの議論の出発点
http://www.enterpriseintegrationpatterns.com より

EIPとMule
https://docs.mulesoft.com/mule-user-guide/v/3.9/understanding-enterprise-integration-patterns-using-mule より
Pattern Mapping to a Mule Object
File Transfer File Transport
Shared Database JDBC Transport
Messaging Mule is all about Messaging
Message Channel Mule provides a message channel that
connects the message processors in a flow.
Pipes and Filters A Flow implements a pipe and filter
architecture
Message Router Message Routers
Message Translator Message Transformer
Message Endpoint Inbound & Outbound Endpoints
Pattern Mapping to a Mule Object
Point-to-Point Channel The default channel within a flow.
Message Bus Mule is a message bus.
Content-Based Router Choice
Message Filter Filters
Recipient List Recipient List
Splitter Collection Splitter, Message Chunk Splitter &
Plain Splitter
Aggregator Collection Aggregator, Message Chunk
Aggregator & Custom Aggregator
Resequencer Resequencer
Idempotent Receiver Idempotent Message Filter

Conversation Patterns
• EIP本の第２弾
– Gregor Hohpe氏が執筆中(2019.1.19に発売予定? Amazonより)
• EIPは、メッセージとそれが通るコンポーネントに着目していたが、
Conversation Patternsでは時間の経過に伴うメッセージの流れ相互作用に着目
http://www.enterpriseintegrationpatterns.com/patterns/conversation/ より

基本的な会話のパターン
• システム連携の相互通信を検討する際のパターン
• REST APIの設計時にも役に立つ考え方
Pattern 概要
Fire-and-Forget 発信者はメッセージを送信し、受信者からの応答は期待しません
Asynchronous Request-Response 発信者と受信者はリクエスト-レスポンスを非同期で行います。リク
エストが送信された順序とは異なる順序で応答が到着する可能性が
あります
Request-Response with Retry Asynchronous Request-Response において、発信者と受信者の両方を
重複しないようにして重複したメッセージを処理できるようにする
Polling 受信者が即時に応答ができない場合、発信者が結果を要求するリク
エストを発行する
Subscribe-Notify Subscriber は Providerが提供するデータへの関心を示すメッセージを
送信することで購読します。その後、Providerは通知メッセージを
Subscriberに送り続けます
Quick Acknowledgment 受信者はリクエストを処理するのに時間がかかる場合でも、
Acknowledgmentメッセージを返信し、後でリクエストの結果を返信
する

一貫性に関するパターン
• API-let ConnectivityやApplication Networkを実現する上で重要なREST APIのエラー
とリトライ、べき等性に関連するパターン(齋藤理解)
• 一部のパターンはHohpe氏のブログ記事「スターバックスは2フェーズコミットを
使わない(Starbucks Does Not Use Two-Phase Commit)」に実例が掲載されている
Pattern 概要
Ignore Error エラーを無視する。エラー処理のコストが処理全体のコスト
に見合わないケース
Compensating Action 補償行為。エラーにより不整合が発生した場合、元に戻す。
処理を行うことで一貫性を担保する
Tentative Operation 仮の操作を実行し、その後確認を行うことで処理を完結させ
る
Coordinated Agreement 仲介者が各参加者の状況・回答を確認し、その結果を判断し。
参加者と共有する

Mule のアーキテクチャコンセプト
イベントドリブンとパイプ＆フィルタ
• Mule は様々なシステム連携に対応するために抽象化された処理モデルを
採用している
• イベントドリブンアーキテクチャとパイプ＆フィルタモデルである
イベント
(メッセージ)
Flowの処理モデル
データ
変換
API
呼出
DB
アクセスイベント
(メッセージ)
API
DB

Mule3のスレッドモデル
• 同期の場合は、すべてが同じスレッドで動作する
• 非同期の場合は、RECIVER、Flow、DESPACHTERが別々のスレッドで動作する
https://docs.mulesoft.com/mule-user-guide/v/3.9/tuning-performance

Mule4のNon-blocking IO
• I/O(HTTPリクエストなど)の処理を待たずに別の処理を開始することができる
• Mule 3.7 からHTTPなど一部のConnectorで適応可能だった
• 基本的にすべてのFlowでNon-blocking IO方式が適用される

Mule3におけるチューニング
• Muleのパフォーマンスチューニングは、スレッドに関するパラメータの調整になる
– maxThreadsActive
– maxThreadsIdle
• 以下の要素を考慮しなければならない
– Flowのスレッドパーン
– 利用している Connectorの性質

Mule4のセルフチューニングとは
• CPUリソース状況を確認しながら処理のスケジュール
• Muleの各コンポーネントに ProcessingTypeが割与えられている
– CPU INTENSIVE
• 計算処理や変換処理など
– CPU LITE
• ルーティング、フィルタリング
non-blocking IOなど
– IO_RW
• ストリーミングデータ処理など
Mule 4.1.2 org.mule.runtime.core.api.processor.ReactiveProcessor より
https://www.mulesoft.com/whitepaper/api/what-is-new-mule-4 より

で、結局Mule4になったら何が変わるのか？
• 新しくMule4を使う人
– 非常に難しいスレッド回りの概念やチューニングからサヨナラで
きて Happy！
• Mule3からマイグレーションする人
– (おそらく)Muleが利用するリソース(CPU、メモリ)の使い方が変わ
るので注意
• 処理によるがMule(3まで)は高負荷時メモリの消費が多くなる(スレッドを多く生成するため)が、
non-blockingになったことによりメモリの消費が少なくなり、CPUの負荷が上がると考えられる
• セルフチューニングにより、どこまで最適化されるかは実際のFlowを高負荷環境で動作させな
いとわからないため要検証

Thank you 

Mule Runtime のアーキテクチャコンセプト紹介

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Mule Runtime のアーキテクチャコンセプト紹介

Similar to Mule Runtime のアーキテクチャコンセプト紹介 (20)

Recently uploaded

Recently uploaded (9)

Mule Runtime のアーキテクチャコンセプト紹介