システム層

API 主導の接続アプローチで使用される API は、次の 3 つのカテゴリに分類されます。
システム API - これらは通常、レコードのコア システムにアクセスし、ユーザーを基盤システムの複雑さや変更から隔離する手段を提供します。一度構築されると、多くのユーザーは基盤システムを学習することなくデータにアクセスでき、複数のプロジェクトでこれらの API を再利用できます。
プロセス API - これらの API は、単一のシステム内またはシステム間で (データ サイロを解体して) データと対話してデータを形成します。これらの API は、データの元となるソース システムや、そのデータが配信されるターゲット チャネルに依存せずにここで作成されます。
エクスペリエンス API - エクスペリエンス API は、各チャネルに個別のポイントツーポイント統合を設定するのではなく、共通のデータ ソースからデータを再構成して、対象ユーザーが最も簡単に使用できるようにするための手段です。エクスペリエンス API は通常、API ファーストの設計原則に基づいて作成され、特定のユーザー エクスペリエンスを念頭に置いて API が設計されます。

正解: CloudHub 共有ロードバランサー
****************************************
この質問のシナリオは以下のように分割できます。
>> CloudHub ワーカーは 3 つあります (つまり、大量のリクエストを処理するのに十分な数のワーカーがすでにあります)
>> ワーカーは静的 IP アドレスを使用していません (したがって、静的 IP なしでは顧客の負荷分散ソリューションを使用することはできません)
>> ワーカー間でクライアント要求の負荷を分散するための最もコスト効率の高いコンポーネントを探しています。
シナリオに記載されている上記の詳細に基づきます。
>> 実行時の自動スケーリングは、追加コストがかかるため、まったく費用対効果が高くありません。ほとんどの場合、すでに 3 つのワーカーが実行されており、これは適切な数です。
>> 顧客がホストするロード バランサは、コスト効率が最も良くないため (保守とライセンスにカスタム ロード バランサが必要)、選択できません。また、Mule アプリには静的 IP アドレスがないため、カスタム ロード バランシングの使用が制限されます。
>> API プロキシは、大量の処理や負荷分散に関して役割を果たさないため、ここでは無関係です。
したがって、最もコスト効率が高く、シナリオの目的に合う唯一の適切なオプションは、CloudHub 共有ロードバランサを使用することです。

非本番環境と本番環境用に個別の Anypoint VPC を作成し、対応する顧客ホスト環境のバックエンド システムへの接続を構成します。
****************************************
>> 異なるビジネス グループを作成しても、非本番環境と本番環境の顧客ホスト環境へのアクセスには影響しません。プロセス ネットワーク制限が設定されていない限り、両方のビジネス グループからアクセスすることになります。
>> Mule アプリケーション実装を環境に合わせて変更または結合する必要があります。実際、プロパティにバインドして環境と結合したアプリケーションを実装することは絶対に避けてください。エンドポイント URL などの基本的なものだけをプロパティにバンドルし、環境レベルのアクセス制限はバンドルしないでください。
>> CloudHub 上の IP アドレスは、特別な静的アドレスが割り当てられない限り動的です。そのため、顧客がホストするインフラストラクチャでファイアウォール ルールを設定することはできません。さらに、静的 IP アドレスが割り当てられている場合でも、CloudHub 上で実行されるアプリケーションは数百に上る可能性があり、それらすべてにルールを設定するのは大変な作業で、メンテナンスが不可能であり、間違いなく良い習慣になります。
>> Mulesoft (実際はどのクラウド プロバイダーでも) が推奨するベスト プラクティスは、Anypoint VPC を Prod と Non-Prod に分離し、これらの Anypoint VPC に対して、それぞれの Prod および Non-Prod の顧客ホスト環境ネットワークへの VPC ピアリングまたは VPN トンネリングを実行することです。