적용 대상: 모든 API Management 계층
API 요청 및 관련 정보에 대한 응답을 저장하고 검색하도록 Azure API Management에서 캐싱을 구성합니다. API Management는 백 엔드 서비스의 응답을 저장하여 캐시에서 직접 후속 동일한 요청을 처리할 수 있으므로 백 엔드 서비스를 반복적으로 호출할 필요가 줄어듭니다. 캐싱은 API 성능을 향상시키고, 백 엔드 로드를 줄이며, API Management를 통해 API를 호출하는 고객의 전반적인 환경을 향상시킬 수 있습니다.
이 문서에서는 API Management의 캐싱 옵션에 대해 설명하고 주요 시나리오 및 구성 고려 사항을 강조 표시합니다.
중요합니다
캐싱을 사용하려면 캐싱 서비스(API Management 서비스의 일부로 자동으로 배포된 내부 캐시 또는 사용자가 배포한 외부 캐시)와 캐싱 정책을 구성하여 캐싱을 API 요청에 적용하는 방법을 지정해야 합니다.
캐싱 서비스 옵션
Azure API Management는 다양한 성능 및 아키텍처 요구 사항을 충족하기 위해 다음과 같은 캐싱 서비스 옵션을 제공합니다.
내부(기본 제공): 내부(기본 제공) 캐시는 소비 계층을 제외한 모든 API Management 서비스 계층에서 자동으로 프로비전됩니다. 내부 캐시 구현은 클래식 계층(개발자, 기본, 표준 및 프리미엄)과 v2 계층(기본 v2, Standard v2 및 Premium v2) 간에 다릅니다. v2 계층의 기본 제공 캐시는 향상된 안정성을 제공합니다. 기본 제공 캐시를 사용한 캐싱에 대해 자세히 알아봅니다.
외부 캐시: 향상된 성능 및 지속성을 위해 필요에 따라 API Management 서비스 계층 또는 게이트웨이와 함께 사용하도록 Azure Managed Redis와 같은 외부 Redis 호환 캐시를 구성합니다. Azure Managed Redis를 사용하여 외부 캐시를 설정하는 방법에 대해 자세히 알아봅니다.
다음 표에서는 내부 및 외부 캐시의 기능을 비교합니다.
| Capability | 내부 | External |
|---|---|---|
| 자동 프로비저닝 및 관리 | ✔️ | ❌ |
| 추가 비용 | ❌ | ✔️ |
| 사용자 지정 구성 | ❌ | ✔️ |
| 모든 계층 및 게이트웨이의 가용성 | 소비 계층 또는 자체 호스팅 게이트웨이에서 사용할 수 없음 | ✔️ |
| 지역 저장소 | API Management 인스턴스와 동일한 지역에 제공되고 배율 단위 간에 공유되는 캐시입니다. 다중 지역 배포에서 각 지역에는 자체 캐시가 있습니다. |
고객의 기본 설정에 따라 다름 |
| 영구 스토리지 | v2 계층에서 영구적입니다. 클래식 계층(개발자, 기본, 표준 및 프리미엄)에서는 서비스 업데이트가 수행되면 캐시 콘텐츠가 유지 되지 않습니다 . |
✔️ |
| 계층별 제한 | 캐시 크기는 서비스 계층에 따라 다릅니다. | 제한되지 않음 |
| 여러 API Management 인스턴스의 공유 액세스 | ❌ | ✔️ |
| 시맨틱 캐싱 지원 | ❌ | ✔️ |
| 데이터 미리 로드 및 제거 지원 | ❌ | ✔️ |
캐싱 시나리오
다음 표와 같은 시나리오의 경우 Azure API Management에서 캐싱을 사용합니다.
| Scenario | Description | 캐시 유형 | 캐시 가용성 또는 연결이 끊어진 동작 |
|---|---|---|---|
| 클라이언트 환경 최적화 | 클라이언트에 대한 반복적인 요청 처리 속도를 향상합니다. | 내부 또는 외부 | 백 엔드는 요청을 제공하며 캐시를 사용할 수 없는 경우 전체 로드를 처리해야 합니다. |
| 비용 제어 및 백 엔드 크기 조정 | 백 엔드가 전체 트래픽에 맞게 확장되지 않는 경우 백 엔드 로드 및 비용을 줄입니다. | External | 캐시 및 서비스 구성에 따라 달라집니다. 권장 사항: 안정성이 가장 높은 캐시 서비스 계층을 선택하고 성능을 모니터링합니다. |
| 메타데이터 저장소 | cache-store-value를 사용하여 캐시에 임의의 데이터를 저장합니다. | 내부 또는 외부 | 캐시 및 서비스 구성에 따라 달라집니다. |
Considerations:
캐싱 시나리오에서 캐시 가용성 또는 연결이 손실되는 가능성을 고려합니다. API Management는 캐시의 가용성을 보장하기 위해 "최선의 노력" 접근 방식을 사용합니다. 구성된 캐시를 사용할 수 없는 경우 캐시 누락이 발생하고 기본적으로 요청은 백 엔드 서비스로 계속 진행됩니다.
API Management 클래식 계층에서 내부 캐시는 일시적이며 서비스 업데이트 간에 유지되지 않습니다. 서비스 업데이트 동안 내부 캐시는 전체 캐시의 최대 50%씩 점진적으로 지워집니다.
비고
업데이트에 대한 유지 관리 기간을 포함하여 서비스 업데이트 설정을 구성하여 내부 캐시 손실과 같은 잠재적인 고객 영향을 최소화할 수 있습니다.
외부 캐시를 구성하는 경우 영구적일 수 있지만 가용성 및 연결을 보장해야 합니다.
캐시를 사용할 수 없을 때 오버로드될 수 있는 트래픽 급증으로부터 백 엔드 서비스를 보호하려면 캐시 조회 정책 바로 후에 속도 제한 정책(속도 제한 또는 키별 속도 제한)을 구성합니다.
캐싱 정책
Azure API Management에서 API 응답을 캐시하고 검색하는 방법을 제어하도록 캐싱 정책을 구성합니다.
기본적으로 캐싱 정책에서 API Management는 구성된 경우 외부 캐시를 사용하고, 그렇지 않으면 기본 제공 캐시로 대체합니다.
API Management는 다음 표와 같이 캐싱 정책을 쌍으로 제공합니다. 정책 정의에서 캐시된 응답을 확인하도록 섹션에서 캐시 조회 정책을
inbound구성하고, 캐시에 성공한 응답을 저장하도록 섹션의outbound캐시 저장소 정책을 구성합니다.
| Policies | Description | Usage |
|---|---|---|
| cache-lookup / cache-store | - 캐시에서 응답 검색 - 캐시 요청에 응답 저장 |
- 동일한 GET 요청에 대해 캐시에서 전체 API 응답을 검색하는 데 사용 |
| 캐시-조회-값 / 캐시-저장-값 | - 캐시에서 특정 값 검색 - 캐시에 특정 값 저장 |
- 특정 캐시 키를 사용하는 사용자 지정 캐싱 시나리오에 사용 |
| Azure-OpenAI-시맨틱 캐시 조회 / Azure-OpenAI-시맨틱 캐시 저장 | - Azure OpenAI API 요청에 대한 의미상 유사한 응답이 캐시에 있는지 확인합니다. - Azure OpenAI API 요청에 대한 응답 저장 |
- Azure OpenAI 채팅 완료 API 요청에 대한 유사한 응답을 검색하는 데 사용 |
| llm-시맨틱-캐시-조회 / llm-시맨틱-캐시-저장 | - LLM API 요청에 대한 의미상 유사한 응답이 캐시에 있는지 확인합니다. - LLM API 요청에 대한 응답 저장 |
- LLM 채팅 완료 API 요청에 대한 유사한 응답을 검색하는 데 사용 |
팁 (조언)
- 캐시에 항목을 저장하는 정책에는 캐시된 항목이 지속되는 기간을 지정하는 특성이 포함
duration됩니다. - cache-remove-value를 사용하여 캐시에서 키로 식별되는 특정 값을 제거합니다.
캐싱 정책 예제
다음은 API Management의 캐싱 정책의 기본 예제입니다. 자세한 예제는 캐싱 정책 참조 문서를 참조하세요.
응답 캐싱
백 엔드 호출 없이 동일한 요청을 제공하도록 내부 캐시에서 전체 API 응답을 캐시합니다. 이 예제에서 캐시는 7일 동안 응답을 저장합니다.
<policies>
<inbound>
<base />
<cache-lookup vary-by-developer="false" vary-by-developer-groups="false" downstream-caching-type="none" must-revalidate="true" caching-type="internal" >
<vary-by-query-parameter>version</vary-by-query-parameter>
</cache-lookup>
</inbound>
<outbound>
<cache-store duration="604800" />
<base />
</outbound>
</policies>
값 캐싱
여러 요청에서 다시 사용할 특정 데이터 값을 캐시합니다.
<policies>
<inbound>
<cache-lookup-value key="user-preferences" default-value="none" variable-name="preferences" />
<choose>
<when condition="@(context.Variables["preferences"].ToString() == "none")">
<!-- Load preferences from backend -->
<send-request mode="new" response-variable-name="prefsResponse">
<set-url>https://backend.api/user/preferences</set-url>
</send-request>
<cache-store-value key="user-preferences" value="@(((IResponse)context.Variables["prefsResponse"]).Body.As<string>())" duration="1800" />
</when>
</choose>
</inbound>
</policies>
속도 제한 보호
캐시 조회를 속도 제한과 결합하여 백 엔드 서비스를 보호하는 것이 가장 좋습니다.
<policies>
<inbound>
<cache-lookup-value key="@("data-" + context.Request.IpAddress)" variable-name="cachedData" />
<choose>
<when condition="@(!context.Variables.ContainsKey("cachedData"))">
<rate-limit calls="10" renewal-period="60" />
<!-- Proceed to backend -->
</when>
<otherwise>
<!-- Return cached data without rate limiting -->
<return-response>
<set-body>@((string)context.Variables["cachedData"])</set-body>
</return-response>
</otherwise>
</choose>
</inbound>
</policies>
보안 고려 사항
- 중요한 데이터: 중요한 정보 또는 개인 정보가 포함된 응답 캐싱 방지
- 캐시 키: 캐시 키가 로그 또는 진단에서 중요한 정보를 노출하지 않도록 합니다.
- 액세스 제어: 외부 캐시에는 적절한 네트워크 보안 및 액세스 제어가 필요합니다.
- 암호화: 외부 캐시 인스턴스에 대한 연결에 TLS/SSL 사용
관련 콘텐츠
- API Management의 캐시 정책에 대해 자세히 알아보기
- Azure Managed Redis를 사용하여 외부 캐싱 설정
- 고급 시나리오를 사용하는 사용자 지정 캐싱 예제
- API Management 성능 및 캐싱 메트릭 모니터링