API Gateway의 REST API 캐시 설정

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

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

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

이것은 HIPAA 적격 서비스입니다. AWS, 1996년 미국 HIPAA(Health Insurance Portability and Accountability Act) 및 AWS 서비스를 사용하여 보호되는 건강 정보(PHI)를 처리, 저장 및 전송하는 방법에 대한 자세한 내용은 HIPAA 개요를 참조하십시오.

Amazon API Gateway 캐싱 활성화

API Gateway에서 지정된 단계의 모든 메서드에 대해 캐싱을 활성화할 수 있습니다.

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

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

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

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

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

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

메서드 수준 캐싱에 대한 API Gateway 단계 수준 캐싱 재정의

특정 방법에 대한 캐싱을 켜거나 꺼서 스테이지 수준 캐시 설정을 재정의할 수 있습니다. TL 기간을 늘리거나 줄이거나 캐싱된 응답에 대해 암호화를 켜거나 끕니다.

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

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

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

메서드 또는 통합 파라미터를 캐시 키로 사용하여 캐시된 응답을 인덱싱할 수 있습니다. 여기에는 사용자 지정 헤더, 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 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 권한을 사용하여 REST API에 대한 액세스 제어 단원을 참조하세요.

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

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

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

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