Category: Messaging

皆さん、こんにちは。アマゾン ウェブ サービス ジャパン、 シニアアドボケイトの亀田です。 Amazon Pinpointが東京リージョンに対応しましたのでお知らせいたします。 Amazon Pinpoint Amazon Pinpoint は柔軟でスケーラブルな、マーケティングコミュニケーションサービスです。E メール、SMS、プッシュ通知、音声などのチャネルを介してインバウンド、アウトバウンド双方でカスタマーとつながることができます。 従来AWSでは、通知を行うメッセージングサービスとしてAmazon Simple Notification Service (SNS)を提供していました。Amazon Pinpointでは、例えば、キャンペーンの対象となる顧客を細分化し、内容に合わせてメッセージをパーソナライズして配信を行うなど、カスタマーのセグメンテーションを踏まえたコミュニケーションを実現でき、 1 日あたり何十億ものメッセージを送るところまで拡張します。 顧客リストに基づいて対象となる顧客を細分化し、モバイルアプリケーションやウェブアプリケーションのデータからセグメントを作成し、カスタマーを引き込むようメッセージの内容をパーソナライズします。AWSが提供しているパーソナライズなレコメンドを構築可能なAIサービスであるAmazon Personalize との連携を行うことでカスタマー毎の推奨を作成し、通知を行うことを実現できます。 マーケティングのキャンペーンと連動させ、メッセージ配信結果から、閲覧数やクリック数などのキャンペーンデータまで、コミュニケーションの効果を理解できるようメトリクスを活用します。結果に沿って顧客リストをさらに更新し、次のキャンペーンで役に立ちそうなデータを適用し、さまざまな送信先に対するキャンペーンメトリクス等分析結果を確認することができるようになります。 また、購入の確認やワンタイムパスワード、発送通知など、トリガーベースの顧客連絡事項を直接送信する機能に加えて、SMS を使って、カスタマーからメッセージの返信を受信することも可能となり、双方向のコミュニケーションを実現できます。 Available Today Amazon Pinpointは今日から東京リージョンでご利用いただけます。PinpointはE メール、SMS、プッシュ通知、音声でのカスタマーコミュニケーションを実現しますが、今回のリリースでは音声は東京リージョンに対応していませんのでご注意ください。 利用における必要なリソースはこちらをご覧ください。 – シニアアドボケイト 亀田  

みなさん、こんにちは。アマゾン ウェブ サービス ジャパン、アドボケイトの亀田です。 Amazon SESが東京リージョンでご利用いただけるようになりましたので、お知らせいたします。SESは、デジタルマーケティング担当者やアプリケーション開発者がマーケティング、通知、トランザクションに関するEメールを送信できるように設計された、クラウドベースのEメール送信サービスで、2011年1月にリリースされています。 AWSが提供するSMTPインターフェースやAWS SDKを用いて、既存アプリケーションへの統合をサポートし、従量課金型でメールを送信できます。また毎月62,000通のメールを無料で配信することができます。 2015年9月には、メール送信に加えて、メール受信機能がリリースされ、DNSのTXTレコードを設定することでメールを受信しAmazon S3へ保存したりAWS Lambda関数を起動したりすることでお使いの問い合わせ処理を行うアプリケーションとの統合も可能になりました。 さらに2016年3月には、カスタムFROMドメイン設定（SPFやDKIM）に対応し、メール送信時にFROMをAWS所有のamazonses.comドメインではなく、皆さんがお持ちのドメインを設定することが可能となりより使いやすくなっています。 バウンス、苦情、グローバルサプレッションリスト SESを用いてメール配信を行う際には、発生するエラーの種類や迷惑メールとして扱われるケース、そしてメールが届かない原因などについてご理解いただき、エラーに対する処理を適宜行う必要があります。ここでは主なものを纏めます。 バウンス – バウンスにはソフトバウンスとハードバウンスの2種類があります。 ソフトバウンス – 一時的な E メール配信の障害。たとえば、メールボックスがいっぱいである、接続が多すぎる (スロットリングとも呼ばれる)、または接続がタイムアウトになった場合です。Amazon SES は、ソフトバウンスを何回か再試行します。それでも E メールを配信できない場合、Amazon SES は再試行を停止します。 ハードバウンス – 永続的な E メール配信の障害。たとえば、メールボックスが存在しない場合です。Amazon SES は、DNS ルックアップの失敗を除いて、ハードバウンスを再試行しません。ハードバウンスの原因となっている E メールアドレスに対して配信の試行を繰り返さないことを強くお勧めします。 苦情 – 多くの E メールクライアントプログラムには、メッセージをスパムフォルダに移動して E メールプロバイダーに転送するためのボタン ([Mark as Spam (スパムとしてマーク)] など) が用意されています。また、ほとんどの E メールプロバイダーでは、ユーザーが不要な E メールメッセージを転送して E […]

Amazon EventBridge をご存知でしょうか? EventBridge は、独自のアプリケーション、SaaS および AWSのサービスから発行されるイベントをタイムリーにトリガーできるようにするサーバーレスなイベントバス機能として 2019年に発表されました。CloudWatch Events の拡張として作られており、AWSサービスからのシステムイベントも受信できますが、一番の特徴は、サードパーティの SaaS からイベント発行していただけるような仕様になっていることです（こちらもご覧ください）。 上図の左下あたりにある [SaaS Apps] として対応いただいたアプリケーションをご利用いただくと、SaaS 側で発生したイベントを SaaS 利用ユーザー側の AWS アカウント（SaaS アプリケーションとは異なる環境）へ EventBridge を経由してイベント通知することができるようになります。これによって、利用ユーザー環境で AWS Lambda の関数で追加の処理を起動したり、Kinesis/SQS/SNS にメッセージを飛ばしたり、Step Functions のフローを起動するなどの Push 型処理を簡単に実現できるようになります。つまり、SaaS がサーバーレスアプリケーションのトリガーとしてサーバーレス環境と融合することになるのです。 直近で BlackBelt セミナーも実施しましたので、EventBridge というサービス自体を理解したい方はこちらをぜひご覧ください。

この投稿は Otavio Ferreira, Sr Manager, SNS の寄稿によるものです 郵便システムにおいて、デッドレターキューは配信不能な郵便物を取り扱うための施設です。pub/sub メッセージングモデルにおけるデッドレターキュー (DLQ: dead-letter-queue) は、トピックに対して発行されたメッセージがサブスクライブしているエンドポイントに配信できなかった場合に、そのメッセージを送ることができるキューを表します。 Amazon SNS による DLQ サポートによって、アプリケーションはメッセージ配信における各種故障モードに対する、さらなる耐久力と回復力を持つことが可能になりました。 メッセージの配信失敗と再試行を理解する Amazon SNSがサブスクライブされたエンドポイントにアクセス出来ない場合、メッセージの配信は失敗します。このような状況は大きく2つの原因によって引き起こされます: クライアントエラー。ここでクライアント (メッセージ送信者) は SNS となります。 サーバーエラー。ここではサーバーは、例えば Amazon SQS や AWS Lambda のようにサブスクリプションのエンドポイント (メッセージ受信者) をホストするシステムとなります。 クライアントエラー クライアントエラーは、 SNS の保持しているメタデータが最新ではない場合に発生します。クライアントエラーの発生するよくある原因としては、エンドポイントの所有者がエンドポイントを削除した場合が挙げられます。例えば SNS に紐付いたサブスクリプションを削除することなく、SNS トピックにサブスクライブした SQS キューを削除してしまったような場合です。やはりよくある別の例としては、エンドポイントに適用されたポリシーに対して、SNS がメッセージを配信することを阻害するような変更を加えてしまった場合が挙げられます。 これらのエラーは、クライアントがメッセージの配信を試みたにもかかわらず、クライアントの視点からエンドポイントがアクセス不能となっていることが原因で発生するため、クライアントエラーとして取り扱われます。SNS はクライアントエラーの結果として失敗したメッセージの配信を再試行することはありません。 サーバーエラー サーバーエラーは、サブスクライブしているエンドポイントを実行しているサーバーが利用できないか、または SNS からの有効なリクエストを処理できなかったことを表す例外応答を返した場合に発生します。 サーバーエラーが発生した場合、SNSは線形、指数的のいずれかのバックオフ機能に基づいて配信を再試行します。SQS や Lambda 上で実行される AWS […]

先日 (2019/07/17) 開催しました AWS Black Belt Online Seminar「Amazon Simple Queue Service (SQS)」の資料を公開しました。当日、参加者の皆様から頂いた QA の一部についても共有しております。   20190717 AWS Black Belt Online Seminar Amazon Simple Queue Service from Amazon Web Services Japan AWS クラウドサービス活用資料集（すべての過去資料が閲覧できます） Q. AWS LambdaでサポートされたAmazon SQSに対するポーリングはどういう方式になりますか？ A. 以前はLambdaを定期的に起動し、かつ、SQSに対してポーリング処理を実装する必要がありました。2018年6月にリリースされたAWS　Lambdaの新機能により、Amazon　SQSがAWS Lambdaのイベントソースとして加わり、LambdaがSQSにロングポーリングをしてメッセージの到着イベントをもとに関数を起動するようになりました。なお正常終了するとキューからメッセージをLambdaが削除します。 構成方法等はこちらをご覧ください また、SQSと連携する場合のAWS Lambdaのエラー発生時の挙動についてはこちらに記載がありますので併せてご確認ください。 Q. 過去のAWS Black Belt Online Seminarの動画は見れますか？ A. こちらで、YouTubeをご確認いただけます。 Q. 同期処理の場合に利用できるマネージドサービスにはどのようなものがありますか？ A. メッセージングサービスは非同期型になりますが、例えば、HTTP(S)の負荷分散サーバであるELBや、API環境を構築するAmazon API […]

先日 (2019/6/4) 開催しました AWS Black Belt Online Seminar「Amazon Simple Notification Service (SNS)」の資料を公開しました。当日、参加者の皆様から頂いた QA の一部についても共有しております。 20190604 AWS Black Belt Online Seminar Amazon Simple Notification Service (SNS) from Amazon Web Services Japan AWS クラウドサービス活用資料集（すべての過去資料が閲覧できます） Q. SNS と Pinpoint との違いを教えて欲しい。 A. アプリケーション統合の目的でpub-subを実現したい場合はAmazon SNSをご利用ください。 mobile pushの用途で、より顧客エンゲージメントに関するマネージドな機能（分析、セグメントプッシュ、キャンペーン）を利用したい場合はAmazon Pinpointをご利用いただくのがお勧めです。またこれから新規にmobile push機能を利用される場合には、より新しいサービスであるAmazon Pinpointを選択して始めてみるのが、顧客エンゲージメント機能の独自実装が不要なため簡単です。Amazon SNSはデバイストークンを独自にデータベースで管理する必要があり、運用面のアーキテクチャも考えなければならない箇所が多くなります。一方、独自にデバイストークンのライフサイクルを管理したいといった要求がある場合には、Amazon SNSを選択することもできます。 Amazon PinpointはSMSの双方向送信が可能ですが、Amazon SNSは購読解除時以外に逆方向のSMSを受け付けることはできません。 Q. アンスクライブリンクの消し方について、ベストプラクティスはありますか？ A. AWS CLIを使ってサブスクリプション解除されないようにできます。詳細はAWS公式サイトを参照ください。 […]

先日 (2019/5/21) 開催しました AWS Black Belt Online Seminar「Amazon Simple Email Service (SES)」の資料を公開しました。当日、参加者の皆様から頂いた QA の一部についても共有しております。 20190521 AWS Black Belt Online Seminar Amazon Simple Email Service (Amazon SES) from Amazon Web Services Japan AWS クラウドサービス活用資料集（すべての過去資料が閲覧できます） Q. 一般的に、SPF、DKIMやそれらに基づいたDMARC準拠を実施すれば、メールのセキュリティ対策としては十分なのでしょうか。 A. 大事なのは相手先メールサービスも関係しているいうことです。どれがいいのか？これで十分なのか？ ではなく、やれることは全てやっておいた方がより安定する可能性があるということです。 SPF, DKIM, DMARC だけに限りません。 Q. SESのバウンス例はバウンス処理をする為にあの構成を組まないといけないということですか？ A. あくまでバウンス処理の構成例となります。必ずそのような構成にしなければならないわけではありません。お客様がバウンス処理を実装する際のお役に立てればと思います。 Q. SES での受信メールにLambdaをアクションさせています。大量mailを受信したとき、S3への書き込みやLambdaのスロットリングエラーが発生した時は、何のErrorで確認できますか ? また、Error リトライはどうなりますか ? A. CloudWatch […]

みなさん、こんにちは。アマゾン ウェブ サービス、プロダクトマーケティング エバンジェリストの亀田です。 非常に多くのユーザーさんからご要望をいただいていた 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を紹介するため、以下のゲストポストを書きました。