ApsaraMQ for RocketMQ は、分散システムに対して、非同期通信、トランザクションの一貫性、順序指定配信、トラフィックバッファリング、リアルタイムデータ同期を提供します。
たとえば、ある eコマース企業が、登録、注文、在庫、物流などのビジネス側面をカバーしているとします。この企業は、タイムセール、周年記念イベント、定期的な特別オファーなどのプロモーションイベント中に、ビジネスのピークに対応する必要があります。これらの活動は、分散マイクロサービスアーキテクチャに大きな課題をもたらします。
以下のシナリオでは、ApsaraMQ for RocketMQ が一般的なアーキテクチャの課題をどのように解決するかを示します。各シナリオでは、eコマースプラットフォームを実行例として使用します。
| シナリオ | 解決する課題 |
|---|---|
| 非同期デカップリング | セカンダリタスクをオフロードしてレスポンスレイテンシーを削減 |
| 分散トランザクションの一貫性 | 独立したサービス間でデータの一貫性を維持 |
| 順序指定メッセージ配信 | エンティティごとにメッセージを厳密な FIFO 順で処理 |
| ピーク負荷シフト | ダウンストリームサービスに過負荷をかけることなくトラフィックスパイクを吸収 |
| 大規模キャッシュ同期 | クラスター内のすべてのサーバーにリアルタイム更新をブロードキャスト |
非同期デカップリング
ユーザーが eコマースプラットフォームに登録すると、システムはメールと SMS の両方で確認通知を送信します。登録サービス、メールサービス、SMS サービスは独立したコンポーネントです。これらの連携方法によって、ユーザーの待機時間が決まります。
メッセージキューを使用しない場合
直列処理では、各ステップが順次連鎖します。各ステップに 50 ms かかると、ユーザーは成功応答が表示されるまで 150 ms 待つことになります。
ユーザーが登録認証情報を送信し、登録サービスがアカウントデータを書き込みます。
登録サービスがメールサービスを呼び出し、確認メールを送信します。
メールサービスが SMS サービスを呼び出し、確認メッセージを送信します。
3 つのステップすべてが完了した後、ユーザーは成功応答を受け取ります。
並列処理では、メールと SMS の通知を同時に送信するため、合計待機時間は 100 ms に短縮されます。
ユーザーが登録認証情報を送信し、登録サービスがアカウントデータを書き込みます。
登録サービスがメールサービスと SMS サービスを同時に呼び出します。
両方の通知が送信された後、ユーザーは成功応答を受け取ります。
どちらのアプローチも、登録サービスを通知サービスに密結合させます。いずれかの通知サービスが遅くなったり、利用できなくなったりすると、登録が遅延または失敗します。
ApsaraMQ for RocketMQ を使用する場合
登録サービスと通知サービスの間に ApsaraMQ for RocketMQ を配置します。登録サービスは単一のメッセージをパブリッシュしてすぐに復帰するため、ユーザーの待機時間は約 55 ms に短縮されます。
ユーザーが登録認証情報を送信し、登録サービスがアカウントデータを書き込みます。
登録サービスは、登録成功メッセージを ApsaraMQ for RocketMQ にパブリッシュし、すぐに成功応答を返します。
メールサービスと SMS サービスはそれぞれ登録トピックをサブスクライブし、非同期で通知を送信します。
登録サービスは、ダウンストリームの通知サービスの可用性やパフォーマンスに依存しなくなります。メッセージフォーマットが同じである限り、プロデューサーとコンシューマーは独立して進化できます。
非同期デカップリングは、即時応答を必要としないあらゆる操作に適しています。
分散トランザクションの一貫性
上記の登録例では、登録サービスとメールサービスは別々のシステムです。これらのデータは一貫性を保つ必要があります。つまり、登録が成功した場合はメールがトリガーされ、登録が失敗した場合はトリガーされてはなりません。
通常メッセージの問題点
標準 (非トランザクション) メッセージでは、登録サービスはまずデータを書き込み、次に成功メッセージをパブリッシュします。パブリッシュに失敗すると、メールサービスはメッセージを受信できず、2 つのシステムの同期が失われます。
登録サービスが登録を処理します。
登録サービスが成功メッセージを ApsaraMQ for RocketMQ にパブリッシュします。
パブリッシュが成功した場合、メールサービスはメッセージを受信します (ステップ 3)。
パブリッシュが失敗した場合、メールサービスは登録について知ることができません。登録データとメールデータは不整合になります。
メールサービスが成功メッセージを受信します。
メールサービスが確認メールを送信します。
トランザクションメッセージによる解決
ApsaraMQ for RocketMQ のトランザクションメッセージは、2フェーズプロトコルを使用します。まずハーフメッセージが送信され、ローカルトランザクションの結果に基づいてコミットまたはロールバックされます。
登録サービスがハーフメッセージを ApsaraMQ for RocketMQ に送信します。
ハーフメッセージの送信に成功した場合、ステップ 2 に進みます。
失敗した場合、登録は続行されません。両方のシステムは一貫性を保ちます。
登録サービスがローカルの登録トランザクションを実行します。
登録が成功した場合、ステップ 3a に進みます。
登録が失敗した場合、ステップ 3b に進みます。
登録サービスがトランザクションの結果を報告します。
3a. コミット： ApsaraMQ for RocketMQ はメッセージをダウンストリームのコンシューマーに配信します。ステップ 4 に進みます。
3b. ロールバック： ApsaraMQ for RocketMQ はハーフメッセージを破棄します。通知は送信されません。両方のシステムは一貫性を保ちます。
メールサービスが登録成功メッセージを受信します。
メールサービスが確認メールを送信します。これで両方のシステムは一貫性が保たれます。
すべての決定ポイントで、両方のサービスにまたがるデータは同期を保ちます。実装の詳細については、「トランザクションメッセージ」をご参照ください。
順序指定メッセージ配信
一部の操作は、特定のシーケンスで処理する必要があります。ユーザーの登録レコードが作成、更新、削除された場合、これらのイベントはまさにその順序でコンシューマーに到達する必要があります。順序が狂った処理は、古いデータや不整合なデータを残す可能性があります。
ApsaraMQ for RocketMQ は、パーティション順序付きメッセージをサポートしています。トピック内のメッセージはシャーディングキーによってパーティション分割され、同じシャーディングキーを共有するすべてのメッセージは、そのパーティション内で厳密な FIFO (First-In, First-Out) 順で配信および消費されます。これにより、各メッセージが 1 つのプロセスによって消費されることが保証されます。
ユーザー登録への適用： ユーザー ID をシャーディングキーとして設定します。同じユーザーに対するすべてのイベント (作成、更新、削除) は同じパーティションに入り、パブリッシュされた順序で処理されます。
FIFO 順序は単一のパーティション内でのみ保証されます。異なるパーティション間のメッセージには順序の保証はありません。
実装の詳細については、「順序付きメッセージ」をご参照ください。
ピーク負荷シフト
タイムセールや共同購入イベント中、多数のユーザーリクエストによりトラフィックが急増します。ダウンストリームの通知サービスは、この突然の急増に対応できず、メッセージのドロップやサービス停止につながる可能性があります。
ApsaraMQ for RocketMQ は、高スループットのアプリケーション層と容量制限のあるダウンストリームサービスとの間でメッセージをバッファリングします。
ユーザーが大量の購入リクエストをタイムセール処理システムに送信します。
タイムセールシステムは、ビジネスルールに基づいてリクエストを検証し、条件を満たす注文を ApsaraMQ for RocketMQ にパブリッシュします。
通知システムは、持続可能なレートでメッセージを消費し、購入成功通知を送信します。
ユーザーが確認通知を受け取ります。
キューがトラフィックのバーストを吸収し、通知システムが自身のペースでメッセージを処理できるようにします。
大規模キャッシュ同期
「独身の日 (Double 11)」のような大規模なショッピングイベント中、各会場には価格が頻繁に変動する多種多様な商品があります。従来のリクエストごとのキャッシュルックアップは、キャッシュサーバーに過負荷をかけます。ネットワークインターフェースコントローラー (NIC) が飽和状態になり、ページの読み込み時間が増加します。
ApsaraMQ for RocketMQ は、ブロードキャスト消費でこの問題に対処します。デフォルトのクラスター消費では、各メッセージはコンシューマークラスター内の 1 つのコンシューマーにのみ配信されます。ブロードキャスト消費モードでは、クラスター内のすべてのコンシューマーがすべてのメッセージを受信します。
価格同期への適用： 価格が変更されると、単一のメッセージが ApsaraMQ for RocketMQ にパブリッシュされます。コンシューマークラスター内のすべてのアプリケーションサーバーが更新情報を受信し、ローカルキャッシュをリフレッシュします。これにより、繰り返しのキャッシュクエリが不要になり、すべてのサーバーが同期状態に保たれます。
消費モードの詳細については、「クラスター消費とブロードキャスト消費」をご参照ください。