--- schema_version: "1" id: 342b2f2f5986e421e6415bb48440331da7fbf6e725f905c6e40aaf68cc3b11bf title: 拡張性ベンチマーク collection: mulesoft version: current locale: ja-jp portal_url: https://docs.salesforce.com/mulesoft/current/ja-jp/runtime-fabric/2.5/rtf-scale.md canonical_url: https://docs.mulesoft.com/jp/runtime-fabric/2.5/rtf-scale source_site: docs.mulesoft.com content_type: documentation content_hash: 8e003936f8c9cc486882e9d7e676472c1729e263427c82a1d722d20f7a242066 description: MuleSoft Documentation Site release: "2.5" latest: false --- # 拡張性ベンチマーク Runtime Fabric は中核となる Kubernetes (K8s) ソフトウェアであり、Runtime Fabric のハードウェアとソフトウェアの要件に準拠するすべての K8s 環境で同じように動作します。次のスケールリミットは、Amazon Elastic Kubernetes Service (Amazon EKS) クラスターで評価されています。
制限事項 説明 Runtime Fabric による適用

ノード数

ノードの最大数は 400 です。

推奨

Runtime Fabric でのデプロイメント

最適なパフォーマンスを保証するため、任意のインスタンスにおいて Runtime Fabric が管理するデプロイメントの最大数は 8000 を超えないようにしてください。

推奨
Runtime Fabric の機能やアプリケーションデプロイメントの管理は以下に左右されません。 - 各アプリケーションのサイズ - ワーカーノードのサイズ - ワーカーノードあたりの実行されているポッド数 Runtime Fabric は K8s ベースであり、クラウドネイティブのオーケストレーションプリンシパルを使用しているため、指定されたデプロイメントの設定に従って動作します。 次の評価されたメトリクスを確認して、ほぼ空のクラスターと 8000 個のデプロイを実行しているクラスターを比較した場合のさまざまな管理メトリクスを把握してください。使用されているクラスター設定は、AWS EKS クラスター上の Runtime Fabric です。
設定 説明

VPC とノードグループ

eksctl から実行されるデフォルトの設定。3 つのサブネット (ノードグループごとに 1 つのサブネット)、NAT ゲートウェイ。

AWS NLB

Nginx 作成時に Helm チャートを介して装備。

ノードの自動スケーラー

推奨 3 GB (メモリ)/200m vCore (要求==上限)

ワーカー

m5.4x の大きさ、ワーカーノードグループ

監視

固定、1 つのノード、Prometheus、監視ノードグループ、m5.2x の大きさ

イングレス

固定、2 つのノード、Nginx、イングレスノードグループ、m5.4x の大きさ
次の画像は、顧客またはクラスターのアップグレードによって呼び出された場合に Runtime Fabric エージェントが再起動に要する時間を示しています。 ![ほぼ空のクラスターと負荷ありのクラスターの再起動のレイテンシーを示す図](/mulesoft/current/ja-jp/runtime-fabric/2.5/_images/rtf-scale-cluster-upgrade.png) Runtime Fabric は、デプロイメントの量に関係なくアプリケーションの作成に約 190 秒を要します。 次の表に、Mule アプリケーションの起動、停止、削除に要する時間を示します。
アプリケーション操作 ほぼ空のクラスター 負荷あり

起動のレイテンシー

~110 秒

158 秒

停止のレイテンシー

~10 秒

20 秒

削除のレイテンシー

~9 秒

~28 秒
次の表に、不正なノードがある場合に node cordon 操作を再開するのに要する時間を示しています。
ノード操作 空のクラスター 負荷ありのクラスター

Cordon

~2 秒

~2 秒

Drain process

~4 秒

~35 秒
考慮すべき側面: - Runtime Fabric エージェントは大規模なデプロイメントのクラスターを管理する場合に必要なメモリや CPU の量がデフォルトよりも多くなり、これらの値は次の表の情報を使用して変更できます。8000 件のデプロイメントがあるクラスターでは、少なくとも次の量を使用してください。
クラスターの推奨 デフォルト 200 個のノード/8000 個のアプリケーションリソース設定

エージェントリソース

メモリは 200 mb を要求、500 mb が上限。CPU は 100m を要求、1vCore が上限。

3 GB (メモリ)/2vCore (要求 == 上限)
- Helm では、大規模の操作を行う場合、ノードウォッチャー ​`nodeWatcherEnabled`​ を明示的に無効にする必要があります。ノードウォッチャーは必ずデフォルトで有効になっています (​`nodeWatcherEnabled: true`​)。 - Runtime Fabric を使用した大規模のデプロイメントのオーケストレーションのパフォーマンスはデプロイメントの量に反比例します。 - RTFCTL クラスターは特定のベンチマークに対してのみサポートされています。 - Helm を使用すると、クラスターのサイズのために Runtime Fabric エージェントにカスタマイズされたリソースが必要な任意のクラスターを管理できます。