翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 # AWS AppSync でのサーバー側のキャッシュと API ペイロード圧縮の設定 AWS AppSyncの AppSync のサーバー側のデータキャッシング機能は、データを高速インメモリキャッシュで利用できるようにし、パフォーマンスを高め、レイテンシーを減らします。これにより、データソースに直接アクセスする必要が少なくなります。キャッシングは、ユニットリゾルバーとパイプラインリゾルバーの両方で使用できます。 AWS AppSync では、API レスポンスを圧縮して、ペイロードコンテンツのロードとダウンロードを高速化することもできます。これにより、アプリケーションへの負担を軽減できると同時に、データ転送料金も削減できる可能性があります。圧縮動作は設定可能で、独自の判断で設定できます。 AWS AppSync API でのサーバー側のキャッシュと圧縮の望ましい動作を定義する方法については、このセクションを参照してください。 ## インスタンスのタイプ AWS AppSync は AWS AppSync API と同じ AWS アカウントと AWS リージョンで Amazon ElastiCache (Redis OSS) インスタンスをホストします。 ElastiCache (Redis OSS) では、次のインスタンスタイプを使用できます。 **small** 1 vCPU、1.5 GiB RAM、低～中程度のネットワークパフォーマンス **medium** 2 vCPU、3 GiB RAM、低～中程度のネットワークパフォーマンス **large** 2 vCPU、12.3 GiB RAM、最大 10 ギガビットのネットワークパフォーマンス **xlarge** 4 vCPU、25.05 GiB RAM、最大 10 ギガビットのネットワークパフォーマンス **2xlarge** 8 vCPU、50.47 GiB RAM、最大 10 ギガビットのネットワークパフォーマンス **4xlarge** 16 vCPU、101.38 GiB RAM、最大 10 ギガビットのネットワークパフォーマンス **8xlarge** 32 vCPU、203.26 GiB RAM、10 ギガビットのネットワークパフォーマンス (一部のリージョンで使用できません) **12xlarge** 48 vCPU、317.77 GiB RAM、10 ギガビットのネットワークパフォーマンス **注記** 従来は、特定のインスタンスタイプ ( `t2.medium` など) を指定しました。2020 年 7 月時点で、これらのレガシーインスタンスタイプは引き続き利用可能になりますが、使用は推奨されなくなります。ここで説明するジェネリックインスタンスタイプを使用することをお勧めします。 ## キャッシュの動作 以下は、キャッシュに関連する動作です。 **なし** サーバー側のキャッシュはありません。 **完全なリクエストのキャッシュ** フルリクエストキャッシュは、リゾルバーの実行結果を個別にキャッシュするメカニズムです。この設定では、 はリクエスト中に呼び出されたすべてのリゾルバーの実行を AWS AppSync キャッシュし、各リゾルバーは個別にキャッシュされます。各リゾルバーのデータはデータソースから取得され、有効期限 (TTL) が切れるまでキャッシュに投入されます。後続の API リクエストの場合、特定のリゾルバーごとの結果がキャッシュから返されます。つまり、TTL の有効期限が切れていない限り、データソースに直接接続されません。 は の内容 AWS AppSync を使用し`context.arguments`、各リゾルバーのキャッシュキーとして`context.identity`マッピングします。 **リゾルバーごとのキャッシュ** この設定では、レスポンスをキャッシュするために、各リゾルバーを明示的にオプトインする必要があります。TTL とキャッシュキーはリゾルバーで指定できます。指定できるキャッシュキーは、これらのマップの最上位マップ `context.arguments`、`context.source`、`context.identity`、および/または文字列フィールドです。TTL 値は必須ですが、キャッシュキーはオプションです。キャッシュキーを何も指定しない場合、デフォルトは、`context.arguments`、`context.source`、`context.identity` マップの内容です。 たとえば、以下のようなコマンドを実行できます。 + *context.arguments* と *context.source* + *context.arguments* と *context.identity.sub* + *context.arguments.id* または *context.arguments.InputType.id* + *context.source.id* と *context.identity.sub* + *context.identity.claims.username* TTL のみを指定し、キャッシュキーを指定しない場合、リゾルバーの動作はリクエスト全体をキャッシュする場合と同じになります。 **オペレーションレベルキャッシュ** オペレーションレベルキャッシュは、GraphQL クエリオペレーションレスポンス全体を全体として保存します。有効にすると、成功したクエリレスポンスは TTL の有効期限が切れるまでキャッシュされ、キャッシュ可能なレスポンスの最大サイズは 15 MB です。同じキャッシュキーを持つ後続のクエリリクエストの場合、TTL の有効期限が切れるまで、レスポンスはリゾルバーを実行せずにキャッシュから直接処理されます。 オペレーションレベルキャッシュのキャッシュキーは、次の組み合わせを使用して生成されます。 + リクエストの JSON ペイロードからの特定の属性: + `query` 文字列 + `operationName` 文字列 + `variables` マップ + `context.identity` マップ (IAM リクエストと Amazon Cognito リクエストの `context.identity.sourceIp` を除く) + `context.request.headers` マップ (次のセクションにリストされている特定の予約済みヘッダーを除く) リクエストで使用される認可タイプは、キャッシュキーにも影響します。IAM 認可リクエストの場合、キャッシュキーには、許可されたリソースと拒否されたリソースのリストも含まれます。Lambda 認可リクエストの場合、キャッシュキーには拒否されたフィールドのリストも含まれます。 キャッシュキーは、`context.request.headers` で見つかったすべてのリクエストヘッダーを考慮します。ただし、通常、特定のリクエストに固有の以下の予約済みヘッダーは除きます。 + authorization + cloudfront-forwarded-proto + cloudfront-is-desktop-viewer + cloudfront-is-mobile-viewer + cloudfront-is-smarttv-viewer + cloudfront-is-tablet-viewer + cloudfront-viewer-asn + cloudfront-viewer-country + content-length + host + priority + sec-ch-ua + sec-ch-ua-mobile + sec-ch-ua-platform + via + x-amz-cf-id + x-amz-date + x-amz-security-token + x-amzn-appsync-is-vpce-request + x-amzn-remote-ip + x-amzn-requestid + x-amzn-trace-id + x-forwarded-for **キャッシュの有効期限** この設定は、キャッシュされたエントリがメモリに保存される時間を定義します。最大 TTL は 3,600 秒 (1 時間) です。その後、エントリは自動的に削除されます。 ## キャッシュの暗号化 AWS AppSyncのサーバー側のデータキャッシュ機能を使用する場合、保管時および転送時の暗号化は常に新しいキャッシュに対して有効になり、無効にすることはできません。 既存の API キャッシュで暗号化を有効にするには、キャッシュを削除してから再作成します。 キャッシュエントリを無効にするには、 AWS AppSync コンソールまたは AWS Command Line Interface () を使用してフラッシュキャッシュ API コールを実行できますAWS CLI。 詳細については、 AWS AppSync API リファレンス内の「[ApiCache](https://docs.aws.amazon.com/appsync/latest/APIReference/API_ApiCache.html)」データ型を参照してください。 ## キャッシュエビクション AWS AppSync のサーバー側のキャッシュを設定するときに、最大 TTL を設定できます。これは、キャッシュされたエントリがメモリに保存される時間を定義します。キャッシュから特定のエントリを削除する必要がある場合は、リゾルバーのリクエストまたはレスポンスで AWS AppSync の`evictFromApiCache`拡張機能ユーティリティを使用できます。(たとえば、データソース内のデータが変更され、キャッシュエントリが古くなった場合など)。キャッシュからアイテムをエビクトするには、そのキーを知っている必要があります。このため、アイテムを動的にエビクトする必要がある場合は、リゾルバーごとのキャッシュを使用し、キャッシュにエントリを追加するために使用するキーを明示的に定義することをおすすめします。 ## キャッシュエントリーのエビクション キャッシュからアイテムを削除するには、`evictFromApiCache` 拡張ユーティリティを使用します。タイプ名とフィールド名を指定し、キーと値の項目のオブジェクトを指定して、エビクトするエントリのキーを作成します。オブジェクト内の各キーは、キャッシュされたリゾルバーの `cachingKey` リストで使用されている `context` オブジェクトからの有効なエントリを表します。各値は、キーの値を構成するために使用される実際の値です。オブジェクト内の項目は、キャッシュされたリゾルバーの `cachingKey` リストにあるキャッシュキーと同じ順序で配置する必要があります。 例えば、以下のスキーマを参照してください。 ``` type Note { id: ID! title: String content: String! } type Query { getNote(id: ID!): Note } type Mutation { updateNote(id: ID!, content: String!): Note } ``` この例では、リゾルバーごとのキャッシュを有効にしてから、`getNote` クエリで有効にすることができます。次に、キャッシュキーを `[context.arguments.id]` で構成するように構成できます。 を取得しようとすると`Note`、 AWS AppSync は`getNote`クエリの `id`引数を使用してサーバー側のキャッシュでルックアップを実行します。 `Note` を更新するときは、次のリクエストでそのメモがバックエンドデータソースから取得されるように、特定のメモのエントリをエビクトする必要があります。これを行うには、リクエストハンドラーを作成する必要があります。 次の例は、このメソッドを使用してエビクションを処理する 1 つの方法を示しています。 ``` import { util, Context } from '@aws-appsync/utils'; import { update } from '@aws-appsync/utils/dynamodb'; export function request(ctx) { extensions.evictFromApiCache('Query', 'getNote', { 'ctx.args.id': ctx.args.id }); return update({ key: { id: ctx.args.id }, update: { context: ctx.args.content } }); } export const response = (ctx) => ctx.result; ``` または、レスポンスハンドラーでエビクションを処理することもできます。 `updateNote` ミューテーションが処理されると、 AWS AppSync はエントリの削除を試みます。エントリが正常にクリアされると、レスポンスには削除されたエントリの数を示す `apiCacheEntriesDeleted` 値が `extensions` オブジェクトに含まれます。 ``` "extensions": { "apiCacheEntriesDeleted": 1} ``` ## ID に基づくキャッシュエントリのエビクション `context` オブジェクトの複数の値に基づいてキャッシュキーを作成できます。 たとえば、Amazon Cognito ユーザープールをデフォルトの認証モードとして使用し、Amazon DynamoDB データソースを基盤とする次のスキーマを考えてみましょう。 ``` type Note { id: ID! # a slug; e.g.: "my-first-note-on-graphql" title: String content: String! } type Query { getNote(id: ID!): Note } type Mutation { updateNote(id: ID!, content: String!): Note } ``` `Note` オブジェクトタイプは DynamoDB テーブルに保存されます。このテーブルには、Amazon Cognito ユーザー名をプライマリキーとして使用し、`Note` の `id` (スラッグ) をパーティションキーとして使用する複合キーがあります。これはマルチテナントシステムで、複数のユーザーがプライベートオブジェクトをホストして更新できますが、プライベート `Note` オブジェクトは決して共有されません。 これは読み取り負荷の高いシステムであるため、`getNote` クエリはリゾルバーごとのキャッシュを使用してキャッシュされ、キャッシュキーは `[context.identity.username, context.arguments.id]` で構成されます。`Note` が更新されると、その特定のエントリをエビクトできます。`Note`リゾルバーの `cachingKeys` リストで指定されているのと同じ順序でコンポーネントをオブジェクトに追加する必要があります。 次の例でこれを示します。 ``` import { util, Context } from '@aws-appsync/utils'; import { update } from '@aws-appsync/utils/dynamodb'; export function request(ctx) { extensions.evictFromApiCache('Query', 'getNote', { 'ctx.identity.username': ctx.identity.username, 'ctx.args.id': ctx.args.id, }); return update({ key: { id: ctx.args.id }, update: { context: ctx.args.content } }); } export const response = (ctx) => ctx.result; ``` バックエンドシステムでも `Note` を更新してエントリをエビクトできます。例として、このミューテーションを取り上げます。 ``` type Mutation { updateNoteFromBackend(id: ID!, content: String!, username: ID!): Note @aws_iam } ``` エントリはエビクトできますが、キャッシュキーのコンポーネントは `cachingKeys` オブジェクトに追加できます。 次の例では、エビクションはリゾルバーの応答で行われます。 ``` import { util, Context } from '@aws-appsync/utils'; import { update } from '@aws-appsync/utils/dynamodb'; export function request(ctx) { return update({ key: { id: ctx.args.id }, update: { context: ctx.args.content } }); } export function response(ctx) { extensions.evictFromApiCache('Query', 'getNote', { 'ctx.identity.username': ctx.args.username, 'ctx.args.id': ctx.args.id, }); return ctx.result; } ``` バックエンドデータが AWS AppSync の外部で更新された場合は、`NONE`データソースを使用するミューテーションを呼び出すことで、キャッシュから項目を削除できます。 ## API レスポンスの圧縮 AWS AppSync を使用すると、クライアントは圧縮ペイロードをリクエストできます。要求された場合、API レスポンスは圧縮され、圧縮されたコンテンツが望ましいというリクエストに応答して返されます。圧縮された API レスポンスはより速く読み込まれ、コンテンツのダウンロードも速くなり、データ転送料金も抑えられる可能性があります。 **注記** 圧縮は、2020 年 6 月 1 日以降に作成されたすべての新しい API で使用できます。 AWS AppSync [はベストエフォートベースでオブジェクトを圧縮](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/ServingCompressedFiles.html#compressed-content-cloudfront-notes)します。まれに、 AWS AppSync は現在の容量を含むさまざまな要因に基づいて圧縮をスキップすることがあります。 AWS AppSync は、GraphQL クエリペイロードサイズを 1,000～10,000,000 バイトに圧縮できます。圧縮を有効にするには、クライアントは `gzip` 値を含む `Accept-Encoding` ヘッダーを送信する必要があります。圧縮は、応答 (`gzip`) `Content-Encoding` 内のヘッダーの値をチェックすることで確認できます。 AWS AppSync コンソールのクエリエクスプローラーは、デフォルトでリクエストのヘッダー値を自動的に設定します。応答が十分大きいクエリを実行した場合、ブラウザの開発者ツールを使用して圧縮を確認できます。