使用量および価格設定メトリクスリファレンス

Anypoint Platform は製品全体で使用量メトリクスを取得しますが、すべてのメトリクスが請求可能であったり、使用状況レポートに反映されたりするわけではありません。

製品

メトリクスの説明

使用量の詳細

Mule Runtime

Mule flow (Mule フロー): Mule イベントソースまたはルート APIKit 要求が含まれる、デプロイされて実行されている Mule アプリケーション内のフロー

フローは、最大同時実行モデルを使用して集約されます。1 か月の使用量とは、1 か月の特定の 1 時間に存在するフローの最大数です。

Mule message (Mule メッセージ): ランタイムによって処理されたコア情報のコンテナ。

Mule メッセージは、イベントソースによりトリガーされると 1 単位とみなされます。メッセージは、1 か月間に送信されたすべてのメッセージの合計を使用して集約されます。

Data throughput (データスループット): Mule アプリケーションがデプロイされ、Mule が実行されているインフラストラクチャとの間で送受信されたデータの総量

デプロイされたアプリケーションがそのビジネスロジックを実行するためにデータを送信すると、データスループットが計数されます。これには、監視、ログ、健全性チェック用の内部運用ネットワークトラフィックが含まれますが、これらに限定されません。データスループットは、1 か月間のすべてのバイトの合計として集約されます。

Cluster capacity (クラスター容量): 特定の Runtime Fabric インスタンスの 1 つのデプロイメント対象として機能するワーカーまたはノードのセット。

Runtime Fabric インスタンス内の各ノードの割り当て可能な CPU 容量。

CPU Limit (Millicores) (CPU 制限 (ミリコア数)): Runtime Fabric のワーカーノードで使用できる CPU リソースの最大量

CPU 使用量は、1 時間や 1 日などの特定の期間で集約されます。

各アプリケーションの CPU 制限設定は、各環境 ID でまとめられ、次に各ビジネスグループ、次に本番前 (Sandbox) 環境種別と本番環境種別の各ルート組織 ID で別々にまとめられます。

CPU Reserve (Millicores) (CPU 予約 (ミリコア数)): Runtime Fabric インスタンスのワーカーノードに割り当てられる CPU リソースの保証された最小量

CPU 予約は、クラスターまたは Runtime Fabric インスタンス内でユーザーがアプリケーション用として予約するために割り当てた CPU リソースの総量を計算することで集約されます。

API Manager

API instances (API インスタンス): add、promote、または import オプションを使用して作成された後、API Manager によって管理される、本番、本番前、未分類 API (環境に関連付けられない API) 内の API インスタンス。

API は、削除されるまで API Manager の管理下に置かれます。API Manager のインスタンスは、本番、本番前、および未分類 (環境に関連付けられていない API) の 3 つの別々のメトリクスを使用する最大同時実行モデルを使用して集約されます。

API Manager のデータは、2024 年 10 月から使用可能です。

API Governance

API under Governance (ガバナンス下の API): 少なくとも 1 つのガバナンスプロファイルの選択条件によって識別された API

API が管理されている場合、その API のすべてのバージョンが 1 つの管理対象 API とみなされます。API ガバナンスのインスタンスは、最大同時実行モデルを使用して集約されます。1 か月の使用量とは、1 か月の特定の 1 時間内で管理された API の最大数です。

Flex Gateway

Flex Gateway API call (Flex Gateway API コール): 要求に対する応答が成功したかどうかにかかわらず Anypoint Flex Gateway が受信したアクセス要求

Flex Gateway 要求は、1 か月間のすべての要求の合計として集約されます。

Composer

Composer task (Composer タスク): Composer Connector で実行される任意のアクションであり、参照、作成、更新、および削除が含まれますが、これらに限定されません。

Composer タスクは、1 か月間のすべてのアクションの合計として集約されます。

RPA

Robotic Process Automation (“RPA”) bot minutes (Robotic Process Automation (“RPA”) Bot の分数): すべてのボットセッションでプロセスの自動化を実行した分数

1 つのボットで複数の並列セッションを実行することができます。この場合、RPA Bot の分数は並列セッションごとに集計されます。複数のボットで同じプロセスを実行するように設定することができます。この場合、RPA Bot の分数はこれらの個別のボットセッションごとに集計されます。テストフェーズでのテスト実行またはプロセス実行も、RPA Bot の分数とみなされます。

メッセージキュー

Anypoint MQ API request (Anypoint MQ API 要求): Anypoint MQ API から 1 つ以上のメッセージを取得するために実行された要求

各 Anypoint MQ API 要求には最大 100 KB のデータが含まれます。100 KB を超える Anypoint MQ API 要求は、小数単位のない複数の要求として数えられます。Anypoint MQ API 要求は、すべての環境 (本番、本番前、Sandbox、設計を含む) の集約内で計算されます。現在、Anypoint MQ API 要求は API を介してのみ使用可能で、使用状況レポートでは集約されません。

Object Store (オブジェクトストア)

Object Store API request (Object Store API 要求): Object Store API から 1 つ以上のメッセージを取得するために実行された要求。詳細な定義は、Object Store のドキュメントを参照してください

各 Object Store API 要求には最大 100 KB のデータが含まれます。100 KB を超える Object Store API 要求は、小数単位のない複数の要求として数えられます。現在、Object Store API 要求は API を介してのみ使用可能で、使用状況レポートでは集約されません。

DataGraph

DataGraph orchestration (DataGraph オーケストレーション): Anypoint DataGraph に対して実行された GraphQL API 要求のデータを取得するために、ソース API に対して Anypoint DataGraph により実行された API 要求

現在、オーケストレーションは使用状況レポートでは集約されていません。

インテリジェントドキュメント処理 (IDP)

Intelligent Document Processing (IDP) Document Pages (インテリジェントドキュメント処理 (IDP) ドキュメントページ): IDP により処理された 1 つのページ。

IDP ドキュメントアクションでは、複数のページを含むドキュメントを処理でき、各ページが個別に集計されます。RPA でドキュメントアクションが実行されると、ドキュメントページ数にも集計されるほか、対応する RPA Bot の分数がコンシュームされ、RPA プロセスの実行時間の対象となります。

API Experience Hub 使用状況

API Experience Hub 使用状況レポートでは、テーブルおよびカードに次の情報が表示されます。

Salesforce 組織 ID: API がデプロイされている Salesforce 組織の OrgID
Salesforce ポータル名: API がデプロイされている Salesforce ポータルの名前
# 承認されたアクセス権の要求: API に対する承認されたアクセス権の要求の合計数
承認されたアクセス権の要求の合計数: すべての Salesforce 組織における承認されたアクセス権の要求の合計数

API Governance 使用状況

API Governance 使用状況レポートでは、テーブルおよびカードに次の情報が表示されます。

ビジネスグループ: 管理された API が含まれるビジネスグループ
# 管理された API: 指定したビジネスグループ内で管理された API の合計数
Maximum Number of Governed APIs (管理対象 API の最大数): 1 か月の特定の 1 時間内で管理された API の最大数

API Manager 使用状況

API Manager のデータは、2024 年 10 月から使用可能です。

API Manager 使用状況レポートでは、テーブルおよびカードに次の情報が表示されます。

ビジネスグループ: API が管理されているビジネスグループ
環境: API が管理されている環境種別
ランタイム: API のランタイム種別
# 管理された API: 指定したビジネスグループ、環境、およびランタイム内で管理された API の合計数
Maximum Number of Managed APIs (管理された API の最大数): 本番、本番前、および未分類 API (環境に関連付けられていない API) 内の API インスタンス

Flex Gateway 使用状況

Flex Gateway 使用状況レポートでは、テーブルおよびカードに次の情報が表示されます。

ビジネスグループ: Flex Gateway が登録されているビジネスグループ。
環境: Flex Gateway が登録されている環境。
登録: 登録済み Flex Gateway の名前。
# API コール数: Flex Gateway 内にデプロイされた API により実行された API コールの合計数。
API コールの合計数: 組織内のすべての登録済み Flex Gateway での API コールの合計数。

インテリジェントドキュメント処理 (IDP)

IDP 使用状況レポートでは、テーブルおよびカードに次の情報が表示されます。

Business Group (ビジネスグループ): ドキュメントが処理されたビジネスグループ。
アクション ID。: 処理されたアクションに関連付けられた ID
Action Version (アクションバージョン): 処理されたアクションに関連付けられたバージョン
実行種別: 処理されたアクションに関連付けられた実行種別
Processed Pages (処理済みページ): 処理された総ページ数

Mule Runtime 使用状況

MuleSoft では、Mule フロー、Mule メッセージ、データスループットの使用状況データを取得しますが、このデータのすべてが使用状況レポートで集計されるわけではありません。

Mule メッセージの使用状況を追跡するために、ランタイムレポートでは Mule イベントソースが Mule メッセージをトリガーする回数を数えます。特定の日または月のこれらのメッセージの数をビジネスグループ、環境、およびアプリケーション別に参照できます。

使用量の計算では、MuleSoft は毎日および毎月のメッセージ数を測定して集約します。メッセージがトリガーされると、レポートではメッセージに対する変更が追跡されなくなります。これは、メッセージがアプリケーションのフロー内で処理されるためです。

データスループットとは、Mule アプリケーションを実行する Mule Runtime Engine のインフラストラクチャによって生成されたネットワーク I/O バイトの合計を指します。

使用量の計算では、MuleSoft は使用量を追跡して毎日および毎月の合計 GB を集約します。

US コントロールプレーンの一部のお客様に対して、MuleSoft では一定数の Mule フロー、Mule メッセージ、データスループット (ネットワーク I/O バイト数として測定) を割り当てる Anypoint Platform の価格設定およびパッケージモデルを提供しています。すべての種別の Mule フローおよびメッセージがパッケージの割り当て対象になるわけではありません。

Mule Runtime 使用状況テーブル

使用状況レポートのテーブルに表示される使用量情報は、ビューによって異なります。

ビジネスグループの詳細

[Business Group Details (ビジネスグループの詳細)] タブを選択して表示します。

項目	説明
Business Group (ビジネスグループ)	リソースを所有しているビジネスグループ。Runtime Fabric の場合、これは、Runtime Fabric インスタンスの作成時に使用されたビジネスグループです。
Environment Type (環境種別)	リソースが関連付けられている環境。 Runtime Fabric の場合、これは、Runtime Fabric インスタンスが関連付けられている環境です。Runtime Fabric インスタンスに関連付けられた本番環境がある場合、その本番環境は本番インタンスとみなされます。クラスター容量は、Runtime Fabric インスタンス内で本番前 (Sandbox) 環境と本番環境間で分割されません。
Cluster (クラスター)	アプリケーション、ワーカー、ノードが含まれるクラスターまたは Runtime Fabric インスタンスの名前。
Cluster Capacity (Millicores) (クラスター容量 (ミリコア数))	Runtime Fabric インスタンス内の各ノードの割り当て可能な CPU 容量。

項目

説明

Business Group (ビジネスグループ)

リソースを所有しているビジネスグループ。Runtime Fabric の場合、これは、Runtime Fabric インスタンスの作成時に使用されたビジネスグループです。

Environment Type (環境種別)

リソースが関連付けられている環境。

Runtime Fabric の場合、これは、Runtime Fabric インスタンスが関連付けられている環境です。Runtime Fabric インスタンスに関連付けられた本番環境がある場合、その本番環境は本番インタンスとみなされます。クラスター容量は、Runtime Fabric インスタンス内で本番前 (Sandbox) 環境と本番環境間で分割されません。

Cluster (クラスター)

アプリケーション、ワーカー、ノードが含まれるクラスターまたは Runtime Fabric インスタンスの名前。

Cluster Capacity (Millicores) (クラスター容量 (ミリコア数))

Runtime Fabric インスタンス内の各ノードの割り当て可能な CPU 容量。

Application Details (アプリケーション詳細)

[Application Details (アプリケーション詳細)] タブを選択して表示します。

項目	説明
Application (アプリケーション)	Mule アプリケーションの名前
Business Group (ビジネスグループ)	リソースを所有しているビジネスグループ。Runtime Fabric の場合、これは、Runtime Fabric インスタンスの作成時に使用されたビジネスグループです。
Deployment Type (デプロイメント種別)	Mule アプリケーションがデプロイされているランタイムプレーン: CloudHub (短縮表記: CH)、CloudHub 2.0 (短縮表記: CH2)、または Runtime Fabric (短縮表記: RTF)
Environment Type (環境種別)	Mule アプリケーションがデプロイされている本番前 (Sandbox) 環境または本番環境。
Cluster (クラスター)	ノードとアプリケーションが含まれる Runtime Fabric インスタンス。
CPU Limit (Millicores) (CPU 制限 (ミリコア数))	共有クラスターまたは Runtime Fabric インスタンス内でアプリケーションがバーストできる、ユーザーにより割り当てられた CPU の最大量。
CPU Reserve (Millicores) (CPU 予約 (ミリコア数))	Runtime Fabric クラスターまたはインスタンス内でユーザーがアプリケーション用として予約するために割り当てた CPU の量
Mule Flows (Mule フロー)	フロー数にワーカー数 (CloudHub) またはレプリカ数 (CloudHub 2.0 および Runtime Fabric) を乗じて計算される、Mule アプリケーション内のフローの総数。
Mule Messages (Mule メッセージ)	Mule アプリケーション内のインバウンドおよびアウトバウンド Mule メッセージの総数。
Data Throughput (GB) (データスループット (GB))	Mule アプリケーションにより送信されたインバウンドおよびアウトバウンドデータの総量 (GB)。

項目

説明

Application (アプリケーション)

Mule アプリケーションの名前

Business Group (ビジネスグループ)

リソースを所有しているビジネスグループ。Runtime Fabric の場合、これは、Runtime Fabric インスタンスの作成時に使用されたビジネスグループです。

Deployment Type (デプロイメント種別)

Mule アプリケーションがデプロイされているランタイムプレーン: CloudHub (短縮表記: CH)、CloudHub 2.0 (短縮表記: CH2)、または Runtime Fabric (短縮表記: RTF)

Environment Type (環境種別)

Mule アプリケーションがデプロイされている本番前 (Sandbox) 環境または本番環境。

Cluster (クラスター)

ノードとアプリケーションが含まれる Runtime Fabric インスタンス。

CPU Limit (Millicores) (CPU 制限 (ミリコア数))

共有クラスターまたは Runtime Fabric インスタンス内でアプリケーションがバーストできる、ユーザーにより割り当てられた CPU の最大量。

CPU Reserve (Millicores) (CPU 予約 (ミリコア数))

Runtime Fabric クラスターまたはインスタンス内でユーザーがアプリケーション用として予約するために割り当てた CPU の量

Mule Flows (Mule フロー)

フロー数にワーカー数 (CloudHub) またはレプリカ数 (CloudHub 2.0 および Runtime Fabric) を乗じて計算される、Mule アプリケーション内のフローの総数。

Mule Messages (Mule メッセージ)

Mule アプリケーション内のインバウンドおよびアウトバウンド Mule メッセージの総数。

Data Throughput (GB) (データスループット (GB))

Mule アプリケーションにより送信されたインバウンドおよびアウトバウンドデータの総量 (GB)。

Mule Runtime 使用状況カード

MuleSoft 使用状況レポートのカードには次が含まれます。

最大 Mule フロー数
総 Mule メッセージ数
本番の最大 CPU 制限
本番前の最大 CPU 制限
本番の最大クラスター容量
本番前の最大クラスター容量

最大 Mule フロー数

Mule フローは Mule アプリケーションの XML <flow/> 要素内で設定される論理操作のシーケンスです。ランタイムレポートでは、Mule イベントソースまたは APIkit ルート要求が含まれる、デプロイされて実行されている Mule アプリケーション内の Mule フローを追跡します。

通常、本番環境の Mule アプリケーションは複数の Mule フローとサブフローを使用して、アプリケーションを機能モジュール別またはエラー処理目的で分割します。たとえば、1 つの Mule フローでレコードを受信してデータを特定の形式に変換し、別のフローでそのデータを処理できます。

使用量の計算では、MuleSoft は、すべてのビジネスグループ、環境、アプリケーションの Mule フロー数を追跡します。1 日または 1 か月間の Mule フローの最大数はその日または月のピーク時間の使用量に基づいて特定されます。詳細な内訳を確認できるように、MuleSoft ではビジネスグループ、環境、アプリケーションごとのピーク時間の使用量が表示されます。

使用状況レポートでは、フロー数は、アプリケーション内のフロー数にワーカー数 (CloudHub) またはレプリカ数 (CloudHub 2.0 および Runtime Fabric) を乗じて計算されます。

Anypoint Platform パッケージ割り当ての対象となる Mule フローシナリオ

次の Mule フローは割り当ての対象となります。

『Mule イベントソース』が含まれるフロー
API 要求を処理する、『APIkit キットによって生成されたフロー』

Mule フローが請求の対象となるのは、Mule フローが含まれるアプリケーションがデプロイされ、実行されている場合のみです。

イベントソースが含まれる Mule フロー

この Mule フローには最初の要素としてイベントソースが含まれています。この場合、listener は割り当ての対象となります。

<flow name="test-flow" >
        <http:listener config-ref="cocheras-puerto-madero-api-httpListenerConfig" path="/daily-report"/>
         <logger level="INFO" message="#[output json --- attributes.queryParams]" />
</flow>xml

イベントソースの例

Connector (コネクタ)	ソース
aggregators	aggregator-listener
amqp	リスナー
anypoint-mq	subscriber
apikit-odata	request-entity-collection-listener
request-entity-listener
as2-mule4	as2-listener
as2-mdn-listener
non-repudiation-listener
azure-service-bus-messaging	message-listener
core	スケジューラー
db	リスナー
email	listener-imap
listener-pop3
file	リスナー
ftp	リスナー
ftps	リスナー
google-sheets	new-row-listener
new-spreadsheet-listener
updated-row-listener
http	リスナー
ibm-mq	リスナー
jms	リスナー
kafka	batch-message-listener
message-listener
mllp	mllp-listener
netsuite	deleted-object-listener
modified-object-listener
modified-record-listener
new-record-listener
pubsub	message-listener
salesforce	deleted-object-listener
modified-object-listener
new-object-listener
replay-channel-listener
replay-topic-listener
subscribe-channel-listener
subscribe-topic-listener
sap	document-listener
function-listener
servicebus	リスナー
sftp	リスナー
sockets	リスナー
solace	queue-listener
topic-listener
sqs	receive-messages
receivemessages
stripe	citizen-on-new-charge-listener
on-new-charge-listener
on-new-event-listener
vm	リスナー
websocket	inbound-listener
outbound-listener

Connector (コネクタ)

ソース

aggregators

aggregator-listener

amqp

リスナー

anypoint-mq

subscriber

apikit-odata

request-entity-collection-listener

request-entity-listener

as2-mule4

as2-listener

as2-mdn-listener

non-repudiation-listener

azure-service-bus-messaging

message-listener

core

スケジューラー

リスナー

listener-imap

listener-pop3

file

リスナー

ftp

リスナー

ftps

リスナー

google-sheets

new-row-listener

new-spreadsheet-listener

updated-row-listener

http

リスナー

ibm-mq

リスナー

jms

リスナー

kafka

batch-message-listener

message-listener

mllp

mllp-listener

netsuite

deleted-object-listener

modified-object-listener

modified-record-listener

new-record-listener

pubsub

message-listener

salesforce

deleted-object-listener

modified-object-listener

new-object-listener

replay-channel-listener

replay-topic-listener

subscribe-channel-listener

subscribe-topic-listener

sap

document-listener

function-listener

servicebus

リスナー

sftp

リスナー

sockets

リスナー

solace

queue-listener

topic-listener

sqs

receive-messages

receivemessages

stripe

citizen-on-new-charge-listener

on-new-charge-listener

on-new-event-listener

リスナー

websocket

inbound-listener

outbound-listener

APIkit によって生成され、APIkit 要求のルーティングに使用される Mule フロー

APIkit とは、API 仕様に基づいて最低限のセットの Mule フローを自動的に生成することによって API の実装を簡略化するツールです。各 APIkit ルーターエンドポイントは個別の Mule フローとみなされます。これらの Mule フローにはイベントソースはなく、特定の API メソッドおよびパスの HTTP 要求に使用されます。

次のフローでは、APIkit 要求をルーティングして /reservation パスで GET 要求を処理します。

<flow name="get:\reservation:cocheras-puerto-madero-api-config">
        <logger level="INFO" message="#[output json --- attributes.queryParams]" />
</flow>xml

Anypoint Platform パッケージ割り当ての対象とならない Mule フロー

イベントソースがなく、APIkit 要求のルーティングに使用されない Mule フローは、Anypoint Platform パッケージ割り当ての請求対象になりません。これらの Mule フローは主にコードをモジュール化するために使用されます。

例:

2.a - Flow with only a logger component
<flow name="just-logging">
        <logger level="INFO" message="#[output json --- attributes.queryParams]" />
</flow>xml

総 Mule メッセージ数

Mule メッセージとは、アプリケーションで 1 つ以上の Mule フローを通過するデータ (ペイロードとその属性) です。Mule メッセージは、Mule フロー内のイベントソースがトリガーされたときに生成される Mule イベントの一部です。たとえば、Mule メッセージを構成する Mule イベントは、HTTP Listener が要求を受信したときや Scheduler コンポーネントが Mule フローの実行をトリガーするたびに作成されます。

Mule フロー内の Mule メッセージプロセッサー (コアコンポーネント、File Read 操作、HTTP Request 操作など) は、その設定に従って、Mule イベントに存在する Mule メッセージデータを取得、設定、処理できます。

Mule イベントは不変であるため、Mule メッセージを変更するたびに新しいインスタンスが作成されます。Mule メッセージを受信するフローの各プロセッサーは、メッセージペイロード (メッセージの本文) とメッセージ属性 (メッセージに関連付けられたメタデータ) で構成される新しい Mule メッセージを返します。

Anypoint Platform パッケージ割り当ての対象となる Mule メッセージシナリオ

Mule アプリケーションのフロー内のイベントソースがトリガーされると、イベントソース (HTTP Listener や Scheduler など) によって Mule メッセージをカプセル化する Mule イベントが生成されます。イベントソースによって生成された Mule メッセージは Anypoint Platform パッケージ割り当ての対象となります。接続された Mule フローの他のプロセッサーを通過するときに元のメッセージの処理中に作成されたそのメッセージの新しいインスタンスは Anypoint Platform パッケージ割り当ての対象となりません。

総データスループット

データスループットとは、Mule アプリケーションを実行する Mule Runtime サーバーのインフラストラクチャによって生成されたすべてのネットワーク I/O バイトを指します。これには、アプリケーションがそのビジネスロジックを実行するために生成するデータのほか、ログ、健全性チェック、監視トラフィックなど、内部運用ネットワークトラフィックが含まれます。たとえば、データスループットにはデータベースへのレコードの挿入や、ログの転送、コントロールプレーン接続、監視メトリクスの転送など、アプリケーションインフラストラクチャに関連付けられたネットワークトラフィックが含まれます。

Runtime Fabric 使用量メトリクス

Runtime Fabric の使用状況ダッシュボードでは、ハイブリッド環境のコア使用量を追跡、監視、管理できるほか、Runtime Fabric インスタンスとアプリケーションデプロイメントの詳細なメトリクスと分析が提供されます。

ビジネスグループで絞り込まれたクラスター容量メトリクスを表示できます。CPU 制限の集約をビジネスグループレベルで確認するには、「使用状況レポートを CSV としてエクスポート」します。CPU 制限は、関連付けられたビジネスグループと共に使用状況ダッシュボードにアプリケーションレベルで表示されます。これにより、最も多くの CPU を使用しているアプリケーションを特定できるため、必要に応じてアプリケーション設定を調整できます。

ダッシュボードでは、各アプリケーションでコンシュームされたコアとフローを並べて比較できるため、使用量および関連付けられた価格設定を把握できます。各アプリケーションでコンシュームされたコアとフローを並べて視覚化できます。使用状況レポートを CSV ファイルにエクスポートして各アプリケーションでコンシュームされたコアとフローを視覚化し、環境 ID およびビジネスグループごとにドリルダウンします。

クラスター容量メトリクスを請求に使用している場合、コア使用量からフロー使用量へのこの変換を使用すると、必要な変更をアプリケーションに加えることができるため、使用量ベースの価格設定に反復的に移行できます。これにより、インテグレーションニーズと共に拡張し、インフラストラクチャに結び付けられないより柔軟な価格設定モデルが提供されます。

Runtime Fabric エージェントのバージョンおよび設定要件

クラスター容量メトリクスを追跡に使用している場合、追加の設定要件が適用されます。この要件は、CPU 制限メトリクスの正確な追跡には適用されません。

Runtime Manager エージェントのバージョンは 2.7.0 以降である必要があります。

詳細は、『Upgrading Runtime Fabric』を参照してください。
Helm ベースの Runtime Fabric インストールを使用している場合、NODE_WATCHER パラメーターが有効になっていることを確認します。

NODE_WATCHER の有効化についての詳細は、「省略可能なパラメーター」を参照してください。

この設定は Runtime Fabric エージェントにのみ適用され、アプリケーションには影響しません。クラスター容量と CPU 制限のメトリクスを追跡するためにアプリケーションに対してアクション (再デプロイや再起動) を実行する必要はありません。

使用量メトリクスを使用した Runtime Fabric コンプライアンス追跡

正確な使用量メトリクス測定を行うには、クラスターとアプリケーションの設定を調整する必要があります。ユースケースに応じてコントラクトガバナンスのルート組織レベルで CPU 制限メトリクスまたはクラスター容量メトリクスを引き続き使用できます。

これらの推奨事項は、メトリクスを正確に測定するのに役立つ場合があります。

CPU 制限	クラスター容量
各アプリケーションには、ワークロード要件に応じて可変の CPU 割り当てが必要です。開発中に Anypoint Monitoring を使用してアプリケーションの CPU 使用量を分析し、適切な CPU 制限と CPU 予約の設定を特定します。 Runtime Manager では、CPU 制限設定は基盤となる Runtime Fabric インスタンスの使用可能なクラスター容量にデフォルトで設定されます。デプロイメント中に CPU 制限設定を明示的に変更しない場合、これにより、アプリケーションに対して報告される CPU 制限の使用量が大きくなる可能性があります。正確な CPU 制限メトリクスを得るには、アプリケーションの CPU 制限設定がアプリケーションのパフォーマンスに基づいて適切な値で更新されることを確認します。	Runtime Fabric インスタンスは、アプリケーションと Runtime Fabric コアサービスワークロードの名前空間分離とノード分離の両方を備えた共有 Kubernetes クラスターにインストールできます。これらの分離は、Kubelet サーバーから取得されるクラスター容量メトリクスに反映されません。このメトリクスをコンプライアンスに使用するには、Runtime Fabric インスタンス専用のクラスターを使用して正確な測定を行います。クラスターがハイパースレッドや計算コアの仮想化を使用して再設定されている場合や、高度なクラスター管理用のシステムノードがある場合、MuleSoft はクラスター容量メトリクスに対するこれらの設定の使用の影響を考慮できません。これらの設定が必要であり、クラスター容量メトリクスを使用する場合、アカウントチームに連絡して正確なコンプライアンス監査を行ってください。

CPU 制限

クラスター容量

各アプリケーションには、ワークロード要件に応じて可変の CPU 割り当てが必要です。開発中に Anypoint Monitoring を使用してアプリケーションの CPU 使用量を分析し、適切な CPU 制限と CPU 予約の設定を特定します。
Runtime Manager では、CPU 制限設定は基盤となる Runtime Fabric インスタンスの使用可能なクラスター容量にデフォルトで設定されます。デプロイメント中に CPU 制限設定を明示的に変更しない場合、これにより、アプリケーションに対して報告される CPU 制限の使用量が大きくなる可能性があります。正確な CPU 制限メトリクスを得るには、アプリケーションの CPU 制限設定がアプリケーションのパフォーマンスに基づいて適切な値で更新されることを確認します。

Runtime Fabric インスタンスは、アプリケーションと Runtime Fabric コアサービスワークロードの名前空間分離とノード分離の両方を備えた共有 Kubernetes クラスターにインストールできます。これらの分離は、Kubelet サーバーから取得されるクラスター容量メトリクスに反映されません。このメトリクスをコンプライアンスに使用するには、Runtime Fabric インスタンス専用のクラスターを使用して正確な測定を行います。
クラスターがハイパースレッドや計算コアの仮想化を使用して再設定されている場合や、高度なクラスター管理用のシステムノードがある場合、MuleSoft はクラスター容量メトリクスに対するこれらの設定の使用の影響を考慮できません。これらの設定が必要であり、クラスター容量メトリクスを使用する場合、アカウントチームに連絡して正確なコンプライアンス監査を行ってください。

詳細は、「MuleSoft ライセンスコンプライアンス」を参照してください。

本番の最大 CPU 制限

CPU 制限ベースの使用量をアプリケーション ID ごとにドリルダウンして追跡し、次のメタデータを使用してグループ化できます。

Runtime Fabric クラスター名

基盤となるクラスターに、拡張するための十分な容量があるかどうかを追跡します。
ビジネスグループ

ビジネスグループごとに使用量を表示します。
ルート組織

コア使用量を監視して、合計エンタイトルメントを超えないようにします。

クラスター容量メトリクスは、ルート組織レベルでのみ使用できます。

本番の最大 CPU 制限は、アプリケーションが本番ランタイムプレーンにデプロイされて実行されている場合に使用できる CPU の最大量です。CPU 数はワーカーノードで共有されます。同じアプリケーションのワーカーセットの各メンバーは、異なる CPU 制限値を持つことができます。自動スケールポリシー (実装されている場合) は、30 分ごとに実行できます。これは、アプリケーションデプロイメントのワーカーまたはレプリカ数と CPU 制限に影響する可能性があります。

データは 1 時間ごとに取得されますが、max (最大) メトリクスは、この例で示されているとおり、日および月単位で追跡されます。

例

次に、2 つのアプリケーションの例を示します。

App1 の CPU 制限は 1 ずつで、ワーカー数の範囲は 1 ～ 3 です。

App2 の CPU 制限は 1 ずつで、ワーカー数の範囲は 2 ～ 5 です。

00:00 分に取得されたデータ:

App1: sum(1,1,1) = 3
App2: sum(1,1,1,1,1) = 5
取得された Max (最大) メトリクス = 8 個の集約された CPU 制限

CPU 制限が 2 でワーカーの範囲が 1 ～ 6 の App1 を 00:45 分に再デプロイメント:

App1: sum(1,1,1,2,2,2) = 9
App2: sum(1,1,1,1,1) = 5

時間 01:00 分:

App1: sum(2,2,2,2,2,2) = 12
App2: sum(1,1,1,1,1) = 5
取得された Max (最大) メトリクス = 17 個の集約された CPU 制限
(使用状況ダッシュボードに報告されない) 特定の時間のルート組織:

最大同時実行の制限の CPU = 17
特定の日のルート組織:

最大同時実行の制限の CPU = 17
特定の月のルート組織:

最大同時実行の制限の CPU = 17

02:00 分以降に App2 が 3 個のワーカーに自動スケールダウン:

App1: sum(2,2,2,2,2,2) = 12
App2: sum(1,1,1) = 3
Max (最大) メトリクス = 15 CPU 制限集約
(使用状況ダッシュボードに報告されない) 特定の時間のルート組織:

最大同時実行の制限の CPU = 15
特定の日のルート組織:

最大同時実行の制限の CPU = 17
特定の月のルート組織:

最大同時実行の制限の CPU = 17

本番前の最大 CPU 制限

本番前 (Sandbox) の最大 CPU 制限は、アプリケーションが本番前環境にデプロイされて実行されている場合に使用できる CPU の最大量です。

CPU 制限ベースの使用量をアプリケーション ID ごとにドリルダウンして追跡し、次のメタデータを使用してグループ化できます。

Runtime Fabric クラスター名

基盤となるクラスターに、拡張するための十分な容量があるかどうかを追跡します。
ビジネスグループ

ビジネスグループごとに使用量を表示します。
ルート組織

コア使用量を監視して、合計エンタイトルメントを超えないようにします。

クラスター容量メトリクスは、ルート組織レベルでのみ使用できます。

データは 1 時間ごとに取得されますが、max (最大) メトリクスは、この例で示されているとおり、毎日および毎月追跡されます。

アプリケーションが本番前環境から本番環境に移行されると、そのアプリケーションの CPU 制限設定は、本番前環境と本番環境の両方の毎日の max (最大) メトリクスで考慮されます。

本番の最大クラスター容量

最大クラスター容量は、クラスター設定によって異なります。

データは 1 時間ごとに取得されますが、max (最大) メトリクスは、この例で示されているとおり、毎日および毎月追跡されます。

『Cluster Configurations』を参照してください。

本番前の最大クラスター容量

最大クラスター容量は、クラスター設定によって異なります。

データは 1 時間ごとに取得されますが、max (最大) メトリクスは、この例で示されているとおり、毎日および毎月追跡されます。

『Cluster Configurations』を参照してください。

使用量および価格設定メトリクスリファレンス

API Experience Hub 使用状況

API Governance 使用状況

API Manager 使用状況

Flex Gateway 使用状況

インテリジェントドキュメント処理 (IDP)

Mule Runtime 使用状況

Mule Runtime 使用状況テーブル

ビジネスグループの詳細

Application Details (アプリケーション詳細)

Mule Runtime 使用状況カード

最大 Mule フロー数

Anypoint Platform パッケージ割り当ての対象となる Mule フローシナリオ

イベントソースが含まれる Mule フロー

イベントソースの例

APIkit によって生成され、APIkit 要求のルーティングに使用される Mule フロー

Anypoint Platform パッケージ割り当ての対象とならない Mule フロー

総 Mule メッセージ数

Anypoint Platform パッケージ割り当ての対象となる Mule メッセージシナリオ

総データスループット

Runtime Fabric 使用量メトリクス

Runtime Fabric エージェントのバージョンおよび設定要件

使用量メトリクスを使用した Runtime Fabric コンプライアンス追跡

本番の最大 CPU 制限

例

本番前の最大 CPU 制限

本番の最大クラスター容量

本番前の最大クラスター容量

関連情報