Category: Messaging

10 月 28 日に、「SaaS+サーバーレス/EventBridge」で開発迅速化、運用作業削減 〜ビジネスにアジリティーをもたらす「SaaS + サーバーレス」〜 と題したセミナーを開催し、6社の SaaS パートナー様にご登壇いただきました。登壇いただいたパートナー様の SaaS アプリケーションはすべて　Amazon EventBridge に対応いただいています。 EventBridge は、サービスとサービスの間をつなぐためのバスとして機能し、様々なアプリケーションや AWS サービスと連携できます。EventBridge に対応いただいているSaaS アプリケーションは、簡単かつセキュアに、イベントソースとして AWS のサーバーレスサービス群と連携させることができます。 本セミナーでは、各社の SaaS のご紹介とともに、EventBridge に対応することで SaaS パートナーとして何が良いのか、SaaS を利用されるお客様にとってどんなメリットがあるのか、といったポイントでご説明いただきました。アンケート結果でも、SaaS との連携手法として EventBridge という選択肢があることを知る機会になった、とか、なかなか聞けないパートナー様目線での EventBridge の効能がわかってよかったなどのご意見がありました。 本記事では、改めて、ご登壇いただいたパートナー様のセッション動画および公開資料をご紹介します。EventBridge ってなんぞや? という方は、AWS セッションとしてご説明した「サーバーレスを取り巻く状況と EventBridge の概要」や Game Server Services 丹羽様のセッション資料/動画を先にご覧いただくことをお勧めします。その上で、各 SaaS パートナー様のセッション内容をご覧いただくと、SaaS + EventBridge で何ができるのかをご理解いただけるかと思います。また、次の BlackBelt 資料も参考になるでしょう。 EventBridge に関連した Black Belt […]

　先の見通せない不確実な時代であっても、選挙や政治に携わる関係者は、セキュアで拡張性があり、費用対効果の高い方法で──すなわちクラウドを活用し── 有権者にダイナミックに進化し続けるサービスを提供することに尽力しています。　AWSと AWS パートナーネットワーク (APN) の提供するクラウドベースのテクノロジーは、選挙管理を行う行政機関、選挙献金を扱う団体、そして投票へのエンゲージメントを高める活動を行うNPOのそれぞれが、１）選挙関連の情報共有や、２）アプリやサービス、インフラのセキュリティ向上、３）スケーラビリティの確保、４）不在者投票に特化したワークフロー管理のソリューション────に容易にアクセスできるよう、支援しています。 有権者教育と、必要な情報へのアクセス 選挙管理を行う行政機関は、直観的なオムニチャネルによる認知度向上とアウトリーチの取り組みにより、投票日・投票場所・投票方法の変更など、投票者に常に最新情報を迅速に伝達する必要があります。 AWS とそのパートナーは、こうしたミッションを担う組織・機関を支援しています。 例えば、以下の手法で、有権者が容易にアクセス可能な最新の選挙情報を提供いたします。 Alexa 対応のデバイスやスキル (Alexa アプリを搭載したスマートフォンなど) による、州や郡レベルの選挙情報へのアクセス：　ニューハンプシャー州が Alexa スキルを どのように展開して、今年100 周年を迎え、当時は米国”初”であった大統領”予備選挙”と 11 月に行われる本選挙に備えているかをご覧くさい。同様に、ウェストバージニア州務長官が独自の Alexa スキルを活用して、「有権者教育」と必要情報へのアクセシビリティを劇的にモダナイズした方法についても、ご確認ください。 質問に回答してくれる「チャットボット」：投票者は自然言語による質問をしたり、関連性の高い回答を迅速に得ることができます。たとえば、有権者は「投票の登録をするにはどうすればいいですか?」、「どうすれば世論調査作業員になれますか?」、「不在者投票はできますか?」、「選挙の結果はどうなっていますか?」などの質問をすることができます。 Amazon Pinpointを使用して、マルチ・チャネル通信により不在者投票・国外投票者向けのメッセージを自動化して配信します。E メール・SMS テキストメッセージ・ボイスメッセージなどの多様な配信チャネルを活用します。最新のメッセージを迅速に送信し、強力なアナリティクス機能を使用して、有権者へのアウトリーチ・キャンペーンを監視および改善し続けることができます。 Amazon Connect を使用して瞬時にスケーラブルなクラウドベースの「コールセンター」を構築し、通話での情報収集を希望する有権者とのコミュニケーションを合理化することで、リソースの所有コストを低減した上でもなお、優れたサービスを実現することができます。 “セキュリティ”と”拡張性”の、高度な両立 連邦選挙委員会などの選挙を所掌する行政機関は、オンラインでの有権者登録、オンラインでの”不在者投票”のリクエスト、開票日当日の速報レポートの作成、選挙に関する情報を集約したe-bookの発行など、機密性の高いワークロードに対する予測不可能な”脅威”や”負荷要求”に絶えず対処していく必要があります。こうしたワークロードを、ロードアイランド州政府・州務省は AWS パートナーである KNOWiNK社を介して管理・運用しています。同様に、インディアナ州政府の州長官オフィスも AWS パートナーである FireEye社と協力し、2020年～2022 年の各種選挙を対象として40カ月間の契約を結び、インディアナ州が選挙に関わる技術インフラを潜在的な脅威から保護できるように支援しています。 AWS および APN パートナーは、以下のように多様な手法を用いて、選挙を所管する行政組織を支援しています。 AWS Well Architected フレームワークを使用して、アプリケーションやインフラストラクチャのセキュリティ・信頼性・スケーラビリティを評価および改善することで、リスクが発生する”前”に脅威を軽減または低減することができます。 AWS Control Tower、および Amazon Guard Duty […]

皆さん、こんにちは。アマゾン ウェブ サービス ジャパン、 シニアアドボケイトの亀田です。 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 秒あたり最大 […]