Runtime Fabric のリソース割り当てとパフォーマンス

お客様は、常に MuleSoft のライセンス規約に準拠する必要があります。準拠の条件は以下のいずれかになります。

予約済み vCPU と vCPU 制限を追跡する方法は、 「How to Get Runtime Fabric (RTF) CPU Reserved and Limit for Self Managed Kubernetes and RTF Appliance (自己管理型 Kubernetes と RTF アプライアンスでの予約済み Runtime Fabric (RTF) CPU および制限の取得方法)」​を参照してください。

[​Reserved vCPU​ (予約済み vCPU)] と [​vCPU Limit​ (vCPU 制限)] が等しい場合、保証されたモデルでワーカーノードの CPU が割り当てられます。コンテナでは、常に指定された数の CPU を使用できます。vCPU は、アプリケーションの各レプリカ用に予約されており、Runtime Fabric で他に何が実行されていても保証されます。

CPU の割り当てが保証されていると、他のアプリケーションとの CPU 競合がなくなり、アプリケーションの実行の一貫性が確保されます。すべてのケースでパフォーマンスが保証されます。

[​vCPU Limit​ (vCPU 制限)] の値が [​Reserved vCPU​ (予約済み vCPU)] の値よりも高く設定されていると、アプリケーションは、[vCPU limit (vCPU 制限)] の値またはワーカーノードの予約されていない vCPU の数のいずれか少ない方までバーストできます。

ワーカーノードに必要な CPU とメモリを見積もる場合、Anypoint Monitoring エージェントには Anypoint Monitoring 用に 0.05 以上の vCPU コアと 50 Mi 以上のメモリが必要です。このコンテナは、アプリケーションメトリクスをコントロールプレーンにストリーミングするために使用され、無効にできません。これらのコアとメモリの割り当ては Mule のライセンスには使用されません。

CPU バーストを使用するときは、次の要素を考慮する必要があります。

Mule アプリケーションまたは API ゲートウェイの各レプリカに割り当てられるメモリの量の最小値は、次のとおりです。

Anypoint Monitoring を有効化すると、Anypoint Monitoring サイドバーコンテナ用に 50MB のメモリが予約され、デプロイされた各アプリケーションがメトリクスを処理する際に最大 70MB を消費します。

Anypoint Platform は、デプロイされたアプリケーションにネイティブメモリとヒープメモリを割り当てます。ヒープメモリは、Mule Runtime とアプリケーションで使用可能な合計メモリの一部です。ヒープメモリはペイロードの処理などのタスクに使用されます。Anypoint Platform は、デプロイされたアプリケーションへのネイティブメモリの割り当てを JVM を介して、Java メモリ管理の標準プラクティスを考慮して実行します。

CloudHub と Anypoint Runtime Fabric とも、両方の種別のメモリを割り当てます。ただし、各メモリ種別のメモリ割り当てが計算される方法は異なります。

Mule アプリケーションの起動時間は、そのアプリケーションがアクセスできる vCPU コアの総数と相関しています。次の表では、ペイロードで処理を実行する単純な Mule プロキシアプリケーションのおおよその起動時間を示しています。

Mule アプリケーションに割り当てられたリソースによって、アプリケーションのパフォーマンスが決まります。次の表では、10-KB ペイロードで簡単な処理を実行する 1 つの Mule アプリケーションに割り当てられた vCPU コアの総数に基づく、スループットのおおよその値を次に示します。

最小 10 個の PEM/P12 または 8 個の JKS/JCEKS 証明書をサポートするのに十分な CPU リソースを割り当てていることを確認します。推奨されるコアの数は次のとおりです。

RSA キーは最も一般的なキー種別です。2K の長さの RSA キーは、セキュリティとパフォーマンスの最適なバランスを実現します。

ECDSA キーもサポートされています。ほとんどの場合、ECDSA のパフォーマンスは、2K RSA キーの 2 倍になります。サポートされている曲線は、次のとおりです。