TARGET_CONNECT_TIMEOUT과 함께 VPC 피어링 503 서비스를 사용할 수 없음 오류

Apigee 및 Apigee Hybrid 문서입니다.
이 주제에 해당하는 Apigee Edge 문서가 없습니다.

증상

이 문제는 API Monitoring, 디버그 또는 기타 도구에 '503 - 서비스를 사용할 수 없음' 오류로 표시됩니다. 'TARGET_CONNECT_TIMEOUT' 이유는 VPC 피어링을 사용할 때 Apigee 인스턴스와 대상 간의 연결 제한 시간을 나타냅니다.

이 오류는 504 게이트웨이 시간 초과와 같은 다른 시간 초과 오류와 혼동해서는 안 됩니다.

오류 메시지

디버그 세션 또는 응답 페이로드의 일반적인 오류입니다. 그 이유는 TARGET_CONNECT_TIMEOUT입니다.

{"fault":{"faultstring":"The Service is temporarily unavailable",
"detail":{"errorcode":"messaging.adaptors.http.flow.ServiceUnavailable",
"reason":"TARGET_CONNECT_TIMEOUT"}}}

가능한 원인

이러한 원인은 VPC 피어링으로 설정된 Apigee에만 해당됩니다. Apigee 네트워킹 옵션을 참조하세요. 대상이 PSC(엔드포인트 연결)인 경우 대신 PSC 플레이북을 참조하세요.

원인	설명
경로 구성 오류	대상 경로는 Apigee 인스턴스와의 피어링으로 내보내지 않습니다.
대상의 연결 문제	대상이 항상 TCP 연결을 수락할 수 있는 것은 아닙니다.
일부 또는 전체 Apigee NAT IP가 추가되지 않은 대상의 IP 허용 목록	모든 Apigee NAT IP가 대상에서 허용 목록에 포함되지는 않습니다.
NAT IP 포트 소진	트래픽을 수용할 수 있는 NAT 포트가 충분하지 않습니다.
connect.timeout.millis 값이 너무 낮게 설정됨	Apigee 측의 연결 제한 시간 설정이 너무 낮습니다.

일반적인 진단 단계

디버그는 문제에 대한 다음 세부정보를 캡처하고 평가하는 데 필수적인 도구입니다.

총 요청 기간입니다. 일반적으로 연결 시간 초과가 발생할 때까지 3초(기본값 connect.timeout.millis)가 걸립니다. 기간이 짧으면 대상 엔드포인트 구성을 확인하세요.
대상 호스트 이름 및 IP 주소입니다. 잘못된 IP 주소가 표시되면 DNS 관련 문제를 나타낼 수 있습니다. 또한 서로 다른 대상 IP와 문제에 상관관계가 있을 수 있습니다.
빈도입니다. 문제가 간헐적인지 또는 지속적인지에 따라 다른 접근 방법이 필요합니다.

원인: 경로 구성 오류

진단

문제가 지속되는 경우 최근에 시작되었더라도 경로 구성 오류로 인해 발생할 수 있습니다.

이는 내부(피어링된 VPC 내에서 라우팅됨) 대상과 외부(인터넷) 대상 모두에 영향을 줄 수 있습니다.

먼저 Apigee 인스턴스에서 확인된 대상의 IP 주소를 식별합니다. 방법 중 하나는 디버그 세션을 사용하는 것입니다. 디버그에서 AnalyticsPublisher(또는 기본 디버그의 AX)로 이동합니다.

화면 오른쪽에서 target.ip 값을 찾습니다.

이 예시에서 IP는 10.2.0.1입니다. 이 범위는 비공개이므로 Apigee가 대상에 도달할 수 있도록 특정 라우팅 조치를 적용해야 합니다.

대상이 인터넷에 있는 경우 Apigee에 VPC 서비스 제어가 사용 설정되어 있으면 인터넷 연결이 차단되므로 이 단계를 수행해야 합니다.
영향을 받는 Apigee 인스턴스가 배포된 리전을 확인합니다. Cloud 콘솔의 Apigee UI에서 인스턴스를 클릭합니다. 위치 필드에서 인스턴스의 정확한 리전을 찾을 수 있습니다.
Apigee와 피어링된 프로젝트의 UI에서 VPC 네트워크 -> VPC 네트워크 피어링 섹션으로 이동합니다. 공유 VPC를 사용하는 경우 Apigee 프로젝트 대신 호스트 프로젝트에서 이 단계를 수행해야 합니다.
servicenetworking-googleapis-com을 클릭하고 내보낸 경로 탭을 선택한 후 2단계에서 얻은 리전으로 필터링합니다.

이 예시에서는 내보낸 10.2.0.0/24 경로를 보여주고 10.2.0.1 예시 대상 IP를 포함합니다. 대상에 해당하는 경로가 표시되지 않는다면 문제의 원인입니다.
참고: 대상이 외부에 있으면 일반적으로 경로가 내보낸 경로에 없으며 Apigee 요청이 인터넷에 직접 라우팅됩니다. 항상 그런 것은 아니므로 원하는 네트워크 토폴로지를 명확히 해야 합니다. 예를 들어 VPC 서비스 제어가 사용 설정된 경우 외부 대상에 연결하려면 기본 경로 또는 다른 경로도 내보내야 합니다.

해결 방법

네트워크 아키텍처를 검토하고 Apigee와의 VPC 피어링으로 경로가 내보내졌는지 확인합니다. 누락된 경로는 정적 또는 동적일 가능성이 높습니다. 필요한 동적 경로가 없으면 해당 기능(예: Cloud Interconnect)에 문제가 있음을 나타냅니다.

전환 피어링은 지원되지 않습니다. 즉, VPC 네트워크 N1이 N2 및 N3과 피어링되었지만 N2와 N3이 직접 연결되지 않은 경우 VPC 네트워크 N2는 VPC 네트워크 피어링을 통해 VPC 네트워크 N3과 통신할 수 없습니다.

자세한 내용은 Southbound 네트워킹 패턴을 참조하세요.

원인: 대상의 연결 문제

진단

VPC에서 대상에 연결할 수 없거나 연결을 수락하지 못할 수 있습니다. 두 가지 방법으로 문제를 진단할 수 있습니다.

연결 테스트(비공개 대상 IP 주소)

대상이 비공개 네트워크에 있는 경우 연결 테스트 기능을 사용하여 일반적인 원인을 진단할 수 있습니다.

Apigee 인스턴스에서 확인된 대상의 IP 주소를 식별합니다. 방법 중 하나는 디버그 세션을 사용하는 것입니다.

디버그에서 AnalyticsPublisher(또는 기본 디버그의 AX)로 이동합니다. 화면 오른쪽에서 target.ip 값을 찾습니다.

이 예시에서 IP는 10.2.0.1입니다. 이것은 비공개 IP 주소이므로 연결 테스트를 사용할 수 있습니다.
대상에 연결할 수 없는 Apigee 인스턴스의 IP 주소를 확인합니다. Apigee 콘솔의 인스턴스에서 IP 주소 필드에서 Apigee 인스턴스의 IP 주소를 찾습니다.
연결 테스트로 이동하고 연결 테스트 만들기를 클릭합니다. 다음과 같은 정보를 제공하세요.
1. 소스 IP 주소: 위의 2단계에서 가져온 Apigee 인스턴스 IP를 사용합니다. 이는 Apigee가 대상에 요청을 보내는 데 사용하는 정확한 소스 IP는 아니지만 동일한 서브넷에 있으므로 테스트에 충분합니다.
2. Google Cloud에서 사용되는 IP 주소입니다: Google Cloud 프로젝트에 이 주소가 없으면 선택하지 않은 상태로 둡니다. 이 값을 확인할 경우 프로젝트와 네트워크도 제공합니다.
3. 대상 주소(1단계)와 포트를 각각 대상 IP 주소와 대상 포트로 입력합니다.
만들기를 클릭하고 테스트에서 첫 번째 실행을 마칠 때까지 기다립니다.
연결 테스트 목록에서 보기를 클릭하여 실행 결과를 확인합니다.
결과가 '연결할 수 없음'이면 구성에 문제가 있는 것입니다. 이 도구는 연결 테스트 상태 문서로 이동하여 계속 진행할 수 있도록 합니다. 상태가 '연결 가능'인 경우 많은 구성 문제가 제외됩니다. 하지만 이렇게 한다고 해서 대상에 도달할 수 있다고 보장할 수는 없습니다. 대상과 TCP 연결을 실제로 설정하려는 시도는 없었습니다. 아래의 진단만 이를 테스트하는 데 도움이 됩니다.

VM 연결 테스트(모든 대상)

Apigee와 피어링된 동일한 VPC에서 Linux에 VM 인스턴스를 만듭니다.
VM에서 연결 테스트를 수행합니다. Apigee에서 문제를 재현할 수 있는 시점에 수행하는 것이 좋습니다. telnet, curl, 기타 유틸리티를 사용하여 연결을 설정할 수 있습니다. 이 curl 예시는 3초의 제한 시간 동안 루프에서 실행됩니다. curl이 3초 내에 TCP 연결을 설정할 수 없으면 실패합니다.
```
for i in {1..100}; do curl -m 3 -v -i https://[TARGET_HOSTNAME] ; sleep 0.5 ; done
```
전체 출력을 확인하고 다음 오류를 찾습니다.
```
* Closing connection 0
 curl: (28) Connection timed out after 3005 milliseconds
```
이 오류가 있으면 Apigee 외부에서 문제를 재현할 수 있습니다.

TLS 관련 오류, 잘못된 상태 코드 등 다른 오류가 표시되면 연결 시간 초과를 확인하지 않으며 이 문제와 관련이 없습니다.
대상에 IP 허용 목록이 필요한 경우 VM 인스턴스의 소스 IP도 허용 목록에 추가해야만 VM에서 대상을 테스트할 수 있습니다.

해결 방법

연결 테스트를 기반으로 문제를 발견한 경우 문서화된 해결 단계를 진행합니다.

VM에서 제한 시간을 재현하는 경우 대상 측에서 문제를 해결하는 방법에 대한 명확한 안내가 없습니다. Apigee 외부에서 연결 제한 시간을 재현할 수 있으면 VPC에서 더 나아가 문제를 해결해야 합니다. 대상과 최대한 가깝게 연결을 테스트하세요.

대상이 VPN 연결 뒤에 있으면 로컬 네트워크에서도 테스트할 수 있습니다.

대상이 인터넷에 있는 경우 Google Cloud 콘솔 외부에서 문제를 재현해 볼 수 있습니다.

사용량이 가장 많은 시간에 문제가 발생하면 대상 연결이 과부하될 수 있습니다.

이 단계에서 Google Cloud 지원 케이스를 제출해야 하는 경우 이제 VPC에서 직접 문제를 재현할 수 있으므로 더 이상 Apigee 구성요소를 선택할 필요가 없습니다.

원인: 일부 또는 전체 Apigee NAT IP가 추가되지 않은 대상의 IP 허용 목록

진단

이는 IP 허용 목록이 사용 설정된 외부 대상(인터넷)과 관련이 있습니다. 모든 Apigee NAT IP가 영향을 받는 대상 측에 추가되었는지 확인합니다. 대상에 허용 목록이 없으면 이 섹션을 건너뛸 수 있습니다.

오류가 간헐적으로 발생하는 경우 특정 NAT IP와 오류 간의 상관관계를 찾을 수 있으므로 문제를 쉽게 발견할 수 있습니다.

문제가 지속(모든 호출이 실패함)되면 Apigee에서 NAT IP가 사용 설정되어 있는지 확인하고 다음 단계에 따라 가져옵니다.

인스턴스의 NAT IP를 나열합니다.

curl -H "Authorization: Bearer $TOKEN" \
"https://apigee.googleapis.com/v1/organizations/$ORG_ID/instances/$INSTANCE_NAME/natAddresses"

응답 예시:

{
  "natAddresses": [
    {
      "name": "nat-1",
      "ipAddress": "35.203.160.18",
      "state": "ACTIVE"
    },
    {
      "name": "nat-2",
      "ipAddress": "35.230.14.174",
      "state": "RESERVED"
    }
  ]
}

출력에 주소가 수신되지 않으면 NAT IP가 Apigee 측에 추가되지 않습니다. 주소가 수신되었지만 활성 상태가 아닌 경우 사용된 주소 중 어느 것도 인터넷 액세스를 허용하지 않는데 이는 문제이기도 합니다.

활성 주소가 하나 이상 있으면 대상에서 허용 목록에 추가될 수 있으므로 Apigee 측에 잘못된 구성이 없습니다. 이 경우 대상의 허용 목록에서 주소가 누락되었을 수 있습니다.

문제가 간헐적인 경우 NAT IP의 하위 집합만 대상의 허용 목록에 추가되었음을 나타낼 수 있습니다. 이를 확인하는 방법은 다음과 같습니다.

영향을 받는 대상이 TargetEndpoint에 지정된 새로운 역방향 프록시를 만듭니다. 대신 기존 프록시를 다시 사용하여 다음 단계로 이동할 수도 있습니다.
ServiceCallout 정책을 요청 PreFlow에 추가합니다. ServiceCallout은 'https://icanhazip.com', 'https://mocktarget.apigee.net/ip' 또는 응답에서 호출자 IP 주소를 반환하는 기타 공개 엔드포인트를 호출해야 합니다. 콘텐츠가 디버그에 표시되도록 'response' 변수에 응답을 저장합니다. 다음은 ServiceCallout 정책 구성의 예시입니다.
```
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ServiceCallout continueOnError="false" enabled="true" name="Service-Callout-1">
    <DisplayName>Service Callout-1</DisplayName>
    <Properties/>
    <Request clearPayload="true" variable="myRequest">
        <IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>
    </Request>
    <Response>response</Response>
    <HTTPTargetConnection>
        <Properties/>
        <URL>https://icanhazip.com</URL>
    </HTTPTargetConnection>
</ServiceCallout>
```
커스텀 변수에 응답을 저장할 수도 있지만, 디버그 도구에 응답을 표시하려면 AssignMessage 정책으로 해당 변수의 '.content'를 읽어야 합니다.

대상이 영향을 받는 프록시에서와 동일한 방식으로 구성되었는지 확인합니다.

참고: ServiceCallout 요청과 Target 요청은 모두 단일 트랜잭션에서 발생해야 합니다. 이는 영향을 받는 요청의 NAT IP가 ServiceCallout에서 가져온 NAT IP와 일치하도록 동일한 서버가 요청을 처리하도록 보장하기 위함입니다.
디버그 세션을 실행하고 ServiceCallout 단계를 클릭합니다.
오른쪽 하단에 요청을 수행하는 Apigee 인스턴스의 NAT IP(본문 내)가 포함된 응답 콘텐츠 섹션이 표시됩니다. 또는 ServiceCallout 응답을 다른 위치에 저장하면 해당 위치에 표시됩니다.

흐름의 후반부에서 프록시는 대상을 호출하고 응답 콘텐츠는 오류 또는 대상의 응답으로 덮어쓰입니다.
NAT IP를 문제와 연관시켜 봅니다. 특정 IP만 실패하는 경우 이는 대상에서 전체가 아닌 일부 IP만 허용 목록에 포함되었음을 나타내는 신호입니다.
NAT IP와 오류 간에 상관 관계가 없는 경우, 예를 들어 하나의 요청에서는 동일한 IP가 실패하지만 다른 요청에서는 실패하지 않는다면 허용 목록 문제가 아닐 수 있습니다. NAT 소진일 수 있습니다. 원인: NAT IP 포트 소진을 참조하세요.

해결 방법

NAT IP가 프로비저닝 및 활성화되어 있는지 확인하고 모두 대상 측에 추가되었는지 확인합니다.

원인: NAT IP 포트 소진

진단

Apigee에서만 문제를 재현할 수 있고 NAT IP가 조직에 프로비저닝된 경우 동시에 다른 대상에서 발생하는 것으로 확인된 경우, NAT 소스 포트가 소진되고 있을 수 있습니다.

문제가 발생한 기간을 확인합니다. 예: 매일 오후 5시 58분~오후 6시 8분
동일한 기간 동안 다른 대상이 문제의 영향을 받는지 확인합니다. 다른 대상은 인터넷을 통해 액세스할 수 있어야 하며 영향을 받는 원래 대상과 동일한 위치에서 호스팅되면 안 됩니다.
특정 트래픽 볼륨(tps) 이상으로만 오류가 발생하는지 설정합니다. 이렇게 하려면 문제의 기간을 기록하고 프록시 성능 대시보드로 이동합니다.
오류 기간과 초당 평균 트랜잭션 수(tps) 증가의 상관관계를 찾아봅니다.

이 예시에서 tps는 오후 5시 58분에 1000으로 증가합니다. 이 예시에서 정확히 오후 5시 58분에 문제가 발생했으며 관련 없는 두 개 이상의 대상에 영향을 미친다고 가정하면, 이는 NAT 소진과 관련된 문제를 나타냅니다.

해결 방법

고정 NAT IP 요구사항 계산의 안내에 따라 NAT IP 요구사항을 다시 계산합니다.

또한 NAT IP를 더 추가하여 문제가 해결되는지 확인할 수 있습니다. IP를 더 추가하려면 먼저 모든 대상에서 이를 허용 목록에 추가해야 할 수 있습니다.

원인: connect.timeout.millis 값이 너무 낮게 설정됨

진단

프록시에 시간 제한 값이 잘못 구성되었을 수 있습니다.

확인하려면 영향을 받는 프록시로 이동하여 해당 TargetEndpoint를 검사합니다. 'connect.timeout.millis' 속성과 해당 값을 확인합니다. 여기 예시에서 값은 50, 즉 50밀리초로, 일반적으로 너무 낮아 TCP 연결 설정을 보장할 수 없습니다. 값이 1,000 미만이면 문제 원인일 수 있습니다. 이러한 'connect.timeout.millis' 속성이 표시되지 않으면 기본값이 설정된 것이며 원인이 확인되지 않은 것입니다.

제한 시간이 있는 프록시

해결 방법

시간 단위가 밀리초 단위인지 확인하고 connect.timeout.millis 값을 수정합니다. 기본값은 3,000(3,000밀리초)입니다. 자세한 내용은 엔드포인트 속성 참조를 참조하세요.

추가 지원이 필요하면 지원팀에 문의

위 안내를 따른 후에도 문제가 지속되면 Google Cloud 지원팀에 제출할 다음 진단 정보를 수집합니다.

프로젝트 ID 및 Apigee 조직 이름
프록시 이름 및 환경
문제가 발생한 기간
문제 빈도
대상 호스트 이름
문제가 있는 디버그 세션
위의 가능한 원인에 대해 수행된 확인 결과. 예를 들어 VM의 curl 명령어 출력입니다.