AWS AppSync에서 서버 측 캐싱 및 API 페이로드 압축 구성 - AWS AppSync
인스턴스 타입캐싱 동작캐시 암호화캐시 제거캐시 항목 제거자격 증명을 기반으로 캐시 항목 제거API 응답 압축

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

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

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

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

인스턴스 타입

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

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

small

vCPU 1개, 1.5GiB RAM, 낮음에서 중간 수준의 네트워크 성능

medium

vCPU 2개, 3GiB RAM, 낮음에서 중간 수준의 네트워크 성능

large

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

xlarge

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

2xlarge

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

4xlarge

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

8xlarge

vCPU 32개, 203.26GiB RAM, 10기가비트 네트워크 성능(일부 리전에만 사용 가능)

12xlarge

vCPU 48개, 317.77GiB RAM, 10기가비트 네트워크 성능

참고

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

캐싱 동작

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

None

서버 측 캐싱이 없습니다.

전체 요청 캐싱

캐시에 데이터가 없으면 데이터 원본에서 데이터를 가져와 TTL(Time To Live)이 만료될 때까지 캐시를 채웁니다. API에 대한 모든 후속 요청은 캐시에서 반환됩니다. 즉, TTL이 만료되지 않는 한 데이터 원본에 직접 연결되지 않습니다. 이 설정에서 캐싱 키로 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만 지정하고 캐싱 키는 지정하지 않는 경우 해석기의 동작은 전체 요청 캐싱과 동일합니다.

TTL(Time To Live) 캐시

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

캐시 암호화

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

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

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

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

자세한 내용은 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를 가져오려고 하면 AWS AppSync는 getNote 쿼리의 id 인수를 사용하여 서버 측 캐시에서 조회를 수행합니다.

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 사용자 이름을 프라이머리 키로 사용하고 Note의 id(슬러그)를 파티션 키로 사용하는 복합 키가 있습니다. 이 시스템은 여러 사용자가 프라이빗 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;
}

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

API 응답 압축

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

참고

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

AWS AppSync는 가능한 한 객체를 압축합니다. 드문 경우이긴 하지만 AWS AppSync는 현재 용량을 비롯한 다양한 요인을 기반으로 압축을 건너뛸 수 있습니다.

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

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