AliyunAMQPReadOnlyAccess がキューメッセージのクエリをサポートしない理由
AliyunAMQPReadOnlyAccess ポリシーは、amqp:Get* および amqp:List* 権限のみを付与します。キュー内のメッセージにアクセスするには、カスタムポリシーで amqp:BasicGet 権限を追加する必要があります。詳細については、「ApsaraMQ for RabbitMQ カスタムポリシーリファレンス」をご参照ください。
{
"Version": "1",
"Statement": [
{
"Action": [
"amqp:BasicGet"
],
"Resource": [
"acs:amqp:*:*:/instances/$instanceId/vhosts/$vhostName/queues/$queueName/messages/*"
],
"Effect": "Allow"
}
]
}キューをパージした後もコンソールにメッセージの蓄積が表示される理由
デフォルトでは、キューをパージしても遅延メッセージは削除されません。
QoS の仕組み
タイムアウトやブロッキングが発生した場合、サービス品質 (QoS) またはプリフェッチカウントを 1 に設定することで、クライアント側で同時に期限切れとなるメッセージが過剰にキャッシュされるのを防ぐことができます。
メッセージがデッドレターメッセージになるタイミング
メッセージに Time-to-Live (TTL) が設定されていない場合、メッセージがデッドレターメッセージになるのは、否定応答 (NACK) で拒否された場合、またはリトライ回数が上限に達した場合の 2 つのケースのみです。
メッセージ ID の設定方法
詳細については、「メッセージ ID の設定方法」をご参照ください。
デッドレターキューのメッセージ数が減少する理由
ApsaraMQ for RabbitMQ はメッセージを最大 3 日間保持します。デッドレターキュー内のメッセージが 3 日以上消費されないままでいると削除されるため、メッセージ数が減少します。詳細については、「使用制限」をご参照ください。
メッセージ保持期間
ApsaraMQ for RabbitMQ は、正常に消費されたメッセージと未消費のメッセージをすべて最大 3 日間保持します。詳細については、「使用制限」をご参照ください。
RabbitMQ の CIDR ブロック
ApsaraMQ for RabbitMQ の CIDR ブロックは固定されておらず、事前に取得することはできません。
キューの自動削除が有効にならない理由
コンシューマーがキューのサブスクライブに失敗した場合、`channel.close` を呼び出してもキューの自動削除はトリガーされません。自動削除機能は、コンシューマーが `channel.basicConsume` を使用してキューに正常にサブスクライブした後にのみ有効になります。
ストレージ料金とは
ApsaraMQ for RabbitMQ はメッセージを 3 日間保持します。ストレージ料金は、保存されているメッセージ本文の合計サイズに基づいて計算されます。このストレージ領域を手動でクリアすることはできません。メッセージの有効期限が切れると、領域は自動的に解放されます。
キューをパージすると、コンシューマオフセットがリセットされるだけです。履歴メッセージはパージ操作後もアクセス可能なため、ストレージ領域は減少しません。
キューのパージの役割
キューをパージするとコンシューマオフセットがリセットされ、コンシューマーは未消費のメッセージをスキップします。メッセージ自体は削除されません。履歴メッセージは、キューがパージされた後もアクセス可能です。
キューが 1 秒あたりに配信するメッセージ数を決定する要因
キューが 1 秒あたりに配信できるメッセージ数は、メッセージの量、コンシューマーの数、および各コンシューマーのサービス品質 (QoS) 設定によって決まります。
排他キューを使用する際の考慮事項
Spring を CONNECTION モードで使用する場合、アプリケーションを実行する前に、コンソールでエクスチェンジ、キュー、およびバインディングを作成する必要があります。これは、CONNECTION モードがこれらのリソースを自動的に宣言または作成しないためです。
メッセージがキューに入り 16 回リトライされた場合、課金は 1 回か 16 回か
課金は 1 回のみです。メッセージの再キューイングと再消費に追加料金は発生しません。最初の配信のみが課金対象となります。
再キューイングとは、消費試行が失敗した後、メッセージがサーバー側のキューに戻されることを意味します。その後、サーバーは専用のリトライキューを使用し、スケジュールされた間隔でメッセージを再度コンシューマーにプッシュします。
TPS 制限に対応する Cloud Monitor のメトリック
Cloud Monitor のメトリックは「インスタンスあたりの API リクエストレートのピーク」です。
接続数が制限を超える可能性
はい、超える可能性があります。公式ドキュメントでは接続制限はインスタンスごとと記載されていますが、実際にはバックエンドノードごとに適用されます。そのため、インスタンスの合計接続数が記載されている制限をわずかに超えることがあります。
サブスクリプションインスタンスの場合、構成を動的に調整することはできません。リソース制限によるサービス中断を避けるため、インスタンス作成時にリソースを慎重に計画する必要があります。
生成レートと消費レートが一致しているのに、モニタリングで蓄積が表示される理由
実際の送信レートと消費レートはほぼ同じですが、一部の確認応答 (ACK) の処理に時間がかかることがあります。これにより、特定のサンプリングポイントでモニタリングがメッセージの蓄積を報告する可能性があります。通常、蓄積レベルは次のサンプリングサイクルで正常に戻ります。
一部の Pod で消費量が急に低下した理由
Pod のパフォーマンスを確認する必要があります。CPU 使用率が高いと、クライアントが確認応答 (ACK) を迅速に送信できなくなる可能性があります。サーバーが ACK を受信しない場合、新しいメッセージのプッシュを停止し、タイムアウトを待ってからリトライします。この動作により、消費レートが低下します。
たとえば、サービス品質 (QoS) が 1 に設定されている場合、コンシューマーは一度に 1 つの未確認メッセージしか保持できません。サーバーは次のメッセージを送信する前に ACK を待つ必要があります。ACK が届かない場合、サーバーはタイムアウト期間が経過するまで待ってから処理を続行します。
RabbitMQ はデフォルトのマスターキーを使用できるか
はい、使用できます。
エラー：「The channelMax limit is reached」
サーバーは、チャンネルの総数ではなく、接続ごとのチャンネル数を制限します。
SDK では、`createChannel` が null を返すたびに「The channelMax limit is reached」というエラーが報告されます。
インスタンスをスペックアップした後は、クライアントを再起動する必要があります。そうしないと、クライアントは接続を確立する際にスペックアップ前のチャンネル制限を使い続け、エラーを報告し続けます。
たとえば、インスタンスが Channel Max 値 100 で購入された場合、クライアントは接続設定時にサーバーとこの制限をネゴシエートします。スペックアップ前に作成された既存の接続は、スペックアップ後の値である 2,000 や 2,500 ではなく、ネゴシエートされた値 100 を保持します。その結果、エラーは解消されません。
チャンネルパラメーターのネゴシエーションプロセス
TPS の増加は既存のサービスに影響するか
いいえ、影響しません。コンソールで 1 秒あたりのトランザクション数 (TPS) をスペックアップしても、瞬断や既存の接続の中断は発生しません。
接続の作成が他のチャンネルをシャットダウンする可能性
通常はありえません。ただし、ネットワーク帯域幅、メモリ、Java 仮想マシン (JVM) のキャパシティなど、クライアントのリソースが不足している場合、他の接続やチャンネルが中断される可能性があります。クライアントのリソース使用状況を確認し、中断の原因となっているリソースの競合や不足がないか特定する必要があります。
キューのコンシューマーが消えた理由
まず、該当期間中のクライアントのビジネスロジックとリソース使用量を確認する必要があります。サービス中断の原因となる可能性のある、一時停止したプロセスやリソース不足を探してください。クライアントが正常に実行されている場合は、サーバーがメッセージを正しく配信しているか確認してください。
キューをパージしてもメッセージが削除されない理由
1) 未確認 (unacked) のメッセージはパージでは削除できません。これらはすでにクライアントに配信されたものの、まだ確認応答がされていないメッセージです。これらのカウントは、有効期限が切れたときに自動的に更新されます。
2) Time-to-Live (TTL) 付きのメッセージがクリアされない場合は、チケットを送信して関連する構成スイッチが有効になっているか確認できます。
クラウドベースの RabbitMQ インスタンスは reply-to をサポートしているか
クラウドベースの RabbitMQ インスタンスは reply-to 機能をサポートしていません。
クライアントログから TPS を計算する方法
対応する SQL クエリは次のとおりです：
* and amqp-cn-xxx and Action : SendMessage | select InstanceId as instance_id, VHost as virtual_host, Queue as queue, microtime / 1000 / 1000 as time_second, count(*) as send_qps group by instance_id, virtual_host, queue, time_second order by time_second, send_qps limit 10000000結果のサンプル：
RabbitMQ ログの Logstore を変更した後、ログが空になる理由
新しい Logstore で、**[インデックスを有効化]** をクリックします。約 1 分後、ページをリフレッシュしてログを表示します。
手順：
1) **[インデックスを有効化]** をクリックします
2) **[OK]** をクリックします
RabbitMQ の接続が切断される原因
クライアントが有効な確認応答 (ACK) をほとんど送信しない場合、サーバーは応答がないためにメッセージを繰り返し再送します。これにより、持続的なメッセージの蓄積が発生します。
これはまた、メッセージがクライアント側で蓄積していることを示しており、ハートビートパケットの送信を妨げる可能性があります。最終的に、接続は `Connection ALL_IDLE` エラーで中断されます。まず、クライアントが有効な ACK を送信できない理由を調査する必要があります。
TTL の設定
設定できる Time-to-Live (TTL) の最大値は 3 日です。3 日を超える設定は無効です。TTL が有効にならない場合、期限切れのメッセージはデッドレターキューに送信されず、予期しない動作をする可能性があります。
1) TTL が設定されていない場合、キュー内のすべてのメッセージは通常メッセージです。モニタリングの readyMessage メトリックは通常メッセージの数を反映し、これが実際の蓄積量となります。
2) TTL が設定されている場合、readyMessage メトリックは有効なメッセージの数を反映します：
a) TTL が正しく機能する場合、有効なメッセージの数は TTL に基づいて動的に計算されます。readyMessage メトリックは実際の有効なメッセージ数を示します。これは期待される動作です。
b) TTL が設定されているがアクティブでない場合、有効なメッセージ数は 0 のままで、`readyMessage` メトリックは常に 0 を示します。これは実際のメッセージ蓄積量を反映しません。
エラー：java.lang.IllegalArgumentException: Content headers exceeded max frame size: 40209 > 32768
メッセージヘッダーのフレームサイズが制限を超えています。デフォルトのヘッダーサイズ制限は 32 KB であり、この制限はサーバー側で変更できません。
ヘッダーフレームサイズの制限を超えないように、大きなデータをヘッダーからメッセージ本文に移動することができます。
キューをパージした後もメッセージが見つかる理由
キューがパージされた後、メッセージ検索機能はログからデータを取得します。ログはメッセージよりも長期間保持されるため、履歴メッセージは引き続き検索可能です。
サブスクリプション関係のデタッチに失敗する理由
原因：
排他キューは、最初にそれを宣言した接続からのみ可視です。その接続のみがキューを削除できます。コンソールから削除することはできません。
詳細については、「排他キュー」をご参照ください。
解決策：
1) 排他キューが不要になった場合は、関連する接続を切断できます。キューとそのバインディングは自動的に削除されます。
2) 排他キューを作成するために使用された接続 ID が見つからない場合は、クライアントを再起動してキューを削除できます。
エラー: VPC フローのログインは許可されていません
原因：
サーバーは、使用されたユーザー名とパスワードがコンソールで生成された静的認証情報ではないことを検出します。これにより、トラフィックをオープンソース認証トラフィックと誤認し、接続を拒否します。
解決策：
VPC エンドポイントへの接続性を確認した後、ユーザー名とパスワードがコンソールで生成された静的認証情報であることを確認してください。不明な場合は、再生成して正しい構成を確保することができます。
クロスリージョンのプライベートネットワークアクセスを有効にする方法
標準的なソリューションは PrivateLink + CEN です。
注意：このソリューションには PrivateLink の料金が発生します。これを使用するには、チケットを送信してプライベートエンドポイントをリクエストする必要があります。リクエストが承認された後、コンソールでエンドポイントを構成できます。エンドポイントを構成する際は、vSwitch ゾーンとセキュリティグループの設定を確認してください。
詳細については、「PrivateLink エンドポイント」をご参照ください。