プロセスのパフォーマンスを最大限に引き出すアプリケーションの設計

アプリケーションを設計する際には、以下のベストプラクティスを考慮して処理のパフォーマンスを高めてください。これらのプラクティスには、Mule Runtime Engine (Mule) バージョンの選択、アプリケーション設計時の問題の回避、Mule のコンポーネントやコネクタを使用するための設定に関するガイドラインが含まれています。

Mule Runtime Engine バージョン

アプリケーションのチューニングを開始する前に、Mule バージョンに関する以下の推奨事項を確認してください。

アプリケーションの作成と実行には最新バージョンの Mule を使用してください。
最新のパフォーマンスの向上とバグフィックスのアドバンテージを活用するため、アプリケーションの連動関係を最新のバージョンに更新してください。
可能な限り Mule パッチを最新バージョンに更新してください。
アプリケーションを開発してテストする際には、環境にアプリケーションをデプロイしたときと同じ Mule バージョンを使用してください。

処理パフォーマンスを向上させるための設計のヒント

アプリケーションを設計する際には、パフォーマンスを向上させるための以下の推奨事項を考慮してください。

Java モジュールを繰り返し使用して Java ライブラリなどのコードを再利用するのではなく、Java 呼び出しをラップする操作で SDK モジュールを作成してください。
Java や Groovy のようなカスタムスクリプティングコードではなく、DataWeave を使用してデータを変換または強化し、ペイロードを作成してください。

次の例のような set-variable/set-payload コンポーネントのシーケンスは避けてください。

<set-variable value='"Hello"' doc:name="Set Variable" variableName="hello"/>
<set-variable value='"world!"' doc:name="Set Variable" variableName="world"/>

その代わりに、これらを単一の ee:transform 操作に組み合わせることで、各コンポーネントに対して新しいイベントが生成されるのを防止してください。

<ee:transform doc:name="Transform Message" >
	<ee:variables >
		<ee:set-variable variableName="hello" ><![CDATA[%dw 2.0
            output application/json
            ---
           "Hello"]]></ee:set-variable>

           <ee:set-variable variableName="world" ><![CDATA[%dw 2.0
            output application/json
            ---
           "world"]]></ee:set-variable>
	</ee:variables>
</ee:transform>

次の例の様に、set-variable 変数を使用して一時的な値を保存することは避けてください。

<flow name="FileComponentWithsetVariableFlow" doc:id="daa9e38a-bb8c-4c87-a4c0-ba2dd90316b2" >
       <set-variable value="#['file_path/' ++ attributes.queryParams['filename']]" doc:name="Set Variable" doc:id="cf876447-12a6-4267-9b26-5e849153142c" variableName="fileName"/>
       <file:read doc:name="Read" doc:id="e4ad1ad4-0edb-45c9-ab43-d7f07effa277" path="#[vars.fileName]"/>
</flow>

これらの値は、これらを必要とするコンポーネントに移動してください。

<flow name="FileComponentWithoutsetVariableFlow" doc:id="0d44d155-cabe-4a79-99e4-81de22743edb" >
      <file:read doc:name="Read" doc:id="09dfb229-67fd-4508-862f-489c123527ba" path="#['file_path/' ++ attributes.queryParams['filename']]"/>
</flow>

プロパティリゾルバーを使用すると、すべてのイベントで DataWeave を使用する必要があり、処理オーバーヘッドが増大するため、プロパティリゾルバーは作成しないでください。
```
<flow-ref name="#[p(someProp) default p(otherProp)]"/>
```
その代わりに、プロパティプレースホルダーに DataWeave ロジックを配置して、静的なフロー参照を使用してください。
```
<flow-ref name="${propertyContainer.propertyName}"/>
```

コンポーネントコネクタのベストプラクティス

Mule コンポーネントとコネクタを使用してアプリケーションを設計する場合は、以下の推奨事項を考慮してパフォーマンスを高めてください。

APIkit

パフォーマンスを高めるため、APIkit 検証は無効化してください。ペイロードの検証が必要な場合、APIkit は API 仕様に基づいて入力された要求を検証します。

DataWeave

DataWeave を使用する場合は、以下の方法でパフォーマンスを高めることを検討してください。

ペイロードが大きい場合は、indent=false を含めることでクライアントの解析を改善し、応答サイズを抑えてください。
content-type を定義することで、ログの冗長メッセージを回避してください。
開発中はインライン DataWeave スクリプトを使用し、後で外部ファイルに移動することで、XML を見やすくし、スクリプトを再利用可能にしてください。
すべての要求で複雑な DataWeave 式をログに記録しないでください。

コレクションを反復処理して個別の項目を変換するパターンは避けてください。

<foreach>
	<ee:transform >
		<ee:message >
			<ee:set-payload ><![CDATA[%dw 2.0
output application/json
---
payload mapObject (value, key) -> {
	(upper(key)): value
}
			]]></ee:set-payload>
		</ee:message>
	</ee:transform>
	...
</foreach>

その代わりに、コレクション全体を変換して、後で反復処理を行ってください。

<ee:transform>
	<ee:message >
		<ee:set-payload ><![CDATA[%dw 2.0
output application/json
---
payload map (item, index) -> {
	book: item mapObject (value, key) -> {
		(upper(key)): value
	}
}
		]]></ee:set-payload>
	</ee:message>
</ee:transform>
<foreach>
	...
</foreach>

バリデーター

Groovy スクリプトで例外をスローするのではなく、バリデーターモジュールを使用してください。

HTTP と HTTPS

HTTP と HTTPS では、以下の推奨事項を考慮してください。

DataWeave 式による基本認証ヘッダーの手動生成といった手動認証を使用するのではなく、HTTP 用 Anypoint Connector (HTTP Connector) が提供する認証メカニズムを使用してください。
HTTPS が必要な場合は、HTTP リスナーで TLS コンテキスト参照を使用して、Keytool で生成されたキー-値ペアでキーストアを設定してください。
CloudHub で専用ロードバランサーを使用するときに SSL もロードバランサーレベルで終端できる場合や、ハイブリッドシナリオでオンプレミスのロードバランサーを使用する場合には、HTTPS 設定を回避できます。
```
<tls:context name="TLS_Context" doc:name="TLS Context">
      <tls:key-store type="jks" path="company-keystore.jks" alias="${jks.alias}" keyPassword="${jks.key.password}" password="${jks.password}"/>
</tls:context>
```

データベース

パラメーター化クエリの使用動的クエリを使用する必要がある場合は、必ず最初に入力を検証してください。動的クエリを使用すると、SQL インジェクション脆弱性の原因となる場合があります。

ファイルコネクタ

Write 操作で Transform コンポーネントを使用して変換を行うのではなく、DataWeave 式を使用してください。これにより、次の例に示すように、Write 操作後に発生するメッセージペイロードの変更を回避できます。

<file:write path="output.csv">
 <file:content>#[%dw 2.0
                 output application/csv
                 ---
                 payload.customers.email
               ]
 </file:content>
</file:write>

recursive (再帰) パラメーターを使用して、サブフォルダー内のファイルとフォルダーをリストします。

<file:list config-ref="File_Config" directoryPath="relativePath" recursive="true" />

Web サービスコンシューマーコネクタ

プロジェクト内のすべての参照 (XSD) を含む WSDL をインポートするには、Web サービスコンシューマー用 Anypoint Connector (Web サービスコンシューマーコネクタ) を使用して、設定がローカル WSDL を参照するようにしてください。

AMQP Connector

AMQP 用 Anypoint Connector (AMQP Connector) のパフォーマンスと設定はサーバーによって制約されるため、パフォーマンスの問題を調べるときには、サーバー側の設定を調べて、consume パラメーターまたは publish パラメーターが性能に影響していないかを確認してください。

consume パラメーター

cconsume パラメーターがパフォーマンスに影響していないかを確認してください。

Number Of Consumers (コンシューマーの数)

AMQP 設定とリスナーソースのコンシューマー数の設定は、ソースによって実行されて AMQP メッセージを同時に受信するコンシューマーの数を決定します。各コンシューマーは異なるチャネルを作成して使用します。
メッセージのスループットは、コンシューマー数によって異なり、コンシューマー数が増えるほど大きくなります。ただし、スループットは、フローのパフォーマンス特性にも影響されます。

ACK Mode (肯定応答モード) パラメーター

ACK モードは、AMQP ブローカーからコンシュームするときに使用する肯定応答モードを決定します。肯定応答モード (ACK) は、設定レベルで ([Consumer (コンシューマー)] タブを使用して) 設定しますが、Listener 操作と Consume 操作はこのモードを変更できます。
次の 3 つの肯定応答モードがあります。

AUTO
フローの実行が正常に完了した場合にのみ受信メッセージの自動的な肯定応答を行うには、自動モードを使用します。
MANUAL
メッセージの肯定応答を行うタイミングを決定するアプリケーションロジックにすべての責任を委譲するには、手動モードを使用します。
IMMEDIATE
アプリケーションがメッセージを処理する前にコンシュームするときにそのメッセージの肯定応答を行うには、即時モードを使用します。

チャネルでトランザクションが開かれると、ACK Mode (肯定応答モード) パラメーターが上書きされ、コミットがプロセスメッセージの肯定応答を自動的に処理して、ロールバックが自動的に回復を処理します。

[Quality of Service Tab (サービス品質)] タブ

QoS パラメーターは ([Quality of Service Tab (サービス品質)] タブを使用して) 設定レベルで設定します。0 は無制限値を表します。Listener 操作は、この設定を上書きできます。
パラメーターは次のとおりです。

Prefetch Size (プリフェッチサイズ)
プリフェッチサイズウィンドウを定義します。ブローカーは、オクテット (バイト) 単位のプリフェッチサイズウィンドウを超えない範囲でできるだけ多くのメッセージを送信します。
Prefetch Count (プリフェッチ数)
メッセージ全体の最大数に関してグローバルプリフェッチウィンドウを指定します。このパラメーターを prefetch-size パラメーターと組み合わせて使用することで、両方のプリフェッチウィンドウサイズで可能であれば、メッセージを事前に送信できます。

ACK Mode (肯定応答モード) と Prefetch (プリフェッチ)

肯定応答モードと QoS プリフェッチの値は、コンシューマーのスループットに大きく影響します。一般に、プリフェッチ値を大きくして Immediate (即時) 肯定応答モードを選択することで最高の配信レートを実現できます。ただし、この設定では配信済みで未処理のメッセージ数も増えるため、コンシューマー RAM の消費量も増えます。

Automatic (自動) または Manual (手動) 肯定応答モードで、プリフェッチ値を無制限にする場合は、注意が必要です。肯定応答のないまま大量のメッセージをコンシュームすると、ブローカーノードのメモリ消費量が増えます。適切なプリフェッチ値は試行錯誤を経て探す必要があり、最適な値はワークロードによって異なります。

publish パラメーター

以下のパラメーターは設定レベルで [Publisher (パブリッシャー)] タブを使用して設定します。Publish 操作と Publish-Consume 操作では、これらのパラメーターを上書きできます。使用事例によって、これらのパラメーターのどちらか片方のみを有効化します。

Delivery Mode (配信モード) パラメーター

このパラメーターは、AMQP ブローカーへのパブリッシュに使用する配信モードを決定します。可能なパラメーター値:

PERSISTENT
永続的なキューに配信されたメッセージは、ブローカーのディスクに記録されます。
TRANSIENT
配信されたメッセージは記録されません。

永続的なメッセージで使用する記録可能なストレージメカニズムの実装はブローカーの責任となります。この機能がパフォーマンスに与える影響は、AMQP サーバーによって異なります。

Request Broker Confirm (ブローカーの確認を要求) パラメーター

ブローカーが確認を返さない場合に操作が失敗するかどうかを決定します。このパラメーターを使用すると、パブリッシュされるメッセージごとに、ブローカーとクライアントの間で通信が 1 回増えます。

ガートナーが MuleSoft をリーダーとして評価

Salesforce のフルパワーを解放する API 活用術

Anypoint Platform：開発基礎 (無料)

MuleSoft Forum Japan