이 섹션에서는 Response Cache 정책을 살펴보겠습니다. Apigee 플랫폼의 Response Cache 정책을 사용하면 백엔드 서버의 응답을 캐시할 수 있습니다. 클라이언트 애플리케이션이 동일한 백엔드 리소스에 반복적으로 요청을 수행하고 리소스가 정기적으로 업데이트된다면 이 정책을 사용하여 이러한 응답을 캐시할 수 있습니다. Response Cache 정책은 캐시된 응답을 반환하는 데 도움이 되므로 백엔드 서버로 불필요한 요청을 전달하는 것을 방지합니다.
Response Cache 정책의 이점은 다음과 같습니다.
백엔드에 도달하는 요청 수 감소
네트워크 대역폭 감소
API 성능 및 응답 시간 개선
안티패턴
ResponseCache 정책을 사용하면 기본적으로 가능한 상태 코드가 있는 HTTP 응답을 캐시할 수 있습니다. 즉, 성공 및 오류 응답을 모두 캐시할 수 있습니다.
Response Cache 정책은 기본 구성에서 오류 응답을 캐시합니다. 하지만 다음과 같은 이유로 부정적인 영향에 대해 고려하지 않은 채로 오류 응답을 캐시하는 것은 바람직하지 않습니다.
시나리오 1: 알 수 없는 기간에 일시적으로 오류가 발생하고 문제가 해결된 후에도 캐싱으로 인해 Apigee에서 오류 응답을 계속 보냅니다.
또는
시나리오 2: 오류가 일정 기간 동안 관찰되고, 문제가 해결된 후 응답을 캐싱하지 않도록 코드를 수정해야 합니다.
설명을 위해 이 두 가지 시나리오를 더 자세히 살펴보겠습니다.
시나리오 1: 일시적인 백엔드/리소스 실패
백엔드 서버 오류가 발생한 이유는 다음 중 하나입니다.
일시적인 네트워크 오류
백엔드 서버가 매우 바빠 일시적인 기간 동안 요청에 응답할 수 없음
요청한 백엔드 리소스가 일시적인 기간 동안 제거되거나 사용할 수 없음
일시적인 기간 동안 서버의 처리 시간이 길어서 백엔드 서버의 응답이 느림
이러한 경우 모두 알 수 없는 기간에 오류가 발생한 후 성공적인 응답을 받기 시작할 수 있습니다. 오류 응답을 캐시하면 백엔드 서버의 문제가 해결되어도 Apigee에서 오류 응답을 사용자에게 계속 보낼 수 있습니다.
시나리오 2: 오래되었거나 수정된 백엔드/리소스 실패
백엔드의 오류가 일정 기간 동안 발생했다고 가정해 보겠습니다. 예를 들어 다음 상황 중 하나에 해당합니다.
특정 백엔드 리소스를 1시간 동안 사용할 수 없음
또는
갑작스러운 사이트 오류, 확장 문제, 유지보수, 업그레이드 등으로 인해 백엔드 서버가 24시간 동안 삭제되거나 사용할 수 없음
이 정보를 통해 Response Cache 정책에서 캐시 만료 시간을 적절하게 설정하여 더 이상 오류 응답을 캐시하지 않도록 할 수 있습니다. 하지만 백엔드 서버/리소스를 다시 사용할 수 있게 되면 오류 응답이 캐시되지 않도록 정책을 수정해야 합니다. 이는 백엔드 서버에서 일시적인 일회성 오류가 발생하는 경우 응답을 캐시하여 위의 시나리오 1에서 설명한 것과 같은 문제를 초래하기 때문입니다.
영향
캐싱 오류가 발생하면 백엔드 서버에서 문제가 해결된 후에도 오류 응답이 전송될 수 있습니다.
사용자는 백엔드 서버에서 오류 응답을 캐싱하는 것이 문제의 원인임을 알지 못하고 문제의 원인을 해결하기 위해 많은 시간을 보낼 수 있습니다.
권장사항
응답 캐시에 오류 응답을 저장하지 않습니다. 오류 응답이 캐시되지 않도록 아래 코드 스니펫에서와 같이 ResponseCache 정책에서 <ExcludeErrorResponse> 요소가 true로 설정되어 있는지 확인합니다. 이 구성을 사용하면 성공 코드가 수정되지 않는 한 기본 성공 코드 200~205의 응답만 캐시됩니다.
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["이해하기 어려움","hardToUnderstand","thumb-down"],["잘못된 정보 또는 샘플 코드","incorrectInformationOrSampleCode","thumb-down"],["필요한 정보/샘플이 없음","missingTheInformationSamplesINeed","thumb-down"],["번역 문제","translationIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 2025-08-18(UTC)"],[[["\u003cp\u003eCaching temporarily stores data for faster retrieval, reduces processing time, and lightens the load on backend servers.\u003c/p\u003e\n"],["\u003cp\u003eApigee offers caching capabilities through PopulateCache, LookupCache, InvalidateCache, and ResponseCache policies for improved API performance.\u003c/p\u003e\n"],["\u003cp\u003eThe Response Cache policy in Apigee caches responses from backend servers to prevent repeated requests, improving API performance and reducing network bandwidth.\u003c/p\u003e\n"],["\u003cp\u003eCaching error responses with the Response Cache policy can lead to users receiving error messages even after the underlying issue has been resolved, which is generally not recommended.\u003c/p\u003e\n"],["\u003cp\u003eIt is a best practice to set the \u003ccode\u003e<ExcludeErrorResponse>\u003c/code\u003e element to \u003ccode\u003etrue\u003c/code\u003e in the ResponseCache policy to avoid caching error responses, and Apigee specifically advises against caching 5xx error responses.\u003c/p\u003e\n"]]],[],null,["# Antipattern: Cache error responses\n\n*You're viewing **Apigee** and **Apigee hybrid** documentation.\nView [Apigee Edge](https://docs.apigee.com/api-platform/antipatterns/caching-error) documentation.*\n\nCaching is a process of storing data temporarily in a storage area called cache for future\nreference. Caching data brings significant performance benefits because it:\n\n- Allows faster retrieval of data\n- Reduces processing time by avoiding regeneration of data again and again\n- Prevents API requests from hitting the backend servers and thereby reduces the overhead on the backend servers\n- Allows better utilization of system/application resources\n- Improves the response times of APIs\n\nWhenever we have to frequently access some data that doesn't change too often, we highly\nrecommend to use a cache to store this data.\n\nApigee provides the ability to store data in a cache at runtime for persistence and faster\nretrieval. The caching feature is made available through the [PopulateCache policy](/apigee/docs/api-platform/reference/policies/populate-cache-policy),\n[LookupCache policy](/apigee/docs/api-platform/reference/policies/lookup-cache-policy), [InvalidateCache policy](/apigee/docs/api-platform/reference/policies/invalidate-cache-policy), and [ResponseCache policy](/apigee/docs/api-platform/reference/policies/response-cache-policy).\n\nIn this section, let's look at Response Cache policy. The Response Cache policy in Apigee\nplatform allows you to cache the responses from backend servers. If the client applications\nmake requests to the same backend resource repeatedly and the resource gets updated\nperiodically, then we can cache these responses using this policy. The Response Cache policy\nhelps in returning the cached responses and consequently avoids forwarding the requests\nto the backend servers unnecessarily.\n\nThe Response Cache policy:\n\n- Reduces the number of requests reaching the backend\n- Reduces network bandwidth\n- Improves API performance and response times\n\nAntipattern\n-----------\n\nThe [ResponseCache policy](/apigee/docs/api-platform/reference/policies/response-cache-policy) lets you cache HTTP responses with any possible Status code,\nby default. This means that both success and error responses can be cached.\n\nHere's a sample Response Cache policy with default configuration: \n\n```gdscript\n\u003c!-- /antipatterns/examples/1-1.xml --\u003e\n\u003c?xml version=\"1.0\" encoding=\"UTF-8\" standalone=\"yes\"?\u003e\n\u003cResponseCache async=\"false\" continueOnError=\"false\" enabled=\"true\" name=\"TargetServerResponseCache\"\u003e\n \u003cDisplayName\u003eTargetServer ResponseCache\u003c/DisplayName\u003e\n \u003cCacheKey\u003e\n \u003cKey Fragment ref=\"request.uri\" /\u003e\u003c/CacheKey\u003e\n \u003cScope\u003eExclusive\u003c/Scope\u003e\n \u003cExpirySettings\u003e\n \u003cTimeoutInSec ref=\"flow.variable.here\"\u003e600\u003c/TimeoutInSec\u003e\n \u003c/ExpirySettings\u003e\n \u003cCacheResource\u003etargetCache\u003c/CacheResource\u003e\n\u003c/ResponseCache\u003e\n```\n\nThe Response Cache policy caches error responses in its default\nconfiguration. However, it is not advisable to cache error responses without\nconsiderable thought on the adverse implications because:\n\n- [Scenario 1](#scenario1): Failures occur for a temporary, unknown period and we may continue to send error responses due to caching even after the problem has been fixed\n\n **OR**\n- [Scenario 2](#scenario2): Failures will be observed for a fixed period of time, then we will have to modify the code to avoid caching responses once the problem is fixed\n\nLet's explain this by taking these two scenarios in more detail.\n\nScenario 1: Temporary backend/resource failure\n----------------------------------------------\n\nConsider that the failure in the backend server is because of one of the following reasons:\n\n- A temporary network glitch\n- The backend server is extremely busy and unable to respond to the requests for a temporary period\n- The requested backend resource may be removed/unavailable for a temporary period of time\n- The backend server is responding slow due to high processing time for a temporary period, etc\n\nIn all these cases, the failures could occur for a unknown time period and then we may start\ngetting successful responses. If we cache the error responses, then we may continue to send\nerror responses to the users even though the problem with the backend server has been fixed.\n\nScenario 2: Protracted or fixed backend/resource failure\n--------------------------------------------------------\n\nConsider that we know the failure in the backend is for a fixed period of time. For instance,\nyou are aware that either:\n\n- A specific backend resource will be unavailable for 1 hour **OR**\n\n- The backend server is removed/unavailable for 24 hours due to a sudden site failure, scaling issues, maintenance, upgrade, etc.\n\nWith this information, we can set the cache expiration time appropriately in the Response Cache\npolicy so that we don't cache the error responses for a longer time. However, once the\nbackend server/resource is available again, we will have to modify the policy to avoid caching\nerror responses. This is because if there is a temporary/one off failure from the backend\nserver, we will cache the response and we will end up with the problem explained in scenario 1 above.\n\nImpact\n------\n\n- Caching error responses can cause error responses to be sent even after the problem has been resolved in the backend server\n- Users may spend a lot of effort troubleshooting the cause of an issue without knowing that it is caused by caching the error responses from the backend server\n\nBest practice\n-------------\n\n- Don't store the error responses in the response cache. Ensure that the `\u003cExcludeErrorResponse\u003e` element is set to `true` in the [ResponseCache policy](/apigee/docs/api-platform/reference/policies/response-cache-policy) to prevent error responses from being cached as shown in the below code snippet. With this configuration only the responses for the default success codes 200 to 205 (unless the success codes are modified) will be cached. \n\n ```gdscript\n \u003c!-- /antipatterns/examples/1-2.xml --\u003e\n \u003c?xml version=\"1.0\" encoding=\"UTF-8\" standalone=\"yes\"?\u003e\n \u003cResponseCache async=\"false\" continueOnError=\"false\" enabled=\"true\" name=\"TargetServerResponseCache\"\u003e\n \u003cDisplayName\u003eTargetServerResponseCache\u003c/DisplayName\u003e\n \u003cCacheKey\u003e\n \u003cKeyFragment ref=\"request.uri\" /\u003e\n \u003c/CacheKey\u003e\n \u003cScope\u003eExclusive\u003c/Scope\u003e\n \u003cExpirySettings\u003e\n \u003cTimeoutinSec ref=\"flow.variable.here\"\u003e600\u003c/TimeoutinSec\u003e\n \u003c/ExpirySettings\u003e\n \u003cCacheResource\u003etargetCache\u003c/CacheResource\u003e\n \u003cExcludeErrorResponse\u003etrue\u003c/ExcludeErrorResponse\u003e\n \u003c/ResponseCache\u003e\n ```\n- If you have the requirement to cache the error responses for some specific reason, then you can determine the maximum/exact duration of time for which the failure will be observed (if possible):\n - Set the Expiration time appropriately to ensure that you don't cache the error responses longer than the time for which the failure can be seen.\n - Use the ResponseCache policy to cache the error responses without the `\u003cExcludeErrorResponse\u003e` element.\n\n Do this *only if you are absolutely sure that the backend server failure is not for a\n brief/temporary period*.\n- Apigee does not recommend caching 5xx responses from backend servers.\n\n| ### NOTE\n|\n| After the failure has been fixed, remove/disable the [ResponseCache policy](/apigee/docs/api-platform/reference/policies/response-cache-policy). Otherwise, the error responses for temporary backend server failures may get cached."]]
