API 호출의 성능 문제 해결

아티클
11/20/2024

Azure API Management 문제 해결 시리즈의 블로그를 참조하면 랩의 네 번째 시나리오입니다. 이에 따라 랩 설정 지침을 따라 문제를 다시 만들어야 합니다.

원래 제품 버전: API Management 서비스
원래 KB 번호: 4464929

증상

APIM의 API ProductStore 는 백 엔드 엔드포인트(https://productstoreapp.azurewebsites.net)와 통신하여 필요할 때 레코드를 쉽게 만들고, 읽고, 업데이트하고, 삭제합니다. 그러나 아래에 나열된 API 작업을 호출하는 동안 몇 가지 성능 문제 및 예외가 발생할 수 있습니다. 테스트를 쉽게 수행하려면 ID가 1에서 3까지인 제품 3개만 유지합니다.

Products_GetAllProducts API 함수 중 하나는 결과를 반환하는 데 5초가 걸리는 반면 예상 응답 시간은 1초 미만입니다.
위에서 언급한 ID(1~3)가 있는 제품을 삭제하는 동안 Products_DeleteProduct 작업을 호출하여 아래 메시지와 함께 HTTP 500 - 내부 서버 오류가 발생합니다.

{
"Message": "오류가 발생했습니다."
}
제품을 업데이트하는 Products_PutProduct 작업이 예기치 않게 제한되어 HTTP 429 - 요청에서 보내는 제품 ID 및 요청 본문에 관계없이 아래 오류 메시지가 포함된 요청이 너무 많습니다. 예를 들어 고객이 아래 Json 본문으로 제품 ID = 1을 갖는 "토마토 수프"의 제품 가격을 업데이트하면 HTTP 429 상태 코드를 받습니다.

템플릿 매개 변수 ID: 1
요청 본문: {"Name": "토마토 수프","카테고리": "식료품","가격": 2.45}
응답 본문:
{
속도 제한을 초과했습니다. 잠시 후 다시 시도하십시오.
}

문제 해결 단계

성능 문제를 해결하는 동안 가장 좋은 방법은 [각 섹션(인바운드/백 엔드/아웃바운드)에서 소요된 시간을 보여 주는 APIM 검사기 추적]을 캡처하는 것입니다.
첫 번째 문제에 대한 API 검사기 추적을 분석하는 경우 백 엔드 섹션이 대부분의 시간(약 5초)을 소요한다는 것을 알 수 있습니다. 즉, 백 엔드에서 약간의 속도 저하 또는 장기 실행 작업이 수행되고 있음을 의미합니다.

"source": "forward-request",
"timestamp": "2018-07-29T16:16:46.6615081Z",
"경과됨": "00:00:05.5844430","data": {
"response": {
"status": {
"code": 200,
"reason": "OK"
}

속도가 백 엔드에 있음을 격리한 후에는 Web API 애플리케이션의 백 엔드 애플리케이션 코드를 조사해야 합니다. 백 엔드에 액세스할 수 없는 시나리오의 경우 아래와 같이 APIM 수준에서 캐싱을 구현할 수 있습니다. Azure API Management에서 성능을 향상시키기 위해 캐싱 정책을 구현하는 방법에 대해 알아봅니다.

<?xml version="1.0" encoding="UTF-8"?>
<policies>
   <inbound>
      <base />
      <cache-lookup vary-by-developer="true" vary-by-developer-groups="true" must-revalidate="true" downstream-caching-type="public" />
   </inbound>
   <backend>
      <base />
   </backend>
   <outbound>
      <base />
      <cache-store duration="60" />
   </outbound>
   <on-error>
      <base />
   </on-error>
</policies>

두 번째 문제(HTTP 500 - 내부 서버 오류)의 경우 APIM 검사기 추적을 분석하는 동일한 절차에 따라 'forward-request' 응답 특성 아래에 HTTP 500 상태 코드가 표시됩니다.
즉, 백 엔드 코드에서 처리되지 않은 예외가 발생하여 백 엔드 API가 HTTP 500을 반환했습니다. APIM 수준에서는 문제가 없습니다.

forward-request(841.060ms)
{
"response": {
"status": {
"code": 500,
"reason": "Internal Server Error"
}
세 번째 문제(HTTP 429 - 요청이 너무 많음)의 경우 API 호출 속도 제한에 도달한 것 같습니다. 작업 수준에서 구현된 '속도 제한' 또는 'rate-limit-by-key' 정책이 있는지 확인할 수 있습니다.
작업 수준에서 이러한 정책을 찾을 수 없는 경우 이 문제를 일으킬 수 있는 제품 수준에서 일부 정책이 있을 수 있는 것처럼 다양한 수준의 상속된 모든 정책을 표시하는 유효 정책 계산 단추를 클릭합니다.

여기서 일부 정책은 API 호출 속도를 실제로 제한하지 않지만 아웃바운드 섹션에서 'return-response' 및 'set-status' 정책을 사용하여 클라이언트에 사용자 지정된 응답을 다시 반환하여 해당 작업을 모방하는 API 수준에서 구현됩니다.

<?xml version="1.0" encoding="UTF-8"?>
<outbound>
   <!--base: Begin Api scope-->
   <return-response>
      <set-status code="429" reason="Too many requests" />
      <set-body><![CDATA[{

Rate limit is exceeded. Try again after some time.

}]]></set-body>
   </return-response>
   <!--base: End Api scope-->
</outbound>

도움을 요청하십시오.

질문이 있거나 도움이 필요한 경우 지원 요청을 생성하거나 Azure 커뮤니티 지원에 문의하세요. Azure 피드백 커뮤니티에 제품 피드백을 제출할 수도 있습니다.

다음을 통해 공유

API 호출의 성능 문제 해결

증상

문제 해결 단계

도움을 요청하십시오.

피드백

추가 리소스