API 캐싱 활성화 메서드 캐싱에 대한 단계 캐싱 재정의 메서드/통합 파라미터를 캐시 키로 사용 API Gateway에서 API 단계 캐시 비우기 API Gateway 캐시 항목 무효화

응답성 향상을 위한 API 캐싱 활성화

Amazon API Gateway에서 API 캐싱을 활성화하여 엔드포인트의 응답을 캐싱할 수 있습니다. 캐싱을 사용하면 엔드포인트에 대한 호출 수를 줄이고 API에 대한 요청 지연 시간을 개선할 수 있습니다.

단계에 대한 캐싱을 활성화하면 API Gateway는 지정된 time-to-live (TTL) 기간 (초) 동안 엔드포인트의 응답을 캐싱합니다. 그런 다음 API Gateway는 엔드포인트에 요청하는 대신 캐시에서 엔드포인트 응답을 조회하여 요청에 응답합니다. API 캐싱에 대한 기본 TTL 값은 300초입니다. 최대 TTL 값은 3600초입니다. TTL=0이면 캐싱이 비활성화됩니다.

참고

캐싱은 최선의 작업을 기반으로 이루어집니다. CloudWatch Amazon의 CacheHitCount 및 CacheMissCount 지표를 사용하여 API Gateway가 API 캐시에서 제공하는 요청을 모니터링할 수 있습니다.

캐싱할 수 있는 응답의 최대 크기는 1048576바이트입니다. 캐시 데이터 암호화는 캐싱할 경우 응답의 크기를 증가시킬 수 있습니다.

이것은 HIPAA 적격 서비스입니다. 1996년 미국 건강 보험 양도 및 책임법 (HIPAA) 및 보호 대상 건강 정보 (PHI) 를 처리, 저장 및 전송하기 위한 AWS 서비스 사용에 대한 AWS자세한 내용은 HIPAA 개요를 참조하십시오.

중요

단계에 대한 캐싱을 활성화할 경우, GET 메서드만 기본적으로 캐싱을 활성화합니다. 이렇게 하면 API의 안전성 및 가용성이 보장됩니다. 메서드 설정을 재정의함으로써 다른 메서드에 대해 캐싱을 활성화할 수 있습니다.

중요

캐싱의 경우 선택한 캐시 크기에 따라 시간 단위로 요금이 청구됩니다. 캐싱은 프리 티어 적용 대상이 아닙니다. AWS 자세한 내용은 API Gateway 요금을 참조하세요.

Amazon API Gateway 캐싱 활성화

API Gateway에서는 특정 단계에 대한 캐싱을 활성화할 수 있습니다.

캐싱을 활성화할 경우 캐시 용량을 선택해야 합니다. 일반적으로 용량이 클수록 성능이 우수하지만 비용이 더 높습니다. 지원되는 캐시 크기는 API Gateway API 참조를 참조하십시오 cacheClusterSize.

API Gateway에서 전용 캐시 인스턴스를 생성하여 캐싱을 활성화합니다. 이 프로세스에는 최대 4분이 걸릴 수 있습니다.

API Gateway에서 기존 캐시 인스턴스를 제거하고 수정된 용량으로 새 캐시 인스턴스를 생성하여 캐싱 용량을 변경합니다. 캐시된 모든 기존 데이터가 삭제됩니다.

참고

캐시 용량은 캐시 인스턴스의 CPU, 메모리 및 네트워크 대역폭에 영향을 미칩니다. 따라서 캐시 용량이 캐시 성능에 영향을 줄 수 있습니다.

API Gateway에서는 10분 로드 테스트를 실행하여 캐시 용량이 워크로드에 적합한지 확인하는 것이 좋습니다. 로드 테스트 중 트래픽이 프로덕션 트래픽을 미러링하는지 확인합니다. 예를 들어, 램프 업, 상수 트래픽 및 트래픽 급증을 포함합니다. 로드 테스트에는 캐시에서 제공 할 수 있는 응답과 캐시에 항목을 추가하는 고유 응답이 포함되어야 합니다. 로드 테스트 중에 지연 시간, 4xx, 5xx, 캐시 적중 및 캐시 누락 지표를 모니터링합니다. 이러한 지표를 기반으로 필요에 따라 캐시 용량을 조정합니다. 부하 테스트에 대한 자세한 내용은 속도 제한에 도달하지 않도록 최상의 API Gateway 캐시 용량을 선택하려면 어떻게 하나요?를 참조하세요.

API Gateway 콘솔의 스테이지 페이지에서 캐싱을 구성합니다. 스테이지 캐시를 프로비저닝하고 기본 메서드 수준 캐시 설정을 지정합니다. 기본 메서드 수준 캐시를 켜면 해당 메서드에 메서드 재정의가 없는 한 스테이지의 모든 메서드에 대해 메서드 수준 캐싱이 설정됩니다. 스테이지에 배포하는 추가 GET 메서드에는 모두 메서드 수준 캐시가 있습니다. 스테이지의 특정 메서드에 대한 메서드 수준 캐싱 설정을 구성하려면 메서드 재정의를 사용할 수 있습니다. 메서드 재정의에 대한 자세한 내용은 을 참조하십시오. 메서드 수준 캐싱을 위한 API Gateway 단계 수준 캐싱을 재정의합니다.

지정된 단계에 API 캐싱을 설정하려면 다음을 수행합니다.

https://console.aws.amazon.com/apigateway에서 API Gateway 콘솔에 로그인합니다.
단계를 선택합니다.
API에 대한 단계 목록에서 단계를 선택합니다.
스테이지 세부 정보 섹션에서 편집을 선택합니다.
추가 설정에서 캐시 설정에 대해 API 캐시 프로비저닝을 켜십시오.

이렇게 하면 스테이지에 캐시 클러스터를 프로비저닝할 수 있습니다.
스테이지에 대한 캐싱을 활성화하려면 기본 메서드 수준 캐싱을 켜십시오.

이렇게 하면 스테이지의 모든 메서드에 대해 메서드 수준 캐싱이 활성화됩니다. 이 단계에 배포하는 추가 GET 메서드에는 모두 메서드 수준 캐시가 있습니다.

참고
메서드 수준 캐시에 대한 기존 설정이 있는 경우 기본 메서드 수준 캐싱 설정을 변경해도 기존 설정에는 영향을 주지 않습니다.
변경 사항 저장를 선택합니다.

참고

API Gateway에서 캐시 생성 또는 삭제를 완료하는 데 4분 정도 걸립니다.

캐시가 생성되면 캐시 클러스터 값이 에서 로 변경됩니다. Create in progress Active 캐시 삭제가 완료되면 캐시 클러스터 값이 에서 Delete in progress 로 변경됩니다Inactive.

스테이지의 모든 메서드에 대해 메서드 수준 캐싱을 설정하면 기본 메서드 수준 캐싱 값이 로 변경됩니다. Active 스테이지의 모든 메서드에 대해 메서드 수준 캐싱을 끄면 기본 메서드 수준 캐싱 값이 로 변경됩니다. Inactive 메서드 수준 캐시에 대한 기존 설정이 있는 경우 캐시 상태를 변경해도 해당 설정에는 영향을 주지 않습니다.

스테이지의 캐시 설정에서 캐싱을 활성화할 때 GET 메서드만 캐시됩니다. API의 안전성 및 가용성을 확보하려면 이 설정을 변경하지 않는 것이 좋습니다. 그러나 메서드 설정을 재정의함으로써 다른 메서드에 대해 캐싱을 활성화할 수 있습니다.

캐싱이 예상한 대로 작동하는지 확인하려면 두 가지 일반적인 옵션이 있습니다.

API 및 스테이지의 CloudWatch CacheHitCount메트릭과 CacheMissCount스테이지를 검사하세요.
타임스탬프를 응답에 넣습니다.

참고

CloudFront 응답의 X-Cache 헤더를 사용하여 API가 API Gateway 캐시 인스턴스에서 제공되고 있는지 판단해서는 안 됩니다.

메서드 수준 캐싱을 위한 API Gateway 단계 수준 캐싱을 재정의합니다.

특정 메서드의 캐싱을 켜거나 끄면 단계 수준 캐시 설정을 재정의할 수 있습니다. 또한 TTL 기간을 수정하거나 캐시된 응답의 암호화를 켜거나 끌 수 있습니다.

스테이지 세부 정보에서 기본 메서드 수준 캐싱 설정을 변경해도 재정의가 있는 메서드 수준 캐시 설정에는 영향을 주지 않습니다.

캐싱하는 메서드가 중요 데이터를 응답으로 수신할 경우 Cache Settings(캐시 설정)에서 Encrypt cache data(캐시 데이터 암호화)를 선택합니다.

콘솔을 사용하여 개별 메서드에 대한 API 캐싱을 구성하려면 다음을 수행합니다.

https://console.aws.amazon.com/apigateway에서 API Gateway 콘솔에 로그인합니다.
API를 선택합니다.
단계를 선택합니다.
이를 위해 단계 보조 탐색 창에서 단계를 확장하고 메서드를 선택합니다.
메서드 재정의 섹션에서 편집을 선택합니다.
메서드 설정 섹션에서 메서드 캐시 활성화를 설정 또는 해제하거나 기타 원하는 옵션을 사용자 지정합니다.

참고
스테이지에 캐시 클러스터를 프로비전할 때까지는 캐싱이 활성화되지 않습니다.
저장을 선택합니다.

메서드/통합 파라미터를 캐시 키로 사용하여 캐시된 응답 인덱싱

캐시된 메서드 또는 통합에 사용자 지정 헤더, URL 경로 또는 쿼리 문자열 형식을 취할 수 있는 파라미터가 있는 경우 파라미터 중 일부 또는 모두를 사용하여 캐시 키를 생성할 수 있습니다. API Gateway에서는 사용된 파라미터 값에 따라 메서드의 응답을 캐싱할 수 있습니다.

참고

리소스의 캐싱을 설정하려면 캐시 키가 필요합니다.

예를 들어 다음과 같은 형식의 요청이 있다고 가정하겠습니다.



GET /users?type=... HTTP/1.1
host: example.com
...

이 요청에서 type은 admin 또는 regular 값을 가질 수 있습니다. type 파라미터가 캐시 키의 일부로 포함되어 있는 경우, GET /users?type=admin의 응답은 GET /users?type=regular의 응답과 별도로 캐싱됩니다.

메서드 또는 통합 요청에서 두 개 이상의 파라미터를 취하는 경우 파라미터의 일부 또는 모두를 포함하여 캐시 키를 생성하도록 선택할 수 있습니다. 예를 들어 TTL 기간 내에 나열된 순서로 생성되는 다음 요청에 대해 캐시 키에 type 파라미터만 포함할 수 있습니다.



GET /users?type=admin&department=A HTTP/1.1
host: example.com
...

이 요청의 응답은 캐싱되어 다음 요청을 처리하는 데 사용됩니다.



GET /users?type=admin&department=B HTTP/1.1
host: example.com
...

메서드 또는 통합 요청 파라미터를 API Gateway 콘솔에서 캐시 키의 일부로 포함하려면 파라미터를 추가한 후 캐싱을 선택합니다.

API Gateway에서 API 단계 캐시 비우기

API 캐싱을 활성화한 경우 API 클라이언트가 통합 엔드포인트에서 최신 응답을 가져오도록 API 단계의 캐시를 비울 수 있습니다.

API 스테이지 캐시를 비우려면 스테이지 작업 메뉴를 선택한 다음 스테이지 캐시 비우기를 선택합니다.

참고

캐시가 플러시되면 캐시가 다시 빌드될 때까지 통합 엔드포인트에서 응답이 처리됩니다. 이 기간 동안 통합 엔드포인트에 전송되는 요청 수가 증가할 수 있습니다. 이로 인해 API의 전체 지연 시간이 일시적으로 증가할 수 있습니다.

API Gateway 캐시 항목 무효화

API의 클라이언트는 기존 캐시 엔트리를 무효화하고 개별 요청에 대해 통합 엔드포인트에서 캐시 엔트리를 다시 로드할 수 있습니다. 클라이언트는 Cache-Control: max-age=0 헤더를 포함하는 요청을 전송해야 합니다. 클라이언트는 캐시 대신 통합 엔드포인트에서 직접 응답을 수신합니다(클라이언트에게 해당 권한이 부여된 경우). 이 경우 기존 캐시 엔트리를 통합 엔드포인트에서 가져오는 새 응답으로 대체합니다.

클라이언트에게 권한을 부여하려면 다음과 같은 형식의 정책을 사용자에 대한 IAM 실행 역할에 추가합니다.

참고

교차 계정 캐시 무효화는 지원되지 않습니다.



{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "execute-api:InvalidateCache"
      ],
      "Resource": [
        "arn:aws:execute-api:region:account-id:api-id/stage-name/GET/resource-path-specifier"
      ]
    }
  ]
}

이 정책은 API Gateway 실행 서비스에서 지정된 리소스 요청에 대한 캐시를 무효화하도록 허용합니다. 타겟 리소스 그룹을 지정하려면 account-id, api-id 및 Resource ARN 값의 기타 엔트리에 대해 와일드카드(*) 문자를 사용합니다. API Gateway 실행 서비스에 대한 권한을 설정하는 방법에 대한 자세한 내용은 IAM 권한을 사용하여 API에 대한 액세스 제어 단원을 참조하세요.

InvalidateCache 정책을 적용하지 않은 경우(또는 콘솔에서 Require authorization(권한 부여 필요) 확인란을 선택한 경우), 모든 클라이언트가 API 캐시를 무효화할 수 있습니다. 대부분의 클라이언트가 API 캐시를 무효화할 경우 API의 지연 시간이 일시적으로 증가할 수 있습니다.

정책이 적용되면 캐싱이 활성화되어 권한 부여가 필요합니다.

API Gateway 콘솔의 무단 요청 처리에서 옵션을 선택하여 무단 요청이 처리되는 방식을 제어할 수 있습니다.

세 옵션의 동작은 다음과 같습니다.

403 상태 코드와 함께 요청 실패: 403 권한 없음 응답을 반환합니다.

API를 사용하여 이 옵션을 설정하려면 FAIL_WITH_403을 사용합니다.
캐시 컨트롤 헤더 무시, 응답 헤더에 경고 추가: 요청을 처리하고 응답에 경고 헤더를 추가합니다.

API를 사용하여 이 옵션을 설정하려면 SUCCEED_WITH_RESPONSE_HEADER을 사용합니다.
캐시 컨트롤 헤더 무시: 요청을 처리하고 응답에 경고 헤더를 추가하지 않습니다.

API를 사용하여 이 옵션을 설정하려면 SUCCEED_WITHOUT_RESPONSE_HEADER을 사용합니다.

javascript가 브라우저에서 비활성화되거나 사용이 불가합니다.

AWS 설명서를 사용하려면 Javascript가 활성화되어야 합니다. 지침을 보려면 브라우저의 도움말 페이지를 참조하십시오.

문서 규칙

최적화

콘텐츠 인코딩