VM/ベアメタルの 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 および制限の取得方法)」​を参照してください。

使用状況を監視して、使用量がライセンス量を超えた場合にアラートを受け取る方法は、 MuleSoft ナレッジベースの「Cronjob Script to Monitor RTF Appliance CPU of Mule Apps (Mule アプリケーションの RTF アプライアンス CPU を監視するための Cronjob スクリプト)」​を参照してください。

[​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 とアプリケーションで使用可能な合計メモリの一部です。ヒープメモリはペイロードの処理などのタスクに使用されます。

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

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

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

内部ロードバランサーのメモリ要件は、スレッド数、応答時間のレイテンシー、およびメッセージサイズの影響を受けます。メモリを割り当てる場合は次のガイドラインを使用してください。

インバウンドトラフィックは、Anypoint Runtime Fabric によって管理される内部ロードバランサーを使用して処理されます。このロードバランサーは TLS の終了を担当するため、必要なリソースの数は受信接続の数と各要求の平均ペイロードサイズに基づいて調整されます。

パフォーマンステストの結果は、AWS EC2 M4 インスタンスを使用するコントローラーノードが含まれる Runtime Fabric クラスターに基づきます。クラスターは、3 個の m4.large コントローラーノードと 3 個の r4.large ワーカーノードを使用して設定されています。パフォーマンステストで使用された負荷ジェネレーターは、同じリージョンの別の AWS インスタンスでホストされました。M4 インスタンスは EC2 専用に最適化されたカスタム Intel Xeon E5-2676 v3 Haswell プロセッサーを搭載しており、2.4 GHz のベースクロックレートで実行されました。Intel Turbo Boost を使用すると、クロックレートが 3.0 GHz まで上昇しました。

SSL 接続の効率がより高い C++ ベースの負荷ジェネレーターを使用して、最大のスループットを実現しました。

次の表には、CPU コアの数に基づいて、内部ロードバランサーの 1 つのレプリカで処理できるおおよその要求数 (平均 10 KB) がまとめられています。ほとんどの場合、Elliptical Curve Digital Signature Algorithm (ECDSA) のパフォーマンスは、2K RSA キーの 2 倍になります。サポートされている曲線は、secp521r1 (P-521)、secp384r1 (P-384)、secp256r1 (prime256v1 (P-256) とも呼ばれる) です。

*RSA キーの長さを 2 倍にすると、パフォーマンスが 6 倍以上低下します。

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

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

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