すべてのプロダクト
Search
ドキュメントセンター

ApsaraMQ for RocketMQ:Lite トピックモデル

最終更新日:Jun 22, 2026

このトピックでは、ApsaraMQ for RocketMQ における LiteTopic の定義、モデル関係、内部プロパティ、動作制約、バージョン互換性、および推奨される使用方法について説明します。

前提条件

  • 現在、Lite トピックは非サーバーレスインスタンス (サブスクリプションおよび従量課金) と専用サーバーレスインスタンスでのみサポートされています。

  • lite トピックモデルをサポートするインスタンスを購入するには:

    • 新しいインスタンスを購入する際、購入ページでプロダクト機能タグを追加し、タグキーに version_capability、タグ値に lite-topic を設定します。

    • 既存のインスタンスについては、チケットを送信して、Lite トピックモデルをサポートするバージョンにアップグレードします。チケットを送信する際は、インスタンス ID とリージョンを記載してください。

  • 特定のシナリオ向けの LiteTopic ソリューションに関する無料相談は、チケットを送信してお問い合わせいただけます。

定義

Lite トピックは、ApsaraMQ for RocketMQ におけるメッセージの転送とストレージのためのセカンダリコンテナであり、同じタイプのビジネスロジックの下で異なるサブクラス (異なるセッション、タスク、その他の粒度など) に属するメッセージを識別するために使用されます。

Lite トピックの主な目的は次のとおりです。

  • 排他的な消費を可能にし、第 2 レベルのデータ隔離を定義します。

より細かい粒度でのストレージとサブスクリプションの隔離を実現するために、異なるサブカテゴリのデータを別々の Lite トピックに分割することを推奨します。

  • データ ID と権限を定義します。

トピックベースの ID と権限管理の上に構築された Lite トピックは、ユーザー ID と権限をさらに細かく定義することができます。

モデル関係

ApsaraMQ for RocketMQ のドメインモデルにおいて、Lite トピックのフローと位置付けは次のとおりです。

image.png

  • トピックは、ApsaraMQ for RocketMQ におけるメッセージ転送とストレージの最上位コンテナです。トピックタイプが Lite の場合、その下に Lite トピックを作成でき、トピックと Lite トピックの組み合わせによってメッセージストレージコンテナが一意に識別されます。

  • トピックタイプが Lite の場合、各ストレージコンテナはデフォルトで 1 つのキューを持ちます。

内部プロパティ

Lite トピック名

  • 定義:Lite トピックを識別する名前です。Lite トピック名は、その親トピック内でグローバルに一意です。

  • 値:トピックタイプが Lite で、メッセージに対して setLiteTopic を呼び出すと、Lite トピックが存在しない場合にシステムが自動的に作成します。

  • 制約:詳細については、「パラメーターの制限」をご参照ください。

有効期間 (TTL)

  • 定義:Lite トピックの有効期限です。TTL を超える期間、Lite トピックに新しいメッセージが書き込まれない場合、システムは自動的にそれを削除します。削除とは、Lite トピックに割り当てられたカウントを解放すること (合計カウントから 1 を引く) を意味します。

  • 値:Lite タイプのトピックを作成する際に、expiration パラメーターを設定できます。

  • 制約:詳細については、「パラメーターの制限」をご参照ください。

バージョン互換性

  • サーバーサイドのバージョン:5.0-rmq-20251024-1 以降

  • クライアントサイドのバージョン:RocketMQ gRPC 5.1.0 以降

Lite タイプと標準タイプのトピックの違い

シナリオ

比較項目

Lite トピック

標準タイプのトピック

メッセージストレージ

最上位トピック

同じです。どちらも事前にトピックリソースを作成する必要があります。

第 2 レベルのトピック

1 つのトピックの下に数百万の第 2 レベルの LiteTopic リソースを作成でき、それぞれが新しい機能を持ちます。

第 2 レベルのトピックリソースはありません。

自動ライフサイクル管理

LiteTopic のライフサイクル管理は自動化されています。

  • 自動作成:送信またはサブスクライブ時に LiteTopic が存在しない場合、システムが自動的に作成します。

  • 自動削除:有効期限を設定します。指定された期間、新しいメッセージが送信されない場合、LiteTopic は自動的に削除されます。

なし

注文

各 LiteTopic は厳密に 1 つのキューを持ちます。同じキュー内のメッセージは順序通りに保存されます。

  • LiteTopic ごと

複数のキューが作成されます。パーティション順序付きトピックのみが順序性を保証します。

送受信の最大同時 TPS

各 LiteTopic は 1 つのキューしか持たないため、その TPS は制限されます。

ただし、1 つのトピックの下に数百万の LiteTopic を作成できるため、合計 TPS は LiteTopic の数に比例してスケールします。

トピックの TPS は、キューの数とクラスターノードの数に基づいて水平にスケールします。

メッセージ消費

サブスクリプションの一貫性

同じである必要はありません。

同じグループ内でも、各コンシューマーは異なる LiteTopic のセットをサブスクライブできます。グループレベルの制限は緩和されます。

必須です。

同じグループ内のすべてのコンシューマーは、ターゲットトピックのメッセージを共有するために、同一のサブスクリプションを維持する必要があります。

注文

順序付き消費:1 つの LiteTopic 内のメッセージは、1 つのコンシューマースレッドによってのみ処理されます。

同時消費または順序付き消費のいずれかをサポートします。

動的サブスクリプション

各コンシューマーは、特定の LiteTopic へのサブスクリプションを動的に追加または削除できます。

なし

単一コンシューマーがサブスクライブできる最大 LiteTopic 数

各コンシューマーは数千の LiteTopic をサブスクライブできます。

なし

可観測性

メトリクス

メッセージ蓄積メトリクスが含まれます。

メッセージ処理遅延時間のメトリクスはありません。

メッセージ蓄積メトリクスが含まれます。

メッセージ処理時間メトリクス

メッセージトレース

同じ

Lite トピックの一般的なユースケース

ユースケース 1:マルチエージェントシステムの非同期通信による長時間実行される呼び出しのブロッキング解決

AI シナリオが複雑化するにつれて、単一エージェントシステムは、専門性の欠如、複数ドメインの統合の難しさ、動的な協調的意思決定の実現不可能性といった限界に直面しています。単一エージェントアプリケーションとワークフローは、マルチエージェントアーキテクチャへと移行しています。しかし、AI タスクはしばしば長時間かかるため、同期呼び出しは呼び出し元のスレッドをブロックし、大規模な協調作業のスケーラビリティを制限します。

image.png

上記のように、マルチエージェントワークフローは次のように機能します。スーパーバイザーエージェントがリクエストを 2 つの子エージェントのための 2 つのサブタスクに分割します。各子エージェントは自身の部分を解決し、結果をスーパーバイザーエージェントに返します。スーパーバイザーエージェントはそれらを集約し、最終的な応答を Web クライアントに送信します。RocketMQ を非同期通信に使用する場合:

  1. リクエスト処理フロー:

    1. 各子エージェントのタスクバッファーキューとしてトピック (Request) を作成します。優先度の高いタスクを先に処理するために、優先度トピックを使用します。

    2. スーパーバイザーエージェントは、分割されたタスク詳細を対応するリクエストトピックに送信します。

  2. レスポンス処理フロー:

    1. スーパーバイザーエージェントは Lite タイプのトピック (Response) を作成し、それをサブスクライブします。

    2. 各子エージェントは、タスク結果を Response トピックの下の LiteTopic に送信します。タスク ID を使用して各 LiteTopic に名前を付け、すべてのタスクに専用の LiteTopic を与えます。

    3. スーパーバイザーエージェントは、サブスクリプションを通じてリアルタイムで結果を受け取り、HTTP SSE を使用して Web クライアントにプッシュします。

ユースケース 2:分散セッション状態管理による AI アプリケーションのセッション継続性問題の解決

AI アプリケーションのインタラクションは、長時間実行、マルチターン、セッションごとに高価な計算リソースに大きく依存するという点で独特です。アプリケーションが SSE などの持続的接続に依存している場合、(ゲートウェイの再起動、タイムアウト、またはネットワークの不安定性による) 切断は、現在のセッションコンテキストの喪失と、すでに投資された AI 計算リソースの無駄を引き起こします。

image.png

ユースケース 1 のレスポンスフローと同様に、リアルタイムの結果通知に Lite タイプのトピックを使用します。SessionID を使用して各 LiteTopic に名前を付けます (例:chatbot/{sessionID})。すべてのセッション結果は、このトピック内で順序付きメッセージとして配信されます。再接続後にセッションの継続性を維持するには、次の手順を実行します。

  1. Web クライアントは、アプリケーションサーバーノード 1 との持続的接続を確立し、セッション Session2 を開始します。

  2. アプリケーションサーバーノード 1 は、LiteTopic [chat/SessionID2] をサブスクライブします。

  3. 大規模言語モデル (LLM) タスクスケジューラは、リクエスト内の SessionID に基づいて、結果を LiteTopic [chat/SessionID2] に送信します。

  4. ネットワークの問題により、WebSocket はアプリケーションサーバーノード 2 に再接続します。

  5. アプリケーションサーバーノード 1 は、LiteTopic [chat/SessionID2] のサブスクリプションを解除します。アプリケーションサーバーノード 2 はそれをサブスクライブします。

  6. LiteTopic [chat/SessionID2] は、最後に消費されたオフセットから配信を再開し、継続的なセッション状態とデータを保証します。

サンプルコード

完全な例については、「RocketMQ 5.x gRPC SDK」のサンプルコードをご参照ください。

メッセージの送信

Producer producer = provider.newProducerBuilder()
    .setTopics(topic)
    .setClientConfiguration(clientConfiguration)
    .build();
final Message message = provider.newMessageBuilder()
    .setTopic(topic)
    // キーワードによる正確な検索のためにメッセージキーを設定します。
    .setKeys("messageKey")
    // LiteTopic を設定します。
    .setLiteTopic("lite-topic-1")
    // メッセージ本文
    .setBody("messageBody".getBytes())
    .build();
try {
    final SendReceipt sendReceipt = producer.send(message);
    log.info("Send message successfully, messageId={}", sendReceipt.getMessageId());
} catch (LiteTopicQuotaExceededException e) {
    // LiteTopic のクォータを超えました。クォータを評価し、引き上げてください。
    log.error("Lite topic quota exceeded", e);
} catch (Throwable t) {
    log.error("Failed to send message", t);
}

メッセージの消費

LitePushConsumer クラスを使用します。

// コンシューマーグループ、ターゲットトピック、通信パラメーターで LitePushConsumer を初期化します。
LitePushConsumer litePushConsumer = provider.newLitePushConsumerBuilder()
    .setClientConfiguration(clientConfiguration)
    // コンソールで作成時に ConsumerGroup にバインドされたトピック
    .bindTopic(topicName)
    // コンシューマーグループを設定します。
    .setConsumerGroup(consumerGroup)
    .setMessageListener(messageView -> {
        // メッセージを処理し、消費結果を返します。
        LOGGER.info("Consume message={}", messageView);
        return ConsumeResult.SUCCESS;
    })
    .build();
try {
    // 目的の LiteTopic をサブスクライブします。
    litePushConsumer.subscribeLite("lite-topic-1");
    litePushConsumer.subscribeLite("lite-topic-2");
    litePushConsumer.subscribeLite("lite-topic-3");
} catch (LiteSubscriptionQuotaExceededException e) {
    // LiteTopic のサブスクリプションクォータを超えました。クォータを評価し、引き上げてください。
    log.error("Lite subscription quota exceeded", e);
} catch (Throwable t) {
    log.error("Failed to subscribe lite topic", t);
}
// ビジネス処理後、使用しなくなった LiteTopic は速やかにサブスクリプションを解除します。
litePushConsumer.unsubscribeLite("lite-topic-3");
// 現在サブスクライブしている LiteTopic のセットを取得します。
Set<String> liteTopicSet = litePushConsumer.getLiteTopicSet();

サブスクリプションの動的更新

/**
 * サブスクリプションを動的に追加します。
 * subscribeLite() メソッドはネットワーク呼び出しを行い、クォータを検証するため、
 * 失敗する可能性があります。
 * サブスクリプションが成功したことを確認するために、必ず結果を確認してください。
 * 考えられる失敗シナリオ:
 * 1. ネットワークエラー – 呼び出しをリトライします。
 * 2. クォータ検証の失敗 – LiteSubscriptionQuotaExceededException がスローされます。
 * ご利用のクォータが要件を満たしているか評価し、速やかに
 * unsubscribeLite() を呼び出して、使用していないトピックのリソースを解放してください。
 */
litePushConsumer.subscribeLite("lite-topic-1");
// サブスクリプションを動的に削除します。
litePushConsumer.unsubscribeLite("lite-topic-1");

制限事項

  1. 単一のコンシューマーは最大 2,000 の LiteTopic をサブスクライブできます (チケットで調整可能)。

  2. 各 LiteTopic は最大 200 の消費 TPS をサポートします。

  3. サービスの安定性を確保するため、各インスタンスには作成またはサブスクライブできる LiteTopic の総数に制限が課せられています。具体的なクォータについては、次の表をご参照ください (チケットで調整可能)。

    1. LiteTopic 数

      • 定義:単一インスタンスのライフサイクル中に現在作成され、アクティブになっている LiteTopic の総数。

      • トリガーと影響:この制限に達すると、存在しない LiteTopic (自動作成をトリガーする) へのメッセージ送信試行は送信エラーで失敗します。

    2. LiteTopic サブスクリプション数

      • 定義:インスタンス下のすべてのオンラインコンシューマークライアントと LiteTopic との間のアクティブなサブスクリプション関係の総数。この数は動的に変化します。

      • 影響:この制限に達すると、コンシューマーによる新しい LiteTopic へのサブスクライブ試行は失敗します。

      • 特別ルール:LiteTopic が削除された場合でも、それに対する残りのコンシューマーサブスクリプションは、それらのコンシューマーがサブスクリプションを解除するまで合計にカウントされます。

サーバーレスインスタンス

デプロイメントアーキテクチャ

キャパシティモード

仕様

作成またはサブスクライブ可能な最大 LiteTopic 数

専用

予約済み + 弾性

5000

300,000

10000

600,000

15000

720,000

[20,000, 50,000]

1,000,000

(50,000, 100,000]

1,500,000

(100,000, 200,000]

2,400,000

(200,000, 300,000]

4,700,000

(300,000, 500,000]

6,300,000

(500,000, 1,000,000]

11,600,000

非サーバーレスインスタンス (サブスクリプションおよび従量課金)

Standard Edition

インスタンスタイプ

送受信の基本 TPS 制限 (ops/秒)

作成またはサブスクライブ可能な最大 LiteTopic 数

rmq.s2.2xlarge

2000

150,000

rmq.s2.4xlarge

4000

250,000

rmq.s2.6xlarge

6000

300,000

Professional Edition

インスタンスタイプ

送受信の基本 TPS 制限 (ops/秒)

作成またはサブスクライブ可能な最大 LiteTopic 数

rmq.p2.2xlarge

2000

150,000

rmq.p2.4xlarge

4000

250,000

rmq.p2.6xlarge

6000

300,000

rmq.p2.10xlarge

10000

600,000

rmq.p2.20xlarge

20000

800,000

rmq.p2.30xlarge

30000

1,000,000

rmq.p2.40xlarge

40000

120 万

rmq.p2.50xlarge

50000

140 万

rmq.p2.100xlarge

100000

2,200,000

rmq.p2.120xlarge

120000

270 万

rmq.p2.150xlarge

150000

330 万

rmq.p2.200xlarge

200000

450 万

Platinum Edition

インスタンスタイプ

送受信の基本 TPS 制限 (ops/秒)

作成またはサブスクライブ可能な最大 LiteTopic 数

rmq.u2.10xlarge

10000

600,000

rmq.u2.20xlarge

20000

800,000

rmq.u2.30xlarge

30000

1,000,000

rmq.u2.40xlarge

40000

1,200,000

rmq.u2.50xlarge

50000

1,400,000

rmq.u2.60xlarge

60000

1,600,000

rmq.u2.70xlarge

70000

1,700,000

rmq.u2.80xlarge

80000

1,800,000

rmq.u2.90xlarge

90000

2,000,000

rmq.u2.100xlarge

100000

2,200,000

rmq.u2.120xlarge

120000

2,700,000

rmq.u2.150xlarge

150000

3,300,000

rmq.u2.200xlarge

200000

4,500,000

rmq.u2.250xlarge

250000

5,600,000

rmq.u2.300xlarge

300000

6,300,000

rmq.u2.350xlarge

350000

7,500,000

rmq.u2.400xlarge

400000

9,300,000

rmq.u2.450xlarge

450000

10,400,000

rmq.u2.500xlarge

500000

11,600,000

rmq.u2.550xlarge

550000

12,800,000

rmq.u2.600xlarge

600000

14,000,000

rmq.u2.1000xlarge

1000000

23,200,000