APIコンシューマ
****************************************
>> API クライアントは、API コンシューマーのクライアント認証情報を使用するコードまたはプログラムの一部ですが、アクセスを取得するために Anypoint Exchange と直接対話することはありません。
>> API コンシューマは登録を取得して API へのアクセスをリクエストする必要があり、API クライアントはそれらのクライアント認証情報を使用して API にアクセスする必要があるため、API コンシューマは Anypoint Exchange から API へのアクセスをリクエストする必要があります

サービス拒否攻撃に対する防御
****************************************
>> バックエンド システムの過負荷は、「スパイク コントロール ポリシー」を適用することで処理できます。
>> HTTP リクエストと応答のログは、「メッセージ ログ ポリシー」を適用することで実行できます。
>> 「セキュリティ」ポリシーと「コンプライアンス」ポリシーを使用して認証情報の改ざんを防止できます。 ただし、残念ながら、Anypoint Platform には現在 DOS 攻撃を防ぐ適切な方法がありません。

4.0.0
****************************************
semver.org のセマンティック バージョニング仕様によると、次のようになります。
バージョン番号 MAJOR.MINOR.PATCH を指定すると、次の値をインクリメントします。
- 互換性のない API 変更を行った場合のメジャー バージョン。
- 下位互換性のある方法で機能を追加する場合のマイナー バージョン。
- 下位互換性のあるバグ修正を行う場合の PATCH バージョン。
質問に示されているシナリオによれば、API 実装の動作は完全に変更されています。
時刻の形式はまだ hh:mm:ss として維持されており、スキーマ形式に変更はありませんが、時代が完全に異なるため、この変更後は API が異なる機能を開始します。
例: 変更前は、時間が PST を表す 09:00:00 として進行していたとします。変更後は、中央ヨーロッパの夏時間は太平洋時間より 9 時間進んでおり、同じ時刻が 18:00:00 になります。
>> これにより、API クライアントが API 応答の時間をどのように処理しているかによって、API クライアントで不確実な動作が発生する可能性があります。API 機能が変更され、CEST 形式で返されることをすべての API クライアントに通知する必要があります。したがって、これは大きな変更とみなされ、この新しい変更の API のバージョンは 4.0.0 になります。

HTTPS エンドポイントを公開するために API 実装によって使用される SSL 証明書
****************************************
>> 各 HTTP リクエストの特定の CloudHub ワーカーへの割り当ては、Anypoint Platform 自体によって処理されます。API 実装で明示的に管理する必要はなく、実際、API 実装で管理することはできません。
>> Runtime Manager でログ エントリを表示できるようにするログ設定は、SLB だけでなく、常に API 実装で管理されます。したがって、これは SLB を使用するときに独占的に行うものではありません。
>> コード内の API 実装に割り当てられた DNS エントリの数は管理されません。
Anypoint Platform がこれを処理します。
これは、API 実装によって排他的に管理される HTTPS エンドポイントを公開するために API 実装によって使用される SSL 証明書です。Anypoint Platform は、SLB を使用する場合、これを行いません。

CloudHub ワーカーのサイズを増やす
****************************************
特定のシナリオから得られる主な詳細は次のとおりです。
>> API 実装では、データベース一括挿入コマンドを使用して、すべての購入データをデータベースに送信します
>> JDBC ドライバーはデータを CloudHub ワーカー上の複数の一時ディスク ファイルのセットに処理します
>> リクエストが失敗し、ファイル容量不足を示すメッセージがログに表示される場合があります。 上記の詳細に基づくと、次のようになります。
>> エラー メッセージに基づいて自動スケーリング ルールを設定できないため、両方の自動スケーリング オプションは役に立ちません。自動スケーリング ルールは、特定のエラーやディスク容量の問題ではなく、CPU/メモリの使用量に基づいて開始されます。
>> CloudHub ワーカーの数を増やしても、失敗の理由は CPU やメモリなどのパフォーマンス面によるものではないため、ここでは役に立ちません。ディスク容量が原因です。
>> また、API は受信したバッチデータを送信するために一括挿入を行っています。つまり、すべてのデータは一度に 1 人のワーカーによってのみ処理されます。したがって、ディスク容量の問題は「ワーカーごと」に基づいて取り組む必要があります。特定のワーカーのディスク領域が不足している場合、どのワーカーでもバッチが失敗する可能性があるため、複数のワーカーを使用しても役に立ちません。
したがって、この問題に対処して解決する正しい方法は、ワーカーの仮想コア サイズを増やして、より多くのディスク領域を持つ新しいワーカーがプロビジョニングされるようにすることです。