#1158 - OIC 26.07 - Async Queue Depth の新しいサービス制限 (2026/07/30)
#1158 - OIC 26.07 - Async Queue Depth の新しいサービス制限 (2026/07/30)
https://niallcblogs.blogspot.com/2026/07/1158-oic-2607-new-service-limit-for.html
はじめに
Oracle Integration Cloud (OIC) では、非同期リクエストは、ファイア・アンド・フォーゲット型のメッセージキューイングメカニズムを使用して、クライアントとバックエンドプロセスを分離します。このパターンにより、スループットが最大化され、下流システムがトラフィックの急増から保護され、統合リソースが効率的に使用されます。
貴重な情報ありがとうございます！ただし、サービス制限を導入いたしました。26.07リリース以降、この制限はOICインスタンスに割り当てられたメッセージパックの数に基づいています。
また、最近、新しいサービス指標である非同期キュー深度を導入しました。
さて、新しいサービス制限に戻りましょう。実際の計算式は次のように構成されています。
1時間あたりのメッセージ数を10倍してください。それが、非同期キューの潜在的なサイズの上限値となります。
簡単な例を挙げると、私のOICインスタンスには1つのメッセージパックが割り当てられているので、これは5000×10に相当します。つまり、キューサイズの上限は5万となります。これは、通常の10倍のリクエストが急増しても対応できる、言い換えれば10時間分のバックログがある、ということです。
この上にバッファを追加することで、1メッセージパックのOICインスタンスの場合、50001番目のメッセージが拒否されないようにします。ただし、バッファに頼るのではなく、割り当てたメッセージパック数の制限に注意してください。
ご覧のとおり、上限は60万ですが、必要に応じて引き上げることも可能です。そのためには、Oracleに問い合わせ、サービスリクエスト（SR）を起票するなどの手続きが必要になります。
限界に達する
OIC 26.07インスタンスでテストを実行しますが、その前に、 そのインスタンスの非同期キュー深度サービスメトリックを確認しましょう。
これから、非同期処理を実行し、その非同期処理が同期処理を呼び出します。同期処理には、120秒に設定された待機処理が含まれています。
そうやって私は順番待ちの列を作るんです。
サービスメトリクスを確認すると、キューが蓄積されていることがわかります。私が使用するサービスメトリクスクエリは次のとおりです。AsyncInboundRequestsDepth [ 1m]{resourceId = " yourOCID "}.grouping() .max()
別の2万キロテストを実行します。
さて、3回目のSOAPUIテストです。
そして4回目のラン -
私は現在、OIC内から同じ非同期統合を実行しています。
429 リクエストが多すぎます
{"type":"429","title":"現在、サービスが混み合っています。しばらくしてからもう一度お試しください。","detail":"サービスが一時的に混み合っています。しばらくしてからもう一度お試しください。"}
キュー制限の80%でアラームが鳴ります
キューが上限の80%に達したときに通知を受け取れるように、OCIアラームを作成しましょう。
別の負荷テストを実行します -
ビジネスの観点からすると、80%というのはおそらく非常に高い上限でしょう。ある顧客とこの件について話し合ったところ、彼女は上限を10%、つまり1時間分のバックログに設定すると言っていました。結局のところ、何が自社にとって最適かを決めるのはあなた次第です。
コメント
コメントを投稿