ApsaraMQ for RabbitMQ:よくある質問

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 に設定してください。これにより、クライアントが、同時に期限切れになる可能性のあるメッセージをキャッシュしすぎるのを防ぎます。

デッドレターキューへのメッセージ配信

TTL 値のないメッセージは、否定応答 (NACK) されるか、リトライ回数が上限に達した場合にのみ、デッドレターキューに送信されます。

メッセージ ID の設定

詳細については、「メッセージ ID の設定方法」をご参照ください。

デッドレターキューのメッセージ数の減少

ApsaraMQ for RabbitMQ はメッセージを最大 3 日間保持します。メッセージが 3 日以内に消費されない場合、デッドレターキューから自動的に削除されるため、メッセージ数が減少します。詳細については、「制限事項」をご参照ください。

メッセージ保持期間

ApsaraMQ for RabbitMQ は、消費されたかどうかに関わらず、すべてのメッセージを最大 3 日間保持します。詳細については、「制限事項」をご参照ください。

RabbitMQ のネットワークセグメント

ApsaraMQ for RabbitMQ インスタンスのネットワークセグメントは固定されていないため、この情報を事前に取得することはできません。

キューの自動削除に関する問題

コンシューマーがキューへのサブスクライブに成功していない場合、channel.close を呼び出してもキューの自動削除はトリガーされません。自動削除ロジックは、コンシューマーが channel.basicConsume を使用してサブスクライブに成功した場合にのみ有効になります。

ストレージ料金

ApsaraMQ for RabbitMQ はメッセージを 3 日間保持します。ストレージ料金は、メッセージ本文のストレージ量に基づいて計算されます。このストレージ領域は手動でクリアすることはできず、メッセージの有効期限が切れた場合にのみ解放されます。

パージしてもメッセージは削除されないため、ストレージ領域の使用量は削減されません。

キューのパージ

キューをパージするとコンシューマーオフセットがリセットされ、コンシューマーは未消費のメッセージをスキップします。この操作ではメッセージは削除されず、引き続きアクセス可能です。

キュー出口レートの決定要因

キューのメッセージ配信レートは、メッセージ量、コンシューマーの数、およびそれらの QoS 設定によって決まります。

排他キューに関する考慮事項

Spring フレームワークを CONNECTION モードで使用する場合、事前にコンソールでエクスチェンジ、キュー、およびバインディングを作成する必要があります。CONNECTION モードでは、これらのリソースは自動的に宣言または作成されません。

メッセージリトライの課金

課金対象は最初の配信のみです。その後の再キューイングおよび消費の試行では、追加料金は発生しません。

再キューイングは、コンシューマーがメッセージの処理に失敗し、サーバーキューに返されたときに発生します。サーバーは専用のリトライキューを使用して、特定の時間間隔でメッセージをコンシューマーに再配信します。

TPS 制限のメトリック

TPS 制限は、Cloud Monitor の [インスタンスあたりのピーク API リクエストレート] メトリックに対応します。

接続制限の超過

接続制限はインスタンスレベルの制限として文書化されていますが、バックエンドノードレベルで適用されます。その結果、インスタンスの合計接続数が記載されている制限をわずかに超える場合があります。

サブスクリプションインスタンスの設定は動的に調整できません。リソース制限を超えてビジネスに支障をきたすことを避けるために、インスタンスを作成する際には慎重にリソースを計画することを推奨します。

レート均衡時のメッセージ蓄積

生成レートと消費レートのバランスが取れていても、一部のメッセージの確認応答 (ACK) が遅れると、モニタリングツールが特定のサンプリング時間に一時的なメッセージの蓄積を報告することがあります。この蓄積は、通常、次のサンプリングサイクルで正常に戻ります。

Pod の消費レートの急激な低下

Pod のパフォーマンスを確認することを推奨します。CPU 使用率が高いと、クライアントが ACK を迅速に送信できなくなる可能性があります。サーバーが ACK を受信しない場合、新しいメッセージをプッシュできず、タイムアウトを待ってからリトライする必要があります。これにより、消費レートが低下します。

たとえば、QoS が 1 に設定されている場合、コンシューマーは一度に 1 つの未確認メッセージしか持つことができません。サーバーは、コンシューマーがメッセージを処理して ACK を送信するのを待ってから、次のメッセージをプッシュする必要があります。ACK が受信されない場合、サーバーはタイムアウトを待ってからリトライする必要があります。

デフォルトのマスターキーの使用

はい。

エラー：「The channelMax limit is reached」

サーバーは、すべての接続にまたがるチャネルの総数ではなく、接続ごとのチャネル数を制限します。

このエラーは、createChannel メソッドが null を返した場合に SDK によってログに記録されます。

インスタンスをアップグレードした後は、クライアントを再起動する必要があります。そうしないと、既存の接続はアップグレード前のチャネル制限を使用し続け、エラーが発生し続けます。

たとえば、インスタンスを最大チャネル数 100 で購入した場合、クライアントとサーバーは接続確立時にこの制限をネゴシエートします。後でインスタンスをアップグレードして 2,000 または 2,500 チャネルをサポートするようにしても、アップグレード前に確立された接続には元の 100 チャネル制限が適用され続け、エラーを引き起こします。

チャネルパラメーターのネゴシエーションプロセス

TPS のアップグレードによる影響

いいえ。コンソールで TPS 制限をアップグレードしても、既存の接続が中断されたり切断されたりすることはありません。

新しい接続が原因のチャネルシャットダウン

通常はありません。ただし、ネットワーク帯域幅、メモリ、JVM 容量などのクライアントリソースが不足すると、他の接続やチャネルが中断される可能性があります。これらの割り込みの原因となっているリソースの競合や不足がないか、クライアントのリソース使用状況を調べることを推奨します。

キューコンシューマーの消失

まず、インシデント発生時のクライアントのアプリケーションロジックとリソースの状態を確認することを推奨します。プロセスの停止やリソース不足など、アプリケーションを中断させた可能性のある問題を探してください。クライアントが正常に機能している場合は、サーバーが期待どおりにメッセージを配信しているかどうかを確認してください。

キューのパージが反映されない場合

キューをパージしても、未確認 (unacked) メッセージはクリアされません。これらは、クライアントに配信されたものの、まだ確認応答がされていないメッセージです。未確認メッセージ数は、メッセージの有効期限が切れた後に自動的に更新されます。

クライアントログからの 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

結果のサンプル：

Logstore 変更後にログが空になる

新しい Logstore で、[インデックスを有効化] をクリックします。約 1 分待ってページを更新すると、ログが表示されます。

手順：

1) [インデックスを有効化] をクリックします。

2) [OK] をクリックします。

RabbitMQ の切断の原因

クライアントが送信する有効な ACK の数が少ない場合、サーバーは確認応答を受信しないため、メッセージを繰り返し再配信します。これにより、メッセージの蓄積が続く可能性があります。

クライアント側でのこのメッセージの蓄積は、接続がハートビートパケットを送信するのを妨げる可能性があります。これにより、最終的に Connection ALL_IDLE エラーと切断がトリガーされます。まず、クライアントが有効な ACK の送信に失敗している理由を調査する必要があります。

TTL の設定

最大 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 flow is not allowed to login in」

原因：

サーバーは、使用された認証情報がコンソールから生成された静的認証情報ではないと判断しました。サーバーはリクエストをオープンソースの認証トラフィックと誤解釈し、接続を拒否します。

解決策：

VPC からの接続性を確認した後、コンソールで生成された静的認証情報を使用していることを確認してください。不明な場合は、認証情報を再生成することを推奨します。

インスタンスの作成に 30 分以上かかる

トラブルシューティング手順：

• インスタンス作成時に指定した VPC が存在し、自分のアカウント (UID) に属し、利用可能状態であることを確認してください。

• インスタンス作成時に指定した vSwitch が要件を満たしていることを確認してください。CreateInstance API の VswitchIds パラメーターをご参照ください。

原因：

この問題は通常、インスタンス作成プロセス中に VPC または vSwitch の設定が変更された場合に発生します。たとえば、最初のリクエスト検証が成功した後に VPC が削除されると、非同期のインスタンス作成は失敗します。

解決策：

プロセス中に作成パラメーターが変更された場合 (たとえば、VPC または vSwitch が削除された場合) 、ApsaraMQ for RabbitMQ インスタンスを解放し、新しいインスタンスを作成してください。

クロスリージョンでのプライベートネットワークアクセス

クロスリージョンでのプライベートネットワークアクセスの標準的なソリューションは、PrivateLink と Cloud Enterprise Network (CEN) の組み合わせを使用することです。

このソリューションでは PrivateLink の料金が発生することにご注意ください。 詳細については、「PrivateLink エンドポイント」をご参照ください。

PrivateLink エンドポイント作成時のエラー：VPC パラメーター

原因：

VPC ID が存在しないか、VPC が利用可能状態ではありません。

解決策：

選択した Virtual Private Cloud (VPC) が存在し、「利用可能」状態であることを確認してください。VPC のステータスは、VPC コンソールで確認できます。

PrivateLink エンドポイント作成時のエラー：vSwitch パラメーター

原因：

選択した vSwitch が、次の条件の 1 つ以上を満たしていません：

• 少なくとも 2 つの異なるゾーンから vSwitch を選択する必要があります (一部の単一ゾーンリージョンには適用されません) 。

• vSwitch は選択した VPC に属している必要があります。

• vSwitch は利用可能状態である必要があります。

• vSwitch には少なくとも 20 個の利用可能な IP アドレスが必要です。

• vSwitch が存在するゾーンは NLB の作成をサポートしている必要があります。

解決策：

• vSwitch の数を確認します：単一ゾーンリージョン (南京、福州、武漢-ローカル、東南アジア 6、東南アジア 7、北東 2、中東 1 など) の場合は、少なくとも 1 つの vSwitch を選択してください。その他のリージョンでは、少なくとも 2 つの異なるゾーンから vSwitch を選択してください。

• vSwitch が選択した VPC に属しており、利用可能状態であることを確認します。

• vSwitch に少なくとも 20 個の利用可能な IP アドレスがあることを確認します。

• vSwitch が存在するゾーンが NLB の作成をサポートしていることを確認します。

PrivateLink エンドポイント作成時のエラー：SecurityGroup パラメーター

原因：

選択したセキュリティグループが、次の条件の 1 つ以上を満たしていません：

• セキュリティグループには、宛先ポート 5672 および 5671 での TCP トラフィックを許可するインバウンドルールが含まれている必要があります。

• マネージドセキュリティグループはサポートされていません。

• セキュリティグループは選択した VPC に属している必要があります。

• セキュリティグループの数がアカウントのクォータを超えることはできません。

解決策：

• セキュリティグループに、宛先ポート 5672 および 5671 での TCP トラフィックを許可するインバウンドルールがあることを確認します。

• マネージドセキュリティグループを選択していないことを確認します。

• セキュリティグループが選択した VPC に属していることを確認します。

エラー：PrivateLink サービスが有効化されていません

原因：

アカウントで PrivateLink サービスが有効化されていません。

解決策：

PrivateLink サービスを有効化してから、再度 PrivateLink エンドポイントの作成を試みてください。詳細については、「PrivateLink とは」をご参照ください。

クライアント側での IOException または接続エラーの原因

次のことが IOException または 接続エラー の原因となる可能性があります：