에서 서버 측 캐싱 및 API페이로드 압축 구성 AWS AppSync - AWS AppSync

기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

에서 서버 측 캐싱 및 API페이로드 압축 구성 AWS AppSync

AWS AppSync의 서버 측 데이터 캐싱 기능을 사용하면 고속 인 메모리 캐시에서 데이터를 사용할 수 있어 성능이 향상되고 지연 시간이 줄어듭니다. 이렇게 하면 데이터 원본에 직접 액세스할 필요가 줄어듭니다. 캐싱은 유닛 해석기와 파이프라인 해석기 모두에서 사용할 수 있습니다.

AWS AppSync 를 사용하면 API 응답을 압축하여 페이로드 콘텐츠가 더 빠르게 로드 및 다운로드되도록 할 수도 있습니다. 이렇게 하면 잠재적으로 애플리케이션에 가해지는 부담을 줄이는 동시에 데이터 전송 요금도 줄일 수 있습니다. 압축 동작은 구성 가능하며 사용자가 임의로 설정할 수 있습니다.

에서 서버 측 캐싱 및 압축의 원하는 동작을 정의하는 데 도움이 필요하면 이 섹션을 참조하세요 AWS AppSync API.

인스턴스 타입

AWS AppSync 는 와 동일한 AWS 계정 및 AWS 리전에 Amazon ElastiCache (RedisOSS) 인스턴스를 호스팅합니다 AWS AppSync API.

다음 ElastiCache (Redis OSS) 인스턴스 유형을 사용할 수 있습니다.

small

1v CPU, 1.5GiB RAM, 낮은 수준에서 중간 수준의 네트워크 성능

medium

2v CPU, 3GiB RAM, 낮은 수준에서 중간 수준의 네트워크 성능

large

2v CPU, 12.3GiB RAM, 최대 10기가비트 네트워크 성능

xlarge

4v CPU, 25.05GiB RAM, 최대 10기가비트 네트워크 성능

2xlarge

8v CPU, 50.47GiB RAM, 최대 10기가비트 네트워크 성능

4xlarge

16v CPU, 101.38GiB RAM, 최대 10기가비트 네트워크 성능

8xlarge

32v CPU, 203.26GiB RAM, 10기가비트 네트워크 성능(일부 리전에서는 제공되지 않음)

12xlarge

48v CPU, 317.77GiB RAM, 10기가비트 네트워크 성능

참고

과거에는 특정 인스턴스 유형(예: t2.medium)을 지정했습니다. 2020년 7월부터 이러한 레거시 인스턴스 유형을 계속 사용할 수는 있지만, 지원이 중단되므로 사용하지 않는 것이 좋습니다. 여기에 설명된 일반 인스턴스 유형을 사용하는 것이 좋습니다.

캐싱 동작

다음은 캐싱과 관련된 동작입니다.

None

서버 측 캐싱이 없습니다.

전체 요청 캐싱

데이터가 캐시에 없는 경우 데이터 소스에서 검색되고 라이브(TTL) 만료까지 캐시를 채웁니다. 에 대한 모든 후속 요청은 캐시에서 반환API됩니다. 즉, 가 TTL 만료되지 않는 한 데이터 소스에 직접 연결되지 않습니다. 이 설정에서 캐싱 키로 context.argumentscontext.identity 맵의 내용을 사용합니다.

해석기 단위 캐싱

이 설정을 사용하면 응답을 캐시하기 위해 각 해석기를 명시적으로 옵트인해야 합니다. 해석기에서 TTL 및 캐싱 키를 지정할 수 있습니다. 지정할 수 있는 캐싱 키는 최상위 맵 context.arguments, context.source, context.identity, 또는 이러한 맵의 문자열 필드입니다. TTL 값은 필수이지만 캐싱 키는 선택 사항입니다. 캐싱 키를 지정하지 않는 경우 기본값은 context.arguments, context.source, context.identity 맵의 내용입니다.

예를 들면 다음과 같은 조합을 사용할 수 있습니다.

  • context.argumentscontext.source

  • context.argumentscontext.identity.sub

  • context.arguments.id 또는 context.arguments.InputType.id

  • context.source.idcontext.identity.sub

  • context.identity.claims.username

캐싱 키TTL가 없고 만 지정하는 경우 해석기의 동작은 전체 요청 캐싱과 동일합니다.

TTL(Time To Live) 캐시

이 설정은 캐시된 항목이 메모리에 저장되는 시간을 정의합니다. 최대값TTL은 3,600초(1시간)이며, 이후에는 항목이 자동으로 삭제됩니다.

캐시 암호화

캐시 암호화는 다음 두 가지 유형으로 제공됩니다. 이는 ElastiCache (Redis OSS)에서 허용하는 설정과 유사합니다. 에 대한 캐싱을 처음 활성화할 때만 암호화 설정을 활성화할 수 있습니다 AWS AppSync API.

  • 전송 중 암호화 - AWS AppSync, 캐시 및 데이터 소스(안전하지 않은 HTTP 데이터 소스 제외) 간의 요청은 네트워크 수준에서 암호화됩니다. 엔드포인트에서 데이터를 암호화하고 해독하기 위해 몇 가지 처리가 필요하기 때문에 전송 중 암호화는 성능에 영향을 미칠 수 있습니다.

  • 저장 데이터 암호화 - 스왑 작업 중에 메모리에서 디스크에 저장된 데이터는 캐시 인스턴스에서 암호화됩니다. 이 설정도 성능에 영향을 줍니다.

캐시 항목을 무효화하려면 AWS AppSync 콘솔 또는 ()를 사용하여 캐시 플러시를 API 호출할 AWS Command Line Interface 수 있습니다AWS CLI.

자세한 내용은 AWS AppSync API 참조의 ApiCache 데이터 유형을 참조하세요.

캐시 제거

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하기 위해 getNote 쿼리의 id 인수를 사용하여 서버 측 캐시에서 조회를 AWS AppSync 수행합니다.

Note를 업데이트할 때는 다음 요청이 백엔드 데이터 원본에서 해당 메모를 가져오도록 특정 메모의 항목을 제거해야 합니다. 이렇게 하려면 요청 핸들러를 만들어야 합니다.

다음 예제에서는 이 방법을 사용하여 제거를 처리하는 방법을 보여 줍니다.

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 시도합니다. 항목이 성공적으로 삭제되면 응답에는 삭제된 항목 수를 보여 주는 extensions 객체에 apiCacheEntriesDeleted 값이 포함됩니다.

"extensions": { "apiCacheEntriesDeleted": 1}

자격 증명을 기반으로 캐시 항목 제거

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 사용자 이름을 프라이머리 키로 사용하고 Noteid(슬러그)를 파티션 키로 사용하는 복합 키가 있습니다. 이 시스템은 여러 사용자가 프라이빗 Note 객체를 호스팅하고 업데이트할 수 있는 다중 테넌트 시스템으로, 절대 공유되지 않습니다.

읽기 중심의 시스템이므로 [context.identity.username, context.arguments.id]로 구성된 캐싱키가 있는 해석기 단위 캐싱을 사용하여 getNote 쿼리를 캐시합니다. 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; }

백엔드 데이터가 외부에서 업데이트된 경우 NONE 데이터 소스를 사용하는 변형을 호출하여 캐시에서 항목을 제거할 AWS AppSync수 있습니다.

API 응답 압축

AWS AppSync 를 사용하면 클라이언트가 압축된 페이로드를 요청할 수 있습니다. 요청이 있는 경우 압축된 콘텐츠가 선호됨을 나타내는 요청에 대한 응답으로 API 응답이 압축되고 반환됩니다. 압축 API 응답은 더 빠르게 로드되고, 콘텐츠는 더 빠르게 다운로드되며, 데이터 전송 요금도 절감될 수 있습니다.

참고

압축은 2020년 6월 1일 이후에 APIs 생성된 모든 새 에서 사용할 수 있습니다.

는 최선을 다해 객체를AWS AppSync 압축합니다. 드문 경우지만 현재 용량을 포함한 다양한 요인에 따라 압축을 건너뛸 AWS AppSync 수 있습니다.

AWS AppSync 는 1,000~10,000,000바이트의 GraphQL 쿼리 페이로드 크기를 압축할 수 있습니다. 압축을 활성화하려면 클라이언트가 gzip 값과 함께 Accept-Encoding 헤더를 전송해야 합니다. 응답(gzip)에서 Content-Encoding 헤더의 값을 확인하여 압축을 확인할 수 있습니다.

AWS AppSync 콘솔의 쿼리 탐색기는 기본적으로 요청의 헤더 값을 자동으로 설정합니다. 응답이 충분히 큰 쿼리를 실행하면 브라우저 개발자 도구를 사용하여 압축을 확인할 수 있습니다.