Google은 AI 기술을 사용하여 콘텐츠를 사용자의 기본 언어로 번역합니다. AI 번역에는 오류가 있을 수 있습니다.

500 내부 서버 오류 - 스트리밍 사용

Apigee Edge 문서입니다.
Go to the Apigee X documentation. info

증상

클라이언트 애플리케이션은 API 호출에 대해 내부 서버 오류 메시지와 함께 HTTP 응답 상태 코드 500 을 수신합니다.

오류 메시지

클라이언트 애플리케이션은 아래와 같이 오류 응답을 수신할 수 있습니다.

HTTP/1.1 500 Internal Server Error

다음과 같은 오류 메시지가 표시될 수 있습니다.

{
   "fault":{
      "faultstring":"Expecting } at line 1"
      "detail":{
         "errorcode":"Internal Server Error"
      }
   }
}

OR

{
   "fault":{
      "faultstring":"Expecting ] at line 1"
      "detail":{
         "errorcode":"Internal Server Error"
      }
   }
}

가능한 원인

500 내부 서버 오류는 여러 가지 원인으로 인해 발생할 수 있습니다. 이 플레이북 에서는 스트리밍 이 사용 설정된 경우 요청/응답 페이로드에 액세스하여 발생하는 500 내부 서버 오류에 중점을 둡니다.

원인	설명	문제 해결 단계를 수행할 수 있는 사용자
스트리밍이 사용 설정된 상태에서 페이로드에 액세스	스트리밍이 사용 설정된 경우 요청/응답 페이로드에 액세스했기 때문에 오류가 발생했습니다.	Edge Private 및 Public Cloud 사용자

원인: 스트리밍이 사용 설정된 상태에서 페이로드에 액세스

진단

절차 1: 추적 사용

추적 세션을 사용 설정하고 API 호출을 통해 문제(500 내부 서버 오류)를 재현합니다.
실패한 요청 중 하나를 선택하고 추적을 검사합니다.
추적의 다양한 단계를 탐색하고 오류가 발생한 위치를 찾습니다.
이 오류는 정책이 요청/응답 페이로드를 파싱하는 동안 발생했을 수 있습니다.
다음은 JSONThreatProtection 정책 이 "1번째 줄에 }이(가) 필요합니다" 오류로 인해 실패하는 것을 보여주는 샘플 추적 스크린샷입니다.

위 스크린샷
과 같이 추적 출력에서 다음 정보를 기록해 둡니다.

실패한 정책: JSONThreatProtection

흐름: 프록시 요청

실패한 정책 정의를 검사하고 파싱 중인 페이로드를 확인합니다.

예시 시나리오에서는 실패한 JSON-Threat-Protection 이라는 JSONThreatProtection 정책을 검사하고 <Source> 요소를 확인합니다.

<JSONThreatProtection async="false" continueOnError="false" enabled="true" name="JSON-Threat-Protection">
   <DisplayName>JSON Threat Protection</DisplayName>
   <ArrayElementCount>20</ArrayElementCount>
   <ContainerDepth>10</ContainerDepth>
   <ObjectEntryCount>15</ObjectEntryCount>
   <ObjectEntryNameLength>50</ObjectEntryNameLength>
   <Source>request</Source>
   <StringValueLength>1000</StringValueLength>
</JSONThreatProtection>

<Source> 요소가 request.를 가리키는 것을 확인합니다. 즉, 요청 페이로드를 파싱하는 동안 오류가 발생했습니다.

API 요청을 확인하여 파싱 중인 페이로드의 유형을 확인합니다.

API 요청에서 요청 페이로드의 콘텐츠와 Content-Type 헤더를 확인할 수 있습니다. 다음 예시 curl 명령어에서는 JSON 페이로드가 사용됩니다.

curl -i https://VIRTUAL_HOST_ALIAS/BASEPATH -H "Content-Type: application/json" \
-X POST -d @request-payload.json

실패한 정책을 확인하고 파싱 중인 페이로드의 유형을 확인할 수도 있습니다. 위의 예시 시나리오에서는 JSON-Threat-Protection 정책이 실패합니다. 이는 페이로드가 JSON 형식이어야 함을 나타냅니다.

페이로드가 올바른 형식인지 확인합니다. 페이로드가 유효하지 않으면 이 오류가 발생할 수 있습니다.

참고: 페이로드가 큰 경우 온라인 포맷터를 사용하여 페이로드의 형식을 확인할 수 있습니다.
페이로드가 유효하지만 오류 메시지 섹션에 나열된 오류가 계속 발생하는 경우 이러한 오류의 원인은 스트리밍이 사용 설정된 경우 페이로드에 액세스하기 때문입니다.

정책에서 파싱하는 페이로드 (6단계에서 확인됨)에 따라 적절한 단계의 추적 도구에서 페이로드 콘텐츠를 검사합니다.

예시 시나리오에서는 요청 페이로드가 파싱되므로 추적에서 "클라이언트에서 수신한 요청" 단계를 검사하고 요청 콘텐츠를 확인합니다.

유효한 페이로드를 전송했음에도 불구하고 위 스크린샷과 같이 요청 콘텐츠가 비어 있는 것으로 확인되면 이 문제의 원인은 요청 스트리밍이 사용 설정되어 있기 때문일 가능성이 높습니다.

이는 스트리밍이 사용 설정된 경우 요청 페이로드가 추적에 표시되지 않기 때문입니다.

마찬가지로 오류가 발생할 때 응답 페이로드가 파싱되는 경우 응답 콘텐츠를 "대상 서버에서 수신한 응답" 단계에서 확인합니다.
다음으로 API 프록시 흐름에서 실패한 정책이 사용되는 위치에 따라 프록시 및 대상 엔드포인트 정의를 검사합니다. 스트리밍이 사용 설정되었는지 확인합니다.

예시 시나리오에서는 실패한 정책이 프록시 요청 흐름에서 실행되었습니다 (위의 5단계에서 확인됨). 따라서 프록시 엔드포인트를 검사합니다.
```
<ProxyEndpoint name="default">
...
  <HTTPProxyConnection>
    <BasePath>/v1/weather</BasePath>
    <VirtualHost>secure</VirtualHost>
    <Properties>
      <Property name="response.streaming.enabled">true</Property>
      <Property name="request.streaming.enabled">true</Property>
    </Properties>
  </HTTPProxyConnection>
</ProxyEndpoint>
```
위의 예시에서 볼 수 있듯이 속성"request.streaming.enabled"이 true로 설정되어 요청 스트리밍이 사용 설정되었습니다.

따라서 오류의 원인은 스트리밍이 사용 설정된 경우 요청 페이로드에 액세스하는 API 프록시 에서 JSONThreatProtection 정책을 사용하는 것입니다. 이로 인해 API 프록시에서 버퍼링이 트리거되고 Apigee Edge에서 스트리밍을 사용하는 목적이 무효화되므로 오류가 발생합니다.

이 오류는 작은 페이로드에서는 표시되지 않을 수 있지만 큰 페이로드를 사용하면 이러한 오류가 표시될 수 있습니다.
아래 단계에 따라 추적의 "AX" (분석 데이터 기록됨) 단계에서 "X-Apigee-fault-source" 값을 확인하여 정책으로 인해 500 오류가 발생하는지 확인할 수 있습니다.
1. 아래 스크린샷과 같이 "AX" (분석 데이터 기록됨) 단계 를 클릭합니다.
2. 단계 세부정보를 "오류 헤더" 섹션까지 아래로 스크롤하고 아래와 같이 "X-Apigee-fault-code", "X-Apigee-fault-source" 및 "X-Apigee-fault-policy" 값을 확인합니다.
3. 위 그림과 같이 "X-Apigee-fault-source" 값이 "정책" 인 경우 스트리밍이 사용 설정된 경우 정책이 페이로드에 액세스하여 오류가 발생했음을 나타냅니다.

해상도

스트리밍이 사용 설정된 상태에서 페이로드에 액세스하는 것은 안티패턴: 스트리밍이 사용 설정된 경우 요청/응답 페이로드에 액세스에 설명된 대로 안티패턴입니다.

페이로드를 처리하려면 아래 예시 ProxyEndpoint와 같이 "request.streaming.enabled" and "response.streaming.enabled" 속성을 삭제하여 프록시/대상 엔드포인트에서 스트리밍을 사용 중지해야 합니다.
```
<ProxyEndpoint name="default">
...
  <HTTPProxyConnection>
    <BasePath>/v1/weather</BasePath>
    <VirtualHost>secure</VirtualHost>
  </HTTPProxyConnection>
</ProxyEndpoint>
```
또는
API 프록시에 스트리밍을 사용하려면 요청/응답 페이로드에 액세스하는 API 프록시에서 정책을 사용하지 마세요.

참고:

이 플레이북에서는 예시 시나리오에서 스트리밍이 사용 설정된 요청 페이로드를 처리하는 데 JSONThreatProtection 정책이 사용되었습니다. 이로 인해 다양한 오류가 포함된 500 내부 서버 오류가 발생했습니다.
이러한 오류는 스트리밍이 사용 설정된 경우 요청 또는 응답 페이로드를 처리하는 JSONToXML 및 XMLToJSON과 같은 정책에서도 발생할 수 있습니다.
스트리밍이 사용 설정된 경우 페이로드에 액세스해야 하는 프록시에서는 이러한 정책을 사용하지 않는 것이 좋습니다.
안티패턴: 스트리밍이 사용 설정된 경우 요청/응답 페이로드에 액세스에 설명된 대로 이렇게 하는 것은 안티패턴입니다. 안티패턴: 스트리밍이 사용 설정된 경우 요청/응답 페이로드에 액세스에 설명된 대로 이렇게 하는 것은 안티패턴입니다.

API 모니터링을 사용하여 문제 진단

Private Cloud 사용자인 경우 이 절차를 건너뜁니다.

API 모니터링을 사용하면 문제 영역을 빠르게 격리하여 오류, 성능, 지연 시간 문제 및 개발자 앱, API 프록시, 백엔드 대상, API 플랫폼과 같은 원인을 진단할 수 있습니다.

API 모니터링을 사용하여 API의 5xx 문제를 해결하는 방법을 보여주는 샘플 시나리오를 단계별로 설명합니다. 예를 들어 500 오류 수가 특정 기준을 초과할 때 알림을 받도록 설정할 수 있습니다.

정책에서 500 오류 응답이 발생할 때 알림을 받으려면 오류 소스 가프록시 인 500 상태 코드 에 대한 알림을 설정해야 합니다.

진단 정보 수집 필요

위 안내를 따른 후에도 문제가 지속되면 다음 진단 정보를 수집하세요. Apigee 지원팀에 문의하고 공유하세요.

Public Cloud 사용자인 경우 다음 정보를 제공하세요.

조직 이름
환경 이름
API 프록시 이름
500 오류를 재현하기 위한 요청 페이로드 (있는 경우)와 함께 전체 curl 명령어
500 내부 서버 오류가 있는 요청이 포함된 추적 파일
500 오류가 현재 발생하지 않는 경우 과거에 500 오류가 발생한 기간을 시간대 정보와 함께 제공합니다.

Private Cloud 사용자인 경우 다음 정보를 제공하세요.

실패한 요청에 대해 관찰된 전체 오류 메시지
500 오류가 관찰되는 조직, 환경 이름, API 프록시 이름
API 프록시 번들
요청에 사용된 페이로드 (있는 경우)
500 내부 서버 오류가 있는 요청이 포함된 추적 파일
NGINX 액세스 로그 (/opt/apigee/var/log/edge-router/nginx/ <org>~ <env>.<port#>_access_log)
메시지 프로세서 로그 (/opt/apigee/var/log/edge-message-processor/logs/system.log)
500 오류가 발생한 시간대의 시간대 정보가 포함된 기간