Amazon Web Services ブログ

Amazon Simple Queue Service (SQS) – 15 年が経過した今もキューを実行中!

時の流れは早いものです! 私は、2006 年に Amazon Simple Queue Service (SQS) の本稼働の開始についての記事を書きました。その頃は、15 年後にまだブログを書いていること、そして、このサービスが、非常に多くの異なるタイプのウェブスケールアプリケーションのアーキテクチャの基本でありながら、引き続き急速な成長を続けていることは考えてもいませんでした。

SQS の最初のベータ版は、2004 年後半にひっそりと発表されました。そのベータ版以降、当社は多くの機能を追加しましたが、元の説明 (「分散アプリケーションコンポーネント間でメッセージをバッファリングするための信頼性が高くスケーラブルなホストされたキュー」) は今でも当てはまります。お客様は SQS をクラウドにおける無限バッファと考えて、SQS キューを使用してアプリケーションアーキテクチャの機能部分間の接続を実装します。

当社では、長年にわたり、内部に多くの複雑さを抱える SQS インターフェイスをシンプルかつ使いやすく保つために努力してきました。SQS をスケーラブルにし、かつ、高い耐久性と信頼性を実現するために、メッセージは各 AWS リージョンで数千のサーバーで構成されるフリートに保存されます。リージョン内では、各メッセージの 3 つのコピーを保存し、複数のストレージノードとアベイラビリティーゾーンにわたってメッセージを配信します。この組み込みの冗長ストレージに加えて、SQS は、ホストの障害やネットワークの中断に対する自己修復機能および回復力を備えています。SQS がリリースされてから 15 年が経過しましたが、当社は、お客様がミッションクリティカルなワークロードを処理するために SQS を頼りにすることができるように、スケーリングおよび負荷管理アプリケーションを改善し続けています。

SQS は驚異的な規模で動作します。以下に例を示します。

Amazon Product Fulfillment – 2021 年のプライムデーでは、SQSへのトラフィックが記録を塗り替えました (ピーク時に毎秒 47.7 万件のメッセージ)。

Rapid7 – Amazon のお客様である Rapid7 は SQS を広範囲に活用しています。Jeff Myers (プラットフォームソフトウェアアーキテクト) は以下のように述べています。

Amazon SQS は、管理に悩まされることなく、使いやすく、高いパフォーマンスを実現し、とてもスケーラブルなメッセージングサービスを提供します。これは、1 日あたり数十億ものメッセージを処理できるようにスケールすることを可能にしてきた当社のアーキテクチャの重要なコンポーネントです。

Amazon SQS のホームページでは、NASA、BMW Group、Capital One、その他の AWS のお客様の大規模なユースケースについての記事をお読みいただけます。

サーバーレスオフィスアワー
本日 (6 月 13 日) の Twitch.tv のサーバーレスオフィスアワー (正午 (PT)) にぜひご参加ください。お楽しみがあるという噂があります!

これまでの軌跡
ここでは、主要な SQS のマイルストーンのいくつかを簡単にまとめました。

2006 年 – 本稼働を開始。アカウントあたりのキュー数およびキューごとの項目数は無制限で、各項目の長さは最大 8 KB。送信したメッセージと転送されたデータに基づく従量制課金。

2007 年 – 可視性タイムアウトやキューに入れられたメッセージの概数へのアクセスの制御を含む追加機能。

2009 年 – 欧州における SQS、ならびに AddPermission と RemovePermission によるキューアクセスの追加制御。このリリースは、当時「アクセスポリシー言語」と呼ばれたものの初期の姿で、現在は IAM ポリシーへと進化しています。

2010 年 – 新しい無料利用枠 (10 万リクエスト/月 (当時)、その後に 100 万リクエスト/月に拡大)、設定可能な最大メッセージ長 (64 KB まで)、および設定可能なメッセージ保持時間。

2011 年 – 各 SQS キューのための追加の CloudWatch メトリクス。その年の後半には、バッチ操作 (SendMessageBatch と DeleteMessageBatch)、遅延キュー、およびメッセージタイマーを追加しました。

2012 年 – ロングポーリングのサポート、およびリクエストのバッチ処理とクライアント側のバッファリングの SDK サポート。

2013 年 – さらに大きなペイロード (256 KB) をサポートし、50% の料金引き下げを実現しました。

2014 年 – タイムアウトまたはコード内の処理エラーを原因としてスタックされたメッセージを受け入れるためのデッドレターキューのサポート。

2015 年 – 拡張クライアントライブラリを使用した拡張ペイロード (最大 2 GB) のサポート。

2016 年 – 1 回の処理と重複排除を備えた FIFO キューのサポート、およびさらなる料金の引き下げ。

2017 年 – メッセージのサーバー側の暗号化とコスト配分タグをサポート。

2018 年 – AWS PrivateLink を使用した Amazon VPC エンドポイントのサポート、および Lambda 関数を呼び出す機能。

2019 年 – 作成時のタグ付けおよび X-Ray トレーシングのサポート。

2020 年 – 詳細なキューモニタリングのための 1 分間のメトリクス、新しいコンソールエクスペリエンス、および ListQueues と ListDeadLetterSourceQueues 関数用の結果のページ割り。

2021 年 – 使用量の増加に合わせてコストを節約できる階層型料金設定と FIFO キュー向けの高スループットモード。

今日、SQS は、引き続きシンプルかつスケーラブルで、費用対効果が高く、高い信頼性を誇ります。

AWS ヒーローからのコメント
当社では、SQS の成功について振り返り、その成功事例をいくつか共有してもらえるよう、一部の AWS ヒーローに依頼しました。以下に当社が学んだことをご紹介します。

Eric Hammond 氏 (サーバーレスヒーロー) は、AWS Lambda デッドレターキューを使用します。問題を調査する必要があるときは、キューにアラームを配置し、内部メールをアラートとして送信します。

Tom McLaughlin 氏 (サーバーレスヒーロー) は、2015 年から SQS を使用しています。彼は次のように述べています。「私のお気に入りのユースケースは、誰かがキューの使用を希望していて、私がキューイングプラットフォームを管理したくないときです。これは日常的な状況です」

Ken Collins 氏 (サーバーレスヒーロー) は、SQS をどの程度の期間利用しているのかを完全に把握しておらず、2 年から 8 年という範囲を提示しました! 彼は、SQS および Lambda に ActiveJob を実装する Lambdakiq ジェムをパワーアップしています。

Kyuhyun Byun 氏 (サーバーレスヒーロー) は、大量のトラフィックを維持しなければならないプッシュシステムを支えるために SQS を使用しており、「SQS のおかげで、キューイングシステムを構築することを検討しなくてもよくなりました」と述べています。

Prashanth HN 氏 (サーバーレスヒーロー) は、2017 年から SQS を使用しており、自分自身を「パーティーに遅れた人」であると考えています。 彼は SQS を最初のサーバーレスアプリケーションの一部として使用し、異なるスループットのサービスをつなぐのに理想的であることを見出しました。

Ben Kehoe 氏 (サーバーレスヒーロー) は、「SQS のパワーを最初に目の当たりにしたのは、インスタンスがシャットダウンされようとしているときに SQS に状態を保存し、起動時の状態について新しいインスタンスにキューを確認させることで、EC2 スポットインスタンスのフリートで状態を保持する方法を同僚が教えてくれたときでした」と述べています。

Jeremy Daly 氏 (サーバーレスヒーロー) は、ユーザーが提供する画像に対して顔認識プロセスを実行する軽量のキューとして 2010 年に SQS の使用を開始しました。今日、彼は頻繁にこれをバッファとして使用して、まだサーバーレスではないダウンストリームサービスへのリクエストをスロットリングしています。

Casey Lee 氏 (コンテナヒーロー) も、疎結合 Java サービス間において ActiveMQ の代わりとして 2010 年に SQS の使用を開始しました。Casey は、キューの深さに基づいて Auto Scaling を実装しています。Casey は、これがロードを処理する正確な方法であることを見出しました。

Vlad Ionecsu 氏 (コンテナヒーロー) は、2014 年に SQS を使用して AWS ジャーニーを始めました。Vlad は API がとても理解しやすいことを知り、SQS を使用して論文プロジェクトを進めました。

Sheen Brisals 氏 (サーバーレスヒーロー) は、Lambda と S3 も使用する概念実証を構築しながら、2018 年に SQS の使用を開始しました。Sheen は、メッセージ処理機能に適したものとするために各キューの特性を調整できる機能を高く評価しており、優先度の高いキューと優先度の低いキューの両方を利用します。

Gojko Adzic 氏 (サーバーレスヒーロー) は、2013 年に MindMup でエクスポーターのためのタスクディスパッチとして SQS の使用を開始しました。このオンラインマインドマッピングアプリケーションでは、大規模なユーザーグループが共同作業を行うことを可能にするもので、各ドキュメントへの更新の順序を厳格に要求します。Gojko は FIFO キューを使用して、各ドキュメント内で順番に、異なるドキュメントのメッセージを並列処理できるようにしました。

Sebastian Müller 氏 (サーバーレスヒーロー) は、ウェブサイトビルダーの jimdo.com の通知センターを構築し、2016 年に SQS の使用を開始しました。センターは、お客様がイベント (注文、サポートメッセージ、連絡先リクエスト) を適時に認識できるようにします。

Luca Bianchi 氏 (サーバーレスヒーロー) は、2012 年に SQS を初めて使用しました。彼は AWS Elastic Beanstalk で実行されているマイクロサービスのペアを疎結合化し、ゲーミフィケーションプラットフォーム用のファンアウト処理システムも作成しました。今日、彼のお気に入りの SQS ユースケースでは、推論ジョブを格納し、Amazon SageMaker で実行されているワーカープロセスで使用できるようにしています。

Peter Hanssens 氏 (サーバーレスヒーロー) は、SQS を使用して、すぐに処理する必要のないタスクをオフロードします。数年前、一部のデータサイエンティストをサポートしながら、彼は Lambda 関数を使用して 5 分ごとにキューをチェックし、EC2 インスタンスを起動してモデルを構築しながら、実行中のインスタンスの最大数に対する厳密な制御を維持するイベント駆動型バッチ処理システムを作成しました。

Serkan Ozal 氏 (サーバーレスヒーロー) は、2013 年頃から SQS を使用しています。彼は非同期メッセージ処理に注力しており、SQS が膨大な数のイベントを処理する能力を頼りにしています。また、メッセージの表示機能を使用して、必要に応じてメッセージを再処理できるようにします。

Matthieu Napoli 氏 (サーバーレスヒーロー) は、EC2 から始まり、他のキューの代わりとして約 5 年間 SQS を使用しています。彼が言うように、「Lambda と組み合わせることで、あまり考えることなく、すぐに大規模な並列性が得られます。さらに、組み込みの障害処理により、非常に堅牢になります」

ご覧のとおり、SQS には多数のユースケースがあります。

SQS に関するリソース
SQS をまだ使用していない場合は、キューに並んで使用を開始しましょう。お客様の活用方法を見つけるのに役立つリソースをいくつかご紹介します。

よいキューを!

— Jeff;