【AWS DevDay Tokyo 2019 セッションレポート】AppSync ユースケース/デザインパターン #AWSDevDay

2019.10.04

AWS DevDay Tokyo 2019のセッション、「AppSync ユースケース/デザインパターン」をレポートします。

セッション概要

GraphQLのマネージドサービスであるAppSyncについて、実際の利用シーンでは認証でCognitoとの連携、管理者と一般ユーザで利用可能なGraphQL APIを分けたい、Deplyを自動化したい、複数DataSourceを組合せる必要性、複数Mutationを実行した結果をSubscriptionに繋げたい等、AppSync内での設計に加え、他AWSサービスと組合せ設計し利用する事が多くあります。本セッションでは各ユースケース単位にどの様にAppSyncを設計し他AWSサービスと組合せ実現するかについてのデザインパターンをご紹介します。

スピーカー

アマゾン ウェブ サービス ジャパン株式会社
ソリューションアーキテクト

布村 純也さん

セッション内容

突然ですが去年のDEV DAYと同じ質問を

  • GraphQL知ってる?
  • GraphQL開発経験?
  • AppSync利用経験?
  • →思ったより利用者少なかった、、

GraphQLについて

  • QUERY言語
  • OSS
  • 定義に従ってQUERYをかきサーバーからJSON取得
  • 処理形態は {Query:取得, Mutation:変更, Subscription:購読}

スキーマ定義

  • スカラー型、オブジェクト型、列挙型などを利用可能
  • Not Nullは感嘆符表現
  • リストは角カッコで表現

クライアントがレスポンス形式を指定

  • モデルデータを定義
  • クライアントが必要なものだけをリクエスト
  • リクエストしたデータだけが返される

GraphQL定義

  • Schema
    • Typeとそれに紐づく要素を定義
  • Query 取得
  • Mutation 変更
    • 追加/更新/削除をまとめたもの
  • Subscription 購入
    • Mutationの実行をトリガーとして実行されるもの

API Interface

RESTとGraphQLを比較

  • REST API
    • 各エンドポイントごとにAPI
  • GraphQL
    • エンドポイントは常に一つ

AppSync

GraphQLマネージドサービス

すぐにGraphQLの利用を始められる

特徴

  • マネージドサービス
  • アカウントのDataSourceに接続
  • データ同期、リアルタイム、オフライン機能
  • GraphQLファサード
  • 競合の検出と解決
  • セキュリティ
    • API Key、IAM、Cognito、OIDC

コンセプト

  • AWS App Sync Client
    • 認証、オフラインロジックなどを含んだクライアント
  • Resolver
    • リクエスト・レスポンス処理を記述する関数
  • Data Source
    • DynamoDB
    • Lambda
    • Aurora Serverless
    • ElasticSearch
    • HTTP Endpoint

利用ケース

  • リアルタイム
    • ダッシュボード
    • ほぼリアルタイムなデータ更新
  • コラボレーション
    • 複数ユーザーが共同編集
    • 様々なコンテンツタイプを自動更新
  • ソーシャルメディア
    • ソーシャルメディアやチャット
    • 複数ユーザー間でのメッセージング管理をサポート
    • オフライン時でもアプリケーションを操作でき、再接続時に自動Sync

AppSync アーキテクチャ

  • AppSync
  • CloudWatchでロギング
  • データソースは前述の5つ+local
  • クライアント
    • エンタープライズ
    • Webアプリ
    • モバイル
    • IoT
    • →クライアントを選ばない
  • SchemaはAppSyncで管理
  • ResolverはAppSyncとデータソースの間
    • 実処理記載する場所

Resolver Mapping Templateで実施する例

  • アクセスコントロール
  • 新規アイテムのデフォルト値
  • 入力のバリデーション、フォーマット

二種類ある

  • Request
  • Response

Resolver Mapping Templateコード例

VTL(Velocity Template Language)で記載

ユースケース・デザインパターン

データソースとしてDynamoDBを利用したい

  • データソースとしてのDynamoDBは鉄板
  • ジェネレートの機能の利用
    • No-Code GraphQL APIBuilder
      • AppSyncスキーマを先に定義→DynamoDBテーブル自動作成
    • Schemaジェネレート
      • 逆パターン
    • 日本だとSchemaジェネレートが多い、海外は逆

データソースにElasticSearch

  • DynamoDBと組み合わせ
  • データ登録はDynamoDBへ→DynamoDB StreamでESに反映
  • キーワード検索などはES参照

既存APIまたは他SaaS APIとの連携

データソース Lambda + HTTP Endpointで実現

  • Lambdaを挟み外部APIの結果をGraphQLResponseに変換

関連する複数処理を一つにまとめたい

  • Unit Resolver
    • 1処理単位で実行することは可能
    • Req/Resが三回発生するのでお勧めできない
  • データソースにLambdaを選択
    • 1Lambdaで連続複数処理を書いてるので再利用しにくい
  • Pipeline Resolverの利用
    • 1 Resolverとして実行される
    • 複数Functionを入れることができる
    • Function間でデータ引継ぎ可能
    • 劇的にアーキテクチャが変わる

GraphAPIのVersion管理

  • Versionless API を推奨
  • 影響を抑えつつ新しいタイプやフィールドの追加が可能

Subscriptionのフィルタリング

  • 対象者を絞ってSubscription受信したい
  • Subscription引数を使用し実現可能

Subscriptionの接続(実行)認可

  • Subscription引数 + DataSource Noneをアタッチ

スキーマフィールドの認証タイプを使い分けたい

  • 開発、ステージング、本番、、環境ごとに認証タイプを使い分けたい
  • Multi-Auth
    • 環境による認証方式使い分けや、複数認証プロバイダを利用することが可能

管理者にだけ叩けるAPI

  • Cognito ユーザープール
    • グループごとに実行権限を制御

パフォーマンス、状態の可視化

  • CloudWatch Insightsへの連携
  • 自動可視化
  • ElasticSearchへの連携

VTL記述例

  • Key,Set 取得・変換
  • DynamoDB TTL設定
  • 日付取得
  • 資料公開されたら参考にしてください

まとめ

  • バックグラウンドのResolver,DataSourceの組み合わせはかなり自由、反面煩雑になりがち
  • ユースケース・デザインパターンをしっかり理解しよう

感想

AppSyncもGraphQLも利用経験がないので後半はついていくのに必死でしたが、前半で概要を掴めて良かったです。ハマるワークロードには積極的に使っていきたいです!