1. Homepage
  2. Runtime Fabric (2.4)

  3. リソース割り当て

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

Mule アプリケーションを Anypoint Runtime Fabric にデプロイする前に、適切な割り当てリソース数を決定します。リソース割り当ての決定は、Anypoint Runtime Fabric で内部ロードバランサーを設定するときにも重要です。

Mule アプリケーションが Runtime Fabric にデプロイされるときに、そのアプリケーションは独自の Mule Runtime Engine (Mule) と共にデプロイされます。レプリカの数、またはそのアプリケーションとランタイムのインスタンスも指定されます。各レプリカに使用できるリソースは、アプリケーションのデプロイ時に設定した値によって決まります。

次のパフォーマンス情報は、カスタム Intel Xeon E5-2676 v3 Haswell プロセッサーを使用するコントローラーノードのクラスターに基づきます。プロセッサーは 2.4 GHz のベースクロックレートで実行され、Intel Turbo Boost を使用すると 3.0 GHz まで上昇します。負荷ジェネレーターは、同じリージョンの別のクラスターでホストされます。

アプリケーションのデプロイ時に次のリソースを割り当てることができます。

  • vCPU コア

    • Reserved vCPU

      アプリケーションに対して保証されていて、アプリケーションで使用するために予約されている vCPU の数。

    • vCPU Limit

      アプリケーションで使用できる vCPU の最大数 (アプリケーションでバーストできるレベル)。これは、ワーカーノードで共有される CPU です。

  • Memory (メモリ)

MuleSoft ライセンスコンプライアンス

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

  1. 各 Mule アプリケーションレプリカに割り当てられている CPU 制限の合計がライセンスされている合計数量以下である。

  2. Mule アプリケーションを実行している Runtime Fabric ワーカーノードによって提供されている合計 CPU 容量がライセンスされている数量以下である。

予約済み 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 および制限の取得方法)」​を参照してください。

vCPU の割り当て

[​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 バースト

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

  • 最小予約済み vCPU: 0.02 vCPU。

  • vCPU の下限: 0.07 vCPU。

    大量のリソースを消費するアプリケーションでは、CPU 容量の追加が必要になる場合があります。アプリケーションデプロイメントで vCPU 下限量を使用していない場合は、vCPU 下限値を大きくしてからアプリケーションを再デプロイしてください。

  • CPU 制限の上限は、ワーカーノードで提供される CPU コアによって決まります。

  • 簡単なアプリケーションおよび API ゲートウェイの CPU コアごとの使用数は最大 20 ～ 25 個にすることをお勧めします。使用量の大きいより複雑なアプリケーションでは、より多くの容量が必要になる場合があります。

  • Runtime Fabric では、ワーカーノードで少数のサービスが実行されます。これらのサービスは、Anypoint Monitoring でログ転送が有効になっているかどうかに応じて 0.3 ～ 0.5 vCPU をコンシュームします。

  • 各アプリケーションのレプリカでは、Anypoint Monitoring を実行するコンテナ用に 50m の CPU と 50Mi のメモリを予約する必要があります。このコンテナは、アプリケーションメトリクスをコントロールプレーンにストリーミングするため、無効にできません。

  • アプリケーションは、ワーカーノードの残りの未割り当て CPU を求めて競合します。ワーカーノードにデプロイされているアプリケーションが多いほど、他のアプリケーションと共有できる未割り当て CPU が少なくなり、パフォーマンスが低下する可能性があります。アプリケーションとの CPU 競合を最小限に抑えるために、次の戦略を検討してください。

    • 日中に負荷がピークになる他のアプリケーションと共に夜間パッチアプリケーションをデプロイします。

    • アプリケーションの複数のレプリカをデプロイし、ワーカーノードで分散されるようにして、未割り当て CPU の表面積を最大化します。

      どのアプローチを選択する場合でも、テストを実行してパフォーマンスを検証します。

メモリの割り当て

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

  • 0.7 GB メモリ (Mule 4)

  • 0.5 GB メモリ (Mule 3)

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

CloudHub および Runtime Fabric のメモリ割り当ての計算

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

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

  • Runtime Fabric は、アプリケーションで使用可能な合計メモリを表示する。
    使用可能なヒープメモリは、アプリケーションに割り当てられる合計メモリの約半分です。

  • CloudHub は、アプリケーションで使用可能なヒープメモリの観点から最小メモリ要件を表す。

アプリケーションの起動時間

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

vCPU コア おおよその起動時間

1.00

1 分未満

0.50

2 分未満

0.10

6 ～ 8 分

0.07

10 ～ 14 分

アプリケーションのパフォーマンス

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

vCPU コア 同時接続 平均応答時間 (ミリ秒)

1.00

10

15

0.50

5

15

0.10

1

25

0.07

1

78
Mule アプリケーションでパフォーマンステストと負荷テストを実行し、割り当てるリソースの数を決定します。

キーと証明書の CPU 要件

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

コア PEM/P12 JKS/JCEKS

0.25

8

2

0.5

10

4

0.75

10

6

<= 1

10

8

キー種別

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

2K よりも長い RSA キーは、ブルートフォースクラッキングを防ぎ、有効期限が何年もある証明書に適しています。ただし、2k から 4k のようにキーの長さが 2 倍になると、パフォーマンスが 6 倍以上低下します。

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

  • secp521r1 (P-521)

  • secp384r1 (P-384)

  • secp256r1 (prime256v1 (P-256) とも呼ばれる)

関連情報