ステップ 2: データソースを追加する - AWS AppSync
データソースのタイプデータソースを追加する

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

ステップ 2: データソースを追加する

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

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

データソースのタイプ

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

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

Amazon DynamoDB

Amazon DynamoDB は、スケーラブルアプリケーション向けの AWS の主要なストレージソリューションの 1 つです。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 は、リソースを実行するためのコード、依存関係、設定を含むグループステートメントである関数を使用します。関数は、関数を呼び出すアクティビティのグループであるトリガーを検出すると自動的に実行されます。リソースなどをスピンアップするアカウントの AWS サービスである API コールを行うアプリケーションなどもトリガーになる場合があります。トリガーされると、関数は、変更するデータを含む JSON ドキュメントであるイベントを処理します。

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

Amazon RDS

Amazon RDS では、リレーショナルデータベースを迅速に構築して設定できます。Amazon RDS では、クラウド内の隔離されたデータベース環境として機能する汎用データベースインスタンスを作成します。このインスタンスでは、実際の RDBMS ソフトウェア (PostgreSQL、MySQL など) である DB エンジンを使用します。このサービスでは、AWS のインフラストラクチャ、パッチや暗号化などのセキュリティサービス、デプロイメントの管理コストの削減によってスケーラビリティを提供し、バックエンドの作業の大部分をオフロードします。

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

Amazon EventBridge

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

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

none データソース

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

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

OpenSearch

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

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

HTTP エンドポイント

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

データソースを追加する

データソースを作成すると、それを AWS AppSyncサービス、より具体的には API にリンクできます。

Console

  1. AWS Management Console にサインインして、AppSync コンソールを開きます。

    1. ダッシュボードで API を選択します。

    2. サイドバーで [データソース] を選択します。

  2. [データソースを作成] を選択します。

    1. データソースに名前を付けます。説明を付けることもできますが、これは任意です。

    2. [データソースタイプ]を選択します。

    3. DynamoDB の場合は、リージョンを選択してから、リージョンのテーブルを選択する必要があります。新しい汎用テーブルロールを作成するか、テーブルの既存のロールをインポートするかを選択することで、テーブルとのインタラクションルールを設定できます。バージョニングを有効にすると、複数のクライアントが同時にデータの更新を試行したとき、リクエストごとにデータのバージョンが自動的に作成されます。バージョニングは、競合の検出と解決を目的に、データの複数のバリアントを保持および管理するために使用されます。また、スキーマ自動生成を有効にすると、データソースが取得され、スキーマ内でそのデータソースにアクセスするのに必要な CRUD、List、Query オペレーションがいくつか生成されます。

      OpenSearch では、リージョンを選択してから、リージョンのドメイン (クラスター) を選択する必要があります。新しい汎用テーブルロールを作成するか、テーブルの既存のロールをインポートするかを選択することで、ドメインとのインタラクションルールを設定できます。

      Lambda の場合は、リージョンを選択してから、そのリージョンの Lambda 関数の ARN を選択する必要があります。新しい汎用テーブルロールを作成するか、テーブルの既存のロールをインポートするかを選択することで、Lambda 関数とのインタラクションルールを設定できます。

      HTTP の場合は、HTTP エンドポイントを入力する必要があります。

      EventBridge の場合は、リージョンを選択してから、地域のイベントバスを選択する必要があります。新しい汎用テーブルロールを作成するか、テーブルの既存のロールをインポートするかを選択することで、イベントバスとのインタラクションルールを設定できます。

      RDS の場合は、リージョンを選択してから、次にシークレットストア (ユーザー名とパスワード)、データベース名、スキーマを選択する必要があります。

      None の場合は、実際のデータソースがないデータソースを追加します。これは、リゾルバーを実際のデータソースではなくローカルで処理するためのものです。

      注記

      既存のロールをインポートする場合は、信頼ポリシーが必要です。信頼ポリシーの詳細については、「IAM 信頼ポリシー」を参照してください。

  3. [作成] を選択します。

    注記

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

CLI

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

    この特定のコマンドでは、いくつかのパラメータを入力する必要があります。

    1. API の api-id。

    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 リファレンスを確認することをお勧めします。

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

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

  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';

  2. RDS などの一部のサービスでは、データソースを作成する前にスタックファイルに追加の設定が必要です (VPC の作成、ロール、アクセス認証情報など)。詳細については、関連する CDK ページの例を参照してください。

  3. ほとんどのデータソース、特に 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 ドキュメントを参照してください。

  4. 次に、データソースを 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 テーブルのPutItemなどのAWSのリソースに対してオペレーションを実行するための適切なアクセス許可をロールに与える必要があります。また、そのロールの信頼ポリシーを次のポリシー例のように変更して、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のような特定のリージョンからのすべてのAWSAppSync API へのアクセスを制限することができます。

{
  "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 ユーザーガイド』の「ロールの修正」を参照してください。

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