翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# AWS AppSync でのデータソースのアタッチ
データソースは、GraphQL APIsできる AWS アカウントのリソースです。 AWS AppSync は、Amazon DynamoDB AWS Lambda、リレーショナルデータベース (Amazon Aurora Serverless)、Amazon OpenSearch Service、HTTP エンドポイントなどの多数のデータソースをサポートしています。 AWS AppSync API は、複数のデータソースとやり取りするように設定できるため、データを 1 つの場所に集約できます。 AWS AppSync は、アカウントから既存の AWS リソースを使用するか、スキーマ定義からユーザーに代わって DynamoDB テーブルをプロビジョニングできます。
次のセクションでは、GraphQL API にデータソースをアタッチする方法について説明します。
## データソースのタイプ
AWS AppSync コンソールでスキーマを作成したら、それにデータソースをアタッチできます。API を初めて作成する場合、定義済みスキーマの作成中に Amazon DynamoDB テーブルをプロビジョニングするオプションがあります。ただし、このセクションではそのオプションについては説明しません。この例については、「[Launching a schema](https://docs.aws.amazon.com//appsync/latest/devguide/schema-launch-start.html)」セクションを参照してください。
代わりに、 AWS AppSync がサポートするすべてのデータソースを確認します。アプリケーションに適したソリューションを選ぶ要因は多数あります。以下のセクションでは、各データソースの追加のコンテキストについて説明します。データソースに関する一般的な情報については、「[データソース](https://docs.aws.amazon.com/appsync/latest/devguide/data-source-components.html)」を参照してください。
### Amazon DynamoDB
Amazon DynamoDB は、スケーラブルなアプリケーション向けの主要なストレージソリューションの 1 AWSつです。DynamoDB のコアコンポーネントは **テーブル**で、これは単なるデータのコレクションです。通常テーブルは、`Book` や `Author` などのエンティティに基づいて作成されます。テーブルエントリの情報は、各エントリに固有のフィールドのグループである**アイテム**として保存されます。アイテム全体は、データベース内の 1 つの行またはレコードを表します。たとえば、`Book` エントリのアイテムにはその値とともに `title` と `author` が含まれる場合があります。`title` や `author` などの個々のフィールドは**属性**と呼ばれ、リレーショナルデータベースの列の値に似ています。
ご想像のとおり、テーブルはアプリケーションからのデータの保存に使用されます。 AWS AppSync を使用すると、DynamoDB テーブルを GraphQL API に接続してデータを操作できます。**フロントエンドのウェブとモバイルのブログからこの[ユースケース](https://aws.amazon.com/blogs/mobile/new-real-time-multi-group-app-with-aws-amplify-graphql-build-a-twitter-community-clone/)を見てみましょう。このアプリケーションでは、ユーザーがソーシャルメディアアプリにサインアップできます。ユーザーはグループに参加して投稿をアップロードできます。この投稿は、そのグループに登録している他のユーザーにブロードキャストされます。ユーザーのアプリケーションは、ユーザー、投稿、ユーザーグループの情報を DynamoDB に保存します。GraphQL API ( によって管理 AWS AppSync) は DynamoDB テーブルとインターフェイスします。フロントエンドに反映される変更をユーザーがシステムで行うと、GraphQL API はその変更を取得し、リアルタイムで他のユーザーにブロードキャストします。
### AWS Lambda
Lambda は、イベントへの応答としてコードを実行するために必要なリソースを自動的に構築するイベント駆動型サービスです。Lambda は、リソースを実行するためのコード、依存関係、設定を含むグループステートメントである**関数**を使用します。関数は、関数を呼び出すアクティビティのグループである**トリガー**を検出すると自動的に実行されます。トリガーは、API コールを行うアプリケーション、リソースをスピンアップするアカウントの AWS サービスなどです。トリガーされると、関数は、変更するデータを含む JSON ドキュメントである**イベント**を処理します。
Lambda は、コードを実行するためのリソースをプロビジョニングしなくてもコードを実行するのに適しています。**フロントエンドのウェブとモバイルのブログからこの[ユースケース](https://aws.amazon.com/blogs/mobile/building-a-graphql-api-with-java-and-aws-lambda/)を見てみましょう。このユースケースは、DynamoDB セクションで紹介した内容と少し似ています。このアプリケーションでは、GraphQL API により投稿の追加 (ミューテーション) やそのデータの取得 (クエリ) などのオペレーションが定義されます。オペレーション (`getPost ( id: String ! ) : Post`、`getPostsByAuthor ( author: String ! ) : [ Post ]` など) の機能を実装するために、Lambda 関数が使用され、インバウンドリクエストが処理されます。*オプション 2: Lambda リゾルバー AWS AppSync では*、 AWS AppSync サービスを使用してスキーマを維持し、Lambda データソースをオペレーションの 1 つにリンクします。オペレーションが呼び出されると、Lambda は Amazon RDS Proxy とやり取りして、データベース上でビジネスロジックを実行します。
### Amazon RDS
Amazon RDS では、リレーショナルデータベースを迅速に構築して設定できます。Amazon RDS では、クラウド内の隔離されたデータベース環境として機能する汎用**データベースインスタンス**を作成します。このインスタンスでは、実際の RDBMS ソフトウェア (PostgreSQL、MySQL など) である **DB エンジン**を使用します。このサービスは、 AWSインフラストラクチャを使用したスケーラビリティ、パッチ適用や暗号化などのセキュリティサービスを提供し、デプロイの管理コストを削減することで、バックエンド作業の多くをオフロードします。
Lambda セクションの同じ[ユースケース](https://aws.amazon.com/blogs/mobile/building-a-graphql-api-with-java-and-aws-lambda/)を見てみましょう。*オプション 3:Amazon RDS リゾルバー AWS AppSync では*、 の GraphQL API を Amazon RDS に直接リンク AWS AppSync する別のオプションがあります。このオプションでは、[データ API](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/data-api.html) を使用して、データベースが GraphQL API に関連付けられます。リゾルバーはフィールド (通常はクエリ、ミューテーション、サブスクリプション) にアタッチされ、データベースへのアクセスに必要な SQL ステートメントを実装します。クライアントによってフィールドを呼び出すリクエストが行われると、リゾルバーはステートメントを実行してレスポンスを返します。
### Amazon EventBridge
EventBridge では、アタッチするサービスまたはアプリケーション (**イベントソース**) からイベントを受信し、一連のルールに基づいて処理するパイプラインである**イベントバス**を作成します。**イベント**は実行環境における一種の状態の変化であり、**ルール**はイベントのフィルタのセットです。ルールは、**イベントパターン**、すなわちイベントの状態変化のメタデータ (ID、リージョン、アカウント番号、ARN など) に従います。イベントがイベントパターンと一致すると、EventBridge はパイプラインを介して送信先サービス (**ターゲット**) にイベントを送信し、ルールで指定されたアクションをトリガーします。
EventBridge は、状態が変化するオペレーションを他のサービスにルーティングするのに適しています。**フロントエンドのウェブとモバイルのブログからこの[ユースケース](https://aws.amazon.com/blogs/mobile/appsync-eventbridge/)を見てみましょう。この例は、異なるサービスを複数のチームで管理している e コマースソリューションを示しています。これらのサービスの 1 つは、フロントエンドの配送の各ステップ (注文済み、進行中、出荷済み、配送済みなど) で顧客に注文の更新情報を提供します。ただし、このサービスを管理するフロントエンドチームは、別のバックエンドチームによって管理されている注文システムデータに直接アクセスすることはできません。バックエンドチームの注文システムはブラックボックスとも呼ばれており、データの構造化に関する情報を収集するのは困難です。しかし、バックエンドチームは、EventBridge によって管理されるイベントバスを通じて、注文データを発行したシステムをセットアップしました。イベントバスからのデータにアクセスしてフロントエンドにルーティングするために、フロントエンドチームは GraphQL API をポイントする新しいターゲットを作成しました AWS AppSync。また、注文の更新情報に関連するデータのみを送信するルールも作成しました。更新が行われると、イベントバスからのデータが GraphQL API に送信されます。API のスキーマによってデータが処理され、フロントエンドに渡されます。
### none データソース
データソースを使用する予定がない場合は、データソースを `none` に設定します。`none` データソースは、設定後も明示的にデータソースとして分類されますが、ストレージメディアではありません。通常、リゾルバーはある時点で 1 つ以上のデータソースを呼び出してリクエストを処理します。ただし、データソースを操作する必要がない場合もあります。データソースを `none` に設定すると、リクエストが実行され、データ呼び出しステップはスキップされて、レスポンスが実行されます。
EventBridge セクションの同じ[ユースケース](https://aws.amazon.com/blogs/mobile/appsync-eventbridge/)を見てみましょう。スキーマでは、ミューテーションによりステータスの更新が処理されて、サブスクライバーに送信されます。リゾルバーの仕組み上、通常は少なくとも 1 つのデータソース呼び出しがあります。ただし、このシナリオのデータは既にイベントバスによって自動的に送信されています。つまり、ミューテーションによりデータソース呼び出しが実行される必要はなく、注文状況はローカルで処理するだけで済みます。ミューテーションは `none` に設定され、パススルー値として機能し、データソースは呼び出されません。その後、スキーマにデータが入力され、サブスクライバーに送信されます。
### OpenSearch
Amazon OpenSearch Service は、全文検索、データ視覚化、ロギングを実装するためのツールスイートです。このサービスを使用すると、アップロードした構造化データをクエリできます。
このサービスでは、OpenSearch のインスタンスを作成します。これらは**ノード**と呼ばれます。ノードには、少なくとも 1 つの**インデックス**を追加します。概念的には、インデックスはリレーショナルデータベースのテーブルに少し似ています (ただし、OpenSearch は ACID に準拠していないため、同じようには使用できません)。OpenSearch サービスにアップロードするデータをインデックスに入力します。データがアップロードされると、インデックス内に存在する 1 つ以上のシャードにインデックスが作成されます。**シャード**は、データの一部を含むインデックスのパーティションのようなもので、他のシャードと別にクエリできます。アップロードされたデータは、**ドキュメント**と呼ばれる JSON ファイルとして構造化されます。その後、ノードに対してドキュメント内のデータをクエリできます。
### HTTP エンドポイント
HTTP エンドポイントをデータソースとして使用できます。 AWS AppSync は、パラメータやペイロードなどの関連情報を含むリクエストをエンドポイントに送信できます。HTTP レスポンスはリゾルバーに公開され、リゾルバーはオペレーション終了後に最終レスポンスを返します。
## データソースを追加する
データソースを作成した場合は、 AWS AppSync サービス、具体的には API にリンクできます。
------
#### [ Console ]
1. にサインイン AWS マネジメントコンソール し、[AppSync コンソール](https://console.aws.amazon.com/appsync/)を開きます。
1. **ダッシュボード**で API を選択します。
1. **サイドバー** で **[データソース]** を選択します。
1. **[データソースを作成]** を選択します。
1. データソースに名前を付けます。説明を付けることもできますが、これは任意です。
1. **[データソースタイプ]** を選択します。
1. DynamoDB の場合は、リージョンを選択してから、リージョンのテーブルを選択する必要があります。新しい汎用テーブルロールを作成するか、テーブルの既存のロールをインポートするかを選択することで、テーブルとのインタラクションルールを設定できます。[バージョニング](https://docs.aws.amazon.com/appsync/latest/devguide/conflict-detection-and-sync.html)を有効にすると、複数のクライアントが同時にデータの更新を試行したとき、リクエストごとにデータのバージョンが自動的に作成されます。バージョニングは、競合の検出と解決を目的に、データの複数のバリアントを保持および管理するために使用されます。また、スキーマ自動生成を有効にすると、データソースが取得され、スキーマ内でそのデータソースにアクセスするのに必要な CRUD、`List`、`Query` オペレーションがいくつか生成されます。
OpenSearch では、リージョンを選択してから、リージョンのドメイン (クラスター) を選択する必要があります。新しい汎用テーブルロールを作成するか、テーブルの既存のロールをインポートするかを選択することで、ドメインとのインタラクションルールを設定できます。
Lambda の場合は、リージョンを選択してから、そのリージョンの Lambda 関数の ARN を選択する必要があります。新しい汎用テーブルロールを作成するか、テーブルの既存のロールをインポートするかを選択することで、Lambda 関数とのインタラクションルールを設定できます。
HTTP の場合は、HTTP エンドポイントを入力する必要があります。
EventBridge の場合は、リージョンを選択してから、地域のイベントバスを選択する必要があります。新しい汎用テーブルロールを作成するか、テーブルの既存のロールをインポートするかを選択することで、イベントバスとのインタラクションルールを設定できます。
RDS の場合は、リージョンを選択してから、次にシークレットストア (ユーザー名とパスワード)、データベース名、スキーマを選択する必要があります。
None の場合は、実際のデータソースがないデータソースを追加します。これは、リゾルバーを実際のデータソースではなくローカルで処理するためのものです。
**注記**
既存のロールをインポートする場合は、信頼ポリシーが必要です。信頼ポリシーの詳細については、「[IAM 信頼ポリシー](#iam-trust-policy.title)」を参照してください。
1. **[作成]** を選択します。
**注記**
または、DynamoDB データソースを作成する場合は、コンソールの **[スキーマ]** ページに移動し、ページ上部の **[リソースの作成]** を選択してから、定義済みのモデルを入力してテーブルに変換することもできます。このオプションでは、基本型を入力またはインポートし、パーティションキーを含む基本的なテーブルデータを設定して、スキーマの変更を確認します。
------
#### [ CLI ]
+ [https://docs.aws.amazon.com/cli/latest/reference/appsync/create-data-source.html](https://docs.aws.amazon.com/cli/latest/reference/appsync/create-data-source.html) コマンドを実行してデータソースを作成します。
この特定のコマンドでは、いくつかのパラメータを入力する必要があります。
1. API の `api-id` です。
1. テーブルの `name`。
1. データソースの `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 の[公式ドキュメント](https://docs.aws.amazon.com/cdk/v2/guide/home.html)と CDK AWS AppSyncリファレンスを確認することをお勧めします。 [https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_appsync-readme.html](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_appsync-readme.html)
以下の手順では、特定のリソースを追加するために使用するスニペットの一般的な例のみを示しています。これは本番稼働用コードで機能するソリューションとなることを**意図したものではありません**。また、動作するアプリが既にあることを前提としています。
特定のデータソースを追加するには、コンストラクトをスタックファイルに追加する必要があります。データソースタイプのリストは次のとおりです。
+ [ DynamoDbDataSource ](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_appsync.DynamoDbDataSource.html)
+ [ EventBridgeDataSource ](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_appsync.EventBridgeDataSource.html)
+ [ HttpDataSource ](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_appsync.HttpDataSource.html)
+ [ LambdaDataSource ](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_appsync.LambdaDataSource.html)
+ [ NoneDataSource ](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_appsync.NoneDataSource.html)
+ [ OpenSearchDataSource ](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_appsync.OpenSearchDataSource.html)
+ [ RdsDataSource ](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_appsync.RdsDataSource.html)
1. 一般的には、使用しているサービスにインポートディレクティブを追加しなければならない場合があります。たとえば、次の形式に従います。
```
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';
```
1. RDS などの一部のサービスでは、データソースを作成する前にスタックファイルに追加の設定が必要です (VPC の作成、ロール、アクセス認証情報など)。詳細については、関連する CDK ページの例を参照してください。
1. ほとんどのデータソース、特に 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 が含まれます (`?` 記号を**使用しない**で表記します)。必要とされる props については、CDK ドキュメントを参照してください。
1. 次に、データソースを 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`) を呼び出し、その組み込みメソッドの 1 つ (`addDynamoDbDataSource`) を使用して、テーブルと GraphQL API を関連付けることができます。引数は、 AWS AppSync コンソール (`data_source_name_in_console`この例では ) とテーブルメソッド () に存在するこのリンクの名前です`add_ddb_table`。このトピックの詳細は、リゾルバーの作成を開始する次のセクションで明らかになります。
データソースをリンクする方法は他にもあります。技術的には、テーブル関数の props リストに `api` を追加することもできます。たとえば、以下はステップ 3 のスニペットですが、`api` props には GraphQL 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 がリソースアクセスに使用するには、そのロールの信頼ポリシーを変更する必要があります。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "appsync.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
------
また、信頼ポリシーに条件を追加して、必要に応じてデータソースへのアクセスを制限することもできます。現在、`SourceArn`および`SourceAccount`キーはこれらの条件で使用できます。たとえば、次のポリシーでは、データソースへのアクセスを`123456789012` アカウントに制限しています。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "appsync.amazonaws.com"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"aws:SourceAccount": "123456789012"
}
}
}
]
}
```
------
または、データソースへのアクセスを、次のポリシーを使用する`abcdefghijklmnopq`のような特定の API に制限することもできます。
------
#### [ JSON ]
****
```
{
"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 へのアクセスを制限できます。
------
#### [ JSON ]
****
```
{
"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/*"
}
}
}
]
}
```
------
次のセクション (「[リゾルバーの設定](https://docs.aws.amazon.com//appsync/latest/devguide/resolver-config-overview.html)」) では、リゾルバーのビジネスロジックを追加し、スキーマのフィールドにアタッチして、データソースのデータを処理します。
詳細については、**「IAM ユーザーガイド」の「[ロールの修正](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_roles_manage_modify.html)」を参照してください。
AppSync の AWS Lambda リゾルバーのクロスアカウントアクセスの詳細については、「[AWS AppSync のクロスアカウント AWS Lambda リゾルバーの構築](https://aws.amazon.com/blogs/mobile/appsync-lambda-cross-account/)」を参照してください。 AWS AppSync