クロス API モニタリングの必要性を理解する:
Center for Enablement (C4E) は、顧客がカートを放棄する原因となっている可能性のある、アプリケーション ネットワーク内の複数の API にわたる潜在的な技術的問題を調査する必要があります。
これには、複数の API にわたるメトリックをリアルタイムで表示して、パフォーマンスの問題やボトルネックを特定できるソリューションが必要です。
Anypoint プラットフォームの機能の評価:
組み込みダッシュボード：Anypoint Platform は、Anypoint Monitoring に組み込みダッシュボードを提供しており、複数の API のメトリクスを単一のインターフェースで確認できます。この機能は、API のパフォーマンス、レイテンシ、エラー、スループットを監視するように設計されており、アプリケーションネットワークのあらゆるレイヤーにわたるパフォーマンスの追跡に最適です。
カスタム ダッシュボード: カスタム ダッシュボードではよりカスタマイズされたビューが可能になりますが、組み込みダッシュボードではすでに複数の API のメトリックが集約されているため、このシナリオ用にカスタム ソリューションを構築する必要はありません。
機能モニタリング: この機能は、特定の API 機能と稼働時間を監視するためのテストを設定するために使用されますが、複数の API にわたるメトリックをリアルタイムで追跡するには適していません。
API マネージャー: API マネージャーは、アプリケーション ネットワーク全体にわたる詳細なリアルタイム メトリックを提供するのではなく、API ポリシー、契約、およびアクセス制御の管理に主に重点を置いています。
結論：
オプション B (組み込みダッシュボード) は、関連するすべての API からのメトリックの包括的なビューを提供し、ショッピング カートの放棄につながる可能性のある問題を C4E チームが迅速に特定できるため、最適な選択肢です。
これらのダッシュボードを効果的に構成して使用する方法の詳細については、MuleSoft の Anypoint Monitoring および組み込みダッシュボードに関するドキュメントを参照してください。

正解: API 実装によって許可される残りの容量。
*****************************************
>> 参考: https://docs.mulesoft.com/api-manager/2.x/rate-limiting-and-throttling-sla-based-policies#response-headers

正解: これらは、Anypoint Platform コントロール プレーンによって管理される Anypoint Platform ランタイム プレーンにデプロイする必要があり、両方のプレーンは同じ管轄区域内にある必要があります。
*****************************************
>> 法規制により、すべてのデータ処理は特定の管轄区域内で行われる必要があります。つまり、米国のデータは米国内に保存され、米国外に持ち出されるべきではありません。同様に、EUのデータはEU内に保存され、EU外に持ち出されるべきではありません。
>> つまり、転送中や保存中のデータを暗号化するだけでは、規則遵守には役立ちません。データが外部に流出しないようにすることも必要です。
>> ここで言及しているデータは、Anypoint MQにパブリッシュされるメッセージだけではありません。実行中のアプリケーション、トランザクションの状態、アプリケーションログ、イベント、メトリック情報、その他のメタデータも含まれます。したがって、Anypoint MQをローカルでホストされているActiveMQに置き換えるだけでは役に立ちません。
>> ここで言及しているデータは、オブジェクトストアに保存されているキー/バリューペアだけではありません。発行されたメッセージ、実行中のアプリケーション、トランザクションの状態、アプリケーションログ、イベント、メトリック情報、その他のメタデータも含まれます。したがって、オブジェクトストアの使用を避けるだけでは役に立ちません。
>> 与えられた選択肢の中で唯一残された、そして正しい選択肢は、管轄区域内にあるランタイム プレーンとコントロール プレーンにアプリケーションをデプロイすることです。

正解: タイムアウトを 100 ミリ秒に設定します。これにより、他の 2 つの下流 API が完了するまでに 400 ミリ秒の時間が残ります。
*****************************************
与えられたシナリオから得られる重要な詳細:
>> アップストリームAPIの設計SLAは500ミリ秒（中央値）です。SLAの最大応答時間は無視します。
>> この API は 3 つのダウンストリーム API を順番に呼び出しますが、これらはすべて同様の複雑さです。
>> 最初のダウンストリーム API は、平均 SLA 100 ミリ秒、80 パーセンタイル: 500 ミリ秒、95 パーセンタイル: 1000 ミリ秒を提供します。
上記の詳細に基づいて:
>> 50msのタイムアウトを設定するという選択肢は除外できます。なぜなら、提供されるSLAの中央値が100msの場合、ほとんどの呼び出しがタイムアウトになり、再試行に時間が浪費され、最終的にはすべての再試行で限界に達してしまうからです。たとえ一部の再試行が成功したとしても、残りの時間では、下流の2番目と3番目のAPIが時間内に応答するのに十分な余裕がありません。
>> このAPIの呼び出しは必須なので、応答するまで待つ必要があるため、タイムアウトを設定しないという選択肢は不適切です。タイムアウトを設定しないことは、適切な実装パターンに反するだけでなく、最初のAPIが提示されている平均SLAの100ミリ秒以内に応答しない場合、おそらく500ミリ秒（80パーセンタイル）または1000ミリ秒（95パーセンタイル）以内に応答するでしょう。どちらの場合も、最初の下流APIから正常な応答が得られても意味がありません。なぜなら、この時点で既に上流APIのSLAである500ミリ秒を超えているからです。2番目と3番目の下流APIを呼び出す時間はありません。
>> アップストリーム API の望ましい SLA を満たすためにタイムアウトが不可能であるというのは真実ではありません。
最初のダウンストリームAPIのSLA中央値は100ミリ秒であるため、ほとんどの場合、その時間内に応答が返されます。したがって、ほとんどの呼び出しではタイムアウトを100ミリ秒に設定することで、残りの2つのダウンストリームAPI呼び出しに400ミリ秒の余裕が確保されるため、理想的です。