re:Invent 2024: AWS AppSyncの多機能性 - GraphQLからAI連携まで
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - I didn't know AWS AppSync could do that! (FWM203)
この動画では、AWS AppSyncの多様な活用方法について、Principal Product ManagerのBrice PelléとSenior Developer AdvocateのMichael Liendoが解説しています。GraphQLによる柔軟なデータアクセス、AppSync Eventsを活用したリアルタイムイベント処理、Amazon Bedrockと連携したGenerative AIのゲートウェイとしての活用など、AppSyncの幅広い機能を実際のデモを交えて紹介しています。特に注目すべき点として、Gartnerの予測による2027年までの企業のGraphQL採用率60%への上昇や、AppSync EventsによるWebSocket通信の実装簡易化、Private APIやMerge APIなどのエンタープライズ向け機能の充実が挙げられます。チャットアプリやリアルタイム翻訳など、具体的なユースケースのデモを通じて、AppSyncの実践的な活用方法を示しています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
AWS AppSyncの可能性を探る：セッション概要
FWM 203「AWS AppSyncってそんなこともできるの？」セッションにご参加いただき、ありがとうございます。皆様がここにいらっしゃるということは、AppSyncに興味をお持ちで、もっと学びたいと思っていらっしゃるのだと思います。このセッションの目標は、私たちの会話を通じて、皆様に「AppSyncってそんなこともできるんだ！」とか「AWS AppSyncが自分の組織やチームが直面している課題に対してソリューションを持っていることを知らなかった」と感じていただくことです。
私はAWSのAppSyncチームのPrincipal Product ManagerのBrice Pelléです。そして、パートナーのMichael Liendoと一緒に進行させていただきます。「みなさん、こんにちは。私はAWSのSenior Developer AdvocateのMichael Liendoです。もともとAmplifyチームにいて、その後AppSyncチームに移り、現在は北米地域のDeveloper Advocateを担当しています。今日は素晴らしい内容をご用意しています。このトークのタイトルは私の考案したものなんです。このセッションでは、AppSyncの異なるユースケースを示す5つのデモをご覧いただきます。途中でスマートフォンを取り出してQRコードをスキャンしていただく場面もありますが、きっと楽しんでいただけると思います。」
アジェンダとして、いくつかのトピックを見ていきます。まず、AWS AppSync GraphQLによる柔軟なデータアクセスについて、次にAppSyncイベントによるリアルタイムイベントについて、そしてGenerative AIバックエンドのためのAIゲートウェイとしてのAppSyncの活用方法についてお話しします。その後、APIの取り扱いと運用をより簡単にするために提供している、セキュリティと運用に関する機能について詳しくご説明します。
GraphQLとAWS AppSyncの基礎：RESTとの比較と利点
では、GraphQL、特にAppSync GraphQLについて見ていきましょう。詳しく説明する前に、これまでにGraphQLを使用したことがある方は何人いらっしゃいますか？かなりの数の手が挙がりましたね。そして、その中でAppSyncを使用したことがある方は？少し少なめですが、それでもかなりいらっしゃいますね。基本的な理解を揃えるために、まずGraphQLとは何かについて説明させていただきます。
GraphQLはAPIのためのクエリ言語です。本質的には、APIの機能と特徴を定義できる仕様です。APIで利用可能なクエリ、ミューテーション、サブスクリプションを定義した完全な型付きドキュメントを定義することができます。RESTとの違いは、GraphQLではクライアントが単一のリクエストを行い、それがGraphQL API（この場合はAppSync）によって解決され、複数のデータソースと単一のリクエストで対話できる点です。ここでの重要なポイントは、GraphQLとGraphQL APIが多くの重い処理を代わりに行ってくれるため、クライアント側での作業が少なくて済むということです。クライアントは特定のデータを特定のフォーマットで要求でき、要求した形式でそのデータを受け取ることができます。
GraphQLはAPI開発を強化しており、データがそれを裏付けています。Gartnerの予測によると、2027年までに企業の60%以上がGraphQLを本番環境で使用するようになり、これは2024年の30%未満から大きく増加する見込みです。GraphQLは登場してからかなりの時間が経っていますが、この予測によれば、まだ比較的初期の段階にあると言えます。今後数年間で、多くの企業がこの分野で動き始め、自社の本番環境にGraphQLを導入していくことが予想されます。
GraphQLを始めるにあたって、いくつかの選択肢があります。セルフホスティングを選んで独自のソリューションを実装することもできますが、それは非常に面倒な作業になります。
ホスティングソリューションについて考えると、小規模なものから始めるのは簡単ですが、本番環境やエンタープライズ環境での展開には数多くの課題が伴います。GraphQLの自己管理は複雑で、コストがかかり、面倒ですが、より良い方法があります。そこで私たちは、完全サーバーレスで完全マネージド型のGraphQL APIをデプロイできるAWS AppSyncを導入しました。コード量が少なく完全サーバーレスであることは、複雑さの軽減につながり、さらに完全に安全で高性能です。これらは機能を実装する際の最重要事項です。AppSyncは完全マネージド型なので、少ないコードで素早く始められ、APIが需要に応じて確実にスケールすることを信頼できます。
現在、多くのお客様がAppSync GraphQLを使用しています。こちらが GraphQLを使用している私たちのお客様の一例です。詳しい事例はAWS AppSyncのオンラインページでご覧いただけます。 GraphQLを始める際、既存のREST APIについて考えることがあるでしょう。私はGraphQLを、REST APIを様々な方法で強化できるエンハンサーとして捉えています。GraphQLはRESTと非常に相性が良く、現在 RESTを使用しているアプリケーションに新機能を追加したい場合は、RESTの横にGraphQLを導入することで実現できます。ストラングラーパターンを使用して、既存のREST APIから機能を徐々に削除し、GraphQL APIに移行することができます。
これらの2つの技術は共存できます。GraphQLをRESTの上に構築することも可能で、これは Backend for Frontend（BFF）と呼ばれる一般的なパターンです。このパターンでは、AppSyncをアプリケーションのBFFとして機能させます。AWS AppSync GraphQL APIでクライアント固有のユーザーエクスペリエンスを実装することができます。これにより、GraphQL APIを非常に具体的な用途に特化させながら、REST APIはシンプルで汎用的なまま、複数のアプリケーションにサービスを提供できます。最後に、GraphQLは REST APIとリアルタイムでの連携も優れています。リアルタイムについて話す際、RESTを使用している多くのお客様はポーリングを実装してリアルタイム通知を取得しています。代わりに、AppSyncを使用してAppSyncのサブスクリプションを活用すれば、WebSocketを通じてAPIにリアルタイム通知を転送できます。AppSyncでこれを実装すると、ポーリングが不要になり、既存のREST APIへの負荷が軽減され、より効率的で低レイテンシーな実装が可能になります。
AWS AppSyncによるBFFパターンの実装と柔軟なデータアクセス
BFFパターンをより詳しく見てみましょう。多くのお客様が様々な理由でこのパターンを採用しています。これはフロントエンドチームにとって素晴らしい選択です。なぜなら、自分たちのBFFデプロイメントを完全にコントロールできるからです。BFFデプロイメントは、アプリケーションで実現しようとしている特定のユーザー体験と密接に結びついています。汎用的なAPIとのやり取りに頭を悩ませる代わりに、フロントエンドアプリケーション専用にカスタマイズされたものを使用でき、自分たちのペースで開発を進められます。一方で、REST APIは汎用的でシンプルな状態を保ち、明確な焦点を持って独立して進化させることができます。
簡単な例を見てみましょう。api.weather.govが提供するAPIを使用して、新しいアプリケーション用の天気APIを実装する必要があるとします。位置情報、一般的な予報、時間ごとの予報を含む気象情報を取得することが要件です。api.weather.gov APIを使用する場合、これを1回のリクエストで実現することはできませんが、BFFを実装することで可能になります。まず、APIのスキーマを作成し、getWeatherというクエリを作成します。getWeatherは座標XとYの2つの引数を取り、ポイントを返します。このポイントには、解決する必要のあるforecastとhourlyフィールドを含む複数のフィールドがあります。これらのフィールドにデータソースをリンクする必要があります。次のステップは、単純にREST APIを指すデータソースを作成することです。ご覧のように、とてもシンプルです - コンソールでHTTPエンドポイントを定義するだけです。このデータソースは、API内の任意のリゾルバーで再利用可能です。
getWeatherのリゾルバーの実装は非常にシンプルです。リクエストハンドラーで、このリソースパスにGETリクエストを送信したいと指定するだけです。座標XとY引数がリクエストに渡されているのがわかります。レスポンスを受け取ると、HTTPレスポンスからプロパティを抽出できます。ここで注目すべき点の1つは、グリッド情報を取得していることです。そして、返されたデータの簡単な変換を行っているのがわかります。
ここでgridId、gridX、gridYに注目してください。最初のリクエストからのこれらの結果を使用して、forecastとhourlyフィールドの追加リクエストを行うための新しいリソースパスを構築できます。これらはGraphQL APIレベルで1つのリクエストハンドリングで解決されます。X-Rayで何が起こっているかを見てみると、1つのリクエストを行い、上部にgetWeatherクエリがあることがわかります。これはAppSyncによって行われた最初のリクエストですが、残りのフィールドを解決するために、2つのリクエストを並行して実行し、クライアントにデータを返す前にすべてを処理します。通常、クライアントから3回以上のリクエストが必要だったものが、BFFでは1回のリクエストで実現できます。これがAppSyncの実装がもたらすパワーの一部です。
APIに関して、AppSyncがRESTを強化するだけでなく、データAPIも強化することについて説明しました。現在のAppSyncの強みの1つは、Amazon Auroraサーバーとの対話に使用できることです。Data APIを使用するAmazon Auroraでは、新しいことを学ぶ必要はありません。JavaScriptで単純にSQLを書くだけです。SQLを書くために使用できるユーティリティを提供しています。ここでは、単純にSQLを記述してパラメータを渡すことができるテンプレート文字列関数があります。これは安全です。なぜなら、これらのパラメータを見たとき、プレースホルダーを持つクエリ文字列を作成し、それらのパラメータをプレースホルダーに送信するからです - 手動で行うよりも、クライアントから行うよりもはるかに安全です。
また、Amazon DynamoDBとの連携もサポートしています。これは私たちが最も長く提供してきた機能の1つだと思います。AppSyncとDynamoDBは非常に相性が良く、DynamoDBテーブルと連携する最もシンプルな方法の1つです。クエリやアップデート、ミューテーションなどを実行するためのユーティリティも提供しています。そのため、DynamoDBが提案する少し複雑な構文を学ぶ必要はありません。私たちのユーティリティを使用すれば、条件付きでフィールドをインクリメントするようなアップデート操作も、通常のDynamoDB構文では少し厄介な操作も、シンプルなJavaScriptで簡単に実行できます。
そして、Pipeline Resolverを使用することができます。Pipeline Resolverを使用すると、追加のコンピュートを必要とせずに、複数のデータソースを順番に呼び出すことができます。GraphQL APIで、Pipeline Resolverを呼び出し、DynamoDBの関数を呼び出し、そのクエリの結果を使用してAuroraデータベース用の別のクエリを構築することができます。ここでPipeline関数の例を示します。最初に、DynamoDBテーブルにアクセスして、引数として渡したIDをキーとしてアイテムを取得します。結果を取得し、その後、順番に実行される2番目の関数では、DynamoDBから取得した結果を使用してSQLクエリを構築できます。単一のアイテムを取得するのにDynamoDBテーブルを使用し、任意のクエリを実行するためにAuroraデータベースを使用したい場合があるかもしれません。それも問題ありません。データソースを組み合わせて使用でき、AppSyncと非常にうまく連携します。
AWS AppSyncを活用したリアルタイムチャットアプリのデモンストレーション
これがAppSync GraphQLによるAPIの強化、RESTの強化、データソースの強化です。しかし、その真の力と機能をお見せするために、最初のデモに進みたいと思います。ここからMichaelに引き継ぎたいと思います。ありがとう、Bree。Breeが触れた重要なポイントがいくつかありますね。AppSyncの真の力は、直接的な統合機能にあります。先ほどAurora、DynamoDB、EventBridge、Lambdaなどを見ていただきましたが、これらすべてのHello Worldとも言えるデモをお見せしたいと思います。その最も基本的な例がチャットアプリです。通常の操作に加えて、リアルタイムのWebSocketサポートも得られます。では、実際に見ていきましょう。ご覧のとおり、これが私の素晴らしいチャットアプリケーションです。
AppSyncはバックエンド側だけでなく、フロントエンド側でも連携が可能です。Amazon CognitoはAppSyncと連携する完璧なユースケースで、サービス同士が相互に連携するエコシステムを形成しています。
パスワードとともにメールアドレスを設定してみましょう。現在、チャットアプリケーションのセットアップを行っています。ルームを作成する必要があります。AppSyncはAmazon DynamoDBと直接通信してルームを作成します。「cool reinvent people」と名付けましょう。ルームが作成され、このURLに移動しました。ここでメッセージを入力して始めることができます。
ここで入力しながらいくつかのことが起きています。これは実際のデプロイされたチャットアプリケーションです。URLにアクセスすれば私とチャットができますが、それは後ほど説明します。メッセージを入力すると、「hello」と送信して保存されます。ページを更新しても、そのメッセージはすぐに表示されます。単純なテキストに加えて、Amazon S3の画像IDなども保存できます。よく「Michael、S3とAPIをどうやって連携させるの？」と聞かれますが、簡単です。S3のキーを取得して、AppSyncのAPIに付加するだけです。
ここに素晴らしい画像があります。これを取り込んでみましょう。インターネット接続が十分であれば、この画像を送信できます。ここまでで、AppSyncがDynamoDBと通信し、そのリアルタイムの接続が私のアプリケーションに戻ってきています。このURLにアクセスすれば、一緒にチャットができ、1つのAPIで作成、読み取り、更新、削除に加えてリアルタイム機能も使えます。これは私の中で最も対話性の低いデモですが、始めるための「Hello World」としては十分です。チャットアプリは通常、AppSyncを使い始める際の最初のステップです。ここでBriceにバトンタッチします。私が気に入っているのは、これがとても簡単にセットアップできることです。通常であれば、AppSync、DynamoDB、S3のインフラ全体のセットアップが必要になりますが、これだけで設定完了です。
AppSync Eventsによるリアルタイムエクスペリエンスの実現
では、スライドに戻って、AppSync Eventsを使用したリアルタイムエクスペリエンスについて次のセクションに移りましょう。ここにいる多くの方がAppSyncを使用されており、おそらくGraphQLを活用するためにAppSyncを使用されていると思います。私たちはAppSyncを長年運用してきており、GraphQLのメリットのためにAppSyncを使用する顧客が多くいます。しかし、多くの顧客は特にAppSyncのサブスクリプション機能を使用したいがために、AppSyncを選んでいます。
現在、顧客はAppSyncのサブスクリプションを使用してAPIでリアルタイムエクスペリエンスを実現しています。多くの顧客がこれを行っており、それには十分な理由があります。今日私たちが日常的に使用しているアプリケーションを考えてみると、至る所でリアルタイムの例を見つけることができます。スポーツファンであれ、オンラインショッピングをしているときであれ、先ほどMichaelが見せてくれたようなグループチャットであれ、リアルタイムエクスペリエンスは顧客により良い体験を提供するために everywhere に存在しています。
お気に入りのスポーツサイトでスコアを確認するとき、状況を知るためにページを何度も更新したくはありません。商品に入札するとき、最新の価格更新を確認したり、在庫切れを確認したりするためにページを更新する必要があってはいけません。このように、リアルタイムエクスペリエンスは現代のWebアプリケーションにとって極めて重要です。これらはイベントブロードキャストの例ですが、コラボレーションの観点ではさらに重要になります。複数のユーザーが一緒に作業するコラボレーションを考えると、リアルタイム性はさらに重要になります。関連情報を非常に低いレイテンシーで伝達できることが重要です。ターンバイターンのナビゲーションで位置情報を更新する場合、低レイテンシーは非常に重要で、適切な情報を適切な人に送信できることも同様に重要です。
私たちは至る所でリアルタイムのエクスペリエンスを目にしますが、実際にリアルタイム機能を実現するのは少し難しいものです。 先ほど少し触れましたが、REST APIを使用する場合、リアルタイム更新を取得するためにポーリングという手法に頼ることになります。
今日のインターネットでは、REST APIを使用したこのポーリング方式がリアルタイム更新の一般的な方法となっていますが、これは本当の意味で効率的とは言えません。クライアントが常にデータを更新するループ状態にあるため、クライアント側に大きな負荷がかかります。また、REST エンドポイントにとっても非効率的です - 数百のアプリケーションがポーリングを行う大規模な実装では、バックエンドに多大な負荷が発生します。これは不必要なリソース消費を引き起こし、スケーラビリティも良くありません。
もう一つの選択肢として、WebSocket を使用してリアルタイム更新を実装することもできます。これは低レイテンシーという点では素晴らしい選択肢です。しかし、WebSocketは半永続的な接続を提供するだけで、接続管理機能は提供しません。これにより、いくつかの課題が生じます：複数の受信者へのメッセージ配信をどのように追跡するのか？マルチキャストやグループメッセージの追跡をどのように処理するのか？オートスケーリングをどのように管理するのか？WebSocketを効果的に管理するには、かなりの複雑さが伴います。さらに、 これを自前で実装する場合、アプローチに関係なく、大量のバックエンドコードが必要になります。このことを考えると、エンドユーザーにとって本当に重要な機能の開発に時間を使うべきところを、これらの技術的な課題に時間を費やすことになってしまいます。
AWSで今日リアルタイムエクスペリエンスを構築するための選択肢を見てみると、いくつかのオプションがあります。Amazon API Gateway WebSocketsを使用することもできます。これはマネージド型のWebSocket APIを提供しますが、接続管理は自分で行う必要があります。AWS IoT Coreを使用することもできます - これは素晴らしいサービスで、 IoTデバイスに適しています。ただし、証明書やIAMロール以外の認証モードを必要とするWebアプリやモバイルアプリがある場合、摩擦が生じる可能性があります。また、MQTTの知識とMQTT SDKの使用も必要です。最後に、AWS AppSync GraphQLがあります。これは素晴らしいサービスです - 私のサービスなので少し偏った見方かもしれませんが - GraphQLの知識が必要です。時にはお客様はGraphQLの機能を必要としておらず、単にサブスクリプションコンポーネントとマネージド型WebSocketのスケーリング機能だけを求めている場合があります。
お客様からは一貫して、リアルタイムエクスペリエンス作成のための目的特化型のPub/Subソリューションへの要望がありました。 そこで私たちは、AWS AppSync Eventsを開発しました。これこそが、リアルタイムエクスペリエンスを構築・スケールする最も簡単な方法だと考えています。AWS AppSync Eventsは、フルマネージド型のPub/Sub WebSocket APIを提供し、数分で - というよりも数秒で - リアルタイムエクスペリエンスを実装することができます。これにより運用オーバーヘッドを削減し、アプリケーションのパフォーマンスを向上させ、低コストで簡単に始めることができます。
AppSync Eventsの機能と実装例：シンプルさとスケーラビリティ
AppSync Eventsは基本的にシンプルです - パブリッシャーがHTTPエンドポイントを通じてデータをプッシュし、サブスクライバーがWebSocketを通じてチャンネルを購読できるWebSocketシステムです。これだけ知っていれば十分です。特別なライブラリも、特別な実装も必要ありません。今までのAppSyncの利点をすべて活用できますが、必要なのはチャンネルを設定して使用するだけです。非常にシンプルなので、ここで一旦中断して、AppSync Eventsのクールな機能をMichaelにデモンストレーションしてもらいましょう。
私が仕事を楽しめる理由は、Solutions ArchitectでProject ManagerのBriceが要件を出してきて、「Michael、何かクールなものを作ってくれない？」と言うと、「はい、できますよ」と答えられるからです。このページにリストアップしているデモをいくつか見ていきましょう。まず1つ、私がChromeエクステンションを持っているのですが、これにre:invent/FWM 203というタイトルを付けています。スマートフォンを取り出してQRコードをスキャンしたい方は、re:invent/FWM 203と入力する必要があります。おお、すごい、もう動いていますね！まだ追いついていない方のために、もう一度言います - re:invent/FWM 203です。現時点では、GraphQLもAmazon API Gatewayも他の何も使わず、AppSync Eventsだけを使用しています。
これはWebSocketsで構築されているため、AppSync Eventsだけで実現できています。とてもクールですよね。私がやったことは、パブリッシャーを皆さんそれぞれのアプリケーションに配置しただけです。表示されているサイトは完全に異なるドメイン上にあり、WebSocketはChromeエクステンション内で動作していて、これらのイベントを拾って、すべてのアイテムをページに表示しています。
一般的なポーリングソリューションの場合、これは決して機能しません。50個のメッセージを表示して、0.5秒待って、さらにポーリングするというのは現実的ではありません。これこそがオークションサイトにおけるAppSync Eventsの素晴らしさです。残り5秒になって全員が最後の入札をしようとするまでは、すべて順調です。これは完璧なユースケースです。これは1つのクライアントが同時に大量のイベントを受信している例です。これはデモページですが、後で私に声をかけてコードを見たい方のために言っておくと、AppSyncのコードは20行程度です。もちろん、Chromeエクステンションなどは別途作成しましたが。
シンプルなチャットを見てきましたが、これはとてもクールですね。他のユースケースとして、リアルタイムのリーダーボードもあります。今は別のドメインにいるので、絵文字は表示されなくなっています。4つ並べというゲームをプレイしたことがある方もいると思います。ユーザー名を入力しますね。私のことを知らない方のために - オンラインではどこでもfocusotterという名前を使っています。新しいゲームコードを生成しましょう。新しいゲームを始めます。QRコードを読み取って参加したい方のために、少し時間を取りましょう。基本的に私対皆さんという、あまり公平ではない戦いになりますが。誰かMichaelに挑戦したい方はいますか？
しかし同時に、隣の人と競って自分のトークンを先に入れなければなりません。サイトとQRコードがありますので、ゲームを始めましょう。これにはAPIは必要ありません。良い面も悪い面もありますが、ページを更新すると、すべてが消えてしまいます。ただし、これは4目並べゲームなので、APIは必要ありません。すぐに終わるゲームです。ここでは、永続性が必要ないため、チャットアプリケーションを使用できます。「hate」と入力してくれた方、ありがとうございます。では、ゲームをプレイしましょう。今は私の番を待っています。では、始めましょう。プレイしていない方は観戦モードです。これこそがリアルタイムの真髄です。自分のゲームで皆さんに勝とうとしています。私の勝ちだと思います。
これが現在起きていることです。誰かが「New Game」をクリックすれば、私たち両方のボードがリセットされます。すべてがリアルタイムで起こっています。ページを更新することもできましたが、ここでAppSync Eventsの効果が見えますね。これは専用のAPIを必要としないリアルタイムデータです。では戻りましょう。素晴らしいデモがありましたね。拍手をお願いします。本当に素晴らしかったですね。まだプレゼンテーションは終わっていませんが、とても良いデモでした。AppSync Eventsは、このプロジェクトで機能しており、成果を上げています。私にとっても、AppSyncチームやすべてのエンジニアにとっても、素晴らしい冒険でした。
ご覧の通り、AppSync Eventsで私たちが本当に実現したかったことの1つは、シンプルさとスケーラビリティです。シンプルさについて話すと、私たちは人々が素早く始められることを望んでいます。今日すぐにAppSyncコンソールに行き、コンソールでボタンを1つクリックするだけでAPIを作成できます。これは、すぐにAppSyncコンソールで操作を開始できるAPIであり、数十万の接続ユーザーをすぐにサポートできるAPIです。始めるのは非常に簡単です。HTTPを介してチャネルにイベントを公開し、標準WebSocketを介してチャネルを購読できます。これはあらゆる規模で機能します。デフォルトのクォータについては数ページ後にお見せしますが、現在利用可能で、クォータの更新をリクエストすることなく、すでに1秒間に100万メッセージを公開できます。
AppSyncが利用可能な約30のリージョンすべてで利用可能で、カスタムドメイン、AWS WAF統合、CloudWatchログ、CloudWatchメトリクスがすぐに使えます。つまり、お気に入りのAWSサービスとの統合がすでに利用可能です。
これにより運用を削減できます。非常にシンプルで、細かい部分に気を取られる必要がありません。ビジネスロジックと顧客にとって最も重要なことに本当に集中できます。全体として、サービスを管理する必要がないためコストを削減できます。寛大なFree Tierがあるので、試してみたい場合はどうぞ。Free Tierでは月間25万回の操作を提供しており、その後は100万回のAPI操作あたり1ドルです。
AWS AppSyncをAIゲートウェイとして活用：Amazon Bedrockとの連携
AppSync Event APIの仕組みについて、もう少し詳しくご説明させていただきます。先ほど、HTTPでパブリッシュし、WebSocketでサブスクライブできるとお話ししましたが、AppSync Eventsで定義する主要な概念は「Namespace」です。Namespaceは、チャンネルの機能を定義する論理的なリソースです。具体的に説明しますと、例えばNamespace「A」があった場合、この「A」は、そのNamespace内で作成されるすべてのチャンネルのプレフィックスとなります。チャンネルは一時的なもので、必要に応じて作成できます。永続的なのはNamespaceの方です。例えば、「/A/ABC/DF/XYZ」というチャンネルパスがありますが、このチャンネルパスを事前に作成しておく必要はありません。必要に応じて、あなたやクライアントが作成できます。
Namespace内では、パブリッシュハンドラーを設定できます。パブリッシュ時にデータを変換する特定のカスタムロジックを作成したい場合は、AppSyncでそれが可能です。クライアントの接続時に適用したい特定の認可ルールを指定するためのアンサブスクライブハンドラーを作成することもできます。また、デフォルトのチャンネル認可をオーバーライドすることも可能です。デフォルトでは最大50個のNamespaceを作成できますが、1つのNamespace内では無制限のチャンネルを作成できることを覚えておいてください。
AppSyncをご利用の方はご存じかと思いますが、私たちは複数の認証モードをサポートしており、それらすべてがAppSync Eventsでもサポートされています：Amazon Cognito User Pools、API keys、AWS Lambda custom authorizer、OpenID Connect、そしてIAMです。これは素晴らしい特徴です。なぜなら、具体的な実装において、サポート方法を心配する必要がないからです。IAMは、Lambda関数でホストされているパブリッシャーや、EC2インスタンスからパブリッシュする場合に最適です。API keysは開発時に便利で、Amazon Cognito User Poolは、WebSocketに接続する各ユーザーを具体的に識別したい場合に最適です。
クォータと料金について、簡単にまとめますと次のようになります。アウトバウンドメッセージは1秒あたり100万件、インバウンドメッセージは1秒あたり1万件、新規接続は1秒あたり2,000件です。これらはデフォルトのクォータであり、すべて調整可能ですが、始めるには十分な規模だと考えています。ぜひAppSync Eventsを試してみてください。コンソールに入って、試してみて、コンソール上で直接Pub/Subエディタを使ってみてください。私たちが公開しているブログ - 私自身のブログやMichaelのブログもいくつかあります - をご覧ください。オンラインで簡単に見つけることができます。とても簡単に始められます。
ここで話題を変えて、Generative AIについてお話ししたいと思います。というのも、Generative AIについて触れないプレゼンテーションというのは、今や考えられないからです。 Generative AIは今やどこにでもあり、避けて通ることはできません。Generative AIとLLMには非常に大きな価値があり、私たちの実際の働き方を変えています。これはあらゆる場面で、そして私たちのお客様にとっても同じことが言えます。お客様はGenerative AIのメリットを実感しており、このチャンスを活かしたいと考えています。そこで、AWSに次のような質問をされています：「これは素晴らしい。これらのLLMや基盤モデルがありますが、どうやって始めればいいのでしょうか？何を使えばいいのでしょうか？どうすれば迅速に、かつセキュアに進められるのでしょうか？」
これこそが、AWSがAmazon Bedrockを作成した理由であり、私はこれが大きなゲームチェンジャーになったと考えています。複数のFoundation Modelと対話することができ、モデルのテストやコンソールでの作業、ガードレールの使用、モデルのカスタマイズなど、非常に多くの機能を提供しています。これは本当にFoundation Modelと対話する最適な方法だと言えます。
しかしながら、アプリケーションを構築する際に、お客様はまだいくつかの課題に直面しています。アプリケーションの接続について考えると、Webのどこかに存在するものをプライベートクラウド内のモデルに接続する必要があり、そこにはいくつかの解決すべき課題があります。
最初の課題は接続性です。 アプリケーションをバックエンドに接続する際には、クライアントに対するアクセス制御と、バックエンドでのモデルへのアクセス方法を適切に制御する必要があります。これは非常に重要で、フロントエンドとバックエンドを切り離せるようにしたいからです。絶対に避けたいのは、フロントエンドアプリケーションでバックエンドの認証情報が漏洩することです。Generative AIのバックエンドにアクセスするための認証情報をクライアントで使用することは避けるべきです。また、モデルとプロンプトをクライアントから分離する抽象化、つまりデカップリングを作成したいと考えています。
多くのお客様が苦心しているもう一つの点は、柔軟なリクエスト処理です。 Large Language Modelを使用した経験がある方なら、モデルが素早く応答を返すケースもありますが、多くの場合、応答を返すまでにかなりの時間がかかることをご存知でしょう。そのため、同期的な応答と非同期的なリクエストの両方に対応できるAPIが必要となります。さらに、応答に時間のかかるチャットボットの場合、多くのユーザーがそれほど長く集中力を保てないため、最適なカスタマーエクスペリエンスとは言えません。数秒以上応答に時間がかかると、ユーザーはページを離れがちです。ポーリングや不要なリクエストに頼ることなく、処理が正常に進んでいることをユーザーに即座にフィードバックできるよう、段階的な更新を提供できる必要があります。
もう一つの重要な側面は、モデルへのリクエストや呼び出しを行う際に、リクエスト元に関する文脈情報を提供できることです。つまり、誰がデータを要求しているのか、そのユーザーをどのように識別し、ユーザーに関連する応答を提供するためにプロンプトをどのように補強するかということです。 最後の課題は、柔軟なモデルの進化です。最初はあるモデルで始めますが、状況は急速に変化し、1、2週間おきや毎月のように新しいモデルが登場します。クライアントに影響を与えることなく、モデルを切り替えてプロンプトを進化させることができるようにAPIを構築したいと考えています。プロンプトをクライアントに公開せず、バックエンドに保持することで、クライアントに大きな障害や影響を与えることなく、それらのプロンプトを変更できるようにしたいのです。
これが、AWS AppSyncがAI Gatewayとして、特にAmazon Bedrockのバックエンドとして優れたソリューションだと考える理由です。Amazon Bedrockと安全に対話できる環境を提供し、長時間実行されるワークロードにリアルタイムソリューションを提供し、ユーザーモデルやユーザーアクセス、モデルアクセスの制御を維持できるからです。GraphQLの優れた機能を、モデルやLLMが提供する機能と組み合わせて活用することができます。
AppSyncについてはすでに説明しましたが、重要なポイントの1つはAppSyncが提供する認証モードです。アプリケーションを構築する際には、さまざまな認証モードを提供する必要がありますが、AppSyncではそれがすぐに利用できる状態で用意されているため、すでにその分離が実現されています。 AppSyncでは、複数の方法でBedrock データソースとやり取りすることができます。数週間前に導入したAmazon Bedrock データソースを使用して、今すぐBedrock と接続することができます。AWS Lambda関数をオーケストレーターとして使用し、Lambda関数にリクエストを送信してBedrock とやり取りすることもでき、これを使用して長時間実行される処理を実装することができます。また、HTTPエンドポイントデータソースを使用することもできます。多くの方がご存じないかもしれませんが、HTTP データソースと呼ばれるデータソースがあり、これを使用してAWSサービスAPIと通信することができます。リクエストの署名を代行してくれるため、非常に柔軟なコミュニケーションが可能です。AWSのあらゆるサービスと通信できるのです。
これにより、フロントエンドの認証をバックエンドの認証から切り離すことができます。ここで重要なのは、この方法で分離することができるだけでなく、AWS AppSyncがAmazon Bedrockと通信するための具体的な権限を設定できることです。Amazon Bedrockデータソースに対して、特定のモデル、特定のガードレール、または特定のプロンプトとのみ通信できるように権限を設定できます。これは非常に強力な機能で、APIがBedrockとどのように連携するかを管理することができます。
また、多くのお客様から見られる傾向として、 AI Gateway実装のサポートとしてAWS AppSync Private APIを使用しているということがあります。多くのエンタープライズのお客様が、現在LLMや生成AIの活用を始めていますが、そのソリューションを外部に公開したくないと考えています。基本的に内部APIを構築しているのですが、AWS AppSync Private APIを使用することで、これらすべてをVPC内でプライベートに保つことができます。Private APIを使用することで、APIをVPCに制限することができ、プライベートな導入に最適なソリューションとなります。
呼び出しについてもう少し詳しく見てみましょう。HTTPリゾルバーを使用してAmazon Bedrockモデルを呼び出すことができます。これは、レスポンスが30秒未満で返ってくることが分かっている場合に非常に簡単な方法です。 最新の機能として、AWS AppSyncでBedrock Runtimeデータソースを使用できる直接統合があります。これは、マイクロ呼び出し（10秒未満の呼び出し）と呼ばれる単純な統合に最適です。これが適している特定のユースケースがあります。より優れた制御が可能で、Invoke ModelとInvoke Model with ConversationのAPIと直接やり取りすることができます。
これを使った簡単な例をご紹介します。私のスキーマには、クエリとアシスタントクエリがあり、これによってバックエンドモデルに自然言語のクエリリクエストを送信し、実際のSQLクエリに変換するように依頼することができます。アシスタントにリクエストを送信する際、SQLの結果を返すように指示します。ここで定義されているSQLの結果には、SQL文字列、パラメータ、説明が含まれています。私が好むのは、このタイプをAWS JSONの形式にマッピングすることで、これがconverse APIで呼び出す際に使用できる形式となります。
これは私のJavaScriptリゾルバーで実行しているリクエストです。新しいconverseユーティリティを使用して、Bedrockランタイムと直接やり取りしています。これは他のAWS SDKでも見られる同じタイプの関数です。JavaScriptやPython SDKでconverse APIを使用したことがある方なら、全く同じものだとわかるでしょう。私はClaude 3.5 Haikuを使用しています。メッセージを送信し、ツール設定を指定し、そしてデータベースアシスタントとしてのシステムを指定します。説明を求めるか回答のみを求めるかに応じて、「回答を説明してください」または「回答を説明しないでください」と指示します。LLMと対話する際は、非常に具体的な指示を出す必要があります。
このリクエストを送信するとどのような結果が得られるでしょうか？例えば、「Las Vegasに出荷された商品の中で最も売れた商品は何ですか？回答を説明してください」というリクエストを送信します。converse APIを使用して形式を指定できたおかげで、要求した通りの正確な形式で結果が返ってきます。これはとても素晴らしいことです - 構造化された出力により、作業が楽になります。バックエンドAPIを構築する際には、 Amazon Titanのようなモデルと対話するためにinvoke model APIも使用できます。これを使って要約を行うことができます。同じようにinvoke model APIを使用して、 エンベディングを作成することもできます。
エンベディングは素晴らしい機能です。なぜなら、エンベディングを取得すれば、Amazon Auroraデータベースで類似性検索を行うことができるからです。Amazon Auroraと簡単に連携できることについては既にお話ししましたが、ここではBedrockへのリクエストから作成したエンベディングを使用して類似性検索を実行できます。最後に、これは同期パターンについてです。AWS AppSyncを使用して長時間実行の呼び出しを作成する方法をご紹介します。 クライアントがAWS AppSyncにリクエストを送信すると、AWS Lambda関数に非同期呼び出しが送信されます。これはLambda関数である必要はなく、AWS Step Functionsのようなサービスでも構いません。そしてこのLambda関数がBedrockのストリームAPIと対話し、BedrockのストリームAPIが段階的な更新を返すと、Lambda関数はAWS AppSyncを介してクライアントにミューテーションを送信し、それによってサブスクリプションがトリガーされます。
AppSync APIを使用するだけで、Bedrockで実行されている長時間実行クエリのリアルタイム更新を取得できます。これは重要なパターンです。re:Inventでは多くのセッションに参加されると思いますが、AppSyncを使用したこれらのパターンを目にすることになるでしょう。これは非常に重要です。なぜなら、多くのお客様がBedrockを使用した長時間実行クエリに対して、リアルタイム通知やリアルタイムパターンを実装できるようになっているからです。
AppSyncとAIの融合：リアルタイム翻訳と要約機能のデモ
それでは、さらにデモをお見せしましょう。Michael に代わって、実際の動作をご紹介させていただきます。先ほどの Emoji Thrower アプリケーションでは、Channel ID を指定する必要がありました。私が指定し、皆さんも指定する必要がありました。今は同期が取れているので、メッセージを双方向でやり取りできます。これはとても素晴らしいことです。そして、/reinvent/some-other-session のように変更することもでき、そこでもメッセージを配信できます。もちろん、そのチャンネルもサブスクライブしている必要があります。
しかし、Bree が説明していたように、長時間実行されるタスクや、最近のトレンドである Generative AI に移行する場合、アプリケーションに情報を戻すにはどうすればよいのでしょうか？Amazon Bedrock との直接統合がありますが、これについては後ほどお見せします。また、単純なユースケースもあります。例えば、アプリケーションで画像を Amazon S3 バケットに投げ込んで、Generative AI タスクを実行したい場合です。そのために AWS Lambda 関数を使用できますが、その結果をアプリケーションに戻すにはどうすればよいでしょうか？15秒や30秒のタイムアウトを超えるリアルタイムデータが必要な場合、これは意外と難しい課題です。Event API でどのように実現すればよいのでしょうか？
そこで、画期的なスタートアップ「SnapScribe」というデモをご紹介します。とてもシンプルです。 アプリケーションにサインインすると、 写真をアップロードでき、先ほどのアーキテクチャ図で示したとおりの処理が実行されます。写真を参照できます。先ほどお見せしたアーキテクチャの同じ画像を使ってみましょう。メッセージを受信しました。これは Lambda 関数からの最初の非同期イベントです。そして処理が完了すると、すぐに更新が表示されるはずです。 はい、表示されました。
拡大して見てみましょう。確かに、画像はアーキテクチャ図を示しています。これが素晴らしいのは、Lambda 関数で Generative AI タスクを実行できて、処理時間を気にする必要がないことです。なぜなら、最終的にはアプリケーションに結果が返されるからです。フロントエンドアプリケーションはポーリングではなく、リスニングしているだけです。これが SnapScribe ですが、さらに良いことがあります。これは長時間実行タスクの例です。コードを確認したい場合は、Bree が言っていたように、実際それほど難しくありません。これが私がアプリケーションを作成するために使用した正確なコードです。これは必要なロールです。 基本的に、ここでは Claude が Cross-Region 推論の多くの作業を行っています。
そして、データソースを接続する際には、CDK Level 1 Construct まで下がるだけです。ここに AppSync API があり、ここに Amazon Bedrock ランタイムがあります。これが重要な部分です。そして、ロールの ARN を渡して、新しいデータソースと関連付けます。複雑である必要はありませんし、過去にそうだったのは残念なことです。さて、ここで皆さんの助けが必要なデモがあります。 先ほどは15分かかる可能性のある長時間実行タスクでしたが、12秒以内に結果が必要な短時間タスクの場合はどうでしょうか？
最後のQRコードをお願いできればと思います。このアプリケーションでは、サインアップが必要になります。Amazon Cognitoで認証を行い、確認コードを受け取る間、私の説明を続けさせていただきます。きっと価値があるはずです。これはチャットアプリですね。最初のチャットアプリに戻ってきたような感じです。最初のチャットアプリでは、実際に参加することができませんでしたが、あまり面白くなかったですよね。今回のアプリはずっと優れています。ここでメッセージを入力してみましょう。私は英語とスペイン語を話します。この2つの言語が私の知っている言語です。残念ながら...いや、むしろ幸運なことに、私たちの世界には素晴らしい言語がたくさんあります。「hello, everyone. Welcome to re:Invent」と入力して、エンターを押してみましょう。すぐには表示されないことにお気づきかと思います - とても速いですが、即座ではありません。即座に表示されない理由は、AppSyncがPipeline Resolverを使用してBedrockのデータソースと通信し、そのデータソースがDynamoDBと通信してメッセージをデータベースに保存しているからです。
ありがとう、Ellis。
これができましたが、皆さんのことをよく知らないですし、中には他の言語の方が馴染みのある方もいらっしゃるかもしれません。ここで、スペイン語を話される方は、スペイン語に切り替えることができます。ここではデフォルト言語を英語に設定したままにしておきます。 はい、みなさん「Ola」「Cómo estás」と言っていますね。また、簡体字中国語もあります。イタリア語にも切り替えられます。そして、ここが重要なポイントですが、どの言語を入力しても対応できるようになっています。
ここでは複数のことが同時に起こっています。先ほど申し上げたように、これはクイックレディタスクです。いくつかの異なる処理を行っています。Cognitoで認証されており、サインインが必要でした。AppSyncはこれと直接連携しています。また、メッセージを送信するたびに翻訳が行われ、その翻訳を作成するために少し時間がかかります。そのメッセージは保存されます。しかし、Bedrockとの別の直接統合を使用して、ここで会話を要約することができます。これは少し怖いですね - この部分は初めて試してみます。これらのメッセージをすべて取り込んで...はい、できました。基本的に、ここにいる全員がre:Inventに参加しているということを示しています。re:Inventはテストです。これがBedrockのパワーです。
そのコードがどのようになっているか気になる方もいらっしゃるかもしれません。とても複雑です。複雑というのは、これが要約コードです。たった15行で、基本的にチャットの会話を取得して、100語以下で見たものを説明するように指示しているだけです。私のために要約してくださいと - 複雑である必要はありません。そして繰り返しになりますが、これはAppSyncが現在それだけ簡単にしてくれているからです。自分のテストで注意すべき点として - ここで小さなアスタリスクを付けておきますが - ジョブに適したモデルを使用することが非常に重要です。多くの人がAnthropicの優れたモデルを使用しています。なぜなら、それらは何でもできるからです。しかし、この場合、ご覧の通り、私はTitanを使用しています。特に要約に関しては、これまでに使用した中で最も優れたモデルだと思います。なぜなら、それに特化して訓練されているからです。
しかし、アプリケーションとしては - AppSyncが勝利です。みなさん、コメントありがとうございます。いいえ、Falconさん。ここには不適切な表現のフィルターはありません。ですが、素晴らしいのは、Guardrailを使ってそれを防ぐことができるということです。私が本当に気に入っているのは、Resolverでの統合において、Guardrail configを設定できることで、実際に多くの不適切な表現を処理してくれます。このデモではありませんが、実際の実装では、Guardrail configも併せて使用してください。
ご覧の通り、6つのデモがありました - リアルタイムAI、長時間実行タスク、短時間実行タスク、AppSync、GraphQL、GraphQLを使用しないAppSyncです。ここには多くのオプションがあります。そして、これは多くの開発者を支援する1つのサービスに過ぎません。結論を急ぎすぎるかもしれませんが、皆さんは「AppSyncがそんなことができるとは知らなかった」というような気づきを得られたのではないでしょうか。では、マイクに戻します。
AppSyncのセキュリティと運用機能：Merge APIとPrivate API
もう少しで終わりです。終わる前に最後にもう1つだけお話ししたいことがあります。セキュリティと運用の側面について少しお話ししたいと申し上げました。AppSync GraphQLイベントとAIゲートウェイとしてのAppSyncは素晴らしい機能ですが、私たちがこれらの優れた機能を提供し、お客様がそれらを活用できるのは、強化されたセキュリティと運用機能があってこそです。これは忘れてはならない重要な点です。AppSyncの導入を検討し、自社のアプリケーションや企業のために評価する際に知っておくべきことの1つは、AppSyncがセキュリティを重視して構築されているということです。私たちは多くの優れたセキュリティ機能を提供しており、それは提供している複数の認証モードや、相互作用の方法でもご覧いただきました。
例えば、データソースとの相互作用では、アクセスの許可、拒否、または権限の制限を設定できます。これらは、Private APIのサポート、クロスアカウント機能、Merged API機能を含むサービスを実装する際の基本的な考慮事項です。これは、アプリケーションの成長に必要な数多くの機能を使い始める最も簡単な方法であり、複数の開発者とアプリケーションを共有し、本番環境に移行するための機能です。私たちが提供する重要な機能の1つがMerge APIです。
Gartnerのこの引用を見てみましょう。彼らは2027年までに、GraphQLを使用する企業の30%がGraphQLフェデレーションを使用するようになると予測しています。これは2024年の5%未満から増加する見込みです。GraphQLフェデレーションは、複数のGraphQL APIを1つのAPIゲートウェイにまとめるという概念を具現化したものです。これは特に企業にとって魅力的です。なぜなら、フェデレーションによって、複数のチームが互いに干渉することなく、GraphQLスキーマの異なる部分を所有できるからです。各チームが独自のAPIとスキーマを所有し、これらのスキーマが1つのユニークなAPIゲートウェイとしてまとめられ、本番環境にデプロイすることができます。
フェデレーションに対する私たちのソリューションは、Merge APIです。このMerge API機能を使用すると、異なるチームや異なるアカウントが所有する複数のAppSync GraphQL APIをまとめて、1つのGraphQL APIとして統合することができます。これにより、各チームが独立して運用を続けながら、チーム間のコラボレーションが可能になります。GraphQL Merge APIはとてもシンプルです - 独自のスキーマを持ち、コンソールやAPIを使用してマージを作成できます。マージが成功したか、失敗したか、あるいは競合が発生したかを通知し、Directiveを使用してそれらのエラーを解決することができます。単一のAPIが大きくなり、複数のデータソースに接続することに懸念がある場合は、Merged APIを検討し、そのフェデレーションアプローチがビジネスの課題をどのように解決できるか確認してみてください。
最後にご紹介したい機能の1つがPrivate APIです。 これは、プライバシーを重視し、APIをプライベートに保ちたいエンタープライズのお客様に広く利用されている機能です。クロスアカウントのPrivate APIは、お客様から強く要望されていた機能でした。 お客様は中央アカウントでAPIを作成し、それを複数のアカウントで共有したいと考えていました。私たちは先日、re:Inventの直前に、AWS Resource Access Managerを活用してこの機能をリリースしました。これは、あるアカウントで作成したAPIを別のアカウントと共有できる標準的なAWSのアプローチを使用しています。典型的なユースケースは、監査やセキュリティ上の理由から、すべてのAPIを中央のAPIアカウントやネットワークアカウントから作成する必要がある組織です。現在はAppSyncでそれが可能になり、すべてのAppSync APIを単一のアカウントで作成し、Resource ManagerとAWS PrivateLinkを使用してアプリケーションアカウントと共有することができます。
イベントドリブンアーキテクチャに興味を持つ方々が多くいらっしゃいますが、私たちはこれを様々な方法でサポートしています。AppSyncをイベントドリブンアーキテクチャの一部として使用し、バックエンドがSubscriptionを使用してフロントエンドと通信することができます。例えば、Amazon EC2インスタンスがAmazon EventBridgeにメッセージをパブリッシュし、EventBridgeのAWSターゲットがそれをAppSyncに送信するという構成が可能です。フロントエンドからバックエンドへの同様の構成も可能で、先ほどModelsとAmazon Bedrockで見たように、Subscriptionを使用したフロントエンドからバックエンドへの非同期通信も実現できます。
そろそろ終わりの時間となりましたが、このプレゼンテーションが皆様にとって有意義で興味深いものであったことを願っています。私たちとお話ししたい方は、この後しばらくここに残っていますので、ぜひお声がけください。本日のセッションにご参加いただき、皆様とお話しできて本当に良かったです。ありがとうございました。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion