인터넷 네트워크 엔드포인트 그룹으로 외부 백엔드 설정

참고: 이 가이드는 Google Cloud API가 포함된 Cloud Service Mesh만 지원하고 Istio API를 지원하지 않습니다. 자세한 내용은 Cloud Service Mesh 개요를 참조하세요.

이 문서에서는 정규화된 도메인 이름이 필요한 인터넷 네트워크 엔드포인트 그룹(NEG)을 사용하여 Cloud Service Mesh의 외부 백엔드를 구성하는 방법을 설명합니다. 이 문서는 다음 주제에 대해 중급부터 고급 수준의 지식을 갖춘 사용자를 대상으로 합니다.

• 외부 애플리케이션 부하 분산기
• Cloud DNS
• Cloud Service Mesh
• 하이브리드 연결

이 설정 가이드에서는 다음에 대한 기본 안내를 제공합니다.

• 아웃바운드 트래픽에 인터넷 NEG 및 인증되지 않은 TLS를 사용하도록 Cloud Service Mesh 구성
• 서비스 메시에서 Cloud Run 서비스로 트래픽 라우팅

시작하기 전에

인터넷 네트워크 엔드포인트 그룹을 사용하는 Cloud Service Mesh 개요를 검토하세요.

이 가이드에서는 예시 구성이 다음 가정을 따릅니다.

• 중간 프록시, Cloud Service Mesh 리소스, Cloud DNS 영역, 하이브리드 연결과 같은 모든 관련 Compute Engine 리소스는 기본 Virtual Private Cloud(VPC) 네트워크에 연결됩니다.
• example.com:443 서비스는 온프레미스 인프라에서 실행됩니다. example.com 도메인은 3개 엔드포인트인 10.0.0.100, 10.0.0.101, 10.0.0.102에서 제공됩니다. Envoy 프록시에서 원격 엔드포인트로 연결을 보장하는 경로가 존재합니다.

결과 배포는 다음과 비슷합니다.

인터넷 NEG를 사용한 설정 예시(확대하려면 클릭)

인터넷 NEG 및 SNI를 사용한 TLS를 사용한 트래픽 라우팅

아웃바운드 트래픽에 대해 FQDN 및 TLS를 사용하여 인터넷 NEG로 Cloud Service Mesh를 구성한 후 배포 예시는 다음 다이어그램 및 트래픽 설명에 표시된 대로 작동합니다.

예시에서 트래픽이 라우팅되는 방식(확대하려면 클릭)

다음 범례의 단계는 이전 다이어그램의 번호 지정을 따릅니다.

단계	설명
0	Envoy가 xDS를 통해 Cloud Service Mesh에서 FQDN 백엔드 구성을 수신합니다.
0	VM에서 실행되는 Envoy가 구성된 FQDN에 대한 DNS를 지속적으로 쿼리합니다.
1	사용자 애플리케이션이 요청을 시작합니다.
2	요청의 매개변수입니다.
3	Envoy 프록시가 요청을 가로챕니다. 이 예시에서는 0.0.0.0을 전달 규칙 가상 IP 주소(VIP)로 사용한다고 가정합니다. 0.0.0.0이 VIP이면 Envoy가 모든 요청을 가로챕니다. 요청 라우팅은 애플리케이션에서 생성된 원본 요청의 대상 IP 주소에 관계없이 레이어 7 매개변수만 기반으로 합니다.
4	Envoy가 정상 원격 엔드포인트를 선택하고 클라이언트 TLS 정책에서 가져온 SNI로 TLS 핸드셰이크를 수행합니다.
5	Envoy가 요청을 원격 엔드포인트에 프록시합니다.

다이어그램에 표시되지 않았지만 상태 확인이 구성되었으면 Envoy가 원격 엔드포인트에 대해 상태 확인을 계속 수행하고 정상 엔드포인트로만 요청을 라우팅합니다.

하이브리드 연결 설정

이 문서에서는 하이브리드 연결도 이미 설정되어 있다고 가정합니다.

• VPC 네트워크와 온프레미스 서비스 또는 타사 퍼블릭 클라우드 사이의 하이브리드 연결은 Cloud VPN 또는 Cloud Interconnect로 설정됩니다.
• VPC 방화벽 규칙과 경로가 Envoy에서 비공개 서비스 엔드포인트로, 선택적으로 온프레미스 DNS 서버로의 양방향 연결 가능성을 설정하도록 올바르게 구성됩니다.
• 성공한 리전별 HA 장애 조치 시나리오의 경우 전역 동적 라우팅이 사용 설정됩니다. 자세한 내용은 동적 라우팅 모드를 참조하세요.

Cloud DNS 구성 설정

다음 명령어를 사용하여 엔드포인트 10.0.0.100, 10.0.0.101, 10.0.0.102, 10.0.0.103을 가리키는 A 레코드가 있는 도메인(FQDN) example.com의 Cloud DNS 비공개 영역을 설정합니다.

gcloud

1. DNS 관리 비공개 영역을 만들고 이를 기본 네트워크에 연결합니다.

    gcloud dns managed-zones create example-zone \
        --description=test \
        --dns-name=example.com \
        --networks=default \
        --visibility=private
    

1. DNS 레코드를 비공개 영역에 추가합니다.

    gcloud dns record-sets transaction start \
        --zone=example-zone

    gcloud dns record-sets transaction add 10.0.0.100 10.0.0.101 10.0.0.102 10.0.0.103 \
        --name=example.com \
        --ttl=300 \
        --type=A \
        --zone=example-zone

    gcloud dns record-sets transaction execute \
        --zone=example-zone
    

인터넷 FQDN NEG로 Cloud Service Mesh 구성

이 섹션에서는 인터넷 FQDN NEG로 Cloud Service Mesh를 구성합니다.

NEG, 상태 점검, 백엔드 서비스 만들기

gcloud

1. 인터넷 NEG를 만듭니다.

    gcloud compute network-endpoint-groups create on-prem-service-a-neg \
        --global \
        --network-endpoint-type INTERNET_FQDN_PORT
    

1. FQDN:Port 엔드포인트를 인터넷 NEG에 추가합니다.

    gcloud compute network-endpoint-groups update on-prem-service-a-neg \
        --global \
        --add-endpoint=fqdn=example.com,port=443
    

1. 전역 상태 확인을 만듭니다.

    gcloud compute health-checks create http service-a-http-health-check \
        --global
    

1. Create a global backend service called on-prem-service-a라는 전역 백엔드 서비스를 만들고 여기에 상태 확인을 연결합니다.

    gcloud compute backend-services create on-prem-service-a \
        --global \
        --load-balancing-scheme=INTERNAL_SELF_MANAGED \
        --health-checks service-a-http-health-check
    

1. on-prem-service-a-neg라는 NEG를 백엔드 서비스의 백엔드로 추가합니다.

    gcloud compute backend-services add-backend on-prem-service-a \
        --global \
        --global-network-endpoint-group \
        --network-endpoint-group on-prem-service-a-neg
    

라우팅 규칙 맵 만들기

URL 맵, 대상 HTTP 프록시, 전달 규칙은 라우팅 규칙을 구성하며, 메시의 트래픽에 대한 라우팅 정보를 제공합니다.

이 URL 맵에는 모든 HTTP 트래픽을 on-prem-service-a로 라우팅하는 규칙이 포함됩니다.

gcloud

1. URL 맵을 만듭니다.

    gcloud compute url-maps create td-url-map \
        --default-service on-prem-service-a
    

1. 대상 HTTP 프록시를 만들고 URL 맵을 대상 프록시와 연결합니다.

    gcloud compute target-http-proxies create td-proxy \
        --url-map td-url-map
    

1. IP 주소 0.0.0.0을 사용하여 전역 전달 규칙을 만듭니다. 이것은 데이터 영역이 대상 IP 주소를 무시하고 요청의 HTTP 매개변수를 기반으로 요청을 라우팅하게 만드는 특별한 IP 주소입니다.

    gcloud compute forwarding-rules create td-forwarding-rule \
        --global \
        --load-balancing-scheme=INTERNAL_SELF_MANAGED \
        --address=0.0.0.0 \
        --target-http-proxy=td-proxy \
        --ports=443 \
        --network=default
    

인증되지 않은 TLS 및 HTTPS 구성

선택적으로 Envoy 프록시 및 온프레미스 서비스 사이에 인증되지 않은 HTTPS를 구성하려면 이 안내를 따르세요. 이 안내에서는 TLS 핸드셰이크로 SNI를 구성하는 방법도 보여줍니다.

클라이언트 TLS 정책은 클라이언트가 특정 서비스로 아웃바운드 요청을 전송할 때 클라이언트 ID 및 인증 메커니즘을 지정합니다. 클라이언트 TLS 정책은 securitySettings 필드를 사용하여 백엔드 서비스 리소스에 연결됩니다.

gcloud

1. 클라이언트 TLS 정책을 만들고 가져옵니다. SNI를 NEG에 구성한 FQDN으로 설정합니다.

    cat << EOF > client_unauthenticated_tls_policy.yaml
    name: "client_unauthenticated_tls_policy"
    sni: "example.com"
    EOF

    gcloud beta network-security client-tls-policies import client_unauthenticated_tls_policy \
        --source=client_unauthenticated_tls_policy.yaml \
        --location=global
    

1. 이전 섹션에서 백엔드 서비스로 HTTP 상태 확인을 구성한 경우 백엔드 서비스에서 상태 확인을 분리합니다.

    gcloud compute backend-services update on-prem-service-a \
        --global \
        --no-health-checks
    

1. HTTPS 상태 확인을 만듭니다.

    gcloud compute health-checks create https service-a-https-health-check \
        --global
    

1. 이전에 만든 백엔드 서비스에 클라이언트 TLS 정책을 연결합니다. 그러면 클라이언트에서 이 백엔드 서비스로의 모든 아웃바운드 요청에 인증되지 않은 HTTPS가 적용됩니다.

    gcloud compute backend-services export on-prem-service-a \
        --global \
        --destination=on-prem-service-a.yaml

    cat << EOF >> on-prem-service-a.yaml
    securitySettings:
      clientTlsPolicy: projects/${PROJECT_ID}/locations/global/clientTlsPolicies/client_unauthenticated_tls_policy
    healthChecks:
      - projects/${PROJECT_ID}/global/healthChecks/service-a-https-health-check
    EOF

    gcloud compute backend-services import on-prem-service-a \
        --global \
        --source=on-prem-service-a.yaml
    

인터넷 FQDN NEG를 사용하여 DNS 확인 가능한 외부 및 내부 서비스 또는 Cloud Run 서비스와 같이 FQDN을 통해 연결될 수 있는 서비스로 트래픽을 라우팅할 수 있습니다.

IP:Port NEG에서 FQDN:Port NEG로 마이그레이션

NON_GCP_PRIVATE_IP_PORT NEG에서는 서비스 엔드포인트를 NEG에 정적 IP:PORT 쌍으로 프로그래밍해야 하고, INTERNET_FQDN_NEG에서는 DNS를 사용하여 엔드포인트를 동적으로 확인할 수 있습니다. 온프레미스 서비스 엔드포인트에 대해 DNS 레코드를 설정하고 다음 단계에 설명된 대로 Cloud Service Mesh를 구성하여 인터넷 NEG로 마이그레이션할 수 있습니다.

1. FQDN에 대해 DNS 레코드를 설정합니다.
2. FQDN으로 새 인터넷 NEG를 만듭니다.
3. 2단계에서 백엔드로 만든 인터넷 NEG를 사용하여 새 백엔드 서비스를 만듭니다. 하이브리드 연결 NEG 백엔드 서비스에 사용한 동일한 상태 확인을 새 백엔드 서비스와 연결합니다. 새 원격 엔드포인트가 정상인지 확인합니다.
4. 하이브리드 연결 NEG를 포함하는 이전 백엔드를 대체하여 새 백엔드 서비스를 참조하도록 라우팅 규칙 맵을 업데이트합니다.
5. 프로덕션 배포에서 라이브 마이그레이션을 수행하는 동안 제로 다운타임이 필요하면 가중치 기반 트래픽을 사용할 수 있습니다. 처음에는 트래픽의 일부(예: 5%)만 수신하도록 새 백엔드 서비스를 구성합니다. 트래픽 분할 설정 안내를 따르세요.
   1. 새 원격 엔드포인트가 트래픽을 올바르게 제공하는지 확인합니다.
6. 가중치 기반 트래픽 분할을 사용하는 경우 새 백엔드 서비스가 트래픽을 100% 수신하도록 구성합니다. 이 단계에서는 이전 백엔드 서비스를 드레이닝합니다.
7. 새 백엔드가 문제 없이 트래픽을 제공하는지 확인한 후 이전 백엔드 서비스를 삭제합니다.

문제 해결

배포 문제를 해결하려면 이 섹션의 안내를 따르세요. 이 정보로 문제가 해결되지 않으면 Envoy를 사용하는 배포 문제 해결을 참조하세요.

온프레미스 엔드포인트에서 트래픽을 수신하지 않음

엔드포인트가 트래픽을 수신하지 않으면 상태 확인을 전달하고 Envoy 클라이언트의 DNS 쿼리가 IP 주소를 일관적으로 반환하는지 확인합니다.

Envoy는 strict_dns 모드를 사용하여 연결을 관리합니다. 정상 상태인 모든 확인된 엔드포인트 간에 트래픽을 부하 분산합니다. 엔드포인트가 확인되는 순서는 strict_dns 모드에서 중요하지 않지만 Envoy는 반환된 IP 주소 목록에 더 이상 없는 엔드포인트로 트래픽을 드레이닝합니다.

요청이 온프렘 서버에 도달할 때 HTTP 호스트 헤더가 FQDN과 일치하지 않음

예를 들어 example.com 도메인이 전달 규칙의 IP 주소인 10.0.0.1로 확인되고 altostrat.com 도메인이 사용자의 온프레미스 서비스 엔드포인트인 10.0.0.100으로 확인되는 경우를 가정해 보겠습니다. NEG에 구성된 altostrat.com 도메인으로 트래픽을 전송하려는 경우

Compute Engine 또는 GKE의 애플리케이션이 HTTP Host 헤더를 온프레미스 엔드포인트로 전달되는 example.com(Host: example.com)으로 설정할 수 있습니다. HTTPS를 사용하는 경우 Envoy는 TLS 핸드셰이크 중에 SNI를 altostrat.com으로 설정합니다. Envoy는 클라이언트 TLS 정책 리소스에서 SNI를 가져옵니다.

이 충돌로 인해 요청이 온프레미스 엔드포인트에 도달할 때 요청을 처리하거나 라우팅하는 데 문제가 발생하는 경우 Host 헤더를 altostrat.com(Host: altostrat.com)에 재작성하면 됩니다. 이 작업은 URL 재작성을 사용하는 Cloud Service Mesh 또는 헤더 재작성 기능이 있는 원격 엔드포인트에서 수행할 수 있습니다.

덜 복잡한 또 다른 해결 방법은 Host 헤더를 altostrat.com(Host: altostrat.com)으로 설정하고 특수 주소 0.0.0.0을 전달 규칙의 IP 주소로 사용하는 것입니다.

Envoy가 여러 5xx 오류를 반환함

Envy가 5xx 오류를 과도하게 많이 반환할 경우 다음을 수행합니다.

• Envoy 로그를 확인하여 응답이 백엔드(온프레미스 백엔드)에서 수신되었는지 여부와 5xx 오류가 발생한 이유를 구분할 수 있습니다.
• DNS 쿼리가 성공했는지 확인하고 SERVFAIL 또는 NXDOMAIN 오류가 없는지 확인합니다.
• 모든 원격 엔드포인트가 상태 확인을 통과하는지 확인합니다.
• 상태 확인이 구성되지 않았으면 Envoy에서 모든 엔드포인트에 연결할 수 있는지 확인합니다. Google Cloud 사이드는 물론 온프레미스 사이드에서 방화벽 규칙 및 경로를 확인합니다.

서비스 메시에서 공개 인터넷을 통해 외부 서비스에 연결할 수 없음

Cloud Service Mesh에서 FQDN 백엔드를 사용하여 공개 인터넷에 있는 서비스로 트래픽을 전송할 수 있습니다. 먼저 Envoy 클라이언트 및 외부 서비스 간에 인터넷 연결을 설정해야 합니다. 외부 서비스에 연결하는 동안 502 오류가 발생하면 다음을 수행합니다.

• 올바른 경로, 특히 기본 경로 0.0.0.0/0과 방화벽 규칙이 구성되어 있는지 확인합니다.
• DNS 쿼리가 성공했는지 확인하고 SERVFAIL 또는 NXDOMAIN 오류가 없는지 확인합니다.
• Envoy 프록시가 외부 IP 주소 또는 비공개 GKE 클러스터가 없는 Compute Engine VM에서 실행 중인 경우 Cloud NAT 또는 아웃바운드 인터넷 연결을 설정하는 다른 방법을 구성해야 합니다.

오류가 지속되거나 다른 5xx 오류가 발생하는 경우 Envoy 로그를 확인하여 오류의 원인을 좁힐 수 있습니다.

서비스 메시에서 서버리스 서비스에 연결할 수 없음

Cloud Service Mesh의 FQDN 백엔드를 사용하여 서버리스(Cloud Run, Cloud Run Functions, App Engine) 서비스로 트래픽을 전송할 수 있습니다. Envoy 프록시가 외부 IP 주소 또는 비공개 GKE 클러스터가 없는 Compute Engine VM에서 실행 중인 경우 Google API 및 서비스에 액세스하려면 서브넷에 비공개 Google 액세스를 구성해야 합니다.

다음 단계

• 클라이언트 TLS 정책에 대한 자세한 내용은 Cloud Service Mesh 서비스 보안 및 Network Security API를 참조하세요.