Apigee Edge 문서입니다.
Apigee X 문서로 이동 정보
이 주제에서는 Populate Cache 정책, LookupCache 정책, InvalidateCache 정책 및 Response Cache 정책과 같은 정책 아래의 캐시 작업에 대해 설명합니다.
공유 및 환경 캐시
구성하는 각 캐싱 정책은 애플리케이션이 액세스할 수 있는 포함된 공유 캐시와 개발자가 만드는 환경 범위 캐시 중 하나를 사용할 수 있습니다.
-
공유 캐시: 기본적으로 프록시는 각 환경의 공유 캐시 하나에 액세스할 수 있습니다. 공유 캐시는 기본 사용 사례에 적합합니다.
공유 캐시는 Management API가 아닌 캐싱 정책을 사용하여야만 사용할 수 있습니다. 캐싱 정책에서 공유 캐시를 사용하도록 하려면 정책의
<CacheResource>
요소를 생략하면 됩니다. -
환경 캐시: 선택한 값으로 캐시 속성을 구성하려면 환경 범위 캐시를 만들 수 있습니다. 캐시 만들기에 관한 자세한 내용은 환경 캐시 만들기 및 수정을 참고하세요.
환경 캐시를 만들 때 기본 속성을 구성합니다. 정책의
<CacheResource>
요소에 캐시 이름을 지정하여 캐싱 정책이 환경 캐시를 사용하도록 할 수 있습니다.
캐시 암호화 정보
퍼블릭 클라우드용 Edge: 캐시는 PCI 및 HIPAA가 사용 설정된 조직에서만 암호화됩니다. 이러한 조직의 암호화는 조직 프로비저닝 중에 구성됩니다.
인메모리 및 영구 캐시 수준
공유 및 환경 캐시 모두 인메모리 수준과 영구 수준으로 구성된 2단계 시스템을 기반으로 빌드되었습니다. 정책은 결합된 프레임워크로 두 수준과 상호 작용합니다. Edge는 수준 사이의 관계를 관리합니다.
-
수준 1은 빠른 액세스를 위한 인메모리 캐시(L1)입니다. 각 메시지 처리 노드(MP)에는 요청에 대한 빠른 응답을 위한 자체 인메모리 캐시(Ehcache에서 구현)가 있습니다.
- 각 노드에서 일정 비율의 메모리가 캐시에서 사용하도록 예약됩니다.
- 메모리 한도에 도달하면 Apigee Edge는 메모리에서 캐시 항목을 삭제하여 (L2 영구 캐시에 여전히 보관) 다른 프로세스에서 메모리를 계속 사용할 수 있도록 합니다.
- 항목은 마지막 액세스 시간 순으로 삭제되며 가장 오래된 항목이 먼저 삭제됩니다.
- 이러한 캐시는 캐시의 항목 수에 따라 제한됩니다.
-
수준 2는 인메모리 캐시 아래에 있는 영구 캐시(L2)입니다. 모든 메시지 처리 노드는 캐시 항목을 유지하기 위해 캐시 데이터 저장소(Cassandra)를 공유합니다.
- 인메모리 한도에 도달하는 경우와 같이 L1 캐시에서 삭제된 후에도 캐시 항목이 유지됩니다.
- 영구 캐시는 리전이 다른 경우에도 메시지 프로세서 간에 공유되어 있으므로 캐시된 데이터에 대한 요청을 수신하는 노드와 상관없이 캐시 항목을 사용할 수 있습니다.
- 특정 크기의 항목만 캐시될 수 있으며 다른 캐시 한도가 적용됩니다. 캐시 한도 관리를 참조하세요.
Apigee 커뮤니티의 Apigee Edge 캐싱 세부정보도 참고하세요.
정책에서 캐시를 사용하는 방법
다음은 Apigee Edge에서 캐싱 정책이 작동하는 동안 캐시 항목을 처리하는 방법을 설명합니다.
- 정책이 캐시에 새 항목을 작성하는 경우(PopulateCache 또는 ResponseCache 정책):
- Edge는 요청을 처리한 메시지 프로세서에서만 메모리 내 L1 캐시에 항목을 작성합니다. 항목이 만료되기 전에 메시지 프로세서의 메모리 한도에 도달하면 Edge는 L1 캐시에서 항목을 삭제합니다.
- Edge도 항목을 L2 캐시에 작성합니다.
- 정책이 캐시에서 읽는 경우(LookupCache 또는 ResponseCache 정책):
- Edge는 먼저 요청을 처리하는 메시지 프로세서의 인메모리 L1 캐시에서 항목을 찾습니다.
- 해당하는 인메모리 항목이 없으면 Edge는 L2 영구 캐시에서 항목을 찾습니다.
- 항목이 영구 캐시에 없는 경우:
- LookupCache 정책: 캐시에서 값이 검색되지 않습니다.
- ResponseCache 정책: Edge는 대상에서 클라이언트로 실제 응답을 반환하고 항목이 만료되거나 무효화될 때까지 캐시에 항목을 저장합니다.
- 정책이 기존 캐시 항목을 업데이트 또는 무효화하는 경우(InvalidateCache, PopulateCache 또는 ResponseCache 정책):
- 요청을 수신하는 메시지 프로세서는 브로드캐스트를 전송하여 자체 및 모든 리전의 다른 모든 메시지 프로세서에서 L1 캐시의 항목을 업데이트하거나 삭제합니다.
- 브로드캐스트가 성공하면 각 수신 메시지 프로세서가 L1 캐시의 항목을 업데이트하거나 삭제합니다.
- 브로드캐스트가 실패하면 브로드캐스트를 수신하지 않은 메시지 프로세서의 무효화된 캐시 값이 L1 캐시에 남아 있습니다. 이러한 메시지 프로세서는 L1 캐시의 비활성 데이터를 항목의 TTL (수명)이 만료될 때까지 저장하거나 메시지 프로세서 메모리 한도에 도달하면 삭제합니다.
- 또한 브로드캐스트가 L2 캐시에서 항목을 업데이트하거나 삭제합니다.
- 요청을 수신하는 메시지 프로세서는 브로드캐스트를 전송하여 자체 및 모든 리전의 다른 모든 메시지 프로세서에서 L1 캐시의 항목을 업데이트하거나 삭제합니다.
캐시 한도 관리
구성을 통해 캐시의 일부 측면을 관리할 수 있습니다. 인메모리 캐시에 사용 가능한 전체 공간은 시스템 리소스에 의해 제한되며 구성할 수 없습니다. 캐시에는 다음 제약조건이 적용됩니다.
- 캐시 한도: 이름 및 값 크기, 총 캐시 수, 캐시의 항목 수, 만료 등 다양한 캐시 한도가 적용됩니다.
-
인메모리 (L1) 캐시. 캐시의 메모리 한도는 구성할 수 없습니다. 한도는 여러 고객의 캐시를 호스팅하는 각 메시지 프로세서에 대해 Apigee가 설정합니다.
모든 고객 배포에 대한 인메모리 캐시가 여러 공유 메시지 프로세서에 걸쳐 호스팅되는 호스팅 클라우드 환경에서 각 프로세서는 캐싱이 애플리케이션의 모든 메모리를 사용하지 않도록 Apigee에서 구성 가능한 메모리 백분율 임곗값을 가집니다. 지정된 메시지 프로세서에 대한 임곗값을 초과하면 가장 최근 사용 시점을 기준으로 캐시 항목이 메모리에서 삭제됩니다. 메모리에서 삭제된 항목은 만료되거나 무효화될 때까지 L2 캐시에 남아 있습니다.
- 영구 (L2) 캐시. 인메모리 캐시에서 삭제된 항목은 구성 가능한 TTL 설정에 따라 영구 캐시에 유지됩니다.
구성 가능한 최적화
다음 표에는 캐시 성능을 최적화하는 데 사용할 수 있는 설정이 나열되어 있습니다. 환경 캐시 만들기 및 수정에 설명된 대로 새 환경 캐시를 만들 때 이러한 설정의 값을 지정할 수 있습니다.
설정 | 설명 | 참고 |
---|---|---|
만료 | 캐시 항목의 TTL(수명)을 지정합니다. | 없음 |