Amazon SQS が誕生 20 周年に: 大規模かつ信頼性の高いメッセージングを支えてきた 20 年間

2006 年 7 月 13 日、Amazon EC2 および Amazon S3 と共にお客様向けに提供される最初の 3 つのサービスのうちの 1 つとして、Amazon Simple Queue Service（Amazon SQS）をリリースしました。分散システムにおいては、緊密な依存関係を作らずに、コンポーネント間でメッセージをやり取りするための信頼性の高い方法が必要であることを私たちは身をもって学んでいました。あるサービスが別のサービスを直接呼び出した際に、そのサービスが遅い場合や利用できない場合、システム全体に障害が広がりました。そこで、メッセージキューを使用してサービスが非同期で通信できるようにすることで、この問題を解決しました。つまり、プロデューサーはメッセージをキューにドロップして次に進み、コンシューマーは準備ができたらそのメッセージを受け取ることができるのです。このアプローチにより、個々のサービス障害がシステムの他の部分に影響するのを防ぎました。

2006 年 7 月に Amazon SQS の一般提供が開始されると、このパターンは AWS のすべてのお客様にご利用いただけるようになりました。20 年経った今でも、プロデューサーとコンシューマーを分離するというその中核的な機能こそが、お客様が SQS を使用する理由となっています。ただし、その規模やパフォーマンス、および運用管理は、現在では大きく異なっています。

Jeff Barr は、15 周年記念の記事のなかで SQS マイルストーンの最初の 15 年間について取り上げています。2006 年の当初の 8 KB のメッセージ制限から、FIFO キュー、サーバー側の暗号化、Lambda 統合に至るまでの内容です。この 5 年間、私たちは SQS の拡張を続け、より強力なセキュリティのデフォルトを追加し、ますます複雑化するワークロードパターンに対応する新機能を導入してきました。

2021 年から 2026 年までの主なマイルストーン
FIFO キューの高スループットモード（2021）: 2021 年 5 月に FIFO キューの高スループットモードの一般提供を開始しました。これにより、API アクションごとに 1 秒あたり最大 3,000 件のトランザクション（TPS）がサポートされ、以前の制限の 10 倍になりました。その後も 2 年間にわたってこの上限を引き上げ続け、2022 年 10 月には 6,000 TPS に、2023 年 8 月には 9,000 TPS に、2023 年 10 月には 18,000 TPS に達しました。その後、2023 年 11 月までに一部のリージョンにおいて API アクションあたり 70,000 TPS を実現しています。

SSE-SQS によるサーバー側の暗号化（2021）: 2021 年 11 月に、Amazon SQS で管理された暗号化キー（SSE-SQS）によるサーバー側の暗号化を導入しました。これにより、キー管理を必要としない暗号化オプションがお客様に提供されました。2022 年 10 月には、新しく作成されたすべてのキューで SSE-SQS がデフォルトになったため、お客様側で明示的に有効にする必要がなくなりました。

デッドレターキューのリドライブの強化（2021）: お客様がデッドレターキューから消費されていないメッセージを回復する方法を段階的に拡張しました。2021 年 12 月に、SQS コンソールにソースキューへの DLQ リドライブを直接追加しました。2023 年 6 月に、StartMessageMoveTask、CancelMessageMoveTask、ListMessageMoveTasks などの新しい API を通じて、この機能を AWS SDK と CLI に拡張しました。2023 年 11 月に、FIFO キューのリドライブサポートを追加しました。

属性ベースのアクセス制御（ABAC）（2022）: 2022 年 11 月に ABAC を導入しました。これにより、リソースのスケーリングに合わせて静的ポリシーを維持するのではなく、キュータグに基づいてアクセス許可を設定できるようになりました。

JSON プロトコルサポート（2023）: 2023 年 11 月に、AWS SDK に JSON プロトコルのサポートを追加し、5 KB ペイロードのエンドツーエンドのメッセージ処理のレイテンシーを最大 23% 削減し、クライアント側の CPU とメモリの使用量を削減しました。

Amazon EventBridge Pipes コンソールの統合（2023）: SQS コンソールから EventBridge Pipes にキューを直接接続する機能を追加しました。これにより、カスタム統合コードを記述しなくても、メッセージをさまざまな AWS サービスターゲットにルーティングできるようになりました。

Python 用拡張クライアントライブラリ（2024）: これまで Java 用に提供されていた拡張クライアントライブラリを Python 開発者向けに提供しました。これにより、ペイロードを Amazon S3 に保存し、キューを介して参照を渡すことで、最大 2 GB のメッセージを SQS 経由で送信できるようになりました。

FIFO の処理中のメッセージ制限の引き上げ（2024）: FIFO キューの処理中のメッセージ上限を 20,000 メッセージから 120,000 メッセージに引き上げました。これにより、コンシューマーは以前の上限による制約を受けることなく、はるかに多くのメッセージを同時に処理できます。

マルチテナントワークロードのフェアキュー（2025年）: マルチテナントの標準キューにおけるノイジーネイバーの問題を軽減するために、フェアキューを導入しました。メッセージの送信時にメッセージグループ ID を含めることで、お客様は 1 つのテナントによって他のテナントへのメッセージ配信が遅延するのを防ぐことができます。コンシューマー側での変更は必要ありません。

最大メッセージペイロードサイズが 1 MiB に（2025）: 標準キューと FIFO キューの両方において、メッセージペイロードの最大サイズを 256 KiB から 1 MiB に増やしました。これにより、お客様は外部ストレージにデータをオフロードせずにより大きなメッセージを送信できます。これと並行して、SQS 用の AWS Lambda イベントソースマッピングが更新され、新しいペイロードサイズがサポートされるようになりました。

この変更において不変のもの
20 年にわたって機能が追加されてきたにもかかわらず、SQS の基本的なユースケースは変わっていません。お客様は SQS を使用して、サービスを分離し、大量のトラフィックをバッファリングし、個々のコンポーネントに障害が発生した場合でも回復力を維持するシステムを構築できます。現在では、同じパターンが AI ワークロードにも適用されています。お客様は SQS キューを使用して、リクエストを大規模言語モデルにバッファリングしたり、推論スループットを管理したり、独立したサービスとして動作する自律型 AI エージェント間の通信を調整したりできます。このアーキテクチャの実際の例については、「Creating asynchronous AI agents with Amazon Bedrock」を参照してください。

Amazon SQS の詳細については、Amazon SQS の製品ページにアクセスするか、デベロッパーガイドを確認するか、AWS ブログで最新情報を確認してください。

– Esra

原文はこちらです。