--- schema_version: "1" id: 34ede7e7ccf29689b15177fb401924c6da8585398884d5dc8da04f0df74e6d80 title: Runtime Fabric へのアプリケーションデプロイメント用のリソースの割り当て collection: mulesoft version: current locale: ja-jp portal_url: https://docs.salesforce.com/mulesoft/current/ja-jp/runtime-fabric/2.8/deploy-resource-allocation-self-managed.md canonical_url: https://docs.mulesoft.com/jp/runtime-fabric/2.8/deploy-resource-allocation-self-managed source_site: docs.mulesoft.com content_type: documentation content_hash: f66d1ed8ac163930513100124415eabd7d61d451c0d3aca85599e254477a5d18 description: MuleSoft Documentation Site release: "2.8" latest: false --- # 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 (メモリ) Runtime Fabric インスタンスにデプロイするアプリケーションの ​[Mulesoft ライセンス要件](https://docs.mulesoft.com/jp/runtime-fabric/2.8/limitations-self#license-compliance)​を確認します。 ## [](#vcpu-の割り当て)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 以上のメモリが必要です。このコンテナは、アプリケーションメトリクスをコントロールプレーンにストリーミングするために使用され、無効にできません。 ## [](#cpu-バースト)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 と 150Mi のメモリを予約する必要があります。このコンテナは、アプリケーションメトリクスをコントロールプレーンにストリーミングするため、無効にできません。 - アプリケーションは、ワーカーノードの残りの未割り当て 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-のメモリ割り当ての計算)CloudHub および Runtime Fabric のメモリ割り当ての計算 Anypoint Platform は、デプロイされたアプリケーションにネイティブメモリとヒープメモリを割り当てます。ヒープメモリは、Mule Runtime とアプリケーションで使用可能な合計メモリの一部です。ヒープメモリはペイロードの処理などのタスクに使用されます。Anypoint Platform は、デプロイされたアプリケーションへのネイティブメモリの割り当てを JVM を介して、Java メモリ管理の標準プラクティスを考慮して実行します。 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-要件)キーと証明書の 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) とも呼ばれる) ## [](#関連情報)関連情報 - [Runtime Fabric に Mule アプリケーションをデプロイする](https://docs.mulesoft.com/jp/runtime-fabric/2.8/deploy-to-runtime-fabric) - [Runtime Fabric の健全性詳細の表示](https://docs.mulesoft.com/jp/runtime-fabric/2.8/view-health)