re:Invent 2024: AWS AppSync Eventsによるリアルタイムイベント処理
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - Real-time event patterns with WebSockets and AWS AppSync (FWM302)
この動画では、AWS AppSync Eventsの機能と活用方法について詳しく解説しています。リアルタイムアプリケーションの構築において、従来のPollingやWebSocketsの実装における課題を指摘し、その解決策としてAWS AppSync Eventsが提供する完全マネージド型のPub/Subサービスの特徴を説明します。PGA TOURの事例を用いて、数百万のユーザーに対して数十億のメッセージを処理する実践的な実装パターンを紹介し、1秒あたり100万イベントの処理能力やP50レイテンシー50ミリ秒以下という具体的な性能指標も示しています。また、Event HandlerやBuilt-in Targets、Amazon Bedrockとの連携など、今後実装予定の新機能についても言及しています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
AWS re:Inventセッション：リアルタイムアプリケーションの課題と解決策
はい、皆さん聞こえていますか？おはようございます。8時30分になりました。私は時間にとても厳格な性格なので、定刻通りに始めたいと思います。re:Inventへようこそ。2024年のre:Inventの最初のセッションとなる、この朝8時30分からのセッションを選んでいただき、ありがとうございます。皆さん、ここまで来られて本当に素晴らしいですね。まだVegas Stripを歩き回って疲れる前の、始まったばかりですから。
今日は、リアルタイムについてお話しします。そして、私たちのセッションはリアルタイムに焦点を当てているので、まずはリアルタイムな聴衆との交流から始めましょう。リアルタイムの要件を持つアプリケーションを所有または運用している方は手を挙げてください。素晴らしいですね。たくさんの手が上がりましたので、皆さん適切な場所にいらっしゃいますね。本題に入る前に、もう一つリアルタイムな聴衆との交流をさせてください。リアルタイムの実装に苦労したことがある方、インフラの管理や運用のオーバーヘッドの複雑さに直面して、それが実装の障害になったことがある方は手を挙げてください。こちらも手が上がっていますね。皆さん適切な場所にいらっしゃいます。もし両方とも手を挙げなかった方は、おそらくアプリケーションへのリアルタイム実装を検討中なのかもしれませんね。
開発者がリアルタイムインフラの構築でこうした課題に直面するのは珍しいことではありません。インフラ自体の管理、認証、認可、メッセージ処理、その他多くのカスタムコードの構築など、考慮すべき要素が多くあります。今日のセッションを通じて、アプリケーションにリアルタイム機能を組み込むためのパターンを学び、なぜAWS AppSyncがそれを構築するための優れたツールなのかを理解していただければと思います。私はAWSのSolutions ArchitectのKim Wendtです。また、AWS AppSyncのSenior Manager of Product ManagementであるBill Fineも後ほど加わる予定です。
本日は以下のような内容をご用意しています。まず、リアルタイムエクスペリエンスのユースケースについてお話しします。リアルタイムについて考えている方々や、アプリケーションへの実装を検討している方々にとって参考になるかもしれません。現在、私たちの顧客がどのようにリアルタイムを構築しているのかについてのアイデアを得ていただけると思います。そして、既存のリアルタイムソリューションに関する一般的な課題についても触れます。既存の制限について説明した後、AWSアプリの世界で比較的新しくローンチされたAWS AppSync Eventsについてお話しします。その後、Billに実際のリアルタイムアーキテクチャパターンと今後の展望について説明してもらいます。また、本日はライブデモもご用意していますので、とても楽しいと思います。QRコードをスキャンできるよう、スマートフォンを準備しておいてください。
リアルタイムユーザーエクスペリエンスの多様なユースケース
リアルタイムがユーザーエクスペリエンスを大きく向上させる例は数多くあります。その広範なユースケースの1つが、購読している多くのクライアントに更新情報をリアルタイムで配信するイベントブロードキャストです。例えば、あなたがSeattle Seahawksの熱烈なファンで、DK Metcalfが試合を左右するタッチダウンを決めたとします。その情報を即座に知りたいですか？それとも数分後でもいいですか？これは実際、リアルタイムイベントに関する課題の一つです。スポーツ会場で周りの人々が歓声を上げ始めるときに遅れを取らないよう、すぐにアップデートを受け取れれば素晴らしいですよね。これは、時間が非常に重要になる重要な領域の一つを示しています。ファンがサイドラインで更新を待つのではなく、リアルタイムで起こっていることの一部として体験できる、素晴らしいファンエクスペリエンスを実現することができるのです。
もう1つの例として、在庫状況の確認が挙げられます。お気に入りのEコマースサイトで高級なInstant Potを見つけて、在庫ありと表示されているので購入しようとします。とても期待に胸を膨らませたのに、1時間後にメールが届いて実は在庫切れだったと知らされます。これは良くないユーザー体験です。Eコマースサイトでショッピング中のユーザーに対して、リアルタイムで最新の在庫状況を提供する必要があるのです。
これらは、多数の接続クライアントへのイベントブロードキャストが、リアルタイムのユーザー体験を向上させる例です。さらに、リアルタイムのコラボレーションユースケースも見られます。これは2つのクライアントが相互にやり取りし、そのコミュニケーションをリアルタイムで実現するものと考えられます。良い例として、マルチターンのゲームプレイが挙げられます。プレイヤー同士が戦略を練り、お互いの動きに反応し合うような場面です。一方のプレイヤーが動いたときに更新が届かないと、全体的な戦略に大きな影響を与え、ユーザー同士のやり取りにおける体験の質が低下してしまいます。
リアルタイム更新は様々なシナリオで重要です。例えば、多くのエージェントがチケットを処理するコールセンターでは、あるエージェントがチケットを担当した際にリアルタイムで更新されないと、別のエージェントが同じチケットの作業を始めてしまい、作業の重複や非効率を招くことになります。これは、クライアントとコールセンターのエージェントの両方にとって良くないユーザー体験を生み出します。この例は、リアルタイム体験に関して、私たちの顧客が採用している実装の一部を示しています。
既存のリアルタイムソリューションの課題とAWS AppSync Eventsの登場
ここで、顧客が自らこれらのソリューションを構築する際に直面する課題について見ていきましょう。 今日の準リアルタイム体験の実装における典型的なパターンは、Pollingです。Pollingパターンをご存じない方のために説明すると、これは基本的にクライアントがサービスに対して「更新はありますか？」と問い合わせる方式です。この方式では、クライアント実装に大きな負担がかかります。クライアントがバックエンドから更新を取得する頻度に制限があるため、レイテンシーが増加する可能性があります。15秒や20秒ごとに更新を確認する場合、更新が発生してから20秒後まで情報を得られない可能性があります。さらに、クライアントがサーバーに更新を問い合わせるたびに、変更がない場合でもその要求に応答するための計算リソースが必要となり、不要なリソース使用につながります。これはスケーラビリティの課題を引き起こします。1つのクライアントがサーバーに更新を問い合わせる程度なら問題ありませんが、何百万人ものSeattle Seahawksの熱心なファンがDK Metcalfの情報更新を問い合わせると、本当の課題となってきます。
独自のWebSocketsを実装するアプローチを取る顧客も見られますが、WebSocketsには固有の複雑さがあります。重要な複雑さの1つは接続管理です。これには、接続クライアントの場所の管理、接続・切断のタイミングの追跡、Connection IDによる一意の識別、そして更新が必要な全ての接続クライアントへのメッセージファンアウトパターンによる更新の送信方法の決定が含まれます。1台のWebSocketサーバーであれば簡単かもしれませんが、多数のWebSocketサーバーにスケールアップすると、接続管理とメッセージファンアウトはますます複雑になっていきます。
これらすべてが、書かなければならないバックエンドコードの増加につながります。私のように書くコードを全て負債と考えるなら、必要なバックエンドコードの行数を減らしたいと思うはずです。多くの場合、カスタムのPub/Sub認可モード、メッセージを処理する異なるコード、フィルタリング変換の実装、そしてロギングやメトリクスといったエンタープライズ向け機能の実装が必要になることを、私たちは顧客の事例でよく目にします。
これらの従来型のリアルタイムアーキテクチャでは、多大な労力と、ビジネスに特化していない非差別化コード（アプリケーション実行に必要だが、ビジネスロジックではないコード）が必要となります。現在、AWSでリアルタイムエクスペリエンスを構築するためのいくつかのオプションがあり、多くの顧客がこれらのパターンを活用しています。 1つ目は、Amazon API Gateway WebSocketsです。これは完全マネージド型のWebSocket APIで、クライアントとサブスクライバー間の双方向WebSocket通信を可能にします。このソリューションでは、接続管理とメッセージのファンアウトは自分で実装する必要があります。特定のConnect routeを通じて接続されたクライアントを追跡し、その情報をデータベースに保存し、更新を受け取る必要のある相手をイテレートしてPost to Connection API呼び出しを通じて送信する、という作業を自分で処理しなければなりません。
また、AWS IoT Coreを使用している顧客も見かけます。AWS IoT CoreはMQTTメッセージングプロトコルを使用し、その通信を可能にするマネージド型ブローカーを提供します。IoT Coreは、MQTTが非常に軽量で、X.509証明書などのセキュリティ機能を提供するため、IoTデバイス通信に特に効果的です。
そして最後に紹介するソリューションは、皆さんの中にも馴染みがあるかもしれないAWS AppSync GraphQLです。AWS AppSync GraphQLは、 アプリケーションで使用できる完全マネージド型のGraphQLおよびWebSocket APIを提供します。AppSync GraphQLでリアルタイムエクスペリエンスを実現する部分は、Subscriptionと呼ばれるもので、これはデータ修正ステップであるGraphQL Mutationの結果として生成されます。このソリューションではスキーマを実際に記述する必要があるためGraphQLの専門知識が必要ですが、完全マネージド型の接続管理、組み込みのメッセージファンアウトとブロードキャストという優れた機能が得られます。
顧客は私たちに異なるソリューションを求めていました。具体的には、これらのリアルタイムエクスペリエンスを構築するための目的特化型のPub/Subソリューションを求めていたのです。私たちはAmazonですから、データを愛しています。これを信じていただけない場合は、 1年前の同様のセッションを振り返ってみましょう。私たちがステージに立ち、BillとRyan（別の発表者の一人）が聴衆にこんな質問をしました：「AppSyncのリアルタイムSubscriptionをさらに良くするには何が必要でしょうか？」圧倒的多数の人々が、GraphQLを必要としないスタンドアロンのイベントAPIと答えました。
AWS AppSync Eventsの機能とデモンストレーション
まさにそれを実現したのが、10月末に発表したAWS AppSync Eventsです。これは大規模なリアルタイム体験を構築するために設計された新しいサービスです。認証機能、クライアント接続管理、メッセージのファンアウトのためのブロードキャスト機能、ポイントツーポイント通信、メッセージ変換機能を備えた、フルマネージド型のPub/Subサービスとなっています。このサービスは、リアルタイム体験の構築と管理における運用上のオーバーヘッドを軽減することを目的として開発しました。アプリケーションのパフォーマンスを重視し、わずか数クリックで始められるシンプルさと、フルマネージドソリューションのメリットを提供します。Serverlessサービスの1つなので、使用した分だけ支払えば良く、アプリケーションの使用量に応じてコスト面でもスケールできます。
では、これはどのように機能するのでしょうか？とてもシンプルです。画面左側 にPublisherがいます - Publisherはアプリケーションクライアントになります。また、Amazon EventBridgeやDynamoDB Streamsを使用したDynamoDBのようなバックエンドのイベント駆動サービスにもなり得ます。これらのPublisherはHTTP POST APIコールを通じて配信を行います。右側にはSubscriberがいます。Subscriberもアプリケーションクライアントになりますし、イベント駆動サービスにもなり得ます。SubscriberはWebSocketを通じてAPIに接続します。中央にあるAWS AppSync Eventsは、接続管理とメッセージファンアウトの機能を備えたWebSocketインフラストラクチャをバックグラウンドで提供します。後ほど、中央部分のNamespace、Pan、Segmentについて詳しく説明します。
ここでデモをお見せしましょう。このスライドに切り替えますので、スマートフォンを取り出してこのQRコードをスキャンしてください。デモ画面に切り替える前に、少し時間を取らせていただきます。 はい、それでは切り替えます。 表示されている絵文字を自由にクリックしてみてください。これはライブデモですので、リアルタイムで見ているのがAWS AppSync Eventsの動作です。たくさんの絵文字が画面に表示されていますね。みなさん、良い絵文字を選んでいますね。
これがライブデモでした。では、これが実際にどのように動作しているのか、詳しく見ていきましょう。上に表示されていた2つのコードブロックについて説明します。左側のコードは、みなさんがアクセスした軽量なReactウェブアプリケーションで使用されているものです。絵文字をクリックすると、内部的にはHTTP POSTを使用したPublish操作によってAppSync Event APIとやり取りしています。構文自体はNamespaceチャンネルを使用しており、下部にあるreinvent emojiがそのNamespaceです。後ほど詳しく説明しますが、基本的には絵文字を含むJSONペイロードを送信しているだけです。
これは私の画面に表示していたアプリケーションで、同じチャンネルNamespace（reinvent/emojiチャンネルNamespace）からの更新をリアルタイムで受信して画面に表示・レンダリングしていました。このコードはAWS Amplify APIクライアントライブラリによって提供されています。PublishにはHTTP POST、SubscriptionにはWebSocketを使用しているだけなので、必ずしもAmplifyを使う必要はありません。お好みのHTTPやWebSocketクライアントライブラリを使用できます。ただし、Amplifyを使えば約20行のコードで実装できますし、コードが少なければ少ないほど、アプリケーションの保守性も高まります。
Bill Fineによるリアルタイムアーキテクチャパターンの解説
私たちのアプリケーションはとてもシンプルです。スマートフォン上にアプリケーションがあり、こちらにデモ画面を表示していますが、実質的に使用しているのはAppSync Eventsというサービスだけです。アプリケーション自体のホスティングには他のサービスも使用していますが、このリアルタイムアプリケーションを動かしているインフラは、AppSync Eventsのみです。これまで少し触れてきたChannel Namespaceですが、これはAppSync Eventsサービスの核となる部分です。これらは、EventsのAPIで利用可能なチャンネルと考えていただければと思います。そして、NamespaceそのものがこれらのチャンネルのCapabilitiesと動作を提供します。
Channel Namespaceは、基本的に、PublisherとSubscriberがAPIとどのように相互作用するかを定義するためのスケーラブルな方法を提供することを目的としています。Namespaceは、特定のチャンネルの設定を一元化するためのものです。チャンネル自体は一時的なものですので、事前に作成する必要があるのはNamespaceだけです。スライドの例を見てみましょう。上部にNamespace Aがありますが、Namespaceは基本的にパスの最初のセグメントでバックスラッシュを含むものです。チャンネルに関して、先頭にスラッシュAがついているものはすべてNamespace Aの一部となり、そしてスラッシュABCスラッシュDEFスラッシュXYZは、すべてその場で作成される個々のチャンネルです。
Publisherがそれらに対して発信するとすぐに作成され、Subscribeすることで特定のチャンネルとやり取りができるようになりますが、一時的なものなので、必要がなくなると消えてしまいます。これにより、アプリケーション内でメッセージをセグメント化する方法に関して大きな力を得ることができます。Namespaceについては、ユーザーが特定のNamespaceとどのように相互作用するかについての設定と動作を保持します。各Namespaceには、そのNamespaceに入ってくるPublishとSubscriptionリクエストに対応するための異なるEvent Handlerを設定できる機能があり、さらにAPIで定義された認証をオーバーライドする機能もあります。
Event Handlerには2種類あります。最初に説明するのはPublisherのパスです。PublisherがAPIにEventを発行すると、このonPublish Handlerによって捕捉することができます。AppSync EventsのHandlerは、AppSync JavaScript RuntimeEnvironmentを使用してJavaScriptで記述されます。ここで想定されるユースケースとしては、Event Enrichment（メッセージが発行された後に追加フィールドを加える）があり、これによってクライアントにすべての情報を含める負担をかけないようにします。その他のユースケースとしては、Event Schema Validation（Publisherが送信するEventの特定の構造を強制する）やEvent Filtering（Schema Validationを満たさないEventや、Subscriberに送信したくない特定のタイプのEventを拒否する）などがあります。
同じことがSubscriberのパスにも当てはまります。SubscriberがAPIへの接続を確立しようとすると、最初にこのonSubscribe Handlerを通ります。ここで考えられるユースケースとしては、きめ細かな認証があります。例えば、ユーザー名を含むチャンネルや、所属するグループを含むチャンネルなど、特定のチャンネルへのSubscribeのみを許可することができます。さらに、これらの認証ルールが満たされない場合にSubscriptionをフィルタリングすることもできます。先ほど述べたように、ここではAppSync JavaScript Runtimeを使用していますので、現在AppSync GraphQLのResolverで使用している環境と同じような環境でEvent Handlerを使用することができます。
Publishでは、1つのメッセージ、または最大5つのメッセージのバッチを送信できます。そのため、下部のPublish Handlerのエクスポート機能では、このバッチの一部として受信したすべてのイベントに対してマッピングを行っています。このエンリッチメントのステップでは、各イベントにいくつかの異なるフィールドを追加しています。具体的には、受信時のタイムスタンプ、現在のイベント、そしてSession IDです。これらは、クライアントがイベントをPublishする際に明示的に提供する必要はありませんが、後で追跡やその他の目的で役立つかもしれない情報です。
右側には、基本的にグループメンバーシップをチェックするSubscribe Handlerがあります。 クライアントが特定のChannelをSubscribeする場合、そのSubscriptionを承認するためには、Subscriberが所属しているグループがそのChannelに含まれている必要があります。これらは単なる例に過ぎませんが、Event Handlerには多くの素晴らしいユースケースがあると思います。皆さんがここでどのようなものを構築されるのか、とても楽しみにしています。
次は認可と認証について見ていきましょう。AWSの他のすべてのサービスと同様に、 セキュリティは最優先事項です。AppSync Event APIには、認可と認証の観点から2つの異なるセキュリティ設定があります。 1つ目はAPI レベルで、これは基本的にAPIのデフォルト設定です。WebSocket接続を確立する際の接続認可モードがあり、これはPublishおよびSubscribe操作をサポートするための認可モードとは独立して設定できます。
APIレベルでは、PublisherとSubscriber向けのデフォルトの認可モードを設定できますが、 これらはNamespaceレベルでオーバーライドすることができます。先ほどのEmoji Throwerの例に戻ると、 /reinventというNamespaceを定義し、そのNamespace特有のPublishとSubscribeモードをオーバーライドすることができます。ユースケースとしては、例えば、ユーザーやクライアントがAPI Keyを使用してSubscribeできる比較的パブリックなNamespaceを持ちながら、OpenID Connectで認証されたユーザーのみがSubscriptionを確立できるよりプライベートなNamespaceを持つといったことが考えられます。
AppSync Event APIは、AWS AppSync GraphQLがサポートしているのと同じ認可モードをサポートしています。 これには、Amazon Cognito User Pools、OpenID Connect、標準でサポートされていない任意のカスタム認証タイプのためのAWS Lambda、API Key、そしてロールベースの認証のためのAWS Identity and Access Managementが含まれます。AppSync GraphQLと同様に、これらのモードを組み合わせたり、APIのデフォルトレベルやNamespace、PublishおよびSubscribeのオーバーライドレベルで複数のモードを使用したりすることができます。
ここで、Bill に引き継ぐ前に、これまでお話ししてきた主要なメリットをまとめさせていただきます。AppSync Event APIには4つの主要なメリットがあります。1つ目は、エンタープライズグレードのリアルタイムAPIソリューションを素早く立ち上げて実行できることです。このAPIを数分で設定できるようにすることが全体的な目標です。そうすることで、アプリケーションチームがバックエンドチームにリアルタイムイベントを処理できるAPIを要求し、バックエンドチームは1分でそれを構築してフロントエンドアプリケーションに組み込むためのエンドポイントを提供することができます。
2つ目のメリットとして、お客様はあらゆる規模に対応できることです。これは、素早く開始できることに加えて、APIで極めて低いレイテンシーとその規模をサポートするデフォルトのクォータを持つエンタープライズスケールを実現できる重要な要素です。デフォルトのクォータでは、AppSync Event APIで1秒あたり100万メッセージまでスケールすることができます。
AWS AppSync Events APIは30のグローバルリージョンにデプロイでき、カスタムドメインサポート、AWS Web Application Firewall統合、Amazon CloudWatchによるロギングとメトリクスなどのエンタープライズ機能が含まれています。接続管理とAPIメッセージのファンアウトを管理することで、お客様が自身でこれらのソリューションを構築する際によく直面する運用オーバーヘッドを削減しています。複数の認証モードを提供することで、カスタムコードを書くことなく、本質的にプラグアンドプレイで完全な認証を実現できます。また、ユースケースに特化したメッセージのフィルタリングやエンリッチメントのためのイベントハンドラーを作成する機能も提供しています。ここでの目標は、全体的なコストを削減し、アプリケーションのニーズの拡大に応じて成長を支援し、無料利用枠を使用してサービスをすぐに開始できるようにすることです。料金は100万APIオペレーションあたり約1ドルとなっています。
Billに引き継ぐ前にもう1つデモをお見せすると申し上げましたので、すぐにそちらに移りたいと思います。最初のEvent APIの作成にどれくらい時間がかかるか見てみましょう。AWS AppSyncコンソールにいますので、Event APIの作成をクリックします。これをemoji-demo-liveと名付けて作成をクリックします。これで完了です。すぐに使い始められる完全に機能するAPIが作成されました。信じられない方のために、Pub/Subエディターに移動してみましょう。
Pub/Subエディターは、アプリケーションに統合する前に、認証が期待通りに機能し、イベントハンドラーコードが期待通りに動作することをコンソールでテストする方法です。イベントを公開するためのPublishパネルとSubscribeパネルという2つの異なるパネルがあります。APIを作成すると、すぐに開始できるように、デフォルトの認証モードとしてAPIキーが提供されます。WebSocket接続を確立してみましょう。下の方に実行している内容を示すログが表示されています。接続を確立し、サービスから接続レスポンスを受信しています。次に、特定のチャンネルネームスペースへのサブスクリプションを確立できます。最初のAPIを作成すると、デフォルトで実験に使用できるデフォルトのネームスペースがあります。このデフォルトネームスペース/テストチャンネルをサブスクライブしてみましょう。サブスクライブリクエストを送信し、サブスクライブ成功のメッセージが返ってきました。
Publisherに戻りますと、認証用のAPI Keyの設定があります。作成したテストチャンネルに切り替えて、下のエディターでJSONペイロードイベントを入力できます。ここでは2つのイベントを用意していますが、最大5つまで送信できますし、1つだけでも構いません。Publishをクリックしてみましょう。 Publish処理のレスポンスが返ってきて、送信した各イベントに対して一意の識別子が付与されています。下の方を見ると、 先ほど設定したリアルタイムサブスクリプションを通じて受信した2つの個別のイベントが確認できます。
およそ2〜3分で、APIのセットアップとテストが完了しました。もう1つ例を見てみましょう。今度はカスタムNamespaceの追加方法です。Namespaceセクションに移動して、 "reinvent"という新しいNamespaceを作成します。先ほど説明したように、Namespaceレベルで認証設定をオーバーライドすることができます。現在このAPIは API Key認証のみをサポートしているので、今これを変更する意味はありませんが、Namespaceレベルで利用できる認証モードを追加することは可能です。では、Event Handlerを追加してみましょう。 これがEvent Handlerエディターで、onPublishハンドラーとonSubscribeハンドラーがあります。デモ中のライブコーディングは常に楽しいので、実際にコードを書いてみましょう。まず、文字列や日時ユーティリティを扱うための便利なユーティリティコードを提供するasync utilライブラリをインポートします。そして、いくつかのフィールドを追加します：util.timeを使用して現在時刻を取得するupdated_appフィールドと、re invent 2024というイベント用の別のフィールドです。
セッションの感想として「素晴らしいセッションでした」というものを追加してみましょう。これでonPublishハンドラーはよさそうですが、onSubscribeハンドラーの実装も見てみましょう。 ここでは、デモで使用したEmojiチャンネルにのみサブスクライブを制限することができます。そのために、context.info.channels.segmentsにemojiが含まれているかどうかをチェックします。 含まれていない場合は、contextを返します。つまり、チャンネル内に存在するセグメントにemojiセグメントが含まれているかどうかをチェックし、含まれていない場合はutil.unauthorizedを返すという処理です。
Pub/Subエディターで、この特定のNamespaceをテストしてみましょう。 サブスクリプションに移動して接続し、まず失敗するケースを試してみます。「this is not valid」と入力します。 コードが正しければ、unauthorized errorが返されるはずです。 コードにエラーがあるようです。 emoji以外のものは全て無効にすることにします。正しいコードは後で共有しますが、デモに戻りましょう。
再び接続を確立し、emojiにサブスクライブして、 その特定のチャンネルにイベントを送信してみましょう。両方のイベントをPublishすると、下部に表示されます。 カスタム絵文字をいくつか追加して、それらを全て送信してみましょう。下部を見ると、 onPublishハンドラーのイベントエンリッチメントステップで追加したメタデータと共に、それぞれのイベントが表示されているはずです。
デモはここまでです。ここからは Bill に引き継いで、実世界のリアルタイムアーキテクチャパターンについて説明してもらいます。ありがとう、Kim。Pub/sub エディタを使ってコードのエラーをすばやくキャッチできることを示してくれて、とても良かったと思います。では、スライドを進めるためにどのボタンを押せばいいのか確認しないと。はい、この大きな緑のボタンですね。 私は Bill Fine で、AWS AppSync のプロダクトマネジメントを担当しています。AWS AppSync Events の開発を始めた時、私たちは2つの基本的な原則を念頭に置いていました。1つ目は、シンプルであることです。Kim のデモで、それが実現できていることをご覧いただけたと思います。20分ちょっとの間に、製品の概要を説明し、デモを行い、クライアント側でたった20行のコードで意味のあるものを構築し、実際のイベント API をカスタム設定でテストするところまでお見せしました。
Event broadcastとコラボレーションパターンの実装例
2つ目の設計原則は、シンプルでありながらも単純すぎないようにすることでした。私たちが設計時に想定していたのは、Super Bowl や Olympics、そして今日のような Cyber Monday や Black Friday といったイベントに向けて、組織がリアルタイムアプリケーションを構築する際のミッションクリティカルなリアルタイムイベントパターンでした。これから、そういった組織がこのソリューションをどのように使用しているのか、その実際のリアルタイムパターンの内部構造について掘り下げていきたいと思います。Kim が言及した Event broadcast から始めましょう。Event broadcast は、バックエンド側に1つか2つのパブリッシャーがあり、数千、数万、数十万、あるいは数百万の接続されたクライアントやサブスクライバーに配信する必要があるパターンです。
これらのクライアントやサブスクライバーは、様々なものにアクセスする可能性があります。今朝、金融アプリで株式ポートフォリオや特定の株価をチェックしたかもしれません。あるいは暗号資産取引をされている方なら、Kim と私の話を聞きながら、ミームコインの取引をしていたかもしれません。Cyber Monday なので、Amazon にログインして Amazon Live を見ているかもしれません。Amazon Live というのは、インフルエンサーが今日 Amazon で購入すべき商品を紹介する動画チャンネルです。その中で、商品の価格や在庫状況も動画フィードに含まれています。
今晩、セッションの後に Sphere に行こうと思っていて、空いている座席を選ぼうとしているかもしれません。あるいは、座席が取れなくてホテルの部屋に戻り、スマートフォンでお気に入りの音楽リアリティ番組を見ながら、オンライン投票の開始や終了を待っているかもしれません。これらはすべて、Event broadcast で見られる実際のリアルタイムパターンです。しかし、おそらく最も典型的な例はスポーツのスコアや統計情報でしょう。Kim は明らかに Seahawks のファンなので、DK Metcalf について話していましたが、ここで私が示す例は PGA TOUR からのものです。
PGA TOUR から来られている方はいらっしゃいますか？今日はいないようですね。ここに QR コードがありますので、クリックしていただくと、PGA TOUR が AppSync を使ってファン体験アプリケーションをどのようにサポートしているかを示す短い動画をご覧いただけます。ゴルファーの方なら、これについてご存知かもしれません。ところで、この動画は1年前のものですが、AppSync Events をリリースしたのはたった4週間前です。なぜ私が PGA TOUR について話しているのか、疑問に思われるかもしれません。
昨年、PGA TOURの方々が私と一緒にここに立ち、AppSync GraphQLのSubscriptionsを使って彼らのリアルタイムのニーズに対応している様子を発表しました。これは、Kimが彼女のプレゼンテーションの冒頭で示したオプションの1つでしたが、彼らはその機能が素晴らしく、ニーズを満たしていると話していました。しかし、実は彼らはもっとシンプルなソリューションを望んでいたのです。GraphQLが特定のユースケースには適していることは理解していましたが、純粋なPub/Subソリューションが欲しかったのです。これがAppSync Eventsを作るきっかけとなりました。もし皆さんがAppSync Eventsを気に入って素晴らしいと思われたら、PGA TOURの方々に出会った際には感謝を伝えてください。彼らがこの会話のきっかけを作ってくれたのですから。
彼らのイベント管理についてもう少し詳しくお話ししましょう。ゴルファーの方ならご存知かもしれませんが、ツアーイベントでは通常、4人のゴルファーのグループが18ホールのいずれか、あるいは2つのコースにまたがる場合は36ホールのいずれかにいます。各コースには、モバイルデバイスを持った人々が配置されており、そのホールで起きていること - ゴルファーが打ったストローク数や、ボールの飛距離、グリーン上でのボールの位置などを記録しています。これらのデータはすべてモバイルデバイスからAmazon DynamoDBデータベースに送られ、DynamoDB Streamsが設定されて、これらのイベントが発生するたびにAWS Lambda関数に送信され、その関数がこれらの変更を監視してAppSyncに書き込んでいます。
彼らの場合、AppSync GraphQLがSubscriptionsをトリガーしていますが、1年前に彼らが望んでいたのは、AppSync Event APIを使ってこれらのイベントを配信し、コース上のリーダーボードを更新することでした。これは、映像や放送チャンネル、スコアやスタッツの状況など、皆さんが目にするものです。また、私が言及したファン体験 - Webやモバイルアプリケーションを通じて、ゴルファーのファンが見るものです。彼らは、すべてのゴルファーではなく、お気に入りのゴルファーの状況を見るためにチャンネルの仕組みを使用してSubscribeしたり、ゴルフトーナメントで次に何が起こるかを賭けるためのベッティングプラットフォームの更新にも使用されています。
ベッティングプラットフォームについて触れたので、画面を切り替えましょう。ここでは大きな違いは2つしかありません。1つはユースケースです。今回はオッズや価格の更新について話しています。このオッズのユースケースでは、様々なイベントに対してWebやモバイルアプリケーションを通じて賭けを行うユーザーにサービスを提供するために、この仕組みを使用している多くの顧客と話をしています。
これらのプレイヤーは、500ミリ秒ごとに変更される可能性のある最新のオッズの更新を受け取ります。これらの例での違いの一つは、Amazon DynamoDB Streamsの代わりに、Amazon KinesisやマネージドKafkaをイベントソースとして使用していることです。これらはLambdaリスナーにストリーミングされ、そこからAWS AppSyncとAPIを通じて、数十万から数百万の接続されたSubscriberにブロードキャストされます。これらの2つのケースでは、AWSのわずか数個のサービスで、数百万の顧客に対して数十億のメッセージを処理しています。
場合によってはさらにシンプルになることもあります。EventBridgeをご存知ない方のために説明すると、これはAWSのサービスポートフォリオの一部で、イベント駆動型アーキテクチャの構築を支援するものです。EventBridgeで設定できるのは、イベントを保持するためのEvent Busです。EventBridgeのEvent BusからAWS AppSync Event APIへの連携は、EventBridgeでいうところのAPI Destinationを設定するだけで簡単に実現できます。これで3つのボックスからなるアーキテクチャが2つのボックスにまで簡略化されました。このように、このブロードキャストパターンをスケールさせて実装するための方法は数多くあります。
次に紹介したいのは、コラボレーションパターンです。これは通常、1～2つのPublisherではなく、より多くのPublisherが限られた数のSubscriberとコラボレーティブな形で相互作用するパターンです。これには様々な例があります。Slackのようなグループチャット体験や、共有ドキュメントで変更を加えたり変更をリアルタイムで確認したりする共同編集、あるいは異なるチーム間で担当者の変更や更新が行われるサポートチケットなどが該当します。
もう一つの例、おそらく最も典型的な例として、今まさに何人かの方が体験されているかもしれませんが、ゲームプレイがあります。こちらが私たちが持っているConnect 4アプリの例です。今週後半に、AppSync Eventsを使ってこのアプリを作成するワークショップが予定されています。残念ながら、現時点で定員に達してしまっているようです。ですが、朗報もありますのでお待ちください。このパターンでは、先ほど申し上げたように、アプリケーション同士の通信が行われます。クライアントアプリケーション自体がPublisherとSubscriberの両方の役割を果たし、HTTPを通じて更新や移動を交互に発行し、自分の番が来たときには通知を受け取ります。
先ほど触れた朗報についてお話しします。このQRコードをスキャンすると、Connect 4アプリの作成方法を解説したブログとリポジトリにアクセスできます。これはAmplify HostingでホストされているNext.jsアプリで、バックエンドにAppSyncを使用しています。ターン制のゲームプレイの実装方法や、統計情報を表示するための一時的なリーダーボード、プレイヤー同士が会話できるグループチャットなど、Event APIを活用したリアルタイムパターンの実装方法をすべて確認できます。
AppSync Eventsでは、設定をほとんど、あるいはまったく必要とせずに、ビルトイン機能だけで多くのことが実現できます。また、私たちの顧客ベースの中で見られる、少し手の込んだパターンについてもお話ししたいと思います。もしかしたらお気づきでないかもしれませんが、AppSync Eventsはステートレスで、イベントの永続化は行いません。多くのユースケースではそれで問題ありませんが、イベントを永続化してアクセスする必要がある場合もあります。こちらがその実装方法の例です。では、なぜこれらのパターンを実装する必要があるのか、説明させていただきます。
典型的な例として、誰かがSubscriptionに接続する際、次のアップデートを待つのではなく、最新のアップデートを取得してそこから更新を受け取りたい、あるいは切断された後に特定のポイントから再接続してメッセージを再生したいというケースがあります。これを実現する一つの方法は、Publisherがイベントを作成する際に、そのイベントを何らかのデータストアに永続化することです。この例では、RDSによってバックアップされたシンプルなAPIパターンを示しています - これはDynamoDBでも、実際には何でも構いません - クライアントがオンラインになってイベントストリームをSubscribeしようとする際に、現在の状態を取得するためにクエリを実行できます。
もう一つの例として、Kimが先ほどデモンストレーションしたように、イベントの順序を追加する方法があります。AWS AppSync Event APIでは、イベントの配信順序を保証していません。必要なのは、Kimが先ほどデモンストレーションしたように、AWS AppSync Utilitiesを活用してイベントの流れの中にタイムスタンプを含め、クライアントが順序を判断できるようにすることです。これがその実現方法の一例です。これは比較的新しいサービスですが、コミュニティのメンバーが毎週のように新しいパターンを考え出しているのを目にします。昨晩も、AWS Community BuilderのメンバーがEventBridge、S3、Lambdaを使用してAWS AppSync Eventsで配信保証を実現するパターンを公開していました。このような高度なユースケースに対応するため、人々は様々な興味深い取り組みを行っています。
AWS AppSync Eventsの現状と将来の展望
AWS AppSync Eventsは比較的新しく、リリースからまだ4週間しか経っていません。新しいサービス特有の雰囲気があり、実際に使用できるかどうか不安に感じる人もいるかもしれません。しかし、答えは間違いなく「Yes」です。その理由は、毎日数十億のイベントを処理している実績のあるAWS AppSync GraphQL Subscriptionsのインフラストラクチャ上に構築されているからです。AWS AppSync Eventsのローンチ時のデフォルトクォータは、アウトバウンドで1秒あたり100万イベント、インバウンドで1秒あたり1万イベント、そしてSubscriber数に制限はありません。1秒あたり2,000の新規接続という接続作成のスロットリングはありますが、これらはすべて調整可能で、ほとんどのお客様が始めるには十分な初期値となっています。
30のリージョンで利用可能で、これは特にこのユースケースでは重要です。ユーザーの近くにEventAPIを配置してレイテンシーを削減できるからです。everyone's use of itが異なるため、レイテンシーの数値を公表するのは難しいのですが、基本的なユースケースで期待される値を共有できます。P50レイテンシーメトリクスは50ミリ秒以下、P99は200ミリ秒以下であるべきです。もしそうでない場合は、ご連絡いただければ調査させていただきます。コストに関しては非常にシンプルで、インバウンドメッセージ、アウトバウンドメッセージ、WebSocket接続などの操作を含むイベントオペレーション100万回あたり1ドルを請求します。また、接続時間1分あたり8セントを請求します。ほとんどのユースケースでは、コストの95%はConnection Minutesではなくイベントオペレーションによるものですが、Connection Minutesが重要になるエッジケースもあります。スタートアップ支援として、最初の1年間は毎月25万回のイベントオペレーションと25万分のConnection Minutesを無料で提供しているので、すぐに試し始めることができます。
AWS AppSync Eventsの今後の展開について、いくつかの取り組みを進めています。一部のお客様からPrivate APIのリクエストがあり、PublisherとSubscriberをセキュアな環境に配置できるよう、VPC内にリアルタイムパターンを実装したいとの要望があります。現在はHTTP経由でPublishしていますが、WebSocket経由でのPublishを追加する作業を進めており、PublishとSubscribe操作のための完全なフルデュプレックスWebSocketが利用可能になる予定です。
これにより開発者の体験が簡素化され、特定のシナリオではレイテンシーが低減されるはずです。Kimが紹介したEvent Handlerは、AppSyncサービス内でネイティブに実行されるJavaScriptランタイム環境だと考えることができます。コールドスタートもなく、効率的で高速です。時にはLambdaのパワーが必要になることもあるので、Lambdaへの切り替えオプションも用意しています。これは、JavaScriptではなくPythonやGoを使いたい場合や、AppSync JavaScriptランタイムでは許可されていないネットワークアクセスが必要なユースケースの場合などが考えられます。
私たちは、Built-in Targetsと呼んでいるもの（AppSync Graphをご存知の方なら、Data Sourcesと考えていただければ）の導入を計画しています。これにより、Event Handlerがデータベースと直接やり取りできるようになります。DynamoDB、Auroraデータベース、OpenSearchをサポートする予定です。これにより、システムを通じて流れるイベントをデータベースに保存したり、イベントに追加データを付加するためにデータベースを呼び出したりするような永続化のユースケースがさらに簡単になります。また、アプリケーションイベントからバックエンドアーキテクチャにイベントを送信したい場合のDestinationまたはBuilt-in TargetとしてEventBridgeもサポートします。さらに、HandlerからあらゆるAPIと連携できるようにHTTP APIもサポートします。
Built-in Targetとしてサポートを予定している最後の機能は、AWS BedrockまたはAmazon Bedrockです。このセッションでBedrock や生成AIについて触れるのは、これが初めてかもしれません。次のようなシナリオを想像してください：金融サービスや保険会社のアプリケーション提供者が、ユーザーに対して自身の保険契約について質問できる機能を提供したいと考えています。ユーザーは自然言語で保険の補償範囲について質問し、それをWebSocket経由でAppSync Event APIを通じてイベントとして発行します。そして、Handlerが RAG を使ってそのユーザーの保険契約情報を取得して補完します。HandlerはこれをBedrockに送信し、Bedrockは最初の質問とユーザーの保険契約情報を基に回答を生成し、同じイベントチャネルとWebSocketを通じてその回答をカスタマーに送り返します。
私たちは、さらに使いやすくする取り組みを進めています。先ほど、イベントの永続化の管理方法についてお話ししましたが、Event Handlerを通じて管理できるData SourcesやBuilt-in Targetsを追加することで、さらに簡単になります。でも、そもそもこれを自動化できないでしょうか？それが次のステップです - AppSync Eventsサービス自体に組み込みのイベント永続化オプションを持たせることです。また、Built-inの順序管理も提供できます。さらに、プレゼンス検出機能の追加も検討しています - グループチャットシナリオでチャンネルを誰かが実際に視聴している時に表示される、あの小さな緑のドットのようなものです。Kimは、Event Handlerを使用してスキーマを検証する方法について説明しましたが、私たちは、Cloud Eventsのような仕組みを使用して型付きイベントを作成し、サーバー自体が検証を管理する機能の提供を検討しています。
PGA TOURの例に戻りたいと思います。彼らは私たちのロードマップに大きな影響を与えました。re:Inventで私に話しかけてきたのは彼らだけでなく、他の方々も製品に期待する機能について語ってくれました。ここで紹介した機能の中で気に入ったものがあり、確実に開発を進めてほしいと思われる場合は、ぜひお知らせください。また、このスライドに含まれていない機能で、私たちが取り組むべきものがあれば、それも教えてください。私たちは皆様の声に真摯に耳を傾けたいと考えています。
セッションのまとめと今後のアクション
以上で終わりです。皆さんのユースケースに合わせて簡単に始められることがお分かりいただけたと思います。ここに2つのQRコードがあります。これらはドキュメントへのリンクですが、本当にシンプルです。数行のコードを書くだけで、フリーティアでテストを始めることができます。皆さんのご意見をお聞かせください。
今日お話しした内容に関連して、より詳しい内容や他の例を紹介するセッションがいくつか予定されています。カタログでAppSyncを検索すれば、それらのセッションが表示されます。ほとんどのセッションは満席ですが、興味のあるセッションに参加できなかった場合でも、ビデオ録画が後で視聴可能になります。
最後に、一日の最初のセッションにご参加いただき、ありがとうございます。Kimには、このセッションの準備に多大な努力を注いでいただき、感謝しています。アプリ内でアンケートが利用可能ですが、このセッションだけでなく、すべてのセッションについて、私たちは本当にこれらのアンケートを重視しています。いただいたフィードバックは、来年どのようなコンテンツやセッションを行うかを決める際の参考になります。また、どのスピーカーに登壇してもらうかにも影響します。ですので、Kimの発表が良かった場合は（そうであるはずですが）、高評価をお願いします。私の発表が気に入らなかった場合は（それも当然ですが）、そう伝えていただければ、来年は別の人に任せることもできます。ぜひアンケートにご協力ください。私たちは真剣に見ています。
これで終わりです。質問の時間を設けられると思っていましたが、残念ながら時間が足りませんでした。このセッション後、すぐにホールで質問をお受けしますので、お話ししたい方はそちらにお越しください。ありがとうございました。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion