でのデータソースのアタッチ AWS AppSync

データソースは、GraphQL が操作APIsできる AWS アカウント内のリソースです。は、 AWS Lambda、Amazon DynamoDB、リレーショナルデータベース (Amazon Aurora Serverless)、Amazon OpenSearch Service、HTTPエンドポイントなどの多数のデータソース AWS AppSync をサポートします。は複数のデータソースとやり取りするように設定でき、データを 1 AWS AppSync APIか所に集約できます。 AWS AppSync は、アカウントから既存の AWS リソースを使用することも、スキーマ定義からユーザーに代わって DynamoDB テーブルをプロビジョニングすることもできます。

次のセクションでは、データソースを GraphQL にアタッチする方法を示しますAPI。

データソースのタイプ

AWS AppSync コンソールでスキーマを作成したら、データソースをアタッチできます。を最初に作成するときにAPI、事前定義されたスキーマの作成中に Amazon DynamoDB テーブルをプロビジョニングするオプションがあります。ただし、このセクションではそのオプションについては説明しません。この例については、「Launching a schema」セクションを参照してください。

代わりに、 AWS AppSync サポートされているすべてのデータソースを確認します。アプリケーションに適したソリューションを選ぶ要因は多数あります。以下のセクションでは、各データソースの追加のコンテキストについて説明します。データソースに関する一般的な情報については、「データソース」を参照してください。

Amazon DynamoDB

Amazon DynamoDB は、スケーラブルなアプリケーション向けののメインストレージソリューションの 1 AWSつです。DynamoDB のコアコンポーネントは テーブルで、これは単なるデータのコレクションです。通常テーブルは、Book や Author などのエンティティに基づいて作成されます。テーブルエントリの情報は、各エントリに固有のフィールドのグループであるアイテムとして保存されます。アイテム全体は、データベース内の 1 つの行またはレコードを表します。たとえば、Book エントリのアイテムにはその値とともに title と author が含まれる場合があります。title や author などの個々のフィールドは属性と呼ばれ、リレーショナルデータベースの列の値に似ています。

ご想像のとおり、テーブルはアプリケーションからのデータの保存に使用されます。 AWS AppSync を使用すると、DynamoDB テーブルを GraphQL に接続してデータをAPI操作できます。フロントエンドのウェブとモバイルのブログからこのユースケースを見てみましょう。このアプリケーションでは、ユーザーがソーシャルメディアアプリにサインアップできます。ユーザーはグループに参加して投稿をアップロードできます。この投稿は、そのグループに登録している他のユーザーにブロードキャストされます。ユーザーのアプリケーションは、ユーザー、投稿、ユーザーグループの情報を DynamoDB に保存します。GraphQL API ( によって管理 AWS AppSync) は DynamoDB テーブルとインターフェイスします。ユーザーがフロントエンドに反映されるシステムに変更を加えると、GraphQL はこれらの変更APIを取得し、リアルタイムで他のユーザーにブロードキャストします。

AWS Lambda

Lambda は、イベントへの応答としてコードを実行するために必要なリソースを自動的に構築するイベント駆動型サービスです。Lambda は、リソースを実行するためのコード、依存関係、設定を含むグループステートメントである関数を使用します。関数は、関数を呼び出すアクティビティのグループであるトリガーを検出すると自動的に実行されます。トリガーは、API呼び出しを行うアプリケーション、リソースをスピンアップするアカウントの AWS サービスなどです。トリガーされると、関数はイベント を処理します。これは、変更するデータを含むJSONドキュメントです。

Lambda は、コードを実行するためのリソースをプロビジョニングしなくてもコードを実行するのに適しています。フロントエンドのウェブとモバイルのブログからこのユースケースを見てみましょう。このユースケースは、DynamoDB セクションで紹介した内容と少し似ています。このアプリケーションでは、GraphQL APIが投稿の追加 (変更) やそのデータの取得 (クエリ) などの操作を定義する役割を担います。オペレーション (getPost ( id: String ! ) : Post、getPostsByAuthor ( author: String ! ) : [ Post ] など) の機能を実装するために、Lambda 関数が使用され、インバウンドリクエストが処理されます。オプション 2: Lambda リゾルバー AWS AppSync では、 AWS AppSync サービスを使用してスキーマを維持し、Lambda データソースをいずれかのオペレーションにリンクします。オペレーションが呼び出されると、Lambda は Amazon RDSプロキシとインターフェイスして、データベースでビジネスロジックを実行します。

Amazon RDS

Amazon RDS では、リレーショナルデータベースをすばやく構築および設定できます。Amazon ではRDS、クラウド内の分離されたデータベース環境として機能する汎用データベースインスタンスを作成します。この場合、実際のRDBMSソフトウェアである DB エンジン を使用します (Postgre SQL、My SQLなど）。このサービスは、の AWSインフラストラクチャを使用したスケーラビリティ、パッチ適用や暗号化などのセキュリティサービス、デプロイの管理コストの削減により、バックエンド作業の多くをオフロードします。

Lambda セクションの同じユースケースを見てみましょう。オプション 3: Amazon RDSリゾルバー AWS AppSync では、 APIの GraphQL を Amazon RDSに直接リンク AWS AppSync するオプションがあります。データを使用してAPI、データベースを GraphQL に関連付けますAPI。リゾルバーはフィールド (通常はクエリ、ミューテーション、サブスクリプション) にアタッチされ、データベースへのアクセスに必要なSQLステートメントを実装します。クライアントによってフィールドを呼び出すリクエストが行われると、リゾルバーはステートメントを実行してレスポンスを返します。

Amazon EventBridge

では EventBridge、イベントバス を作成します。これは、アタッチしたサービスまたはアプリケーション (イベントソース ) からイベントを受信し、一連のルールに基づいてイベントバスを処理するパイプラインです。イベントは実行環境における一種の状態の変化であり、ルールはイベントのフィルタのセットです。ルールは、イベントパターン 、またはイベントの状態変更のメタデータ (ID、リージョン、アカウント番号、ARN(s) など) に従います。イベントがイベントパターンと一致すると、 EventBridge はパイプライン全体でイベントを送信先サービス (ターゲット ) に送信し、ルールで指定されたアクションをトリガーします。

EventBridge は、状態変更オペレーションを他のサービスにルーティングするのに適しています。フロントエンドのウェブとモバイルのブログからこのユースケースを見てみましょう。この例は、異なるサービスを複数のチームで管理している e コマースソリューションを示しています。これらのサービスの 1 つは、フロントエンドの配送の各ステップ (注文済み、進行中、出荷済み、配送済みなど) で顧客に注文の更新情報を提供します。ただし、このサービスを管理するフロントエンドチームは、別のバックエンドチームによって管理されている注文システムデータに直接アクセスすることはできません。バックエンドチームの注文システムはブラックボックスとも呼ばれており、データの構造化に関する情報を収集するのは困難です。ただし、バックエンドチームは、が管理するイベントバスを介して注文データを公開するシステムを設定しました EventBridge。イベントバスからのデータにアクセスしてフロントエンドにルーティングするために、フロントエンドチームは APIにある GraphQL を指す新しいターゲットを作成しました AWS AppSync。また、注文の更新情報に関連するデータのみを送信するルールも作成しました。更新が行われると、イベントバスからのデータが GraphQL に送信されますAPI。のスキーマはデータAPIを処理し、フロントエンドに渡します。

none データソース

データソースを使用する予定がない場合は、データソースを none に設定します。none データソースは、設定後も明示的にデータソースとして分類されますが、ストレージメディアではありません。通常、リゾルバーはある時点で 1 つ以上のデータソースを呼び出してリクエストを処理します。ただし、データソースを操作する必要がない場合もあります。データソースを none に設定すると、リクエストが実行され、データ呼び出しステップはスキップされて、レスポンスが実行されます。

EventBridge セクションから同じユースケースを取ります。スキーマでは、ミューテーションによりステータスの更新が処理されて、サブスクライバーに送信されます。リゾルバーの仕組み上、通常は少なくとも 1 つのデータソース呼び出しがあります。ただし、このシナリオのデータは既にイベントバスによって自動的に送信されています。つまり、ミューテーションによりデータソース呼び出しが実行される必要はなく、注文状況はローカルで処理するだけで済みます。ミューテーションは none に設定され、パススルー値として機能し、データソースは呼び出されません。その後、スキーマにデータが入力され、サブスクライバーに送信されます。

OpenSearch

Amazon OpenSearch Service は、全文検索、データ視覚化、ログ記録を実装するためのツールのスイートです。このサービスを使用すると、アップロードした構造化データをクエリできます。

このサービスでは、のインスタンスを作成します OpenSearch。これらはノードと呼ばれます。ノードには、少なくとも 1 つのインデックスを追加します。概念的には、インデックスはリレーショナルデータベースのテーブルに少し似ています（ただし、 OpenSearch はACID準拠していないため、その方法では使用しないでください）。 OpenSearch サービスにアップロードしたデータをインデックスに入力します。データがアップロードされると、インデックス内に存在する 1 つ以上のシャードにインデックスが作成されます。シャードは、データの一部を含むインデックスのパーティションのようなもので、他のシャードと別にクエリできます。アップロードされると、データはドキュメント と呼ばれるJSONファイルとして構造化されます。その後、ノードに対してドキュメント内のデータをクエリできます。

HTTP エンドポイント

HTTP エンドポイントはデータソースとして使用できます。は、パラメータやペイロードなどの関連情報を含むリクエストをエンドポイントに送信 AWS AppSync できます。HTTP レスポンスはリゾルバーに公開され、オペレーションが終了した後に最終的なレスポンスが返されます (複数可）。

データソースを追加する

データソースを作成した場合は、そのデータソースを AWS AppSync サービス、より具体的にはにリンクできますAPI。

Console

にサインイン AWS Management Console し、AppSyncコンソールを開きます。
1. ダッシュボード APIでを選択します。
2. サイドバー で [データソース] を選択します。
[データソースを作成] を選択します。
1. データソースに名前を付けます。説明を付けることもできますが、これは任意です。
2. [データソースタイプ] を選択します。
3. DynamoDB の場合は、リージョンを選択してから、リージョンのテーブルを選択する必要があります。新しい汎用テーブルロールを作成するか、テーブルの既存のロールをインポートするかを選択することで、テーブルとのインタラクションルールを設定できます。バージョニングを有効にすると、複数のクライアントが同時にデータの更新を試行したとき、リクエストごとにデータのバージョンが自動的に作成されます。バージョニングは、競合の検出と解決を目的に、データの複数のバリアントを保持および管理するために使用されます。また、自動スキーマ生成を有効にすることもできます。これにより、データソースを取得しCRUD、スキーマ内のデータソースへのアクセスに必要な、List、および Queryオペレーションの一部が生成されます。
  
  では OpenSearch、リージョンを選択し、次にリージョンのドメイン (クラスター) を選択する必要があります。新しい汎用テーブルロールを作成するか、テーブルの既存のロールをインポートするかを選択することで、ドメインとのインタラクションルールを設定できます。
  
  Lambda の場合は、リージョンを選択し、次にリージョン内の Lambda 関数ARNのを選択する必要があります。新しい汎用テーブルロールを作成するか、テーブルの既存のロールをインポートするかを選択することで、Lambda 関数とのインタラクションルールを設定できます。
  
  にはHTTP、HTTPエンドポイントを入力する必要があります。
  
  では EventBridge、リージョンを選択し、次にリージョンのイベントバスを選択する必要があります。新しい汎用テーブルロールを作成するか、テーブルの既存のロールをインポートするかを選択することで、イベントバスとのインタラクションルールを設定できます。
  
  ではRDS、リージョン、シークレットストア (ユーザー名とパスワード）、データベース名、スキーマを選択する必要があります。
  
  None の場合は、実際のデータソースがないデータソースを追加します。これは、リゾルバーを実際のデータソースではなくローカルで処理するためのものです。
  
  注記
  既存のロールをインポートする場合は、信頼ポリシーが必要です。詳細については、IAM「信頼ポリシー」を参照してください。
[Create] (作成) を選択します。

注記
または、DynamoDB データソースを作成する場合は、コンソールの [スキーマ] ページに移動し、ページ上部の [リソースの作成] を選択してから、定義済みのモデルを入力してテーブルに変換することもできます。このオプションでは、基本型を入力またはインポートし、パーティションキーを含む基本的なテーブルデータを設定して、スキーマの変更を確認します。

CLI

create-data-source コマンドを実行してデータソースを作成します。

この特定のコマンドでは、いくつかのパラメータを入力する必要があります。
1. api-id の API。
2. テーブルの name。
3. データソースの type。選択したデータソースタイプに応じて、service-role-arn と -config タグの入力が必要になる場合があります。
コマンドの例は、次のようになります。
```
 aws appsync create-data-source --api-id abcdefghijklmnopqrstuvwxyz --name data_source_name --type data_source_type --service-role-arn arn:aws:iam::107289374856:role/role_name --[data_source_type]-config {params}
```

CDK

ヒント

を使用する前にCDK、の公式ドキュメントと CDK AWS AppSyncのCDKリファレンスを確認することをお勧めします。

以下の手順では、特定のリソースを追加するために使用するスニペットの一般的な例のみを示しています。これは本番稼働用コードで機能するソリューションとなることを意図したものではありません。また、動作するアプリが既にあることを前提としています。

特定のデータソースを追加するには、コンストラクトをスタックファイルに追加する必要があります。データソースタイプのリストは次のとおりです。

一般的には、使用しているサービスにインポートディレクティブを追加しなければならない場合があります。たとえば、次の形式に従います。
```
import * as x from 'x'; # import wildcard as the 'x' keyword from 'x-service'
import {a, b, ...} from 'c'; # import {specific constructs} from 'c-service'
```
例えば、 AWS AppSync および DynamoDB サービスをインポートする方法は次のとおりです。
```
import * as appsync from 'aws-cdk-lib/aws-appsync';
import * as dynamodb from 'aws-cdk-lib/aws-dynamodb';
```
などの一部のサービスでは、データソースを作成する前にスタックファイルに追加のセットアップRDSが必要です (VPC作成、ロール、アクセス認証情報など）。詳細については、関連CDKページの例を参照してください。
ほとんどのデータソース、特に AWS のサービスでは、スタックファイルにデータソースの新しいインスタンスを作成します。通常、結果は以下のようになります。
```
const add_data_source_func = new service_scope.resource_name(scope: Construct, id: string, props: data_source_props);
```
その例として、Amazon DynamoDB テーブルの例を次に示します。
```
const add_ddb_table = new dynamodb.Table(this, 'Table_ID', {
  partitionKey: {
    name: 'id',
    type: dynamodb.AttributeType.STRING,
  },
  sortKey: {
    name: 'id',
    type: dynamodb.AttributeType.STRING,
  },
  tableClass: dynamodb.TableClass.STANDARD,
});
```
注記
ほとんどのデータソースには、少なくとも 1 つの必須の props が含まれます (? 記号を使用しないで表記します)。CDK ドキュメントを参照して、どのprops が必要かを確認してください。
次に、データソースを GraphQL にリンクする必要がありますAPI。おすすめの方法は、パイプラインリゾルバーの関数を作成するときに追加することです。たとえば、以下のスニペットは DynamoDB テーブルのすべての要素をスキャンする関数です。
```
const add_func = new appsync.AppsyncFunction(this, 'func_ID', {
  name: 'func_name_in_console',
  add_api,
  dataSource: add_api.addDynamoDbDataSource('data_source_name_in_console', add_ddb_table),
  code: appsync.Code.fromInline(`
      export function request(ctx) {
        return { operation: 'Scan' };
      }

      export function response(ctx) {
        return ctx.result.items;
      }
  `),
  runtime: appsync.FunctionRuntime.JS_1_0_0,
});
```
dataSource props では、GraphQL API (add_api) を呼び出し、その組み込みメソッド (addDynamoDbDataSource) のいずれかを使用して、テーブルと GraphQL を関連付けることができますAPI。引数は、 AWS AppSync コンソール (data_source_name_in_consoleこの例では ) とテーブルメソッド () に存在するこのリンクの名前ですadd_ddb_table。このトピックの詳細は、リゾルバーの作成を開始する次のセクションで明らかになります。

データソースをリンクする方法は他にもあります。技術的には、テーブル関数の props リストに api を追加することもできます。例えば、ステップ 3 のスニペットですが、GraphQL api を含む props がありますAPI。
```
const add_api = new appsync.GraphqlApi(this, 'API_ID', {
  ...
});

const add_ddb_table = new dynamodb.Table(this, 'Table_ID', {

 ...

  api: add_api
});
```
または、GraphqlApi コンストラクトを個別に呼び出すこともできます。
```
const add_api = new appsync.GraphqlApi(this, 'API_ID', {
  ...
});

const add_ddb_table = new dynamodb.Table(this, 'Table_ID', {
  ...
});

const link_data_source = add_api.addDynamoDbDataSource('data_source_name_in_console', add_ddb_table);
```
アソシエーションは関数の props でのみ作成することをおすすめします。それ以外の場合は、 AWS AppSync コンソールでリゾルバー関数をデータソースに手動でリンクするか (コンソール値を使用し続ける場合data_source_name_in_console）、のような別の名前で関数に別の関連付けを作成する必要がありますdata_source_name_in_console_2。これは、props による情報処理の方法に制限があるためです。

注記
変更を確認するには、アプリを再デプロイする必要があります。

IAM 信頼ポリシー

データソースに既存のIAMロールを使用している場合は、Amazon DynamoDB テーブルなど、 AWS リソースでオペレーションを実行するための適切なアクセス許可をそのロールPutItemに付与する必要があります。また、次のポリシー例に示すように、がそのロールの信頼ポリシー AWS AppSync をリソースアクセスに使用するように変更する必要があります。


{
    "Version": "2012-10-17",
    "Statement": [
        {
        "Effect": "Allow",
        "Principal": {
            "Service": "appsync.amazonaws.com"
        },
        "Action": "sts:AssumeRole"
        }
    ]
}

また、信頼ポリシーに条件を追加して、必要に応じてデータソースへのアクセスを制限することもできます。現在、SourceArnおよびSourceAccountキーはこれらの条件で使用できます。たとえば、次のポリシーでは、データソースへのアクセスを123456789012 アカウントに制限しています。


{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "appsync.amazonaws.com"
      },
      "Action": "sts:AssumeRole",
      "Condition": {
        "StringEquals": {
          "aws:SourceAccount": "123456789012"
        }
      }
    }
  ]
}

または、次のポリシーabcdefghijklmnopqを使用してAPI、データソースへのアクセスをなどの特定のに制限することもできます。


{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "appsync.amazonaws.com"
      },
      "Action": "sts:AssumeRole",
      "Condition": {
        "ArnEquals": {
          "aws:SourceArn": "arn:aws:appsync:us-west-2:123456789012:apis/abcdefghijklmnopq"
        }
      }
    }
  ]
}

次のポリシーus-east-1を使用して、などの特定のリージョンからのすべての AWS AppSync APIs へのアクセスを制限できます。


{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "appsync.amazonaws.com"
      },
      "Action": "sts:AssumeRole",
      "Condition": {
        "ArnEquals": {
          "aws:SourceArn": "arn:aws:appsync:us-east-1:123456789012:apis/*"
        }
      }
    }
  ]
}

次のセクション (「リゾルバーの設定」) では、リゾルバーのビジネスロジックを追加し、スキーマのフィールドにアタッチして、データソースのデータを処理します。

ロールポリシー設定の詳細については、「ユーザーガイド」の「ロールの変更IAM」を参照してください。

のリ AWS Lambda ゾルバーのクロスアカウントアクセスの詳細については AWS AppSync、「のクロスアカウント AWS Lambda リゾルバーの構築 AWS AppSync」を参照してください。

ブラウザで JavaScript が無効になっているか、使用できません。

AWS ドキュメントを使用するには、JavaScript を有効にする必要があります。手順については、使用するブラウザのヘルプページを参照してください。

ドキュメントの表記規則

GraphQL スキーマの設計

リ AWS AppSync ゾルバーの設定