Simple Message Queue (SMQ、旧称 MNS) は、AWS Simple Queue Service (SQS) や AWS Simple Notification Service (SNS) などのサービスからのデータ移行をシームレスにサポートします。本トピックでは、機能、制限事項、SDK の観点から SMQ と Amazon SQS、Amazon SNS の違いを説明し、Amazon SQS または Amazon SNS から SMQ へのデータ移行手順を案内します。
背景情報
SMQ、Amazon SQS、Amazon SNS はいずれも類似したメッセージング機能を提供します。
SMQ は、キュー型メッセージングモデルとトピック型メッセージングモデルの両方を提供します。
Amazon SQS は、キュー型メッセージングモデルを提供します。
Amazon SNS は、トピック型メッセージングモデルを提供します。
これらのサービスは機能が重複しているため、Amazon SQS または Amazon SNS から SMQ への移行は容易です。以下のセクションでは、各サービスの違いを理解し、移行計画を立てるための情報を提供します。
前提条件
移行を開始する前に、以下の準備が完了していることを確認してください。
SMQ が有効化された Alibaba Cloud アカウント。詳細については、「SMQ の有効化と RAM ユーザーによる SMQ へのアクセス許可」をご参照ください。
既存の Amazon SQS キューおよび Amazon SNS トピックのインベントリ（保持期間、可視性タイムアウト、遅延設定、サブスクリプションエンドポイント、リトライポリシーなどの構成を含む）。
AWS 環境および Alibaba Cloud 環境の両方へのアクセス資格情報。
現在のメッセージプロデューサーおよびコンシューマーについての明確な理解（デュアル読み取りおよびデュアル書き込みによる切り替えを計画するため）。
概念のマッピング
以下の表は、Amazon SQS/Amazon SNS と SMQ の主要な概念を対応付けたものです。多くの機能が機能的に同等ですが、第 3 列に記載されている動作の違いに注意してください。
| AWS の概念 | SMQ の対応機能 | 動作の違い |
|---|---|---|
| SQS 標準キュー | SMQ キュー（キュー型メッセージングモデル） | いずれも、アクティブ、非アクティブ、削除済み、期限切れのメッセージ状態をサポートします。SMQ のデフォルトの可視性タイムアウトは 30 秒ですが、Amazon SQS にはデフォルト値が定義されていません。 |
| SQS FIFO キュー | SMQ FIFO キュー（順序保証） | いずれもサポートされています。 |
| SQS デッドレターキュー | SMQ デッドレターキュー | いずれもサポートされています。 |
| SNS トピック | SMQ トピック（トピック型メッセージングモデル） | SMQ のトピック名は大文字と小文字を区別しません（1～120 文字）。Amazon SNS のトピック名は大文字と小文字を区別します（3～64 文字）。 |
| SNS FIFO トピック | SMQ FIFO トピック（順序保証） | いずれもサポートされています。 |
| SNS サブスクリプション（JSON フィルターポリシー） | SMQ サブスクリプション（タグベースフィルタリング） | データフィルタリング方式が異なります：SMQ はタグベースフィルタリングを使用します。Amazon SNS は JSON ポリシーベースフィルタリングを使用します。移行時にフィルタロジックを変換する必要があります。 |
| SNS サブスクリプションエンドポイント（キュー、HTTP、SMS、メール、モバイルプッシュ、Lambda） | SMQ サブスクリプションエンドポイント（キュー、HTTP、テキストメッセージ、メール、モバイルプッシュ、Function Compute） | Amazon SNS は AWS Lambda と統合されますが、SMQ は Function Compute と統合されます。 |
| SNS デッドレターキュー | SMQ デッドレターキュー（トピックモデル） | いずれもサポートされています。 |
機能比較
以下の表は、キュー型メッセージングモデルおよびトピック型メッセージングモデルごとに、SMQ、Amazon SQS、Amazon SNS の機能を比較したものです。
キュー型メッセージングモデル
| 機能 | SMQ | Amazon SQS |
|---|---|---|
| メッセージライフサイクル | サポートされています。メッセージ状態機械には、アクティブ、非アクティブ、削除済み、期限切れの状態があります。 | サポートされています。メッセージ状態機械には、アクティブ、非アクティブ、削除済み、期限切れの状態があります。 |
| メッセージのカスタム保持期間 | サポートされています | サポートされています |
| メッセージ遅延（スケジュール期間） | サポートされています | サポートされています |
| 可視性タイムアウト期間 | サポートされています | サポートされています |
| 最大メッセージ長 | サポートされています | サポートされています |
| デッドレターキュー | サポートされています | サポートされています |
| FIFO キュー（順序保証） | サポートされています | サポートされています |
トピック型メッセージングモデル
| 機能 | SMQ | Amazon SNS |
|---|---|---|
| データフィルタリング | タグによるデータフィルタリング | JSON ポリシーによるデータフィルタリング |
| キューへのサブスクリプション | サポートされています | サポートされています |
| HTTP へのサブスクリプション | サポートされています | サポートされています |
| テキストメッセージへのサブスクリプション | サポートされています | サポートされています |
| メールへのサブスクリプション | サポートされています | サポートされています |
| モバイルプッシュ | サポートされています | サポートされています |
| Function Compute | サポートされています | サポートされています |
| デッドレターキュー | サポートされています | サポートされています |
| FIFO トピック（順序保証） | サポートされています | サポートされています |
制限事項の比較
これらの制限事項を慎重に確認してください。一部の違いが移行計画に影響を与える可能性があります。以下の表は、メッセージングモデルごとに SMQ、Amazon SQS、Amazon SNS の制限事項を比較したものです。
キュー型メッセージングモデルの制限事項
| 制限事項 | SMQ | Amazon SQS |
|---|---|---|
| キュー命名規則 | キュー名は大文字と小文字を区別します。各名は 1～120 文字である必要があります。 | キュー名は大文字と小文字を区別します。各名は 1～80 文字である必要があります。 |
| メッセージ保持期間 | 7 日 | 14 日 |
| ロングポーリング間隔 | 有効値：0～30。デフォルト値：15。単位：秒。 | 有効値：0～20。単位：秒。 |
| 最大メッセージペイロード | 64 KB。最大メッセージペイロードを増やしたい場合は、チケットを送信してください。 | 256 KB |
| 可視性タイムアウト期間 | 有効値：1～43200。デフォルト値：30。単位：秒。 | 有効値：1～43200。単位：秒。デフォルト値は定義されていません。 |
| キュー ID | 各キュー名はリージョン内で一意です。各メッセージ ID はグローバルに一意です。各受信ハンドルの名前はカスタム文字列です。 | 各キュー名はリージョン内で一意です。各メッセージ ID はグローバルに一意です。各受信ハンドルの名前はカスタム文字列です。 |
| メッセージ遅延 | DelaySeconds パラメーターでメッセージ遅延を指定します。有効値：0～604800。単位：秒。 | DelaySeconds パラメーターでメッセージ遅延を指定します。有効値：0～604800。単位：秒。 |
| 蓄積可能な最大メッセージ数 | 制限なし | 制限なし |
| 最大クエリ/秒 (QPS) | ユーザーが使用するキューリソースには制限がありません。キュー型メッセージングおよびトピック型メッセージングの QPS は、各 Alibaba Cloud アカウントおよび各リージョンで最大 20,000 まで制限されます。詳細については、「スロットリングポリシー」をご参照ください。 | 制限なし |
トピック型メッセージングモデルの制限事項
| 制限事項 | SMQ | Amazon SNS |
|---|---|---|
| トピック名 | 各トピック名は 1～120 文字である必要があります。トピック名は大文字と小文字を区別しません。 | 各トピック名は 3～64 文字である必要があります。トピック名は大文字と小文字を区別します。 |
| 最大メッセージ長 | 64 KB | 256 KB |
| リトライポリシー | バックオフモード：システムは 3 回リトライします。連続する 2 回のリトライ間隔は 10 秒～20 秒です。指数関数的減衰モード：システムは 1 日以内に 176 回リトライします。 | バックオフモード：システムは 3 回リトライします。連続する 2 回のリトライ間隔は 20 秒です。指数関数的減衰モード：リトライ回数を変更できます。 |
| 1 つのトピックに対する最大サブスクリプション数 | 100。制限を引き上げたい場合は、チケットを送信できます。 | 12500000 |
| 最大 QPS | ユーザーが使用するキューリソースには制限がありません。キュー型メッセージングおよびトピック型メッセージングの QPS は、各 Alibaba Cloud アカウントおよび各リージョンで最大 20,000 まで制限されます。詳細については、「スロットリングポリシー」をご参照ください。 | トピックあたり 300 QPS または 10 MB/秒。トピックが最初のクエリを受信した時点でカウントが開始されます。 |
主な制限事項の違いと回避策
移行計画を立てる際は、以下の重要な制限事項の違いに特に注意してください。
最大メッセージペイロード (64 KB vs. 256 KB): Amazon SQS および Amazon SNS の 256 KB に対し、SMQ のデフォルトの最大メッセージペイロードは 64 KB です。現在のワークロードが 64 KB を超えるメッセージを送信する場合、チケットを送信して、上限の引き上げをリクエストできます。別の方法として、Amazon SQS Extended Client Library パターンと同様に、Alibaba Cloud OSS に大きなメッセージ本文を保存し、メッセージでオブジェクトリファレンスを渡すこともできます。詳細については、「サイズの大きいメッセージの送信」をご参照ください。
トピックあたりの最大サブスクリプション数（100 対 12,500,000）：SMQ はデフォルトでトピックあたり最大 100 サブスクリプションをサポートしますが、Amazon SNS は 12,500,000 です。トピックに 100 件を超えるサブスクライバーがいる場合、チケットを送信して制限を引き上げることができます。
メッセージ保持期間（7 日対 14 日）：SMQ は最大 7 日間メッセージを保持しますが、Amazon SQS は最大 14 日間保持します。コンシューマーが 7 日以内にメッセージを処理できることを確認するか、それに応じて処理パイプラインを調整してください。
データフィルタリングメカニズム：SMQ はトピックサブスクリプションに対してタグベースのデータフィルタリングを使用しますが、Amazon SNS は JSON ポリシーベースフィルタリングを使用します。サブスクリプションを移行する際には、フィルタロジックを再設計する必要があります。
SDK の比較
以下の表は、SMQ、Amazon SQS、Amazon SNS で利用可能な SDK を比較したものです。
| SDK | Alibaba Cloud SMQ | Amazon SQS | Amazon SNS |
|---|---|---|---|
| API 操作 | API リファレンス | API リファレンス | API リファレンス |
| HTTP SDK | Java 向け SDK、Python 向け SDK、C# 向け SDK、PHP 向け SDK、C++ 向け SDK、Go 向け SDK、JMS 向け SDK | Java 向け SDK、JavaScript 向け SDK、PHP 向け SDK、Python 向け SDK、Ruby 向け SDK、.NET 向け SDK | Java 向け SDK、JavaScript 向け SDK、PHP 向け SDK、Python 向け SDK、Ruby 向け SDK、.NET 向け SDK |
移行プロセス
アプリケーションを Amazon SQS または Amazon SNS から SMQ へスムーズに移行するために、サービス間でキュー、トピック、サブスクリプションメタデータを同期することを推奨します。その後、アプリケーション側でデュアル読み取りおよびデュアル書き込みポリシーを有効にしてデータを移行します。以下の図は、Amazon SQS から SMQ へのデータ移行プロセスを示しています。
移行プロセスは 4 つのステージで構成されています。各ステージについて、目標、実施すべき操作、次のステージに進むための終了基準を説明します。
ステージ 1：既存のワークロードが Amazon SQS 経由でメッセージを生成および消費
目標：ベースラインを確立し、SMQ リソースを準備します。
操作：
AWS 環境内のすべての Amazon SQS キューおよび Amazon SNS トピックをインベントリし、保持期間、可視性タイムアウト、遅延設定、サブスクリプションなどの構成を記録します。
同等の構成を持つ SMQ に該当するキューおよびトピックを作成します。上記で説明した制限事項の違い（メッセージペイロードサイズ、サブスクリプション制限、保持期間）に注意してください。
サブスクリプションメタデータを同期します。適用可能な場合は、Amazon SNS の JSON フィルターポリシーを SMQ のタグベースフィルターに変換します。
移行中にメッセージフローを比較できるように、AWS 環境および SMQ 環境の両方にモニタリングを設定します。
終了基準：SMQ キューおよびトピックが作成・構成済みであり、両環境でモニタリングが設定されています。
ステージ 2：コンシューマーサービスが Amazon SQS および SMQ の両方から同時にメッセージを消費
目標：デュアル読み取りを有効にして、コンシューマーが両方のサービスからメッセージを処理できるようにします。
操作：
コンシューマーアプリケーションを更新して、Amazon SQS および SMQ キューの両方から読み取り（デュアル読み取り）を行います。これにより、プロデューサーが切り替わる前に、コンシューマーが SMQ からのメッセージを処理できるようになります。
SMQ に公開されたメッセージが正しく消費されることを検証します。メッセージフォーマットの互換性、確認応答動作、エラー処理を確認します。
両方の環境でコンシューマーの遅延およびエラー率をモニタリングし、SMQ からの消費が安定していることを確認します。
終了基準：コンシューマーが一定期間エラーなく SMQ からのメッセージを正常に処理しています。
ステージ 3：プロデューサーサービスを SMQ に接続
目標：プロデューサーを SMQ への書き込みに切り替え、コンシューマー側では引き続きデュアル読み取りを維持します。
操作：
プロデューサーアプリケーションを更新して、Amazon SQS の代わりに（または追加で）SMQ にメッセージを公開します。
Amazon SQS および SMQ の両方に同時に書き込む（デュアル書き込み）場合、両方のメッセージフローをモニタリングして、メッセージが SMQ に正しく到着することを確認します。
プロデューサーが完全に SMQ に切り替わったら、デュアル書き込みを停止します。コンシューマーは Amazon SQS に残っているメッセージを排出するために引き続きデュアル読み取りを維持します。
終了基準：すべてのプロデューサーが SMQ に正常にメッセージを公開しています。モニタリングを通じてメッセージ配信が確認されています。
ステージ 4：既存のメッセージが消費された後、プロデューサーサービスを Amazon SQS から切断
目標：Amazon SQS/Amazon SNS リソースを廃止して移行を完了します。
操作：
Amazon SQS キュー内のすべての残りメッセージが消費されるのを待ちます。キューデプスをモニタリングして、ゼロになることを確認します。
メッセージが残っていないことを確認したら、コンシューマーアプリケーションからデュアル読み取りロジックを削除し、SMQ のみから読み取るようにします。
AWS 内の Amazon SQS キューおよび Amazon SNS トピックを廃止します。
ドキュメントおよびランブックを更新して、新しい SMQ ベースのアーキテクチャを反映します。
終了基準：すべての Amazon SQS/Amazon SNS リソースが廃止されています。すべてのプロデューサーおよびコンシューマーが SMQ のみを通じて動作しています。
テストおよび検証
移行前および移行中に、以下のテストを実施してデータ整合性およびアプリケーションの安定性を確保してください。
機能テスト：SMQ を通じてテストメッセージを送信し、コンシューマーが正しく受信および処理することを確認します。メッセージ属性、遅延、可視性タイムアウトが期待通りに動作することを確認します。
フィルター検証：データフィルタリングを使用している場合、SMQ のタグベースフィルターが Amazon SNS の JSON ポリシーフィルターと同じ結果を生成することを検証します。
パフォーマンステスト：Amazon SQS/Amazon SNS 環境と SMQ のメッセージスループットおよびレイテンシを比較します。SMQ の QPS 制限（Alibaba Cloud アカウントおよびリージョンあたり最大 20,000）に注意してください。詳細については、「スロットリングポリシー」をご参照ください。
デッドレターキューテスト：意図的に不正な形式または処理不能なメッセージを送信し、SMQ のデッドレターキューが正しくキャプチャすることを検証します。
リトライ動作テスト：リトライポリシー（バックオフモードおよび指数関数的減衰モード）がアプリケーション要件を満たしていることを検証します。SMQ と Amazon SNS のリトライ間隔および回数の違いに注意してください。
モニタリングおよびアラート：モニタリングツールが SMQ メトリック（メッセージ数、コンシューマー遅延、エラー率）を正しく取得し、アラートが期待通りに発火することを確認します。
ロールバック準備：ステージ 2 およびステージ 3 中は、Amazon SQS/Amazon SNS リソースをアクティブに維持します。SMQ で問題が発生した場合、プロデューサーを Amazon SQS に戻し、コンシューマーをデュアル読み取りまたは Amazon SQS 専用モードに復元して、問題解決まで運用を継続できます。