Category: Messaging

みなさん、こんにちは。アマゾン ウェブ サービス、プロダクトマーケティング エバンジェリストの亀田です。 非常に多くのユーザーさんからご要望をいただいていた Amazon SQS のFIFO (First In First Out)機能が東京リージョンでご利用いただける用になりましたのでお知らせいたします。 Amazon SQSの特徴 Amazon SQSは完全マネージド型のメッセージキューイングサービスで、マイクロサービス、分散システム、およびサーバーレスアプリケーションの切り離しとスケーリングを可能とします。 AWS上でのアプリケーション設計において、非常に重要な役割を果たすサービスである一方、そのコンセプトなどが従来の一般的なWEBサービス（以下のような構成です）の設計に頻繁に用いられるものではないことから、使い方のイメージが湧きづらく敬遠されるケースもあります。 非常に良いサービスであり、コストの適正化とシステムの耐障害性を実現することができる可能性のあるサービスですので、少しその特徴を説明します。 コストの適正化： 上記のアーキテクチャを取る場合、ユーザーからのリクエスト数が増えれば増えるほど、WEB、DBともに求められるスペックは比例して向上していきます。これは、すべてのリクエストに対して同期処理、リアルタイムでレスポンスを出力しようとするためです。WEBサービスにおいては、すべてのリクエストが必ずしも同期処理、リアルタイムでのレスポンス出力が必要ないケースがあります。 ＥＣサイトにおけるユーザーからの注文等がその一例です。ユーザーからの注文を受け付けた時点で、画面には「注文を受け付けました。ありがとうございました」と表示させ、後ほどメールやアプリへのプッシュ通知で「注文を確定しました」という連絡をユーザーへ行う実装などはよくあります。 この場合、上記のＷＥＢをさらに2階層に分割し、 １階層目：ユーザーからのリクエストを受け付ける。 SQSへリクエストを書き込む ユーザーへリクエスト受付を行った旨をレスポンスで戻す。 2階層目：SQSに記載されているリクエストを処理する SQSからリクエストを読み込む リクエストを処理ユーザに非同期で処理結果を返す。 とすることができます。この場合、ユーザー数、リクエスト数の増加に応じて求められるスペックの向上が必要なのは、1階層目だけであり、2階層目は自身のコンピュートリソースの状況に応じて任意のタイミングで処理を行うことができるため、システムのサイジングを適切に保つことができます。（もちろんSQSへ書き込まれるリクエストが処理待ち状態で滞留すればするほど、ユーザーからは処理確定の遅延にみえてしまいますので、ある程度のリソース増強は必要になっていきます。） 耐障害性の向上： SQSを採用したアーキテクチャは耐障害性の向上も見込むことができます。SQSは完全マネージド型サービスであり、書き込まれたメッセージが失われることはないため、システム障害においても、SQSからデータを取り出すという処理部分から再開させることで、耐障害性が向上します。 SQS FIFOの特徴 従来のAmazon SQSは、書き込まれたメッセージの配信順序はベストエフォート型であり、「少なくとも最低1回の配信」をサポートしておりました。このため、順番の入れ違いや同じメッセージの複数回配信はアプリケーション側で冪等性を確保しておく必要があり、それらが大きい課題となる場合Amazon Kinesis Data Streamsの利用などが検討されるケースもありました。 新しいSQS FIFO キューでは、「メッセージが送信される順序のとおりに 1 回のみ確実に処理」されるようになるため、アプリケーションでの実装におけるこの考慮点が解消されることとなります。 FIFOキュー利用の注意点 SQS FIFOキューは従来のSQS標準キューからの移行をサポートしておらず、新規でキューの作成が必要となります。 デフォルトでは、FIFO キューはバッチ処理により 1 秒あたり最大 3,000 件のメッセージをサポートします。制限の引き上げをリクエストする場合は、サポートリクエストを提出してください。 バッチ処理なしでは、FIFO キューは、1 秒あたり最大 […]

メッセージングは、分散アプリケーションのパーツを繋げ、弾力性を追加し、スケーラビリティの高い実装を可能にするアーキテクチャです。例えば、今年、Amazon Simple Queue Service (SQS) とAmazon Simple Notification Service (SNS)は、全体で400億件、1秒あたり1000万件にもおよぶPrime Dayのお客様の注文を処理しましたが、目に見えた問題は発生しませんでした。 SQSとSNSは、クラウドで生まれたアプリケーションに幅広く利用されてきました。しかしながら大規模なお客様の多くは、既にオープンソースベースあるいは商用ライセンスのメッセージブローカーを利用しています。彼らのアプリケーションはミッションクリティカルであり、そこで使われるメッセージングも重要です。お客様は、メッセージインフラストラクチャのセットアップと継続的なメンテナンスが”苦痛である”と言っており、少なくとも1週間に10時間をこの雑用に費やしているとおっしゃっています。 新しいAmazon MQ 11/28日、3クリックで数分ではじめられるApache Active MQのマネージドメッセージブローカーサービスであるAmazon MQ をローンチします! 御存知の通り、Active MQは高速で機能が豊富な人気のオープンソースメッセージブローカーです。キューとトピックを提供し、耐久性あり/無しのサブスクリプション、プッシュベースとポーリングベースのメッセージングとフィルタリングを提供します。 マネージドサービスとして、Amazon MQではActive MQの管理とメンテナンスが考慮されています。これには、ブローカーのプロビジョニング、パッチ適用、高可用性のための障害の検知とリカバリ、メッセージの耐久性に関する責務が含まれています。 Amazon MQでは、Active MQ consoleと、JMS,NMS,AMQP,STOMP,MQTT,WebSocketを含むメッセージングのための業界標準のAPIやプロトコルに直接アクセスができます。これによって、これらの標準を利用するあらゆるメッセージブローカーからコードの書き換えなしにアプリケーションごとAmzazon MQへ移行できます。 開発やテスト用にシングルインスタンスのAmazon MQ brokerまたは、AZを跨って素早い自動的なフェイルオーバーを提供するActive/Standbyのペアを作成できます。どちらの場合もデータはAZをまたがって配置され、ブローカーインスタンスとメッセージストレージを従量課金でご利用いただけます。 Amazon MQはAWSファミリーの一員であり、サービスAPIの認証と認可に対してAWS Identity and Access Management (IAM)を利用します。Amazon CloudWatchメトリクスを利用して、キューの深さのような注目すべきメトリクスを継続的に監視し、 必要に応じてコンシューマーフリートのAuto Scalingを発動したりすることが可能です。

私の同僚のGeorgie Mathewsは、あなたのモバイルアプリのユーザーエンゲージメントを測定して改善するのに役立つ新しいサービスであるAmazon Pinpointを紹介するため、以下のゲストポストを書きました。